みずほ銀のSTEPSは1988年に稼働を開始した。当時は、ATMの24時間稼働も、インターネットバンキングも、携帯電話を用いた振り込みサービスも存在しなかった。

表●みずほ銀行30の不手際
表●みずほ銀行30の不手際
本文中の太字にそれぞれ対応する
[画像のクリックで拡大表示]

 その後、これらのサービスを追加する一方、みずほ銀はバッチ処理の上限値の設定を、23年間一度も見直さなかった表-18)。

 さらに、携帯電話での振り込みといった新サービスを導入する際に、夜間バッチの負荷テストを行っていなかった表-19)。

 みずほフィナンシャルグループなどによるシステムに関する内部・外部監査が機能していなかった表-20)ため、こうした問題に気付くこともなかった。

 みずほ銀はシステム監査において、「システム運用管理体制」のリスクを最高レベルとしていない表-21)など、リスクの大きさを正しく把握することができていなかった。

 夜間バッチが異常終了した原因は、口座bの振り込みデータを振り分ける(分割する)処理で、上限値をオーバーしたためだった。ところが、みずほ銀のシステム担当者は夜間バッチのエラーメッセージを読み誤った表-22)。振り分け処理の上限値オーバーであったにもかかわらず、前日と同様に、明細退避処理でエラーが起こったと判断してしまった。

 みずほ銀のシステム担当者は16日午後7時20分から翌17日午前4時13分までの間に、明細退避処理の上限値を拡大するなどして、夜間バッチを再実行した。もちろん、それでは振り分け処理のエラーは解消しない。

 その後、原因が口座bの振り分け処理にあることを突きとめ、一時的に口座bのデータを除外した上で、夜間バッチを再実行した。その結果、17日午前5時20分に口座bのデータを除く15日分の夜間バッチを完了した。

操作ミスでデータ誤削除

 続いて口座bの処理を進めるにあたって、新たなミスが発生した。17日午後1時30分、夜間バッチの手動化によって未処理になっていた、不要データの削除処理を手動で実行した。ここで操作ミスがあり、必要なデータまで削除してしまった表-23)。

 みずほ銀がデータ喪失に気付いたのは、削除から9時間後の午後10時26分だった。そこから喪失データの特定に5時間、データの再作成に11時間を要した表-24)。そのため、口座bを含めた15日分の夜間バッチの完了は、さらに遅れた。