東日本大震災から３日後の２０１１年３月１４日、みずほ銀行はシステム障害を起こした。義援金の集中したのをきっかけに、振り込みの遅れや店舗でのサービス停止、ＡＴＭの取引停止などを連発、影響は日を重ねるごとに広がり、収束までに１０日を要した。みずほ銀行が大規模なシステム障害を発生させたのは、９年前の２００２年４月に続き二度目だ。なぜ失敗は繰り返されるのか。その理由はただ一つ。根本的な原因を究明し、対策をとっていないからだ。根本的な原因は、みずほ銀行とみずほファイナンシャルグループの歴代経営陣のＩＴ軽視、あるいはＩＴへの理解不足だ。みずほの経営陣はシステム障害の恐ろしさを分かっていなかった。そのため障害直後の初動が遅れ、対応が後手に回った。それから、情報システムを日々正常に動作させることの難しさを知らず、システム部門に無理なシステム運用操作を強いた。さらに、２０年以上前に構築した情報システムを使い続けるリスクを認識せず、老朽化した情報システムの刷新を先送りにしてきた。システムの全体像を見渡せる後継者の育成も怠った。こうした実態が、システム障害の影響拡大を招いた。みずほ銀行の西堀 利（さとる）頭取は２０１１年3月のシステム障害後の記者会見で、システム障害の原因について「人的ミス」と繰り返した。確かに、大規模障害を招いた直接の原因は、システム部門の不手際である。システム全体の仕様や機能をつかんでおらず、障害後はミスを重ねた。それが被害を拡大させたのは事実である。だが、根本的な原因は経営陣にある。人的ミスという言葉を借りれば、９年前のシステム障害を教訓にできず、二度目の大規模障害を引き起こしたのは、経営者の「人的ミス」にほかならない。
２０１１年３月にみずほ銀行で発生したシステム障害の経緯
３月１４日午前１０時１６分
テレビ局が番組などを通じて、東日本大震災の義援金への協力を呼びかけたところ、みずほ銀行中央支店に用意された義援金口座（以下、口座ａと呼ぶ）に振り込みが殺到した。みずほ銀行の勘定系システムに多数の振り込みデータが集まり、取引明細の件数が１日に格納できる上限値を超えた。取引明細の件数が上限値を超えた理由は、口座ａの設定を誤っていたことにあった。みずほ銀行は各口座について、格納できる取引明細の件数に上限値を定めている。上限値は、二種類の設定値の組合せによって決まる。一つは、口座が「個人」のものか、それとも「法人」扱いであるか。もう一つは、取引明細を通帳に記帳する「通帳口」か、記帳しない「リーフ口」かである。口座ａの設定は、格納できる取引明細の件数の少ない「個人・通帳口」であった。みずほ銀行は口座ａの開設手続きをしたのは２００５年９月のことである。この際、みずほ銀行は口座ａを「個人・リーフ口」にしていた。このままの設定ならば、取引明細が上限値を超えることはなかった。ところが２００７年１２月、テレビ局から「振り込み明細を通帳で把握したい」との要望を受け、「個人・通帳口」に変更していた。口座ａの取引明細が上限値を超える問題が発生したものの、この時点では口座ａ以外の処理にはほとんど影響がなく、顧客サービスも正常に動作していた。
３月１４日午後１０時７分
義援金の振り込みは、午後３時を過ぎても押し寄せ続けた。午後３時以降に受け付けた振り込み依頼は、翌日扱いとなる。これらの振り込みデータについては、夜間に一括して、翌日の振り込みに向けた準備処理をする。口座ａに対するこの一括処理が異常終了した。振り込みデータの処理件数が上限値をオーバーしたのである。情報システムの運用拠点で作業に当たっていたシステム担当者は、一括処理にも上限値が存在することを知らなかった。みずほ銀行のシステム担当者は、振り込み処理の一括処理が異常終了した時に勘定系システムが出力したエラーメッセージなどから、上限値の存在を突きとめ、その設定値を増やした。その後、一括処理を再実行してみたが、それでもまた異常終了してしまった。先の異常終了によって、一部の振り込みデータが欠落してしまっていたのだ。必要な振り込みデータがそろっていなかったため、処理が正常に終わらなかった。通常、情報システムにおいて、ある処理が異常終了したとしても、一部のデータが欠落することはない。ところが、みずほ銀行では一括処理のコンピューター・プログラムの作り方などに問題があり、あり得ないはずの出来事が起こってしまった。こうなると、欠落したデータを元に戻すまで、一括処理を完了させることができない。結果的に、このデータ復元に８時間を費やした。復元作業に時間を取られすぎたことによって、翌１５日の朝９時までに、店舗の開店に向けた情報システムの準備処理が間に合わない可能性が出てきたのだ。みずほ銀行の勘定系システムは、午前４時３０分から午前８時までの間に、店舗における日中の業務に向けた情報システムの準備作業を進める。
３月１５日午前３時３０分頃
システム担当者からシステム担当役員である萩原忠幸常務執行役員に障害の報告があった。最初のトラブル発生から１７時間かかった計算になる。システム障害時の緊急連絡にしては、あまりにも時間がかかりすぎた。システム担当者は、翌朝のオンライン処理に影響が及ぶ可能性が高まったために、萩原常務に連絡を取ったのであろう。
３月１５日午前５時
萩原常務は、店舗の営業が始まる午前９時までに「営業店端末」でオンライン処理が始められるよう、システム担当者に指示した。この指示の意味は、「一括処理よりもオンライン処理を優先する」ことであり、言い換えると、「異常終了している一括処理については、必ずしもオンライン処理の前までに終わらせなくても構わない」ということだ。つまり、萩原常務はこの時点で、一部の振り込み処理が予定日までに実行されないという、「部分的」なシステム障害を覚悟した。夜間の一括処理が終わらなければ、前日の午後３時以降に受け付けた口座ａへの振り込み処理ができないからだ。その代りに、店舗でのサービス開始が遅れることを防ごうと考えた。システム担当者は、一括処理の完了をあきらめ、オンライン処理の準備に入った。
３月１５日午前９時
店舗は開店したものの、融資や振り込みなど一部のサービスについて、開始することができなかった。オンライン処理の準備にてこずり、当初見込んでいた５倍の時間がかかったためだ。これらのサービスを開始できたのは、開店から１時間２５分後の午前１０時２５分のことだった。
さらにやっかいな問題が発生した。１５日に送信するはずだった振り込み３１万件が、すべて送信できない事態になったのだ。口座ａへの振り込みはもちろん、それ以外の振り込みもである。前日夜間の一括処理による送信準備をすべて完了しないと、翌日のすべての振り込みが送信できない仕組みになっていた。みずほ銀行のシステム部門は、１５日の午前５時に問題が顕在化するまで、口座ａとは何の関係もない振り込みについても送信できなくなるということを認識していなかった。
３月１５日日中
振り込みデータの未送信に気付くのが遅れた結果、「二重振り込み」も引き起こした。店舗では行員が営業店端末を使って、未送信となっている振り込みデータを一件ずつ送信し始めた。顧客企業における資金決済の不渡りなどを防ぐためである。この時点では、行員が日中に営業店端末を使って送信した振り込みデータについては、日中に送信することができた。行員が営業店端末を使って送信した振り込みデータは、未送信となっていた振り込みデータの一部である。これに対して、みずほ銀行のシステム部門は後日、未送信となっていた振り込みデータをそのまますべて送信した。これにより、行員が営業店端末を使って処理した振り込みについては、二重に送金されてしまった。店舗とシステム部門の連携不足が、二重振り込みを引き起こした。
３月１５日午後３時過ぎ
義援金の振り込みが再び急増した。携帯電話会社が、携帯電話を使った振り込みサービスによる募金を呼びかけたためだった。携帯電話会社向けの義援金口座（以下、口座ｂと呼ぶ）は、前日の１４日に振り込みが集中したテレビ局の口座ａとは関係ない。連絡ミスににより、携帯電話会社からの連絡が、システム全体を統括するみずほ銀行のシステム部門に伝わらなかった。その結果、振り込みの急増に備えた手を打てなかった。
３月１６日午前７時１７分
振り込みデータの処理件数が上限値をオーバーする問題が再び発生し、一括処理が異常終了した。異常終了の発生の時間が前日より遅いのは、前日に異常終了した振り込みデータの一括処理を優先していたからだ。「前日に続き、営業店端末の準備作業が午前９時までに終わりませんが、一括処理の完了を優先させたいと思います」と、萩原常務は西堀頭取に報告し、西堀頭取はこれを了承した。
３月１６日午前８時
システム障害はついに、店舗に設置したＡＴＭの停止にまで広がった。ＡＴＭを起動する際に必要な準備処理をシステム担当者がうっかり忘れたのが原因である。みずほ銀行は、この日のような状況の時に使える異常時のシナリオ（運用マニュアル）を用意していなかった。営業店端末を使った取引開始は、午前１１時１２分まで遅れた。さらにこの日から、みずほ銀行にが他行から受け取った振り込みデータについても、振り込み先の口座に対する入金処理ができなくなった。
３月１６日午後７時２０分から翌１７日早朝
異常終了したままになっていた１５日分の一括処理を再実行した。それでも、１７日午前５時２０分までに、一部の一括処理しか完了しなかった。この間、システム運用のミスによってＡＴＭが止まるシステム障害が再発し、一括処理の実行が遅れたことなどが原因だ。
３月１７日午前５時３０分
一括処理を中断し、店舗におけるオンライン処理の準備作業に移った。しかし、ＡＴＭ障害の復旧対応などに手間取り、午前９時の開店までに間に合いそうもないことが分かった。システム担当者が、営業店の開店準備作業に集中できるようにするため、営業店の開店準備作業が終わるまでの間、すべてのＡＴＭを停止することにした。
３月１７日朝
みずほ銀行は「午前８時３０分現在、ＡＴＭが利用できない状態になっています」と、システム障害が発生していることを正式に発表した。併せて、合計５７００億円分の振り込みが未処理になっていることを公表した。
３月１７日午前１０時４６分
営業店端末を稼働させ、６分後の午前１０時５２分にＡＴＭを稼働させた。
３月１７日午後１時
記者会見を開き、西堀頭取は「システムの正常化には時間がかかりそうです」と述べた。その後のシステム障害対応について、「これまでは、夜間の一括処理と、オンライン処理の両方を正常化させようとしていました。今後は窓口業務などのオンライン処理を一部制限して、未処理の一括処理を優先させます」と述べた。
３月１７日午後５時２０分
４時間強（午後５時２０分〜午後９時３６分）にわたってＡＴＭが再び全面停止した。システム担当者が毎日必ず実施しなければならない操作を忘れたのが原因だった。勘定系システムでは、取引が発生するたびにそれをデータとして記録しているログファイルが、あらかじめ決められた容量に近づくと、ファイルの中身を別の保存用ファイルにコピーしてから元のファイル（ログファイル）の中身を削除しなければならない。この、コピーと削除の操作が漏れ、新たに取引を受け付けることができなくなってしまった。
３月１７日午後１０時４６分
携帯電話会社からの振り込みが集中した口座ｂにつて、一部の振り込みデータがなくなっていることが判明した。処理が完了したデータや、コピーが終わったデータなど、不要になったデータの削除命令を入力したときにミスがあり、必要なデータまで削除してしまった。なくなったデータの特定に５時間、データの再作成に１１時間を要した。このため、口座ｂを含めた１５日分の一括処理の完了は、さらに遅れた。これによって、１８日までシステム障害の影響が続くことが決定的になった。１８日には、２０日付けの給与振り込み処理を大量に実施する予定が組まれていたからだ。
３月１８日
一括処理が滞り、１８日に入金予定だった６２万件の給与振り込みができなかった。振り込まれなかった金額は、合計１２５６億円に達した。この時点で、積み残し分を含めた未処理の振り込み件数は１００万件を超えた。
これを受けて、みずほ銀行は二つの決断を下す。
一つは、情報システムの計画停止である。システム担当者と勘定系システムの処理能力を障害対応に集中させる」ため、１８日からの５日間店舗外ＡＴＭやインターネットバンキングなどのサービス停止を決めた。さらに１９日からの３連休の間は、全国にあるすべてのＡＴＭを動かさないことにした。
もう一つは、３連休はすべてのＡＴＭを止める代わりに、店舗を開けて預金者に特別対応を実施することにした。特別対応とは、現金の引き出しを望む預金者などに対して、口座残高が確認できなくても、１０万円まで支払うというものだ。みずほ銀行は、支払いを受ける人には、氏名や勤務先、電話番号などを聞き、対象口座のキャッシュカードの提示を求め、現金を支払うことにした。５月１３日の２０１１年３月期の決算発表時点で、みずほファイナンシャルグループでは４億円（４０００人分）の未回収が生じていると明かした。
３月１８日夜
みずほ銀行の西堀頭取は記者会見で「２２日までにシステムの正常化を目指す」と力を込めた。２２日という日付を挙げたのは、次の給与振り込みの山場である２５日を見すえてのことだ。
３月１９日午後７時５分
１５日分の一括処理を完了させるなど、ある程度は復旧させることができた。それでも積み残した一括処理すべてを解消するには至らなかった。
３月２１日午後１０時
連休明けの２２日朝までに全面復旧できないことが確実になった。これを受けて、西堀頭取は２２日以降も一部のＡＴＭやインターネットバンキングのサービスを引き続き制限することを決めた。２２日は正午まで振り込み関連のサービスなどを停止し、夜間に実施していた一括処理を午前中に実行することにした。
３月２２日夜
夜間の一括処理から、システム運用を正常化することができた。みずほ銀行は、システム障害の解消にメドがついたことから、店舗とＡＴＭともに２３日朝から営業を開始すると発表した。
３月２３日
積み残しになっていた振り込み１６万件をほとんど処理することができた。ただし、このうち１０００件については、翌２４日に入金が延びた。
３月２４日
振り込み処理の積み残しを完全に解消できた。１４日のシステム障害発生から１０日後のことであった。１０日の間に、入金が遅れた他行宛振り込みは合計１２０万件、他行からの振り込みは１０１万件に上った。
みずほ銀行は、システム障害特別委員会がまとめたシステム障害の報告書を５月２０日に発表した。
