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

東日本大震災直後の悪夢

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をいつまで温存するのか、等々の問題点はまだまだある。これでずっと安心、というわけにはいかないだろう。