失敗知識データベース‑失敗百選

みずほフィナンシャルグループ大規模システム障害【2002 年 4 月 1 日〜5 月初旬、みずほ銀行】
中尾政之（東京大学大学院 工学系研究科 総合研究機構）
第一勧業、富士、日本興業の3銀行のシステムを「みずほ銀行」として一本化するシステム
統合で、統合の方針決定が紆余曲折し、システム統合のスケジュール・統合作業が遅れて、予定していたシステム稼働テストの開始がずれ込み、十分な見極めができないまま開業したため、開業初日から現金自動預入払出機（ＡＴＭ）の障害が発生、さらに公共料金の自動引き落としなどの口座振替に遅延が生じるトラブルが起きた。トラブル発生後も対応が遅れるなどで、口座振替の遅延が拡大、大混乱となり最大級の大規模システム障害に陥った。
１．

事象
第一勧業、富士、日本興業の 3 銀行が再編して誕生した「みずほ銀行」は、営業初日(2002年 4 月 1 日)に現金自動預入払出機（ＡＴＭ）の障害が発生、さらに公共料金の自動引き落としなどの口座振替に遅延が生じるトラブルが起き拡大した。口座振替の遅延は 4 月 1 日だけで 105,000 件に達し、翌日以降の積み残しとなり、連鎖的に大量の未処理が発生、4 月 5 日には遅延数は 250 万件にまで膨張していった。それに付随したかたちで、約 3 万件の二重引き落としが発覚し、最大級の大規模システム障害に陥った。復旧を図るも、このトラブルで顧客の混乱が長期化、1 ヶ月以上も続いた。
２．

経過
1999 年 8 月 20 日、旧第一勧業、旧富士、旧日本興業銀行は、共同持ち株会社方式による経営統合を発表した。
1999 年 12 月、 個人・中小企業向け取引部門を担う現「みずほ銀行」の勘定系基幹システムを 2002 年 4 月に第一勧銀システムに一本化する「片寄せ方式」の方針を決定。
2000 年 9 月 29 日、持ち株会社「みずほホールディングス(HD)」設立。旧 3 行は持ち株会社の傘下に入った。
2000 年 12 月、当初案を見直し、勘定系システム一本化を 2003 年 4 月に延期し、それまでの間は旧第一勧銀のシステムを外部と接続するメーンシステムとし、旧富士、旧興業銀の勘定系システムをリレーコンピュータ(RC)で接続する暫定方式に方針変更した。
しかし、この旧第一勧銀の接続系の中で RC とやり取りするプログラムで、RC と論理的な接続経路を維持するために追加したプログラムに、特殊な条件が重なった場合に限って表面化するバグがあり、事前に実施した疎通テストや負荷テストでは検出出来なかった。
2001 年 5 月 10 日、 みずほホールディングス取締役会でシステム移行を実行計画として確定した。
2001 年 3〜6 月、金融庁はみずほグループの検査を実施、スケジュールの遅れ等システム統合の問題点を指摘した。
1

失敗知識データベース‑失敗百選

2001 年 12 月、月間 5 万件を超える大手取引先の口座振替データ振分け処理は、当初、旧興銀システムを引継ぐ「みずほコーポレート銀行」が担当する計画であったが、旧興業銀のシステムは大量処理に適していないため、旧第一勧銀システムを引継ぐ「みずほコーポレート銀行」で処理する方針に変更した。
また、口座振替を委託する企業に対し、2002 年 4 月 1 日から全国銀行協会フォーマットで口座振替データを持込む場合、旧富士、旧興業銀の「金融機関コード」を旧第一勧銀のコードに統一し、旧富士、旧興業銀の一部店舗の「店番号」を変更するよう依頼した。
2002 年 3 月上旬、口座振替の「強化テスト」を実施した。
2002 年 3 月 22 日、みずほホールディングス経営会議が開かれ、システム担当部署に大丈夫か確認したが、システム担当部署は「おおむね問題なく進んでいる」と回答したので、経営会議でそれ以上の確認はせず、予定どおりシステム移行することに決まった。
しかし、誤った口座振替データを入力してシステム全体の負荷を調べる異常テストは「時間的余裕なし」などの理由で見送られ、実行されなかった。
2002 年 3 月 30 日、前日から口座振替データの入力を開始したが、旧 3 行の勘定系システムにデータを振分けるバッチ処理で新旧の「金融機関コード」と「店番号」が入り混じってミスマッチとなるエラーが発生、同時に特殊フォーマットで持込まれる口座振替データの処理でプログラムバグによるエラーが発生。これらエラーを手作業で修正したが、処理の遅れは 5 万件となった。しかし、みずほは「決済システム全体に影響を与えるものではない。4月 1 日中に処理可能なら問題なし」とした。
2002 年 4 月 1 日、みずほ銀行、みずほコーポレート銀行が発足。みずほ銀行で ATM 障害発生、旧富士のキャッシュカードは旧富士の店舗でしか使えず、旧富士の店舗で旧富士以外の銀行のキャッシュカードが利用できなくなった。また他行の ATM で旧富士のキャッシュカードを使用した際、現金が引出せないのに通帳には記帳されるトラブルも発生した。
みずほ銀行は対外接続系システムと RC との接続を一旦切断、13 時頃原因が判明した。
口座振替は、手作業で修正を続けたが、約 10 万件が未処理となった。
この本番直接修正は極力さけるべき障害復旧の行為で、後に顧客の口座データが消失する等の二次被害を発生させた。
2002 年 4 月 2 日、オンライン ATM は一旦復旧した。
2002 年 4 月 4 日、口座振替の処理遅延を公表した。
2002 年 4 月 5 日、4 月 1 日以降の口座振替遅延件数は 250 万件と発表。また 3 万件にのぼる二重引落としが発覚した。
2002 年 4 月 8 日、新たに二重引落し 3 万件判明(9 日までに修正)。
2002 年 4 月 9 日、口座振替の未処理 15 万件に減少した。前田みずほホールディングス社長が衆議院財務金融委員会に参考人招致され、その後記者会見を実施した。
2002 年 4 月 11 日、新たな口座引落し漏れが判明。遅れは 40 万件となった。
2002 年 4 月 18 日、口座引落しの遅れは解消された。しかし入金・結果通知は依然大幅な遅れが続いた。
2002 年 4 月 30 日、月末の口座引落しのヤマ場 1,200 万件を障害無く処理完了。
2

失敗知識データベース‑失敗百選

2002 年 5 月 8 日、金融庁、日銀は、みずほに立入り検査・考査を開始した。
2002 年 5 月 21 日、東京都、みずほに臨時の立入り検査を開始した。
2002 年 5 月 24 日、前田社長は決算発表の記者会見でシステム障害に伴う損害が 18 億円程度にのぼる見通しを公表した。

図 1 システム統合の概要
３．

原因（１） 技術的原因( 直接原因 )① ＴＭが正常に稼働しなくなった原因
旧第一勧銀の対外接続系システム（富士通のメインフレームを利用）の修整ミス。
旧第一勧銀の接続系の中で RC とやり取りするプログラムで、リレーコンピュータと論理的な接続経路を維持するために追加したプログラムに、特殊な条件が重なった場合に限って表面化するバグが存在した。
・・・・・・プログラム開発時考え落とし①

口座振替のトラブルの原因
・ 顧客企業が持ち込んだデータの不備
・ 口座振替処理のために開発した対外接続系プログラムのバグ
対外接続系のバグは「リレーコンピュータ通信中の電文を保存する領域に一定以上の電文がたまる」、「異なる電文をある組み合わせで処理する」といった条件が重なった場合に限って表面化するものであった。
4月8日オンライン障害が再発したのは修整ロジックに不備があったため。
・・・・・・プログラム開発時考え落とし
3

失敗知識データベース‑失敗百選②

負荷テスト、異常テスト等、十分なシステム稼働テストが出来なかった。
プログラム開発には必ずバグが存在する。稼動までに入念なシステム稼働テストを行ない、バグを取り除いて完全なシステムとするのが当然である。テストは実際運用時の条件をどれだけシミュレートして、負荷テスト、異常テスト等を実施するかが肝要である。

（２）組織的原因( 主因 )① システム統合方針決定の遅れ(企画・立案段階に原因あり)
企業統治（ガバナンス）の欠如により経営統合した旧3行が自社のシステムの存続にこだわって主導権争いを演じ、システム統合の方針が二転三転、意思決定が大幅に遅れた。
システム統合に対して、本来、客観的に機能要件を調べたうえで、どこのシステムが望ましいかについて合理的な方針を導き出すはずであったが、旧3行の自社システムの存続にこだわった主導権争い等で、大変なシステム統合である割には、単に三つのシステムを繋げばよいという、タテ割り体制の弊害が見えるような、合理性を欠いたものとなった。リレーコンピュータ方式は決しておかしな方式ではないが、問題はリレーコンピュータの開発作業に遅れが生じたことにある。
根本的なところで設計思想がなかった。
銀行のシステム統合する際には、なるべく処理量の少ない時期を選ぶのがベス
ト、みずほは年間で最多の処理量を迎える 4 月 1 日に固執したことも一因である。
②

システム統合の開発スケジュールの遅れ「統合プロジェクトの管理体制に問題があった」
管理体制については、システム開発が遅れていたのに、担当部署から経営陣に適切な報告がされていなかった。旧 3 行間でシステム開発を分担する「開発責任行体制」をとったため、相互チェックが働かなかった上、各行をたばねる持ち株会社の管理体制も機能しなかった。
システム統合のスケジュールの遅れは、前年からＣＥＯ（最高経営責任者）に数回にわたり報告されていた。これに対しＣＥＯは「遅れを取り戻すように」などと指示するだけで、システム開発責任者の甘い見通しをうのみにし、突っ込んだ確認をしなかった③ システム間を接続するコンピュータの性能を考慮したテストが不十分、事前に有効な負荷テスト、異常テストが行われなかった。
④

経営陣が障害発生の可能性を把握しながら、経営統合の直前に起きた処理の遅れなどを軽視し、見切り発車で統合に踏み切った。

４．

対処① 金融庁は日銀と共同で持ち株会社のみずほホールディングスと、みずほ銀行、みずほコーポレート銀行に対してほぼ１カ月立ち入り検査（考査）し、原因や発生後のみずほ側
4

失敗知識データベース‑失敗百選の対応、再発防止策を調査。
② 金融庁、みずほに業務改善命令
業務改善命令はトラブルの未然防止のための予防策と、障害が起きた場合の対応の2本柱。
システム障害の再発防止のための内部管理体制の充実や、システムの運用体制の見直しのほか、責任の明確化などを求めている。
今後も巨額のシステム開発投資が不可欠で、障害発生の可能性は否定できないことから、抜本的な予防策を求めることにした。システム開発の管理と運営体制の見直しを軸に、システム部門の組織の見直しや監査体制の強化、経営トップのシステム部門への一層の関与のほか、混乱を長引かせた旧3行間の情報交換の緊密化、共有化などを求めた。
また、システム障害が発生した場合に備えて、危機対応マニュアルの策定を要求。みずほは、4月の再編に合わせて、システム障害が発生した場合の復旧手続きなどを定めた内部管理マニュアルについては事前に策定していた。しかし、店舗に殺到する個人顧客や法人の取引先にトラブルの現状や応急策を伝えたり、改善の見通しなどを伝える顧客向けのマニュアルが不十分だった。
５．

対策① システム障害の責任問題について、外部の人間を招き、システム障害等特別委員会を設置した。
② ガバナンス（企業統治）の確立
システム障害は旧銀行間の縄張り争いや意思決定の遅さなど、体制が抱える病巣が原因の一つである。こうした病巣の除去が欠かせない経営体制の見直し、人事の融合と組織のスリム化を行う。
たすき掛け人事を廃止する方針。役員数を削減して情報が素早く持ち株会社に集約できるようにする
行動計画では、トラブル発生の原因と指摘される 3 行のバランスを重視した人事・組織の改革や、システム開発体制の刷新、リストラ計画の前倒しなどを盛り込む方向である。
③ 大規模障害の震源地となったシステム部門は、旧 3 行がそれぞれのシステムを別々に開発する「開発責任行」制を廃止し、旧 3 行が独立してシステム統合の準備を進めたことで相互チェックが機能しなかった反省を踏まえ、旧 3 行出身のシステム担当が連携してシステム開発を行うよう改める。
６．

総括史上初の 3 行のシステム統合という特殊性はあったにしても、システムに対する根本的な認識、特にトップの経営判断について、業種業界を問わない普遍的な問題を提示した。現代の銀行業にとってコンピュータシステムの構築は不可欠の要素である。なかでも、情報系、勘定系と言われる巨大ホストコンピュータは銀行の心臓部である。銀行の合併・統合ではそうしたコンピュータシステムを一体化させていく作業は避けられない。みずほグループも5失敗知識データベース‑失敗百選

2002 年 4 月 1 日を目指して、システム統合の作業を続けていたが、その過程は試行錯誤の連続であり、この経緯のなかに今回の大規模システム障害の原因があった。
合併によるたすき掛け人事は一般的だが、人事だけでなく単に3倍とした統合であった。基本的な意思決定は3行の合議制をとらざるを得なかった。3行の主導権争いによる「企業統治（ガバナンス）の欠如」がシステム統合に影響し、1999年末に決めたシステム統合方針を約一年後に覆すなど方針が二転三転して意思決定が遅れ、これが後々まで響いた。このため開発スケジュールの遅延、システム間を接続するコンピューターの性能を考慮したテストが不十分だったほか、システム統合までの準備・管理体制に不備があった。また旧3行のシステム統合の遅れが内部で指摘されながら、４月の経営統合を優先するあまり正確な報告が経営トップまで伝わらず、適切な対応をとれなかったのが原因である。経営陣の認識の甘さに、障害はシステム統合の意思決定の遅れや内部報告の不備などが原因の「組織的ミス」とされる。今回の大規模システム障害により、決済という社会的インフラを混乱させた、みずほグループの責任は重い。
多大な損害を招いた今回のトラブルは情報社会の怖さを示す一方、日本経済における情報技術（ＩＴ）の重要性を再認識させた。システム障害はその後も金融、航空分野などで起きており、情報化に対する入念な点検と再投資が必要である。
相次ぐシステム障害が日本の金融システムへの不安を拡大しているとすれば、日本はＩＴ分野の産業だけでなく、その利用分野でもシステム投資やＩＴ教育に一層力を入れる必要がある。
７．

知識化① システム障害は、基幹システムと外部システムとをつなぐ接続部分で発生している例が多い。
② システム稼動前に、入念なテスト( 疎通テスト、負荷テスト、強化テスト、異常テスト等)を実施しなければならない。
③ システム設計はまず設計思想の明確化が必要である。
④ 合併・統合の条件となるシステム統合をする際は事前に合理的な対応を入念に行ない、システム統合の方針を決定する必要がある。
⑤ 経営トップはシステムに対する根本的な認識を改めなければならない。
⑥ 企業の合併や経営統合においては、人事の融合と組織のスリム化が必須、たすき掛け人事やバランス人事はよくない。
８．

背景
金融機関のシステム障害は2002年1月末のＵＦＪ銀行でのトラブルに続き、みずほ以外にも郵便貯金やＩＹバンク、信用金庫などでも立て続けに起きた。外見上は現金自動預け入れ払い出し機（ＡＴＭ）の障害といった形で起きているが、実際には基幹システムと外部システムとをつなぐ接続部分で発生している例が多い。
相次ぐトラブルの背景にはこの二年間で急速に進んだ金融市場の再編やサービスの多様化
6失敗知識データベース‑失敗百選がある。ＵＦＪやみずほのような銀行の合併はそれ自体が大幅なシステムの見直しを必要とする。郵便局や信用金庫などとの相互接続、デビットカードやインターネットによる即時決済サービスの登場などもシステムの負荷を高める大きな要因となっている。
特にインターネットを舞台にした電子商取引は営業所や代理店を介さず企業と消費者を直接結ぶのが特徴である。システムも従来の汎用機による閉ざされたものではなく、オープンシステムと呼ばれる分散型の処理が求められ、その分、ネットワークの構成も複雑になっている。問題はそうしたシステム環境の変化に対し企業やメーカーが十分に対応しきれていないところにある。
行政や産業界にも共通する問題としては日本の情報システムに対する過信がある。日本のＩＴストックはバブル経済の崩壊に伴う投資の抑制から米国などに比べ相対的に低下しており、ＩＴ分野の人材不足も目立っている。経営にＩＴを導入したまではよかったが、従業員の情報リテラシー（利用能力）も不十分である。また、大手電機メーカーは九万人を超える人員削減計画を打ち出しているが、その多くは汎用機や家電時代に大量採用した社員で、インターネット時代の新技術に精通した技術者はむしろ不足している状態である。
９．四方山話新しいシステムを作るときは、従来システムの付加設計では限度があることを知るべきである。すなわち、本例は図２のようにシステムを構築したため破綻したが、本来は要求機能と制約条件の下で、図３のような新規設計が必要であった。

AB

ACB

図２

今回の設計

7

C

失敗知識データベース‑失敗百選

旧Ａ

旧Ｂ

旧Ｃ
図３

本来やるべきであった設計＜引用文献＞[1] 「みずほ銀ＡＴＭ障害の原因、接続コンピューターの不具合」朝日新聞 2002/04/01[2] 「みずほを立ち入り検査 金融庁が５月上旬に実施」読売新聞 2002/04/19[3] 「検証・みずほシステム障害 認識甘く、泥沼に突入」読売新聞 2002/04/20[4] 「みずほ、統合前に欠陥把握」産経新聞 2002/04/23[5] 「みずほ社長、衆院委で「経営責任は検査後に」読売新聞 2002/04/24[6] 「《検証》みずほトラブル 土壇場で方針変更、混乱拡大」朝日新聞 2002/04/24[7] 「みずほ社長、障害の全容つかめず――４大金融首脳、衆院委招致、テスト不十分」
日経新聞 2002/04/24[8] 「みずほ複合ミス、混乱増幅、検証・システム障害、口座振替、点検甘く」日経新聞
2002/04/23[9] 「システム統合、金融再編に重いリスク、みずほ、障害沈静化」日経新聞 2002/05/01[10] 「事前テスト不十分だった

みずほ前田社長が衆院委で」朝日新聞 2002/04/24[11] 「みずほが最終報告書、８日から立ち入り検査」朝日新聞 2002/05/07[12] 「読売社説（１）［みずほ報告］「信頼回復への道はまだ険しい」」読売新聞 2002/05/08[13] 「みずほグループに立ち入り検査金融庁・日銀」朝日新聞 2002/05/08[14] 「みずほが明らかにした―― 対等合併 これだけの過ち」日経新聞 2002/05/12[15] 「みずほ銀：部支店長会議を開催、人事見直しで経営改革」毎日新聞 2002/05/19[16] 「みずほ、再生へ「行動計画」６月めどに策定」読売新聞 2002/05/22[17] 「障害から２か月…みずほ、再生プラン急ぐ」読売新聞 2002/06/02
8

失敗知識データベース‑失敗百選[18] 「システム障害、みずほ検査終了、金融庁、近く業務改善命令」日経新聞 2002/06/06[19] 「システム障害、みずほ経営陣認識甘く―社長、衆院委で表明」日経新聞 2002/06/12[20] 「みずほ社長、「３行あつれき反省」、システム障害、たすきがけ人事廃止」
日経新聞 2002/06/13[21] 「自分を守る危機管理術」 Associe (日経 BP)

2002 July vol.3, p.24‑26[22] 「大失敗のメカニズム 3 の倍数の論理」プレジデント

2002 7.1 号 p88‑93[23] 「みずほ銀、混迷の二週間を追う」日経コンピュータ 2002/04/22 ページ：12〜15[24] 「スクープ−みずほ銀行のシステム障害，真相が判明替処」日経コンピュータ 2002/05/06

対外接続系の修整をミス，振ページ ：11〜11[25] 「情報システムの危機管理を見直せ」日経コンピュータ 2002/06/03 p.154〜160

9

失敗知識データベース－失敗百選【追補2010 年 3 月 31 日】

後日談
同様な銀行のシステム統合を控えていた三菱東京 UFJ 銀行では、既存システムの継ぎ足しではなく、多くの時間、工数、費用を費やして新たなシステムを設計し、システム統合を行った。三菱東京 UFJ 銀行では 2 つのフェーズに分けてシステム統合を実施した。
まず、2006 年 1 月から「Day1」プロジェクトを開始し、旧東京三菱銀行と旧 UFJ銀行の勘定系と市場系システムを相互接続した。続けて「Day2」プロジェクトを開始し、残された勘定系システムを統合した。これらのプロジェクトに費やした開発工数と開発費用はは Day1 で 3 万人月、800 億円、Day2 で 11 万人月、2500 億円である。多くの工数、費用、時間を費やした結果、大きなトラブルも無くシステム統合を行うことができたが、その間、ATM 停止、同じ銀行でありながら旧東京三菱か旧 UFJ の口座によって使える店舗やサービスが違うなど、利用者にとっては不便を強いられることになった。

10