全2672文字
PR

紙ベースの事務処理が残る

 STEPSの老朽化はみずほFGにおける事務処理の効率化も妨げていた。例えば営業店の担当者が何か取引を始めようとする際には、営業店端末の画面に5桁の番号を入力する必要があった。そうするとその番号にひも付く取引画面が表示された。GUI(グラフィカル・ユーザー・インターフェース)のような気の利いたメニュー画面は存在せず、担当者は取引ごとに5桁の番号を覚える必要があった。

 振り込み処理などの結果を示した帳票である「還元計表」は、店舗のプリンターから紙で出力する仕様だった。振り込みが失敗した場合は電話やファクスで連絡があり、営業店の担当者が振り込み内容を端末のキーボードから入力し直していた。

 古い勘定系システムは「One MIZUHO」の妨げにもなっていた。みずほFGは2013年7月、BKとCBを統合した。しかしシステムは一本化されておらず、BKの勘定系のSTEPSとCBの勘定系のC-baseは新システムが完成するまで残ったままだった。当たり前だが事務プロセスは勘定系システムに全面的に依存する。2行が1つになっても、BKの営業店は「STEPS店」、CBは「C-base店」と呼ばれ、事務プロセスが別々だった。プロセスを1つに統合したり、効率的なやり方に改めたりするのが難しかった。

図 銀行オンラインシステムの歴史
図 銀行オンラインシステムの歴史
かつては10年ごとに節目が
[画像のクリックで拡大表示]

3行の勘定系を1つに統合

 みずほFGは勘定系システムの全面再構築に当たって、STEPSとC-baseだけでなく、みずほ信託銀行の「BEST」という既存の3システムを廃棄し、新システムの「MINORI」に一本化する決断を下した。しかも一から作り直した。

 MINORIの最大の特徴は「SOA(サービス指向アーキテクチャー)」を全面採用した点にある。勘定系システムを複数のコンポーネントに分割し、コンポーネント間のつながりを緩やかにすることで、障害の影響を極小化する狙いだ。夜間のバッチ処理の仕組みも改め、大量の振り込みであってもオンライン処理するやり方に変えた。

 SOAの全面採用もバッチ処理の解体も「3度目のシステム障害を防ぐ」という課題に対する対策だった。

 みずほFGがMINORIの開発を本格的に始めたのは、2011年3月の2度目のシステム障害の後だ。当初はコンポーネントごとに順次リリースする方針だったが、途中で全てのコンポーネントを一括で更新するやり方に改めた。移行に伴うリスクを最小限に抑える狙いだった。

 景気が良かった1980~90年代に構築した基幹系システムを塩漬けして使い続けている日本の大企業は少なくない。老朽化した基幹系システムを2025年までに刷新しないと、保守運用が難しくなるだけでなく、デジタルトランスフォーメーション(DX)について行けなくなり、企業は「崖」を転がり落ちる――。経済産業省はそれを「2025年の崖」と表現した。銀行の3次オンは塩漬けの代表格だった。

 4000億円台半ばを投じる必要があったが、みずほFGはライバルたちに1歩先んじて「崖越え」を果たした。