みずほ銀行障害の原因分析と対応策

11月26日にみずほ銀行とみずほフィナンシャルグループに対して金融庁からの業務改善命令が発せられました。そこで、改めて、みずほ銀行の障害に関して、システム関連での原因と今後の対応策を、公開情報をベースに纏めてみました。
Ⅰ．原因
第一に、MINORIのアーキテクチャの複雑性、第二に保守運用フェーズでのリソース削減が急であった事、第三にIT現場と経営のコミュニケーションが不十分だったこと、第四にシステム関連の銀行組織、開発会社、運用会社が連携しにくい体制であること、第五に機器の所有を各ベンダーとしたこと。
１）MINORIのアーキテクチャの複雑性
大規模システムでは、マルチベンダーとなることは不可避である。マルチベンダー自体が問題ではない。むしろ勘定系システムの本体部分が、4つの異なる基盤システムで構成されている点が問題である。
それぞれのOSも異なり、データベース管理システムも異なっている。それぞれの専門家はいても、その相違点を十分に理解できる専門家はほぼいないのではないか。基盤を跨る障害に対応するためには、両方の専門家が参画する必要があり、対応スピードがどうしても遅くなってしまう。特に社内にスキルの高い専門家が常駐していれば良いが、そうでないと更に対応スピードは落ちてしまう。第二の原因によるリソース削減で、スキルの高い専門家は常駐していなかったと推測される。
２）保守運用フェーズでのリソース削減が急であった事
大型プロジェクトの場合、リリース直後に障害が発生する。みずほ銀行のシステムリリースは実質的に2019年2月だった。それから約2年たって、システム障害が発生したことに着目すべきである。有識者であるベンダーの人材をそれまでは引き留めていたが、コスト圧縮策の中で、引き留めができなくなり、十分な引継ぎもできず、障害の予兆能力や障害発生後の対応力が低下したと考えられる。
３）IT現場と経営のコミュニケーションが不十分だったこと
経営者とシステムの開発現場のリスク感覚に関する意思疎通ができていなかったことにあるのではないか。現場の状況を経営トップに伝えるのがCIOの一つの役割だが、CIOがシステムの事情に精通していなかったため、経営トップ側の代弁者の機能のみとなり、現場視点の適切な進言を経営トップにすることができなかったのではないか。その結果、２）のように、現場感覚ではリスクが高まるレベルまで人員やベンダーへの支払いを削減してしまったのではないかと考える。
6月のシステム障害調査報告書でも、114ページから116ページにかけて、アンケート調査やホットラインで受け取った意見がまとめてあり、そのことが裏付けられる。
４）システム関連の銀行組織、開発会社、運用会社が連携しにくい体制や伝達方法であること
みずほ内部が、みずほ銀行と開発子会社の二層構造になっている点や、開発会社（みずほリサーチ＆テクノロジーズ）と運用会社（MIDS）の資本関係が異なる点等、組織的に複雑であり、スムーズな連携を阻害している可能性がある。またIT子会社の再編により、保守体制が弱まった可能性がある。一つは、2020年6月に日本IBMの資本を入れた運用会社を設立したことである。もう一つは、2021年2月から3月の4件の障害にもかかわらず、2021年4月に、システム開発を行う子会社だったみずほ情報総研が合併により、みずほリサーチ＆テクノロジーズを設立した点である。
更に、障害発生時の運用会社でのエラーメッセージの検知体制や、運用会社から開発会社への伝達方法が、印刷したうえで電話での口頭の連絡によるなどアナログ的な手法であったことで、大量のエラーが発生した場合の対応が不十分になる素地があった。
５）機器の所有を各ベンダーとしたこと
機器の故障が多い点と、MINORIは35万人月で4000億円台の投資とされているが、投資に機器のコストがほとんど入っていない点とに注目する。機器については、ベンダーの機器を借りている形態で、毎年使用料を払っている形になっているようである。様々なハード機器関連のテスト、障害訓練を自由に行うためには、基本料金以外の追加の費用が発生するため、開発現場ではそのようなテストや訓練を最小限に絞っているのではないか。そのため、機器の故障に際しては、みずほ内部の人間は全く手も足も出ず、ベンダーにお願いする以外方策がないのではないか。しかし２）で説明したように、ベンダーへの保守コストを削減しており、常駐するベンダー担当者のスキルレベルはあまり高くなく、リカバリーに手間取ったのではないか。
Ⅱ．対応策
第１に、システム部門の現場の構造を改善して、ベンダー・開発会社・運用会社・みずほ銀行、みずほFGの一体運営する体制を策定することが望まれる。
特に、みずほ銀行と開発会社の司令塔の一元化、運用会社から開発会社への情報伝達の自動化や改善が喫緊の課題ではないか。
第２に、システム部門のスキルアップと、MINORIのアーキテクチャへの習熟が必要ではないか。MINORIの機能を修得する研修や、障害を想定した、ベンダー、開発会社、運用会社、みずほ銀行、みずほFG、経営まで巻き込んだ訓練の定期的な実施が望まれる。
第３に、経営陣とシステム部門の現場の意思疎通の活性化策を取る必要がある。
CIOが経営陣の代弁者としてだけでなく、IT現場の代弁者として機能するように、するべきである。内部監査部門もこの点を意識した監査を行ってこれを支援することが望ましい。
第４に、アーキテクチャをレビューする組織や体制を強化することが必要ではないか。
複雑なアーキテクチャをこれ以上複雑にしないように、新規開発のアーキテクチャを計画段階でチェックすることが必要である。
第5に、システム部門に過度のプレッシャーをかけないために、経営陣がATMの限定的な停止のような障害（3月3日事案、8月23日事案、9月8日事案）は、今後も十分起こる可能性があることを宣言してしまうことも必要ではないか。