システム障害はなぜ、二度起きたのか みずほ12年の教訓 日経BP

「ブラックボックス化」と老朽化が進行

長年にわたって、新サービスの投入や法制度対応などのための部分的な機能変更を繰り返した結果、勘定系システムの中身が複雑になってしまった。
情報システムがこのような状態に陥ることを、情報システムの「ブラックボックス化」と呼ぶ。
メガバンクの勘定系システムは、利用しているコンピューター・プログラムを見ると、全体で1億行に迫るまで膨らんでいる。
1人のエンジニアが1ヶ月仕事をしたとして、開発できるプログラムは、500行〜800行と言われる。
単純計算すると、1億行を開発するのに、1000人のエンジニアが10年間開発を続けないといけない量である。
みずほ銀行の勘定系システムは、システム担当者でさえ全容が少ないブラックボックス化となった。
その結果、システム担当者が勘定系システムの仕様について、隅から隅まで把握することができなくなってしまった。

「システムは正常に動作して当たり前」は間違い

企業を取り巻く「外部環境」の変化に合わせて、情報システムを毎日正常に動作させるのは、とても難しい作業である。
外部環境の変化を示す最たる例が、3月14日にみずほ銀行が直面した、義援金振込集中である。
内部環境の変化にも、情報システムを適応させて行かなければならない。
新サービスを開始する、利息をつける、利率を変更する、ATMを新設する、法制度の改正に合せて業務ルールを変える、といった場合には、情報システムの変更が欠かせない。
変更作業でミスをすれば、すぐさまシステム障害が起こる。
情報システムの外部・内部環境は日々変化する。
そう考えると、情報システムは今日正常に動いたからといって、明日も正常に動く保証はない。

費用とリスクを嫌い、システム刷新を先送り

みずほ銀行が勘定系システムの刷新を見送ってきたのは、みずほ銀行とみずほフィナンシャルグループの歴代の経営陣が大規模なシステム刷新を決断できなかったからである。
その理由については、メガバンクの元CIOは「費用がネックになったのではないか」と指摘する。
メガバンクの勘定系システムとなれば、全面刷新するには2000億〜3000億円はかかる。
金額以上に厄介なのは、投資効果が見えにくいことだ。
勘定系システムを刷新しても、顧客サービスの質の変化が見えにくい。
それでも、銀行にとってはならない、「縁の下の力持ち」の存在だ。
だからこそ、「勘定系システムは、長期的な視点で刷新を決める必要がある」
みずほ銀行とみずほFGの歴代経営陣がこうした認識を持っていれば、勘定系システムを23年間も放置しておくことはなかったはずだ。
みずほ銀行が勘定系システムの全面刷新に踏み込めなかったのは、経営陣がシステム刷新のリスクを嫌った結果でもある。
メガバンクの勘定系システムを全面刷新するとなると、日本最大級の大規模なシステム開発プロジェクトになる。
難易度は高く、失敗のリスクも膨らむ。

全面統合する三銀行に期待する

第一勧業銀行、富士銀行、日本興業銀行の三頭取が1999年8月20日に発表した「三行の全面的統合」は、我が国の情報技術史に必ず記録されだろう。
「金融機関の経営における最優先事項はITである」ことが改めて明確になったからだ。
最も理想なのは、三行の取締役クラスと三メーカーのエース級エンジニアががっちりスクラムを組むことだ。
全員の英知を結集し、国際競争力のある消費者向け銀行、投資銀行のそれぞれのビジネス・プロセス（業務の仕組み）を作り上げる。
この成果は、他の金融機関の生き残りにも非常に役立つ。
記者会会見で興銀や富士銀の頭取は、「全面統合は国益にかなう」と述べた。
我が国の金融機関とITベンダーの財産となるビジネスモデル作りはまさに国益に合致しよう。
しかし、現実は「ゼロ」であった。
旧第一勧業銀行、旧富士銀行、旧興銀は、正反対の道へ突き進み、迷走した。
最大の問題は経営戦略とビジネスの仕組みを作れなかったことだろう。
みずほFGの経営トップは、三行とコンピューターメーカーの意思統一に失敗した。

情報システムの統合は必要悪

勘定系システムの統合には、大きく2つのパターンがある。
一つは全く新しい情報システムを構築して、各行が既存システムから移行する。
もう1つは、どこか1行の既存システムに他社が移行する。
どのパターンにしても、最終的には1つの勘定系システムに、他の銀行の預金や融資データを1つも間違えずに移し替える必要がある。
ところが銀行によってデータの管理の仕方はまちまち。そこで、何千万件という情報を変換するためのプログラムを新規に作ることになる。
このプログラムでデータを変換し、1つの勘定系システムで扱えるようにしていく。
各社がシステム統合に動くのは、店舗の統廃合をはじめとする事業統廃合による合理化効果を最大限に出すためである。
統合しない場合、例えば新商品を扱う時は、複数ある勘定系システムのプログラムをそれぞれ改良しなければならない。
本来急ぐべき戦略的な情報化に向けた投資ができなくなる。

現場任せが禍根を残す

1999年9月から本格的に始まった統合作業は、当初から難航した。
3行は統合準備委員会なるものを作り、第一勧業銀行、富士銀行、日本興業銀行から代表が出席したが、意見の集約が難しかった。
最大の問題は、3頭取がシステム統合の落とし所を事前に相談していた節があるにもかかわらず、表面上は3行の情報システム部門に統合計画を策定させたことである。
これが諸悪の根源となった。
第一勧銀の杉田頭取は、「当行の勘定系を必ず残すように」と現場に指示したとされる。
富士銀の山本頭取は、「勘定系システムを第一勧銀のものに統合したらどのような弊害があるのか」と尋ねている。
第一勧銀が富士通のコンピューターを残したかったのは、同行のメインバンクであり古河電気工業などの古河グループからも「勘定系は富士通で」という強い要請があった。
また、第一勧銀の情報システム担当者は2000人を超える。
第一勧銀の勘定系がなくなった場合、第一勧銀情報システムのエンジニアは仕事がなくなってしまうことを恐れた。
もちろん、富士通の危機感も強かった。
都市銀行の相次ぐ合併によって、富士通は大手銀行の勘定系システムを次々に失っていた。
東京銀行は三菱銀行との合併により、IBM製に集約した。
さくら銀行は、住友銀行と合併し、NEC製の住友銀行の勘定系システムに一本化することを決めた。
我が国ナンバーワンのコンピューター・メーカーである富士通にとって、メガバンクの勘定系をおさえているという事実は必要なのである。
案の定、情報システムを巡る委員会は泥仕合となった。
富士通を推す第一勧銀とIBMを推す富士銀が真っ向から対立した。
議論を詰めていくと、富士銀の勘定系システムの方が、第一勧銀より優れていることがわかってきた。
最終的には、「富士銀の勘定系システムの方が第一勧銀より一年半進んでいる」という認識がなされ、議事録にも記載されたという。

優位な差はないと結論

第一勧銀と富士銀の不毛な論争の行司役となったのは、興銀とコンサルティング会社のATカーニーである。
ATカーニーは「第一勧銀と富士銀のシステムに有意差はない」という報告書を提出した。
興銀は第一勧銀の幹部を連れて、富士銀のシステム担当役員を訪問した。
「ここは折れてほしい」という説得により、第一勧銀の勘定系を残すことが決まった。
3行はこの報告書作成料として4000万円を予定していたが、割り勘にできないという理由で3900万円に値切った。
この報告書は延々と展開された議論を手際よくまとめ、「さしたる優位差はなし」と書いただけだったから、極めて高額だったといえる。

東証400億円超の損失を生む

2005年12月8日、東証マザーズ市場に公募価格61万円で新規上場したジェイコム株は、「1円で61万株」の売り注文が舞い込んだ。
みずほ証券担当者が、「1株61万円」とすべきところを誤ってしまった。
誤りに気付いたみずほ証券の担当者は、取消注文を出した。が、東証システムの売買システムは取消注文を受け付けない。
みずほ証券は、自ら48万株の買い注文を入れ株式を買い戻したが、400億円超の損失を出した。
発生直後は、誤発注を出したみずほ証券に非難が集まった。
ところがその翌日、富士通から「東証の株式売買システムに誤発注を取り消さない不具合があったことを突き止めた。
誤発注を取り消せない不具合が表面化するのは、以下の5つの条件を全て満たす時に限る。

これら5つの条件が重なった時に起動するコンピュータープログラムの一部のロジックに不具合があり、取消したい注文を「全数約定済」と判断してしまった。
市場の混乱の責任を取る形で、鶴島琢夫社長は12月20日に辞任。

今こそプロジェクトマネジメント

情報システムの開発プロジェクトで欠かせないのは、全体を統括する「プロジェクトマネージャー」である。
その人が許可したことは、社長の許可と同じでなければならない。
どんな情報システムのプロジェクトであっても必ず紆余曲折がある。
ビジネスを遂行する立場で物事を考えるため、特に意見が衝突しやすいのはシステム部門と事業部門である。
立場の違いによる意見の対立を解消するのは、経営陣の責任である。
三菱東京UFJ銀行は、旧東京三菱銀行と旧UFJ銀行のシステム統合プロジェクト「Day2」にあたって、システム部門と事業部門による議論がまとまらない時には、頭取をはじめ経営層が参加する「システム統合委員会」で結論を下すようにした。
経営陣の責任を明確化したのである。
三菱東京UFJ銀行は、システム部門の責任者をシステム開発プロジェクトの現場責任者として位置付け、さらに事業部門の責任者も明確にした。
経営陣、システム部門、事業部門それぞれの責任を明確にしてから、プロジェクトに臨んだわけだ。