リスク管理Naviリスクマネジメントの情報サイト

みずほ銀行(MHBK)の大規模システム障害から、私たちみんなが学べること ~「調査報告書」が示す教訓~(前編)

掲載:2021年07月07日

執筆者:取締役副社長 兼 プリンシパルコンサルタント 勝俣 良介

コラム

去る2021年6月15日、株式会社みずほフィナンシャルグループ(MHFG)から「調査報告書」が公表されました。これは、子会社である株式会社みずほ銀行(MHBK)が同年2~3月にかけて起こしたシステム障害に関して、第三者委員会(*1)が取りまとめた調査結果とMHFGおよびMHBKが策定した再発防止策に対する評価および提言です。この報告書は「特定少数の限られた人が読めばいいもの」と済ませてしまうには、あまりにももったいない内容が書かれています。と言いますのも、ここに記載されている内容はどの企業にも重要な示唆をもたらすものであり、さらに言えば、IT関係者以外の人も学ぶべき教訓があるからです。本稿では、調査報告書から得られる学びについて、前編・後編に分けて解説します。

ただし、調査報告書は全167ページと非常にボリュームがある上、金融機関の基幹システムで起きた障害を扱っているため、知識がなくては読み解けません。ですので、本稿では、調査報告書の細かいテクニカルな部分をできる限り排除し、失敗事例の本質的な部分にスポットライトが当たるように解説することを狙いとしています。トラブルの本質はIT(システム)だけにあるのではないことがお分かりいただけるはずです。IT-BCPの観点から気づきを得たい人も、BCPやリスクマネジメントの視点から気づきを得たい人も、ぜひご一読ください。

*1 システム障害特別調査委員会

         

この報告書から得られる結論は何か

本稿は、報告書の豊富な情報からエッセンスを抽出しコンパクトにまとめたものの、長文ではあります。そこで初めに結論を「学び(1)~(5)」として示します。この結論を見て気になる箇所から読み進めるのも良し、この結論を踏まえながら最初から読むのも良しという構成になっています。
※学び3~5は後編で解説

学び1)「顧客対応が疎かになった」

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

学び2)アラートが届かなかった・アラートだと思ってもらえなかった

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

学び3)気づけたはずのチャンスを活かせなかった

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

学び4)思わぬボトルネックにより対応が大きく遅延した

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

学び5)復旧対応の進め方を誤った

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

注意事項を3点、申し上げておきます。1点目は、本来は「組織風土の問題」が最も大切なことですが、上記5つの学びにはあえて入れていないという点です。例えば、上記「学び2」に「(システム障害の)通報(アラート)は投げればOK、という単純な話ではない」を挙げていますが、そこに然るべき組織風土が備わっていれば、「おいっ、アラート、みんな受け取ってるか? これまずいんじゃないか!? レベル云々はともかく社長の耳に入れておくべきじゃないか!?」と臨機応変の対応ができ、問題が回避された可能性も十分にあります。ただ、「組織風土の問題」で片付けてしまうと、学びの機会が減ってしまうため、あえてその点を取り上げていないことを留意いただければと思います。2点目として、本稿はあくまでも公表された調査報告書を基に筆者の考えをまとめたものであるという点です。従って、報告書で触れられていない事実があればそこには限界が生じます。また、報告書にあった問題や原因の全てを細部にわたって取り上げていないことにご留意ください。あくまでもみなさまの学びにつながりそうなものに焦点を当ててまとめました。最後に、本稿は決して、障害を起こした組織や関係者の方々を非難する目的ではないことを強く申し上げておきます。むしろ、調査報告書を公開いただけたことは世の中のために有益であり、類似のトラブルを未然に防ぐことにつながります。

そもそもどんな障害を起こしたのか

障害の概要を簡単に説明します。2021年2~3月にかけて起きた事象は全部で4つあります(*2)。それぞれ次のようなものです。

A事案(2月28日) 約1.5日間にわたる大規模ATM障害
概要 約1.5日の間にATM内に顧客カードと通帳が取り込まれた事案が約5,000件発生した。MHBKが委託開発したサービス(e-口座案件)のシステムリリース直後に起きた。
直接的な原因 システムのメモリ使用容量オーバーフロー(キャパシティ予測ミス)

 

B事案(3月3日) 約3分間の小規模なATM障害
概要 勘定系システム等の機器の一部が故障し、バックアップシステムに自動で切り替わるまでの約3分間、稼働が不安定になり、顧客カードや通帳がATM内に取り込まれた事案が29件発生した。
直接的な原因 ネットワークカードの故障、および自動切り替えシステム上の致し方のない仕様

 

C事案(3月7日) 約3時間のカードローン案件プログラムのシステム障害
概要 カードローン商品の新機能リリース時に、データに予期しない編集が加えられ、処理エラーが発生。障害は約3時間続き、この間に入金処理エラーが約25件起きた。
直接的な原因 データを初期化するプログラムの初歩的な設計ミス

 

D事案(3月12日) 約7時間にわたるシステム障害に伴う送金処理中断・遅延
概要 送金処理に関わるシステムの機器の一部(ストレージ装置)が故障。バックアップシステムに自動で切り替わるはずがそのままダウンしてしまい、業務システムの停止を引き起こし、約7時間にわたって影響をもたらした。
直接的な原因 機器の一部(ストレージ装置)の故障と当該装置のバグ

 

*2 報告書では、これら4つの事案以外に同社が過去に起こした事案もカバーしていますが、本稿では「わかりやすさ優先」の観点から、この4事案に焦点を絞ります。

これらの事案からどう学びを得るのか

4事案のうち、影響の大きかったものはAとDで、それぞれ半日以上のシステム障害を引き起こしています。その背景には複数のミスが絡んでいます。C事案は3時間のシステム障害ですが、これにも学ぶべき点がありそうです。他方、B事案に関しては影響時間が3分と短く、その理由も「仕様上致し方なかった側面も否めない」ということで、報告書でも「大きな問題はなかった」と結論づけています。そこで、本稿ではA、CおよびD事案に焦点を当てて見ていきます。

事案からの学びを最大限に得るため、事案ごとに個別に分析・評価するのではなく、3つの事案(A,C,D)を類似問題(発生した問題)別に整理して総合的な「学び」を導き出していきます。問題は全部で5つに整理することができました。

確認された問題とそこから得られた学び

以下、全5つの問題とその原因、得られた「学び」について解説します。

発生した問題1)顧客対応が疎かになった

A事案に関する調査結果からは、「①障害発生から数時間経過後も、 ATMによる顧客の通帳・カード取り込みを社内で気にかける人はほとんどいなかった」ということが指摘されています。また D事案では、「②顧客への連絡を疎かにしたのではないか」という指摘がなされています。

では、どうしてこれらは起きたのでしょうか? まずは「①障害発生から数時間経過後も、 ATMによる顧客の通帳・カード取り込みを社内で気にかける人はほとんどいなかった」の原因から見ていきましょう。これについては主として2つの原因を挙げることができます。

①の原因1)そもそもお客様に大きな迷惑がかかっていると思っていなかった

どのような場合に顧客にどれだけの迷惑がかかるのか(≒通帳・カードがATMに取り込まれる条件等)を正確に理解していなかった。仮にATMに通帳・カードが取り込まれたとしても、専用対応オフィスがあるので対応できると考えていた。ゆえに障害発生当初、「ATMに通帳やカードが取り込まれてお客様が困る」と思いついた社員が少なかった。

実際は、ATMに取り込まれた通帳・カードは5,000件を超え、とても通常体制では処理できるものではなかったが、そもそもの処理能力件数が理解されていなかったため問題視されなかった(*3)。

①の原因2)理解不足があったにしても、顧客目線での情報収集意識が薄かった

社内ルール上、システム障害のランクや業務影響等を「一報」として経営陣を含む必要な関係者に報告することとされていた。しかし、主にエラー原因究明・復旧について優先対応した結果、ATMへの通帳・カード取り込み件数や呼損率(*4)といった顧客に直結する業務に関する情報の収集は、トラブル発生から2時間経過しても行われなかった。

 

次に「②顧客への連絡を疎かにしたのではないか」という指摘について。実際、D事案において、顧客対応部門は基本的にはシステム復旧を待つというスタンスであり、対応組織は早期に設置されたものの、翌日まで連絡を遅らせているのです。それはなぜでしょうか。

②の原因)顧客対応の合理性・効率性を優先させてしまった

顧客への説明の大部分が翌営業日に持ち越された理由は「中途半端にお客様へ連絡しては、システム修復後、誰に連絡を取っていた、もしくは取らなかった、などで対応が煩雑になることが想定される」というものだった。しかし、実際には一部の営業部員が個別に顧客に連絡していたケースもあり対応はチグハグだった。

問題1とその原因からの学び1)
「トラブルの発生が、いかに人の視野を狭くしてしまうか」を認識すべし

「①障害発生から数時間経過後も、ATMによる顧客の通帳・カード取り込みを社内で気にかける人はほとんどいなかった」と「②顧客への連絡を疎かにしたのではないか」の原因を導いてきましたが、共通しているのは「トラブルの発生が、いかに人の視野を狭くしてしまうか」という点です。たとえ「システム障害のランクや業務影響等を『一報』として経営陣を含む必要な関係者に報告すること」というように、事前に決めごとを設けてあったとしても、です。

その意味では、有事の行動の優先順位を明確化するとともに、有事対応の真っ最中にも、組織のトップから改めてそうした号令を明確に発信していくことが大事でしょう。また、どんなに慌てた状況下でも、「顧客のことだけを顧客目線で必死に考え続ける組織」というものをあえて設けておくのも有効な手段かもしれません。

 

*3 理論上の処理能力は1日224件だったところ、実被害件数は約5,000件だった
*4 通信回線(設備)の容量不足によって、通信または通話がつながらない割合

発生した問題2)アラートが届かなかった・アラートだと思ってもらえなかった

BCPなどの立派な行動計画があっても、それを実行する「のろし」が上がらなければ、あるいは伝わらなければ、意味がありません。すなわち有事対応においては「発見者による第一報」が重要な鍵を握るわけです。しかしながら、まさにその「第一報」でつまずいたのがA事案でした。「第一報」を極めて早い段階で受け取ったにもかかわらず、関係者の動きはやや緩慢なものでした。調査報告書のA事案に関する記述からは「①アラートをアラートとして認識してもらえなかった」様子が読み取れます。その理由は何でしょうか。

①の原因1)「第一報」の内容に、受け手が緊急性を感じなかった

「第一報」の文面の中に「監視システム上はATM正常稼働ながら…」という文言があったため、多くの人が深刻度は高くないと勘違いした。

①の原因2)「第一報」が持つ意味を、受け手が正しく理解していなかった

そもそも「第一報」が送られてくること自体がどれだけ深刻な意味を持つものかが、関係者の間で正しく理解されていなかった。平時から訓練も行っていたが、「第一報」メールの送受信を確認するなど形式的なものにとどまっており、メールそのものが持つ「深刻さ」を正しく伝えるものではなかった。

 

そして、致命傷となったのは、そもそも「②アラートが届くべき人に届いていなかった」という点です。組織のトップが障害発生から約6時間後にネットニュースを見て初めてその事実に気がついた、ということからもこの問題の大きさが伺えます。これは次の理由によるものでした。

②の原因)深刻さが明らかになった後も「インシデントレベル」が更新されなかった

障害発生から2時間が経過し、事態の深刻さがある程度明らかになった時点で「深刻なインシデント(上から2番目のランク)」と判断すべきだったが、それがなされなかったため、報告対象に含まれていないトップには連絡がいかない状態だった。

問題2とその原因からの学び2)
「通報(アラート)は投げればOK、という単純な話ではない」と認識すべし

本件は、いわゆる「のろし」が本来の役割を果たせなかったという一点に尽きます。私たちはどうしても、「何かあればアラートをあげればいい」と単純に考えてしまいがちですが、そこには落とし穴があります。

皆さんの組織では「アラートがアラートとして認識される」状態になっていますか。それを確認するには、単純に「第一報を受信できたかどうかの訓練」だけでは検証が不十分であることは明らかです。「アラートの発報者が本来伝えたかった意図」が「アラートの受信者に正しく伝わったか」という観点での検証が欠かせません。

また、アラートが届くべき人に本当に届くようになっていますか。本件では、報告が届くべき人に届くための大前提となるインシデントレベルに落とし穴がありました。それ以外にも、届いた人がそもそもそのメールに気づかないということもあるかもしれません。アラートが届くべき人に届くまでに、何がボトルネックになりうるのかを想像し、手を打っておくことが必要でしょう。

 

後編では、学び3~5について解説します。

後編に続く)

当社のWebサイトでは、サイト閲覧時の利便性やサイト運用および分析のため、Cookieを使用しています。こちらで同意をして閉じるか、Cookieを無効化せずに当サイトを継続してご利用いただくことにより、当社のプライバシーポリシーに同意いただいたものとみなされます。
同意して閉じる