連続して発生したシステム障害
その後もみずほ銀行では、同年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日にもトラブルが発生した。
このみずほ銀行の連続障害の原因を掘り下げていくと、次の五点に集約できるのではないかと考えられる。
第一に、MINORIのアーキテクチャの複雑性、第二に、保守運用フェーズでのリソース削減が急であったこと、第三に、経営とIT現場とのコミュニケーションが不十分だったこと、第四に、システム関連の銀行組織、開発会社、運用会社が連携しにくい体制であること、第五に、機器の所有を各ベンダーとしたことが挙げられる。順に見ていこう。
MINORIのアーキテクチャの複雑性
大規模システムでは、マルチベンダー（多数のITベンダー企業が開発を分担すること）となることは不可避である。マルチベンダー自体は問題ではない。むしろ勘定系システムの本体部分が、四つの異なる基盤システムで構成されている点が問題である。
それぞれのOS（Operating System、基本ソフトウェア）も異なり、データベース管理システムも異なっている。それぞれの専門家はいても、その相違点を十分に理解できる専門家はほぼいないのではないかと考えられる。基盤をまたぐ障害に対応するためには両方の専門家が参画する必要があるが、そうなると対応するスピードはどうしても遅くなってしまう。特に社内にスキルの高い専門家が常駐していればいいが、そうでない場合、対応スピードはさらに落ちてしまう。第二の原因によるリソース削減で、スキルの高い専門家は常駐していなかったと推測される。
