東証のシステム障害から考察するBCP

• システム開発 経営
• 2021年5月26日

2020年10月1日、東証の株式売買システム「arrowhead」で大規模なシステム障害が発生しました。

何が問題だったか！？

東証の問題点は2つに整理できます。
1つは障害の原因となったNAS（Network Attached Storage）に関して必要なテストを実施していなかったために設定ミスに気づかず、バックアップのNASへ自動切り替えができなかったこと。
もう1つが、証券会社との間で取引の再開ルールが未整備であったため、NASに切り替えに成功したにもかかわらず、終日の取引停止を決断せざるを得なかったこと。

前者の問題について、テストを実施、あるいは要求しなかった東証の責任も免れませんが、大本の責任は富士通にあります。
しかし、この手の切り替え失敗は比較的よくあることであり、今回の障害では午前9時26分の段階で強制切り替えに成功し、いつでもシステムが再起動できる状態にありました。

後者の問題について、東証の経営責任が厳しく問われなければならないのは確かだと思います。
ただし、システム障害発生時点の東証経営陣の対応は十分に合格点でした。
終日停止の決定は、証券会社との間で取引の再開ルールが未整備である以上、予期せぬトラブルが連鎖し株式市場に大混乱が生じるのを避けるために正しい判断でした。
事態を悪化させずに極小化するダメージコントロールとして評価してよいと考えます。

終日の取引停止へ

とはいえ、取引の終日停止を決断せざるを得ない状況を生み出したのは東証自身です。
証券会社との間で取引の再開ルールが未整備のまま放置していたのは、経営としての重大な落ち度であると言えます。
東証は社内手順の範囲ではBCP（事業継続計画）を整備していたはずですが、証券会社などとの間では、システムを相互に接続して密接に連携しているにもかかわらず、全体を包含するBCPに抜けがあったということになります。

コロナ禍におけるBCP

当社では以前からBCPを策定していましたが、これまでおもに大規模災害を想定しており、感染症対策はあまり考えられていませんでした。
従来は人が動けることを想定してBCP対策を策定していたので、新型コロナで人の移動が制限され、BCPが実態にあわなくなったと感じています。
BCPは策定がゴールではないので、普段の訓練と課題抽出、判断プロセスの明確化、代替機を使う場合の業務運用など、踏み込んだ設計が重要と考えます。

飯田

大学では経済学を専攻。卒業論文でIT革命について執筆。
就活でPCを触ったぐらいの経験で中堅SIerに入社。
新人のころは主にテスト担当、その後Java言語での開発を経験。
現在のメインはマネジメント業務全般。
好きなもの：スポーツ全般、ライブ・フェスに行くこと
愛読書：週刊少年ジャンプ（マッシュル、僕とロボコ推し）

関連記事