プロジェクトオーガナイザの吉田聖書です。
去る10月1日、
東京証券取引所のシステム障害で
全銘柄の取引が終日停止されました。
今回は、システム開発経験者として
思うところを書いてみたいと思います。
最初は当日の午前中にSNSで知りました。
東証の記者会見もアーカイブを見ましたが、
個人的には珍しいタイプのトラブルだなと思いました。
というのも、記者会見での情報によると、
危機の故障によって実際に影響が出たのは
取引のためのシステムではなかったからです。
株価情報を社外に配信するシステムや
取引を監視する業務システムが
起動しなかったと説明がありました。
恐らく取引そのものは継続できたのだけど
多くの混乱を招くことが想定されるから
ということでネットワークを遮断して
取引を停止したということなのでしょう。
この一連の対応について記者から出た
「今回の対応はBCPに基づくものか」という質問に
真正面から答えてはいなかったので、
恐らくBCPに基づく対応ではなく、
その場での判断だったと思われます。
この決断をマスコミは叩きましたが、
SNSでは英断だと称える意見を多く見かけます。
記者会見での発表は10分程度で終わり
その後の質疑応答が90分も続いた訳ですが、
延々と同じような質疑が繰り返されるのを聞いていて
如何に記者たちがシステムを理解していないかが分かりました。
システム開発を経験した立場で言うと
東証の説明はすごく分かりやすかったです。
事象もそれほど複雑ではありませんでしたし。
こういうことが起こるとよく言われるのが
「今回の事故は防げなかったのか」
ということ。
言うのは簡単ですけど、
個人的には防げなかったと思います。
ただ、どこまで想定できていたのかと言えば、
おそらく今回の事象は想定していなかったのではないかとも思います。
何故そう思うか。
今回の事象は、自動フェールオーバーに失敗したということです。
そして、自動フェールオーバーのテストは実施して
問題なく自動で切り替わることを確認していたということです。
システムを開発する立場としては、
テストでうまく行った機能に関しては
実運用でうまく行かないことを想定しません。
想定しなくても済むように
充分なテストを行うという側面もあるのです。
それが怠慢なのかと言うとそうでもなく、
予算もスケジュールもある中では
妥当な判断をしたのだろうと思います。
迅速に影響範囲を見極めて取引を停止した
――市場参加者には堪らないかも知れませんが
更なる惨事も想定できただけに
次善の策としては良かったのではないでしょうか。
事故が起こって良いとは思いませんが、
技術の進歩に事故はつきものです。
現在の安全な建築や安全な交通のために
どれだけの尊い犠牲が払われたか
ということを思い起こす必要があります。
今回の例で言うと、
自動フェールオーバーのテストはうまく行きましたと。
では、テストの時、
どうやってトリガーを引いたのでしょうか。
パっと思いつくのが例えば片方の電源を落とすなどですが、
それ以外にも考え得るパターンはあると思います。
ただ、実際にはリソースの制約から
考え得る全パターンを試すことはしないかもしれません。
逆に、自動フェールオーバーが失敗するケースとして
どのような理由が考えられるのかということは、
今回の事故を契機に研究が進むことを期待します。
その考えられる理由をすべて潰していけば、
それが業界の知見となり、
新しい技術が生まれるかもしれません。
（いや、そもそも自動フェールオーバーだって
素晴らしい機能だと思いますけどね。）
それでも、外野は騒ぎますが、
騒ぎたい人には騒がせておけば良いと思います。
レアケースだと起こる前に気付くというのは難しい。
「後知恵」では何とでも言えるのです。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。