■研究論文(OA学会誌『オフィス・オートメーション』)
本稿は,2002年4月のみずほ銀行のシステムトラブルの発生メカニズムと再発防止策についての事例研究です。 : keywords = みずほ,システム,トラブル,メカニズム,経営,原因
   このホームページのトップへ 
 
 
みずほ銀行のシステムトラブル発生メカニズムの事例研究 〜システムと経営の両面から〜
 
A Case Study of the Mechanism of the System Trouble at Mizuho Bank − From the Both Sides of the Information System and the Management −
 
 
神山卓也
Takuya Kamiyama
 
1.はじめに
 本稿は,所属企業に入社以来10年間以上情報システム部門に在籍した筆者の実務体験も踏まえて,本年(2002年)4月に表面化したみずほ銀行のシステムトラブルについてシステムと経営の両面から事例研究として報告を行うことにより,他企業における今後の経営統合時の再発防止に役立つ教訓を得ることを目的とするものである.
 ご高承のとおりみずほ銀行グループは第一勧業銀行(以下,第一勧銀と略),富士銀行,日本興業銀行(以下,興銀と略)の経営統合の結果発足した銀行であり,既に設立済みの上場持ち株会社みずほホールディングスの下に2002年4月にリティールのみずほ銀行と企業向けのみずほコーポレート銀行の2行に統合再編した.以降本稿ではこのみずほフィナンシャル・グループ3社をまとめて「みずほ」と総称する.
 なお,本稿は余暇時間を用いた私的研究であり,筆者所属企業他全ての筆者関係組織や個人は本稿の内容に関しては免責である.
 
2.システム面からのトラブル状況と発生原因
 今回のシステムトラブルは主として,4月1日を中心として生じたATM障害と,継続的に生じた口座振替(以下,口振と略)や送金の口振系トラブルとに大別できる.まずはATM障害について状況と原因について解説する.
図表1:みずほ銀行のシステム構成
 
 
 図表1はみずほの勘定系システムの構成図である.理由は後述するがみずほでは4月の統合再編時に完全なシステム統合を実施できず,やむを得ず過渡的に旧3行のシステムを残した上でリレー・コンピューター(以下,RCと略)で間をつなぐ構成にした.4月1日など4月上旬に発生したみずほ銀行のATM障害の現象は,旧第一勧銀顧客と旧富士銀行顧客がそれぞれ旧相手側銀行支店でATMが使えず,さらに旧富士銀行顧客は他銀行ATMなどが使えなかったことである.文献7によれば原因は,RCをつなぐための既存ホスト・コンピューター(以下,ホストと略)の対外接続系コボルシステムの論理的な接続経路を維持するための機能にプログラム・ミス(以下,バグと略)があり,一定以上の伝送量発生時など特定の条件が重なる場合のバグの影響発生条件が生じてRCへのデータ伝送が行われず,RC自体は正常稼働していたが旧第一勧銀−旧富士銀行システム間が不通と化したためである.みずほの場合,旧各行システムを併存させたのに対外接続機能だけは旧第一勧銀システムに集約したため,両システム間が不通になった途端に旧富士銀行システムは対外的にも孤立してしまい,被害が拡大した.バグを事前に潰せなかった原因は,十分な大量データでの負荷テストが行われておらず,バグの影響発生条件該当ケースを見逃したためである.
 一方,口振・送金トラブルの現象は,口振遅延,二重引き落とし,誤送金,振込遅延,口振結果通知を行う還元データにおけるレコード落ちなどの内容誤りなど,多現象に渡って多顧客に対して複数日多数件数に及んで発生した.
 ここで口振トラブルのシステム的な原因を理解するためには前準備としてオンライン処理とバッチ処理の理解が必要なので最初にその解説を行う.ホストでの処理は,(1) アプリプログラムが主記憶空間に常駐稼働したままの状態でエンド・ユーザーが端末などからリアルタイムにサービスを利用するオンライン処理,(2) アプリプログラムは主記憶空間に常駐稼働せずにジョブと呼ばれるプロシージャーを流す都度起動されるバッチ処理,に大別される.大手顧客企業から依頼される口振処理のような定型大量データ処理の場合,対話型操作が必要なオンラインでは手事務のワークロードが不必要に生じてしまうなどの理由のため,磁気テープ(以下,MTと略)などでデータ受け渡しを行った上でバッチ処理で機械処理される.
図表2:みずほの口座振替処理フロー
 
 
 みずほの場合には,前述のとおり過渡的に旧3行のシステムを併存させたが,オンラインだけでなくバッチ処理においてもリティールの対外データ受け渡し窓口を旧第一勧銀に集約したため,図表2のとおり,旧第一勧銀システムで顧客企業から受け渡された口振データの旧3行システムへの振り分け処理を行う設計になった.公表資料や各種報道を総合すれば口振系トラブル発生原因は、この振り分け処理のバグや窓口集約による作業量超過で作業が滞留し,営業現場で手事務でリカバリーするためには「数十年に及ぶ機械化による要員削減効果で”予備兵力”が無い」ため事務処理が追いつかず,また人間系の手事務が増えた過程で作業に必要な情報の混乱などのために誤作業が発生し,さらには,図表2の「処理結果通知処理」にて実施される「旧3行ホストに分けて行った処理結果を顧客企業に受け渡す1本の還元データにまとめる」マージ・プログラムにもバグがあった模様である.文献6によれば二重引き落とし発生原因は同一MTの二重読み込みである.この二重読み込みについて或る顧客企業のシステム担当者は,リカバリー用バッチジョブのジョブ制御言語(JCL)上で,MTの日付バージョン情報を与えるコントロール・カードで,既に別のバッチジョブで実施済みの日付を再指定してしまった可能性を推測しており,何かこのようなバッチジョブ運用上のミスという見方に筆者も同意する.
 プログラムの開発にまで遡った口振系トラブルのシステム的な発生原因は準備時間不足であろう.銀行統合の際には銀行コードや支店番号,支店名などが変わるためデータに新旧両形式の差が生じる.さらにみずほコーポレート銀行の顧客企業の場合には引き落とし対象の個人顧客の口座はリティール担当のみずほ銀行にあるため,「引き落とし口座とその振り替え先口座が同じみずほでも別銀行になる」という前例が無いイレギュラーなデータ内容と化す.先述の振り分けも含めて本来このような複雑な処理を行うためには前広なテストが必要になり,筆者のシステム開発体験では巨大システムでバグを潰すためには半年以上のテスト期間を用意することが望ましいが,みずほが新コードを公表したのは2001年10月と通常よりもむしろ遅くて半年ものテスト期間を確保できるものではなく,行内での口振系システムの開発とテストの期間が不足していたと推測できる.みずほでは統合前月の2002年3月になって旧形式データで受け渡しを行って欲しい旨の連絡を顧客企業に急きょ行っていることから,新形式対応プログラムの開発が間に合わなかったことが分かる.みずほは東京電力から二度に渡って依頼された口振テストを「行内で十分にテストを行った」ことを口実にして断った旨が報道されており,本番データを用いてのシステムテストが不十分である旨を自ら白状したに等しい状況に陥ってしまっている.
 
3.経営面からのトラブル発生原因
 前節で見たように,ATMトラブルも口振トラブルも開発期間やシステムテスト期間が十分に取れなかったことがそもそもの原因である.この準備不足が発生したさらに根本的な原因は経営(マネジメント)にある旨が報道されている.
 1999年8月20日の経営統合発表後システムの統合が検討された際,システム開発が最も進んでいたのは富士銀行であった.富士銀行のIBMシステムが進んでいたという報道もあるがIBMだからハード的に優れていたのではなく最新機能のリリース有無というユーザー・アプリシステムの機能差によるものである.しかし,三行対等合併という体裁はシステム統合で主導権争いを生じさせ,富士銀行が山一証券破綻や安田信託銀行経営悪化を抱えたなどの事情もあって第一勧銀の発言力が増した結果,他行統合時に次々と顧客を失ってきた富士通側の巻き返しや古河系の富士通が第一勧銀系列であった事情もあり,勘定系の基幹システムは第一勧銀システムに,それ以外は富士銀行システムに統一することが1999年12月に決まった.
 しかしCEOが3人いる異様な状況下で,システムなど理解できない本部の文系トップ層は課題をシステムの現場に丸投げして内向きの主導権争いに明け暮れ,現場システム部門でも主導権争いが生じてシステム開発が停滞したりした結果第一勧銀システムへの統合は頓挫し,2000年10月に旧3行システムを残してRCで間をつなぐ方式に方針変更するなど迷走した.文献5によれば,システムでの主導権争いは雇用や処遇の危機感を賭けた生存競争であった.既存システムをしばらく併存させる案は安全策ではあったが,この方針変更の段階での2002年4月の3行統合まで1年半という期間は安全策でさえ開発とテストの期間が間に合わないものであった.これには,文献6によれば2000億円の開発費用がみずほコーポレート銀行対応に費消されてしまいみずほ銀行対応にあまり回らなかったことも影響している.また,システム統合は技術に止まらず事務処理という企業文化の統合でもあるため3行が対等だと調整に多大な時間が必要となるが,この調整に十分なスケジュールではなかったのであろう.しかも,システムは旧3行併存なのにシステム上も事務処理上も対外接続窓口をなまじ旧第一勧銀に統一したため,機械的にも事務処理的にも処理容量のボトルネックを作ってしまったばかりか,容量オーバー時のコンテンジェンシー・プランが無い構成と化し,トラブル発生時の被害を拡大させてしまった.さらに,トラブル発生後本部からの情報が営業現場に十分には降りて来ず,現場の顧客対応の上でも二次被害が拡がった旨が報道されている.
 このような状況が発生したそもそもの原因は,
(1) 勝ち負けが無い合併と化したため,CEOもシステム最高責任者であるCIOも3人いて,どこか1行がリーダーシップを採り得る状況にはなく,不毛な主導権争いが発生したこと
(2) 経営陣にシステムの理解が無くCIOに発言力が無くシステムは傍流であり,危機感の欠けた姿勢でシステム統合に臨んだ結果,問題点が上に上がらなかったり上がってきても理解できなかったこと
の2点であろう.(1) に関して言えば報道される一連の経緯では行内権力闘争という「顧客を無視した内向きの視点」しか見えてこない中で意志決定が迷走した結果,開発やテストの遅延の原因と化した.また,各種報道によれば(2) に関しては「現場が気づいても言えない」,「言っても無駄」という空気を生じせしめ,「まずい情報ほど上に上げるべき」というホウ・レン・ソウ(報告・連絡・相談)の基本が欠落した状況と化した結果,開発やテストの遅延とその影響についてトップが的確に認識することを妨げ,無理なカットオーバーを強行する原因と化した.しかも,2002年4月9日の衆議院財務金融委員会で参考人招致された前田晃伸みずほホールディングス社長の有名な失言「直接利用者に実害が出たということではなく」で明らかになったように,みずほのトップ層にはトラブル発生後でさえ問題点を把握する能力が欠落していたのである.
 
4.まとめと教訓
 以上のとおりみずほのシステムトラブルは,勝ち負けの無い「悪い意味で日本的な旧3行の面子を立てる」統合を行ったため主導権争いが生じたこととトップ層のシステム無理解が,システムの統合計画決定の迷走およびその結果の開発やテストの期間不足をもたらして生じたものである.
 したがって,今後経営統合を行う他企業のための教訓としての再発防止策としては,(1) 統合の主導権と意志決定の責任者を明確にし,(2) トップは「どうせシステムの話など分からない」という態度を放棄した上でCIOに発言力と権限を与え,(3) 無理の無いシステム統合計画を立案・遂行することが必要であろう.日本の企業内力学では,「努力した結果がトラブルを未然に防止できた『何も無い状況』である」旨のオペレーション部門の仕事は外見上の功績が見えにくいため軽視されがちであるが,オペレーション部門でのトラブルは顧客離れをもたらしかねず,実際,みずほでは振込の仕向銀行を他行に代えた顧客企業がある.他業界も同様であるが特に金融・保険業界はシステムをコアコンピタンスとする装置産業と化しているため,今後の経営統合時にはトップによるシステムの理解が,オペレーション・リスク極小化のためには欠かせないのである.
 
 
参考文献,参考サイトならびに参考情報
1.筆者所属企業グループ情報システム部門担当者へのヒアリング(ただし守秘義務範囲内)
2.みずほフィナンシャルグループ「記者会見配布資料」,2002年4月18日
3.岡江正樹「みずほ,UFJのシステム障害・真因は経営トップのIT軽視」『金融システム』,2002年6月号,pp.22-25
4.浪川 攻「検証 決済危機の真相 みずほ激震」『週刊東洋経済』pp.12-18
5.三神万里子「巨艦みずほ合併人事の落し穴」『文藝春秋』,2002年6月号,pp.178-187
6.大和田尚孝「特別レポート・みずほ銀,混迷の2週間を追う」『日経コンピュータ』HP
http://itpro.nikkeibp.co.jp/NC/members/NC/REPO/20020511/2/
7.「スクープ・みずほのシステム障害真相が判明」『日経コンピュータ』HP
http://itpro.nikkeibp.co.jp/NC/members/NC/REPO/20020511/1/
 
 
 
 
 
学術研究の部屋へ  
 
このホームページのトップへ
 
HMV
タワーレコード
indiesmusic.com

このHP作者に関係のある別HPです。

STATISTICS

  

炭鉱マニア

  

鉄道艦船航空陸自マニア

  

ネットDE討論@Marine

本稿は,2002年4月のみずほ銀行のシステムトラブルの発生メカニズムと再発防止策についての事例研究です。 : keywords = みずほ,システム,トラブル,メカニズム,経営,原因