みずほの「サグラダ・ファミリア」
いま、エンタープライズIT業界で話題の本がある。『みずほ銀行システム統合、苦闘の19年史』（日経BP）だ。
刊行からわずか2日で増刷となったIT系書籍として異例のベストセラーで、ビジネスマンはもちろん、多くのIT専門家や論客が読んでいる。昨今ようやく重要課題として意識する企業が増えてきた「2025年の崖」の、意図せぬ先行事例としても注目されているのだろう。
なにせ、みずほ銀行の勘定系システムは「IT界のサグラダ・ファミリア」と揶揄されるほど複雑怪奇をきわめ、日本を代表するITブラックボックスと化していた。2002年、2011年には老朽化による大規模障害を引き起こし、悪い意味で注目を浴びてもきた。そのシステム統合の全容が記されているとなれば、関係者ならずとも気になるはずである。
かかった費用は4500億円
みずほ銀行の新勘定系システム「MINORI」は、2011年6月から本格的な開発に入り、まる8年後の昨年7月に本格稼動した。名前の由来は、みずほ＝瑞穂（みずみずしい稲穂）＝実り、ということだろう。総費用約4500億円、関与したITベンダーは日本IBM、日立製作所、富士通、NTTデータのビッグ4をはじめ約1000社、従事したエンジニアは延べ35万人／月という。前代未聞の超ビッグプロジェクトだ。
1999年に富士銀行・第一勧業銀行・日本興業銀行の3行が経営統合の契約を結び、みずほホールディングスが発足して以来、懸案だったシステム再編・構築の挑戦は2度にわたり挫折。「19年越しの悲願」が実ったのが昨年のことだった。「MINORI」の名前について「みずほのMと祈り（INORI）が真の由来」という話にも説得力がある。
同行のシステム統合を語る際に避けて通れないのは、前述の2度にわたる大規模なシステム障害だ。
1度目はみずほ銀行としてスタートした直後の2002年4月1日、営業初日に発生したATMの障害から始まった。翌日、ATMは回復したが、今度は口座振替の遅延が発生。さらに二重引き落としが約6万件、1日には口座引落とし漏れ40万件が次々と判明した。ようやく混乱が落ち着いたのは5月のゴールデンウィークが明けてからのことで、損失は18億円にのぼったという。
2度目は2011年3月、東日本大震災の直後、義援金の振込みが集中したことを引き金にシステム障害が発生した。ホストコンピュータの夜間一括処理（バッチ処理）がオーバーフローし、その修復に手間取って、オンラインシステムとATMが停止した。ピーク時に滞留した処理は、給与振込みなど220万件に及ぶ。3月15日に表面化したシステム障害は、9日後の24日に落ち着いた。
トラブルの詳細と、みずほ銀行がどのように対応したかについては、ぜひ本をお読みいただきたいが、本稿ではみずほ銀行が直面した課題を見つつ、経済産業省が警鐘を鳴らす「ITシステム2025年の崖」への教訓を拾ってみたい。みずほ銀行が受けた試練を、これから他の日本企業も受けることになるかもしれないからだ。
勧銀・興銀・富士銀それぞれの思惑
同行のシステム統合プロジェクトは、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月、富士総合研究所、興銀システム開発と合併し、みずほ情報総研となっている。
東日本大震災直後の悪夢
2回目のシステム障害は、東日本大震災の4日後、2011年3月15日に表面化した。
直接の原因は、3月14日の月曜日、震災義援金の振込みが集中したことにあった。口座に設定された1日当たりの受付リミットを超えたデータは、オンラインを停止したあと、夜間に一括で処理される。「電子計算機」のころ、伝票を束（batch）にして処理したことから、「バッチ処理」と称される。
当日の午後10時過ぎ、システムが異常終了（アベンド）した。バッチ処理にはリミットが設定されていたのだが、オペレータはそれを知らなかった。これが悪夢の始まりとなった。
処理の途中でアベンドしたために、データの一部が失われた。それを復旧するのに時間がかかり、さらにアベンドの原因を確認するのにも時間がかかった。未処理データは38万件にものぼったが、翌日午前6時までにバッチ処理を終了しないとオンラインを起動できない。
15日未明に報告を受けたIT担当役員が「オンライン再開を優先するように」と指示したのだが、間に合わなかった。オンラインが再開した同日午前10時25分まで、入出金・振込みの処理を行員が手作業で行った。
ところがその後、再開したシステムが振込み処理を実行したので、二重振込みが発生してしまう。さらに同日、携帯電話による義援金の振込みが加わった。夜間バッチは完全にオーバーフローし、6万件の積み残しが出た。15日と同様に16日もオンラインが起動できなくなり、手作業による処理がまた二重振込みを発生させることになった。
15日の夜間バッチでもオーバーフローが出たが、経営陣は今度はバッチ処理を優先するよう、現場に指示を出した。前日と一転して、オンラインの開始を遅らせる判断を示したのだ。これが、二重振り込みを増やすことになった。
バッチ処理のオーバーフローがオンラインへの切替えを困難にし、手作業による処理が二重のミスを生む。悪循環は18日金曜日まで続いた。
混乱から立ち直り、ようやく計画的な復旧に手が着いたのは19〜21日（春分の日）の3連休である。システムを全面的にストップして懸命の作業を続けたことによって、ピーク時には220万件以上あった振込みの積残しは、連休明けの22日に16万件、23日に1000件と減少し、24日に完全に解消した。こうして同行は、給与振込みが集中する25日のリスクを辛くも乗り切ることができたのだった。
探っていけば縦割り組織の弊害（連絡・連携ミス、情報の不共有）や判断ミスも指摘できるが、やはり最大の原因はバッチ処理とオンラインの切替えだ。帰還する第1次攻撃隊を先に収容するか、それとも第2次攻撃隊を発艦させるか……手順の混乱が招いた、ミッドウェーにおける大日本帝国海軍の壊滅的敗北を見る思いがする。
三度目の正直
この苦い教訓を受けて、2011年6月から開発作業が始まった新勘定系システム「MINORI」は、2004年から始まったシステム刷新計画（ここでは「前期」とする）の仕切り直しである。計画では2011年3月末までに完成しているはずだったが、進捗が遅れ、周辺システムを手がけているまさにそのとき、東日本大震災のシステム障害が発生した。
MINORIはみずほ銀行だけでなく、「BEST」と呼ばれたみずほ信託銀行の基幹システムも統合している。2017年7月に完成していたが、STEPS、TOP、BESTの3システムからデータを移行する必要があった。ある意味で恥ともいえる「完成遅延」の発表を2度も行い、テストと本番リハーサル、事務員、行員のトレーニングに2年の時間を要した。3度目の失敗は許されない、というなみなみならぬ決意が読み取れる。
旧システムが利用していたメインフレームは19台だったが、MINORIは4台だ。基幹業務はCOBOLで構築され、定期性預金、与信取引、外国為替取引といったアプリケーションとプロトコル変換にはJavaとLinux/UNIXサーバーが使われている。また、アプリケーション共通基盤と全店共通の取引元帳がシステムの負荷を分散・軽減する（次ページの図）。さらに昨年3月には、アマゾンが提供するクラウド基盤「AWS」の採用にも踏み切った。
SOA（Service-Oriented Architecture：サービス指向アーキテクチャー） と疎結合の全面採用、データの逐次処理など、一般読者の方には馴染みのない言葉かもしれないが、エンタープライズIT界隈の人には興味津々なネタが満載だ。ちなみにSOAは機能やサービスを一つの単位としてクラウド／Webで提供する技術基盤、疎結合は個々の機能・サービスを独立させてシステム変更の影響を最小化する技術、データの逐次処理はバッチ処理の解消、と理解していい。
みずほフィナンシャルグループのホームページから
これで安心、とはいかないが
さて、かねて経産省が警鐘を鳴らす「ITシステム2025年の崖」は、1980年代に構築された老朽システムを捨てて、クラウド／Webに対応したリアルタイム型、ないしは逐次データ処理型（バッチ処理からの解放）のデジタルトランスフォーメーション（DX）に向かう道を示すものだ。
みずほ銀行は、様々なしがらみから老朽化したシステムを使い続けざるを得ず、痛い目にあった。システム統合について経営陣の方針がゆらぎ、現場任せにしたために、勧銀／富士銀両陣営の顔を立てるためにRC方式で妥協した。それが老朽システムを延命させ、さらに不幸な天災が重なった。
STEPSは初稼動から31年間使われ続けた。システムの平均耐用年数の1.5倍から2倍という長寿であるが、 ITの世界では長寿は決して誇らしいものではない。
その痛みに裏打ちされ、満を持して稼働し始めたMINORIではあるが、本番への移行を含めて4500億円もの巨費を要したのはどうなのか、このキャッシュレス化の時代に内外900超の支店、全国7200か所・5万台の店外ATMをいつまで温存するのか、等々の問題点はまだまだある。これでずっと安心、というわけにはいかないだろう。
