発生した問題3）気づけたはずのチャンスを活かせなかった

大事故というのは突然やってくることもありますが、大抵の場合は、予兆があるものです。事実、A事案でも予兆がありました。ですが、その予兆に気づく人はいませんでした。具体的には、システム上のある指標が異常値を示していたにもかかわらず、担当チームがそれを見逃していたのです。調査報告書では「確認はしたものの対応の必要性を認識していなかった」とも指摘されています。いったい、なぜそのようなことが起こったのでしょうか。

「障害が起こるとしたら、この辺りでまず異常が検知されるはずだから、気をつけよう」という意識がなかった。A事案での「この辺り」とは「システムの使用量」、「異常」とは「システムの容量が不足気味であるというエラーメッセージ」に該当する。システム設計段階においても処理本番当日の段階においても、該当リスクに気づける知見のある担当者が不在だったせいもあり、こうした認識がなされていなかった。

原因1）に加えて、監視を担当していた技術者が、システムが示した異常値の持つ意味を正しく理解していなかったため「異常」という判断ができなかった。

「取引が集中する月末に行う処理であったこと」「大規模な処理（45万件）であったこと」からそこに大きなリスクが存在することを想定できたはずだが、通常の監視体制とあまり変わらない体制で変更処理を行なった。原因1のリスク認識力不足・意識不足もさることながら、作業リスクの過小評価が、監視の甘さに繋がった可能性は否めない。

発生した問題4）思わぬボトルネックにより対応が大きく遅延した

前編で、BCPを始動させるには「第一報が大事である」という話をしましたが、同じく「活動上のボトルネックをできる限り排除すること」も重要です。A事案では、システム障害の影響期間が約1.5日間という、「止めてはいけないサービス」にしては非常に長い期間停止を余儀なくされたわけですが、その原因となったのが2つのボトルネックでした。1つは「①対応要員がボトルネックになった」というものです。では、どうして対応要員がボトルネックになってしまったのでしょうか。

該当システムの調査を行える技術担当者は（特にリモート環境下では）24時間365日の常駐が前提にはなっておらず、営業時間外は「駆けつけ対応」となっていた。今回の障害は「駆けつけ対応」が必要なものであったため、対応要員である技術担当者の到着を待つ間、原因特定作業がかなり遅延することとなった（該当システムのエラー検知は9時50分、対応要員の現地到着が14時、作業完了が16時22分）。

また、2つ目は「②大量の情報処理がボトルネックになった」というものです。次のような原因が指摘されています。

システム監視をしていた委託先の現場オペレータは2名のみ。大量のメッセージが極めて短時間のうちに生じた場合の手続きは、監視員が一画面に34メッセージまでしか閲覧できない仕様となっている画面をスクロールしながら目視で確認した上、初報とすべきエラーメッセージを抽出して印刷した上で関係者に連絡を入れることになっていた。

さらに、部品故障が7時間のシステム障害に繋がったD事案では「③部品保守の役割を担うベンダーがボトルネックの1つになった」ことがわかっています。事実、ベンダーに部品交換指示を出したのが0時34分、現場に駆けつけたのが2時8分、交換完了が3時50分。このようにシステム障害時間全体の4割をそこで消費しています。その原因の一つには、次の点が挙げられています。

ストレージの保守を担当する株式会社日立製作所と MHBK の間において、障害発生時の具体的な復旧時間に関する取り決め等がなかった。

発生した問題5）復旧対応の進め方を誤った

肝心の復旧対応にいくつかのミスがあり、これが顧客への影響を長引かせた要因にもなりました。ミスは、システム復旧に直接従事する現場だけでなく、間接的な対応を行うチームでも起きました。システム復旧に直接従事する現場で起こしたミスとは、文字どおり「①誤ったシステム復旧手順をとってしまった」というものです。なぜ、そのようなことが起きたのでしょうか。

「ある手続きを手動で再実行すべきであったにもかかわらず、それを実施しなかった」「システムの障害状況に合わせて、とるべき復旧手順が決まっていたのに、その手順をとらなかった」という復旧作業者によるミスがあった。これらによって復旧までにより時間を要する結果となった。復旧作業者のスキル不足によるところも否めない。

整備済みの手順書では対応できない事態に見舞われ、技術者が現地に駆けつけることとなった。「システムの再起動」が必要だったが、技術者はそれがわからず現場で右往左往した。この点に関して、復旧手順書の記述が十分ではなかった。

「復旧対応の進め方を誤った」という観点で次に問題だったのは、「②システム復旧に直接従事する現場以外の対応が緩慢だった」というものです。極端に言えば、有事下にも関わらず必要以上に「待ち」の状態を作ってしまったということです。どうして緩慢になってしまったかという点については次のような原因が考えられます。

先述のとおり、現場で採用されたのは誤った復旧手順だった。一方で、顧客対応を推進する組織などの他部門は、現場によるシステム復旧を待つばかりだった。そのため、「復旧が顧客業務開始時間に間に合わないかもしれない」ということを念頭に置いた、組織としての大局的な検討・行動がみられなかった(そして、実際に間に合わず、間に合わないことが判明してからの後手後手の対応となった)。

いかがでしたか。170ページ近い調査報告書を簡潔にまとめましたが、問題は5つあったため、長文になりましたね。そこで改めて本稿で取り上げた「学び」を再掲します。
※学び1～2は前編で解説

→「トラブルの発生が、いかに人の視野を狭くしてしまうか」を認識すべし

→「通報（アラート）は投げればOK、という単純な話ではない」と認識すべし

→「要所要所のリスクアセスメントを蔑ろにしてはいけない」と認識すべし

→「訓練をしてみなければ発見できないボトルネックは多い」と認識すべし

→「『最悪の事態』の想定が最大のリスクマネジメントになる」と認識すべし

この「学び」を見て、お気づきになった方もいらっしゃると思います。これらは、システム担当者やIT-BCPに関わる人だけに役立つものではないのです。ここでの「学び」は間違いなく、IT-BCPを考える方にも、それ以外の地震・津波災害、火災・爆発事故などさまざまな有事対応を考える方に当てはまる教訓ではないでしょうか。

もちろん、冒頭でも申し上げましたが「組織風土の問題」も置き去りにしないようにしていただければと思います。

本稿を通じて、今回の調査報告書にはこうした「学び」があること、そして、他社の痛みを「自分ごと」として捉え真摯に向き合うことがとても大事であるということ、この2つがみなさまに伝われば目的を果たせたというものです。これをきっかけにみなさまの企業がより強くなることを願っております。