ライフ・マネー

なぜ、みずほ銀行でシステム障害が相次ぐのか【5つの理由】

ライフ・マネー　投稿日：2022.06.19 11:00FLASH編集部

写真：西村尚己/アフロ

　2021年2月28日、みずほ銀行の全国の店舗のATM5900台のうち、7割強に相当する4318台のATMが不稼働となった。それ以上に問題だったのは、取り引きを受け付けているにもかかわらず、突然、取り引きが中断し、通帳やキャッシュカードがATMの中に取り込まれたままになる事態が発生したことである。

　このような場合、備え付けの電話でATMセンターに連絡を取って対処することになっていた。しかし、当時ATMセンターのオペレータは8人程度しかいなかった。多くの店舗で同様の事態が一斉に発生したため、ほとんどの電話がATMセンターにつながらない状況となった。

　しかも2月28日は日曜日で、店舗自体も開いていなかった。顧客は止まってしまったATMが動き出し、カードや通帳が吐き出され、他の人の手に渡ってしまうのではないかと心配し、そこから離れることができなくなってしまった。

　みずほ銀行にとっては、2002年の合併直後のシステム障害、2011年の東日本大震災後の義援金振込によるシステム障害に次ぐ、3回目の大トラブルとなった。

　実は、2011年のシステム障害を機に新たに構築した新システムMINORIがみずほ銀行で2年前にリリースされて以来、約2年間、大きなトラブルはなかった。したがって、この新システムは安定的に稼働していると思われていたのだが、MINORIに関してはこれが初めての大きなトラブルとなった。

　その後もみずほ銀行では、同年3月3日に機器故障によるATMの障害、3月7日にプログラムエラーによる障害、3月11日から12日に機器故障による外為送金の遅延と顧客影響ある障害が連続して発生した。3月17日にはシステム障害特別調査委員会が立ち上げられ、6月15日にはその報告書の公表と合わせて再発防止策が公表された。

　一旦、障害に区切りがついたと思われたところ、8月19日から20日には機器故障によって全国の店頭業務ができないという障害が発生した。さらに8月23日にネットワーク不安定によるATMの障害、9月8日に機器故障によるATMの障害が発生した。

　9月22日、監督官庁である金融庁からは、みずほ銀行とみずほフィナンシャルグループに対して当面のシステム更改、および更新等の計画の提出を求める業務改善命令が発出された。

　9月30日には、システムの処理速度低下による外為送金の遅延の障害が発生した。11月26日には、金融庁から業務改善命令がみずほ銀行とみずほフィナンシャルグループに発出された。

　また、財務省から同日に9月30日の障害時の外為送金の取り扱いが、外為法上不適切であるとして是正措置命令が発出された。その後も12月30日、2022年1月11日、2月11日にもトラブルが発生した。

　このみずほ銀行の連続障害の原因を掘り下げていくと、次の5点に集約できるのではないかと考えられる。

　第1に、MINORIのアーキテクチャの複雑性、第2に、保守運用フェーズでのリソース削減が急であったこと、第3に、経営とIT現場とのコミュニケーションが不十分だったこと、第4に、システム関連の銀行組織、開発会社、運用会社が連携しにくい体制であること、第5に、機器の所有を各ベンダーとしたことが挙げられる。順に見ていこう。

■MINORIのアーキテクチャの複雑性

　大規模システムでは、マルチベンダー（多数のITベンダー企業が開発を分担すること）となることは不可避である。マルチベンダー自体は問題ではない。むしろ勘定系システムの本体部分が、4つの異なる基盤システムで構成されている点が問題である。

　それぞれのOS（Operating System、基本ソフトウェア）も異なり、データベース管理システムも異なっている。それぞれの専門家はいても、その相違点を十分に理解できる専門家はほぼいないのではないかと考えられる。

　基盤をまたぐ障害に対応するためには両方の専門家が参画する必要があるが、そうなると対応するスピードはどうしても遅くなってしまう。

　特に社内にスキルの高い専門家が常駐していればいいが、そうでない場合、対応スピードはさらに落ちてしまう。第2の原因によるリソース削減で、スキルの高い専門家は常駐していなかったと推測される。

■保守運用フェーズでの急なリソース削減

　大型プロジェクトの場合、リリース直後に障害が発生する。みずほ銀行のシステムリリースは実質的に2019年2月だった。それから約2年たって、システム障害が発生したことに着目すべきである。

　有識者である各ベンダーの専門家をそれまでは引き留めていたが、リソース削減策の中で引き留めができなくなり、十分な引き継ぎもできず、障害の予兆管理能力や発生後の対応力が低下したと考えられる。

■経営とIT現場のコミュニケーション不全

　経営者とシステム開発の現場のリスク感覚に関する意思疎通ができていなかったことも、大きな原因と考えられる。システム部門の総責任者をCIO（Chief Information Officer）という。CIOは本来、経営トップの方針をシステム部門に伝えることと、システム部門の状況を経営トップに伝える双方向の役割がある。

　しかしながら、2019年4月にみずほのCIOに就任した人物は人事や企画畑が長く、システムには精通していない人物だった。そのため、経営トップの方針をシステム部門に伝える役割だけが機能して、システム部門の視点での適切な進言を経営トップにすることができなかったと考えられる。

　その結果、システム部門の感覚では、リスクが高まるレベルまで人員やベンダーの要員を削減してしまったのではないか。

■連携しにくい体制、伝達方法

　みずほ内部が、みずほ銀行と開発会社の二層構造になっている点や、開発会社（みずほリサーチ＆テクノロジーズ）と運用会社（MIデジタルサービス）の資本関係が異なる点等、組織的に複雑で、スムーズな連携を阻害している。またIT関連会社の再編により、保守体制が弱まった可能性がある。

　さらに、障害発生時の運用会社でのエラーメッセージの検知体制や、運用会社から開発会社への伝達方法が、印刷したうえで電話での口頭の連絡によるなど、アナログ的な手法であったことで、大量のエラーが発生した場合の対応が不十分になる素地があった。

■機器の所有を各ベンダーとしたこと

　MINORIの開発規模は35万人月（1人の開発者が1か月で開発できる規模を「一人月」と言うが、その35万倍）、4000億円台の投資とされている。

　1人月100万円と仮定すると、それだけで3500億円となることから、投資には機器のコストがほとんど入っていないことになる。初期投資抑制の意味もあり、ベンダーの機器を借りている形態で従量制で使用料を払っていると思われる。

　また、様々なハード機器関連のテスト、障害訓練を自由に行うためには追加の費用が発生するため、開発現場ではそのようなテストや訓練を最小限に絞っていたとも考えられる。

　さらにベンダー所有であることからリカバリー手順書の管理もベンダーが行うため、機器の故障に際してはみずほ内部の人間は対応できず、ベンダーにお願いする以外方策がなかったと推測される。

　しかし先述したように、ベンダー要員を削減していたため常駐するベンダー要員のスキルレベルはあまり高くなく、リカバリーに手間取ったと推測される。

　これが、みずほでシステム障害が相次いだ5つの理由なのだ。