みずほ銀行を苦しめた「悪夢の記録」が異例のベストセラーになったワケ(2)

勧銀・興銀・富士銀それぞれの思惑

同行のシステム統合プロジェクトは、1999年8月から2004年の暫定期、2004年から2011年3月までのシステム刷新前期、2011年6月から2019年7月までの後期、この3つに分けられる。システム障害の1度目は暫定期、2度目はシステム刷新前期に起こっている。

企業の経営統合の際、使用しているシステムを統合するのは必然だが、みずほ銀行がつまずいた原因は、まずシステム統合の指針がぐらついたことにあるようだ。

1999年8月の経営統合発表時点では、リテール向けの勘定系システムは第一勧業銀行（以下勧銀）が使用していた「STEPS」（ホストコンピュータは富士通機）、ホールセール向けは日本興業銀行（以下興銀）が使用していた「C-base」（同日立機）にそれぞれ片寄せ（統一）し、2002年4月の新銀行の発足と同時に、システム刷新に着手する方針だった。

ところが、勧銀のSTEPSが稼働したのは1988年と古く、営業店の行員は取引きごとに5桁のコードを入力しなければならないなど、使い勝手が良くなかった。西暦2000年（Y2K）問題をクリアしたあと、新銀行発足後の新システムを検討する中で、旧富士銀の「TOP」（ホストコンピュータはIBM機）を継続使用する案が勢いを盛り返した。

そもそも、当初STEPSの継続利用が決まりかけた背景には、勧銀がメインバンクを務めていた富士通の金融市場におけるシェアを堅持し、2000人の従業員を抱えるIT子会社・第一勧銀情報システムの雇用を守るねらいがあったとされている。当時は「金融ビッグバン」の真っ只中で、富士通は東京銀行、さくら銀行の勘定系システムを失っていたので、富士通にとってみずほでの継続使用は死活問題であったことは想像に難くない。

2002年、最初のトラブル発生

そこで妥協案として、STEPSとTOPの間に中間サーバーを置いて、データを交換する「リレーコンピュータ（RC）」方式（あるいは「ゲートウェー」方式）が編み出された。提案したのは日本IBMだったとされる。富士銀のTOPが残存すればIBM機も継続され、システム刷新後もIBMがメインコンピュータを受注できるかもしれない、との目算もあった。

そんな中、2002年4月に発生した最初のシステム障害は、このRC方式ではなく、STEPSと全銀システム、都銀キャッシュサービスシステム「BANKS」をつなぐ要となる「対外接続系システム」の障害が原因となった。店舗内外のATMと、旧富士銀系のTOPが対外接続系システム経由で接続していたため、トラブルが全体に及んでしまったのだ（下図）。

2002年4月時点のシステム構成（『みずほ銀行システム統合、苦闘の19年史』を参考に筆者作成）

もちろん、RC方式による擬似的なシステム統合にも問題があった。STEPSのプログラミング言語はCOBOL、TOPはPL/1で記述されていた。システム間でプログラミング言語が異なるため、保守・改造の効率が悪く、要員も手間もコストもかかった。またSTEPSとTOPでは、支店や口座、取引相手のコード、データ形式も異なっていた。この齟齬がシステム障害の早期復旧を阻んだとも指摘できる。

（注）第一勧銀情報システムは2004年10月、富士総合研究所、興銀システム開発と合併し、みずほ情報総研となっている。