失敗事例

シナリオ 失敗百選 (PDF)
事例名称 みずほフィナンシャルグループ大規模システム障害
代表図
事例発生日付 2002年04月01日
事例発生地 全国
事例発生場所 みずほ銀行
事例概要 第一勧業、富士、日本興業の３銀行のシステムを「みずほ銀行」として一本化するシステム統合で、統合の方針決定が紆余曲折し、システム統合のスケジュール・統合作業が遅れて、予定していたシステム稼働テストの開始がずれ込み、十分な見極めができないまま開業したため、開業初日から現金自動預入払出機(ATM)の障害が発生、さらに公共料金の自動引き落としなどの口座振替に遅延が生じるトラブルが起きた。トラブル発生後も対応が遅れるなどで、口座振替の遅延が拡大、大混乱となり最大級の大規模システム障害に陥った。
事象 第一勧業、富士、日本興業の３銀行が再編して誕生した「みずほ銀行」は、営業初日(2002年4月1日)に現金自動預入払出機(ATM)の障害が発生、さらに公共料金の自動引き落としなどの口座振替に遅延が生じるトラブルが起き拡大した。口座振替に遅延は4月1日だけで105,000件に達し、翌日以降の積み残しとなり、連鎖的に大量の未処理が発生、4月5日には遅延数は250万件にまで膨張していった。それに付随したかたちで、約3万件の二重引き落とし発覚し最大級の大規模システム障害に陥った。復旧を図るも、このトラブルで顧客の混乱が長期化、1ヶ月以上も続いた。
経過 99年8月20日　旧第一勧業、旧富士、旧日本興業銀行は、共同持ち株会社方式による経営統合を発表。
99年12月 　　 個人・中小企業向け取引部門を担う現「みずほ銀行」の勘定系基幹システムを02年4月に第一勧銀システムに一本化する「片寄せ方式」の方針を決定。
00年9月29日 持ち株会社「みずほホールディングス(HD)」設立。旧三行は持ち株会社の傘下に入る。
00年12月 当初案を見直し、勘定系システム一本化を03年4月に延期し、それまでの間は旧第一勧銀のシステムを外部と接続するメーンシステムとし、旧富士、旧興業銀の勘定系システムをリレーコンピュータ(RC)で接続する暫定方式に方針変更した。
しかし、この旧第一勧銀の接続系の中でRCとやり取りするプログラムで、RCと論理的な接続経路を維持するために追加したプログラムに、特殊な条件が重なった場合に限って表面化するバグがあり、事前に実施した疎通テストや負荷テストでは検出出来なかった。
01年5月10日 みずほホールディングス取締役会でシステム移行を実行計画として確定した。
01年3～6月　　金融庁はみずほグループの検査実施、スケジュールの遅れ等システム統合の問題点を指摘。　　　
01年12月　　　月間5 万件を超える大手取引先の口座振替データ振分け処理は、当初、旧興銀システムを引継ぐ「みずほコーポレート銀行」が担当する計画であったが、旧興業銀のシステムは大量処理に適していないため、旧第一勧銀システムを引継ぐ「みずほコーポレート銀行」で処理する方針に変更。　　
また、口座振替を委託する企業に対し、02年4月1日から全国銀行協会フォーマットで口座振替データを持込む場合、旧富士、旧興業銀の「金融機関コード」を旧第一勧銀のコードに統一し、旧富士、旧興業銀の一部店舗の「店番号」を変更するよう依頼。
02年3月上旬　 口座振替の「強化テスト」を実施。
02年3月22日 みずほホールディングス経営会議が開かれ、システム担当部署に大丈夫か確認したがシステム担当部署は「おおむね問題なく進んでいる」と回答したことより、経営会議でそれ以上の確認はせず、予定どうりシステム移行することに決まった。
しかし、誤った口座振替データを入力してシステム全体の負荷を調べる異常テストは「時間的余裕なし」などの理由で見送られた。
02年3月30日 前日から口座振替データの入力を開始したが、旧三行の勘定系システムにデータを振分けるバッチ処理で新旧の「金融機関コード」と「店番号」が入り混じってミスマッチとなるエラーが発生、同時に特殊フォーマットで持込まれる口座振替データの処理でプログラムバグによるエラー発生。これらエラーを手作業で修正したが、処理の遅れは5万件となった。しかしみずほは決済システム全体に影響を与えるものではない。4月1日中に処理可能なら問題なしとした。
02年4月 1日　みずほ銀行、みずほコーポレート銀行が発足。
みずほ銀行でATM障害発生、旧富士のキャッシュカードは旧富士の店舗でしか使えず、旧富士の店舗で旧富士以外の銀行のキャッシュカードが利用できなくなった。また他行のATMで旧富士のキャッシュカードを使用した際、現金が引出せないのに通帳には記帳されるトラブルも発生。
みずほ銀行は対外接続系システムとRCとの接続を一旦切断、13時頃原因判明。
口座振替は、手作業で修正を続けたが、約10万件が未処理となった。
この本番直接修正は極力さけるべき障害復旧の行為で後に顧客の口座データが消失する等の二次被害を発生させた。
02年4月 2日　オンラインATMは一旦復旧。
02年4月 4日 口座振替の処理遅延を公表。
02年4月 5日　4月 1日以降の口座振替遅延件数は250万件と発表。また3万件にのぼる二重引落としが発覚。
02年4月 8日 新たに二重引落し3万件判明(9日までに修正)。　
02年4月 9日 口座振替の未処理15万件に減少。
前田みずほホールディングス社長が衆議院財務金融委員会に参考人招致され、その後記者会見。
02年4月11日 新たな口座引落し漏れが判明。遅れは40万件。
02年4月18日 口座引落しの遅れは解消された。しかし入金・結果通知は依然大幅な遅れが続く。
02年4月30日 月末の口座引落しのヤマ場1200万件を障害無く処理完了。
02年5月 8日　 金融庁、日銀は、みずほに立入り検査・考査を開始。
02年5月21日 東京都、みずほに臨時の立入り検査を開始。
02年5月24日 前田社長は決算発表の記者会見でシステム障害に伴う損害が18億円程度
にのぼる見通しを公表。
原因 技術的原因　( 直接原因 )
1. ＡＴＭが正常に稼働しなくなった原因
旧第一勧銀の対外接続系システム（富士通のメインフレームを利用）の修正ミス。
旧第一勧銀の接続系の中でRCとやり取りするプログラムで、リレーコンピュータと論理的な接続経路を維持するために追加したプログラムに、特殊な条件が重なった場合に限って表面化するバグ・・・・・・プログラム開発時考え落とし
2. 口座振替のトラブルの原因，
　 ・顧客企業が持ち込んだデータの不備
　 ・口座振替処理のために開発した対外接続系プログラムのバグ
対外接続系のバグは「リレーコンピュータ通信中の電文を保存する領域に一定以上の電文がたまる」，「異なる電文をある組み合わせで処理する」といった条件が重なった場合に限って表面化するバグ。
４月８日オンライン障害が再発したのは修整ロジックに不備があったため。・・・・・・プログラム開発時考え落とし
3. 負荷テスト、異常テスト等、十分なシステム稼働テストが出来なかった。
プログラム開発には必ずバグが存在する。稼動までに入念なシステム稼働テストを行いバグを取り除いて完全なシステムとするのが当然である。テストは実際運用時の条件をどれだけシミュレートして、負荷テスト、異常テスト等を実施するかが肝要。
　　　　　
組織的原因　( 主因 )　
1. システム統合方針決定の遅れ　( 企画・立案段階に原因あり )
企業統治（ガバナンス）の欠如により経営統合した旧３行が自社のシステムの存続にこだわって主導権争いを演じ、システム統合の方針が二転三転し、意思決定が大幅に遅れた。
システム統合に対して、本来、客観的に機能要件を調べたうえで、どこのシステムが望ましいかについて合理的な方針を導き出すはずであったが、旧３行の自社システムの存続にこだわって主導権争い等で、大変なシステム統合である割りには、単に三つのシステムを繋げばよいという、タテ割り体制の弊害が見えるような、合理性を欠いたものとなった。リレーコンピュータ方式は決しておかしな方式ではないが、問題はリレーコンピュータの開発作業に遅れが生じたことにある。根本的なところで設計思想がなかった。
銀行のシステム統合する際には、なるべく処理量の少ない時期を選ぶのがベスト、みずほは年間で最多の処理量を迎える4月 1日に固執したことも一因。
2. システム統合の開発スケジュールの遅れ
「統合プロジェクトの管理体制に問題があった」
管理体制については、システム開発が遅れていたのに、担当部署から経営陣に適切な報告がされていなかった。旧３行間でシステム開発を分担する「開発責任行体制」をとったため、相互チェックが働かなかった上、各行をたばねる持ち株会社の管理体制も機能しなかった。
システム統合のスケジュールの遅れは、昨年からＣＥＯに数回にわたり報告されていた。これに対しＣＥＯは「遅れを取り戻すように」などと指示するだけで、システム開発責任者の甘い見通しをうのみにし、突っ込んだ確認をしなかった　
3. システム間を接続するコンピューターの性能を考慮したテストが不十分、事前に有効な負荷テスト、異常テストが行われなかった。
4. 経営陣が障害発生の可能性を把握しながら、経営統合の直前に起きた処理の遅れなどを軽視し、見切り発車で統合に踏み切った。
対処 ◆金融庁は日銀と共同で持ち株会社のみずほホールディングスと、みずほ銀行、みずほコーポレート銀行に対してほぼ１カ月立ち入り検査（考査）し、原因や発生後のみずほ側の対応、再発防止策を調査。
◆金融庁、みずほに業務改善命令
業務改善命令はトラブルの未然防止のための予防策と、障害が起きた場合の対応の２本柱。
システム障害の再発防止のための内部管理体制の充実や、システムの運用体制の見直しのほか、責任の明確化などを求めている。
今後も巨額のシステム開発投資が不可欠で、障害発生の可能性は否定できないことから、抜本的な予防策を求めることにした。システム開発の管理と運営体制の見直しを軸に、システム部門の組織の見直しや監査体制の強化、経営トップのシステム部門への一層の関与のほか、混乱を長引かせた旧３行間の情報交換の緊密化、共有化などを求めた。
また、システム障害が発生した場合に備えて、危機対応マニュアルの策定を要求。みずほは、４月の分割・再編に合わせて、システム障害が発生した　場合の復旧手続きなどを定めた内部管理マニュアルについては事前に策定していた。しかし、店舗に殺到する個人顧客や法人の取引先にトラブルの現状や応急策を伝えたり、改善の見通しなどを伝える顧客向けのマニュアルが不十分だった。
対策 1. システム障害の責任問題について、外部の人間を招き、システム障害等特別委員会を設置
2 .ガバナンス（企業統治）の確立
システム障害は旧銀行間の縄張り争いや意思決定の遅さなど、体制が抱える病巣が原因の一つである。こうした病巣の除去が欠かせない。
経営体制の見直し、人事の融合と組織のスリム化を行う。
たすき掛け人事を廃止する方針。役員数を削減して情報が素早く持ち株会社に集約できるようにする。
行動計画では、トラブル発生の原因と指摘される３行のバランスを重視した人事・組織の改革や、システム開発体制の刷新、リストラ計画の前倒しなどを盛り込む方向だ。
3. 大規模障害の“震源地”となったシステム部門は、旧３行がそれぞれのシステムを別々に開発する「開発責任行」制を廃止し、旧３行が独立してシステム統合の準備を進めたことで相互チェックが機能しなかった反省を踏まえ、旧３行出身のシステム担当が連携してシステム開発を行うよう改める。
知識化 1. システム障害は基幹システムと外部システムとをつなぐ接続部分で発生している例が多い。
2. システム稼動前に、入念なテスト(疎通テスト、負荷テスト、強化テスト、異常テスト等)を実施しなければならない
3.システム設計はまず設計思想ありき。
4.合併・統合の条件となるシステム統合をする際は事前に合理的な対応を入念に行ない、システム統合の方針を決定する必要がある。
5. 経営トップはシステムに対する根本的な認識を改めなければならない。特にトップの経営判断において。
6. 企業の合併や経営統合においては、人事の融合と組織のスリム化が必須、たすき掛け人事バランス人事はよくない。
【追補；2010年3月】
システム規模は年々増加しており、世界が求めているシステム処理量は、ここ5年で100倍くらいの増加していると言われている。システム開発に従事する人がこのような全体システム処理量の発展速度の速さを理解した上で、速さに対応したシステム開発を行うべきである。
背景 金融機関のシステム障害は一月末のUFJ銀行でのトラブルに続き、みずほ以外にも郵便貯金やＩＹバンク、信用金庫などでも立て続けに起きた。外見上は現金自動預け払い機(ATM)の障害といった形で起きているが、実際には基幹システムと外部システムとをつなぐ接続部分で発生している例が多い。
　相次ぐトラブルの背景にはこの二年間で急速に進んだ金融市場の再編やサービスの多様化がある。UFJやみずほのような銀行の合併はそれ自体が大幅なシステムの見直しを必要とする。郵便局や信用金庫などとの相互接続、デビットカードやインターネットによる即時決済サービスの登場などもシステムの負荷を高める大きな要因となっている。
特にインターネットを舞台にした電子商取引は営業所や代理店を介さず企業と消費者を直接結ぶのが特徴である。システムも従来の汎用機による閉ざされたものではなく、オープンシステムと呼ばれる分散型の処理が求められ、その分、ネットワークの構成も複雑になっている。問題はそうしたシステム環境の変化に対し企業やメーカーが十分に対応しきれていないところにある。
行政や産業界にも共通する問題としては日本の情報システムに対する過信がある。日本のＩＴストックはバブル経済の崩壊に伴う投資の抑制から米国などに比べ相対的に低下しており、ＩＴ分野の人材不足も目立っている。経営にＩＴを導入したまではよかったが、従業員の情報リテラシー（利用能力）も不十分だ
　一方、大手電機メーカーは9万人を超える人員削減計画を打ち出しているが、その多くは汎用機や家電時代に大量採用した社員で、インターネット時代の新技術に精通した技術者はむしろ不足している。
後日談 【追補；2010年3月】
同様な銀行のシステム統合を控えていた三菱東京UFJ銀行では、既存システムの継ぎ足しではなく、多くの時間、工数、費用を費やして新たなシステムを設計し、システム統合を行った。三菱東京UFJ銀行では2つのフェーズに分けてシステム統合を実施した。まず、2006年1月から「Day1」プロジェクトを開始し、旧東京三菱銀行と旧UFJ銀行の勘定系と市場系システムを相互接続した。続けて「Day2」プロジェクトを開始し、残された勘定系システムを統合した。これらのプロジェクトに費やした開発工数と開発費用はDay1で3万人月、800億円、Day2で11万人月、2500億円である。多くの工数、費用、時間を費やした結果、大きなトラブルも無くシステム統合を行うことができたが、その間、ATM停止、同じ銀行でありながら旧東京三菱か旧UFJの口座によって使える店舗やサービスが違うなど、利用者にとっては不便を強いられることになった。
よもやま話 史上初の3銀行のシステム統合という特殊性はあったにしても、システムに対する根本的な認識、特にトップの経営判断について、業種業界を問わない普遍的な問題を提示した。現代の銀行業にとってコンピュータシステムの構築は不可欠の要素である。なかでも、情報系、勘定系と言われる巨大ホストコンピュータは銀行の心臓部である。銀行の合併・統合はそうしたコンピュータシステムを一体化させていく作業は避けられない。みずほグループも2002年4月1日を目指して、システム統合の作業を続けていたが、その過程は試行錯誤の連続であり、この経緯のなかに今回の大規模システム障害の原因があった。
合併によるたすき掛け人事は一般的だが、人事だけでなく3の倍数の論理に帰結した統合であった。基本的な意思決定は3銀行の合議制をとらざるを得なかった。3銀行の主導権争いによる「企業統治（ガバナンス）の欠如」がシステム統合に影響し、1999年末に決めたシステム統合方針を約一年後に覆すなど方針が二転三転し、意思決定が遅れこれが後々まで響いた。このため開発スケジュールの遅延、システム間を接続するコンピューターの性能を考慮したテストが不十分だったほか、システム統合までの準備・管理体制に不備があった。また旧3銀行のシステム統合の遅れが内部で指摘されながら、4月の経営統合を優先するあまり正確な報告が経営トップまで伝わらず、適切な対応をとれなかったのが原因である。経営陣の認識の甘さに、障害はシステム統合の意思決定の遅れや内部報告の不備などが原因の「組織的ミス」とされる。今回の大規模システム障害により、決済という社会的インフラを混乱させた、みずほグループの責任は重い。
多大な損害を招いた今回のトラブルは情報社会の怖さを示す一方、日本経済における情報技術（ＩＴ）の重要性を再認識させた。システム障害はその後も金融、航空分野などで起きており、情報化に対する入念な点検と再投資が必要である。
相次ぐシステム障害が日本の金融システムへの不安を拡大しているとすれば、日本はＩＴ分野の産業だけでなく、その利用分野でもシステム投資やＩＴ教育に一層力を入れる必要がある。
シナリオ
主シナリオ 価値観不良、異文化、企画不良、組織構成不良、調査・検討の不足、事前検討不足、使用、運転・使用、機能不全、システム不良、組織の損失、社会的損失
情報源 自分を守る危機管理術:Associe（日経BP）2002 July vol.3
大失敗のメカニズム　3の倍数の論理:プレジデント 2002.2.1号
みずほ銀、混迷の二週間を追う:日経コンピュータ　2002/04/22
スクープみずほ銀行のシステム障害、真相が判明、対外接続系の修整をミス、振替処理:日経コンピュータ　2002/05/06
情報システムの危機管理を見直せ:日経コンピュータ　2002/06/03
マルチメディアファイル 図1.システム統合の内容
備考 銀行再編での大規模コンピュータシステム障害
分野 機械
データ作成者 張田吉昭 (有限会社フローネット)
中尾政之 (東京大学工学部附属総合試験所総合研究プロジェクト・連携工学プロジェクト)
シナリオ 失敗百選 (PDF)