みずほ、全銀と銀行の大きな障害事件が続く。そしていつも同じコメントや謝罪がトップから出され、そして数年経てばこのような反省は忘れられ再び危険に晒されることになる。
わたしがNTTデ本のちにNTTDATAに勤務し1970年代にSEとして銀行システム開発に携わり、1980年代にはドコモ（当時関西移動通信）基幹システムの開発リーダーを務めた経験からこうした大障害は現在の開発体制や経営体制で今後も繰り返され、金融庁が行政指導し、経営陣が頭を下げるシーンを見続けることになるだろうと思う。（金融庁と銀行トップの茶番といえば言い過ぎだろうか）
さらに現在急速に進展するAIの危機管理も抜本的な危機管理がなされない限りさらに大きな大惨事を引き起こすに違いないと思う。
なぜこうした大障害が発生するのか。そしてAIには現在以上の規模の大災害が防ぐ方法はあるのか。
経営者にはシステム開発の現場はブラックボックス化しているので銀行の開発チームに任せるしか方法がない。銀行の開発チームは専門家集団だが、だからこそシステムにはバグが宿命的に付き纏うことを知っている。さらに銀行の開発チームは自らプログラミングをせず大規模なシステム請負集団に任せることになる。
最終段階でテストが行われるが１００％網羅的なテストは今でも不可能だろう。テストランのケースが無限に近くありその全てをチェックすることは不可能なのだ。さらにテスト中にバグが見つかるのは普通だが、すると理論的にはバグ修復後に再度バグ修復が影響する全てのテストランを繰り返さなければならない。
バグ修復後に再度バグ修復が影響する全てのテストランといえば限定的に聞こえるが実際は全てをチェックすることになる。システムが系として存在する以上そうなる。しかしコスト的にあるいは納期的に間に合わないので適当なテストでGOを出すしかない。開発リーダーにとっては重圧のため体を壊す人が続出する。
そう言う脆弱な危機管理の上に今でも大規模システム構築は成り立っているのだと40年前のシステム開発者は思う。
現在急速に進展するAIに対する危機管理に警鐘を鳴らしている気がしてならない。AIにも抜本的な危機管理がなされない限り、近い将来にさらに大きな大惨事を引き起こすに違いない。投資家や経営者は利益を追求するためにコスパで開発を行うのは当然といえば当然で責められることはない。あとで頭を下げれば良い、あるいは辞職するリスクを負うだけだ、監督官庁は指導等の処分で気が済む。
ブラックボックスのAIが引き起こす惨事を想像したくない。巨大な課題に立ち向かうにはまず想像力を働かせて議論を始めるべきだ。見てみぬフリは未必の故意になる。
2021年にみずほフィナンシャルグループ（FG）傘下のみずほ銀行が複数回にわたり大規模なシステム障害を起こした。
事態を重く見た金融庁は業務改善命令を出し、みずほFG、みずほ銀のトップら3人が退陣する事態に発展した。【金融庁が指摘する「真因」】システムに関するリスクや専門性の軽視、IT現場の実態軽視、顧客影響に対する感度の欠如、営業現場の実態軽視、言うべきことを言わない、言われたことだけしかしない姿勢
【その他の原因】勘定系システム「MINORI」の複雑さ
2011年3月のシステム障害は「勘定系のブラックボックス化」が原因
東日本大震災直後の2011年3月にみずほ銀行で発生した2度目の大規模システム障害は、勘定系システムにおける夜間バッチ処理でトラブルが生じ、オンラインにも影響が及んだ。夜間バッチ処理が1週間近く未完了になったり、何日もATMが使えなくなったりするほどの大規模システム障害は、日本の金融機関では他に例がない。
| 日時 | 発生事象 | |
| 7～9日（3連休） | 全銀システムと各金融機関をつなぐ中継コンピュータ（Relay Computer：RC）の更新作業を14行で実施 | |
| 10日 | 午前8時半ごろ | 業務開始するも不具合を検知 |
| 午前9時半ごろ | RCのシステムをリブート（再起動）するも復旧に失敗 | |
| 午前10時前 | 11行における障害発生を公表 | |
| 午後2時半ごろ | 代替手段による送金作業に着手 | |
| 深夜～11日未明 | プログラム改修による復旧を試みるも失敗 | |
| 11日 | 午後6時ごろ | 遅延した送金が255万件と公表 |
| 深夜～12日未明 | プログラム改修を再度実施し、復旧作業完了 | |
| 12日 | 早朝 | 復旧による正常稼働開始の目処を午前8時半と発表 |
| 午前10時ごろ | 正常稼働を確認、復旧を公表 | |
| 午後3時半ごろ | 遅延していた送金処理がすべて完了したことを発表 | |
| 13日 | 全銀ネットが金融庁より報告徴求命令を受領 | |