みずほシステム統合の謎、参加ベンダー「約1000社」の衝撃

みずほシステム統合の謎、参加ベンダー「約1000社」の衝撃
岡部 一詩 日経 xTECH/日経FinTech 山端 宏実、中田 敦 日経 xTECH/日経コンピュータ
2019.09.06
有料会員限定
https://xtech.nikkei.com/atcl/nxt/column/18/00942/082900007/

※ この記事でも、「前代未聞の規模」」と言っているな…。

※ そうやって開発した、「前代未聞のシステム」なわけだ…。

※ ベンダーは、「とっとと逃げる」わけだよ…。

※ 支払いの様子は、どうだったんだろう…。

※ 「気持ち良く、支払ってくれた。」ならいいが、これが「散々、苦労かけた上に、渋ちんでした。」ということだと、「二度と、お付き合いするのは、ゴメンです。」ということになる…。

※ そうやって、ふと気づいて辺りを見渡すと、「誰も、いなくなっている…。」…、という話しになるんだよ…。

『新システム「MINORI」の開発に参加したITベンダーの数は、前代未聞の規模に膨れ上がった。取りまとめ役であるみずほ情報総研(IR)の1次委託先だけで70~80社。2次委託先、3次委託先を合わせると約1000社に上る。総務省の調査によると情報通信業を手掛ける企業数は5474社で、子会社や関連会社を含めても9806社(2015年度)。実に日本中のITベンダーの少なくとも約1割が集結した。

 とりわけ重要な役割を担ったのが富士通、日立製作所、日本IBM、NTTデータの主要4ベンダーだ。MINORIを構成する業務アプリケーションの大半を開発した。

 富士通は銀行業務の中核となる「流動性預金」を中心に担当。日立は「外国為替取引」などを手掛けた。日本IBMはメインフレームをはじめとする基盤提供を主な役割とし、NTTデータはPMO(プロジェクト・マネジメント・オフィス)の支援を担った。

 主要4ベンダーを含め、プロジェクト終盤で組織した「トップマネジメント定例」の構成企業16社が、外部委託した全開発工数の約4分の3を占める。

図 主要機能と担当ベンダー
実績を重視して選定
[画像のクリックで拡大表示]

「難しい判断」と富士通

 みずほ銀行がベンダー選定で重視したのは実績だ。流動性預金が分かりやすい。流動性預金は特にトランザクションが多い業務アプリケーションであり、ミッションクリティカルな運用が求められる。日本IBM製メインフレーム上で稼働させることを決めたが、アプリケーションの開発は旧システム「STEPS」を開発・保守してきた富士通に委託した。「流動性預金は銀行業務の根幹。長年信頼関係を築いてきた富士通が最適と判断した」と、みずほ銀行の石井頼幸IT・システム統括第一部副部長は説明する。

 富士通の馬場俊介みずほ事業部事業部長は、「当社は既存システムを手掛けてきた立場。IBMの基盤上でアプリケーションを開発する判断を下すのは正直難しかった」と明かす。とはいえ、これだけの大型案件に参画しないわけにはいかない。富士通はみずほフィナンシャルグループ(FG)の提案を受け入れた。

 基盤とアプリ開発のベンダーが異なることで特有の難しさも生じた。富士通はIBMの基盤上で動作するCOBOLプログラムを開発しなければならなかった。「プロジェクトの初期段階である2012~2013年にかけて、膝詰めで技術検証した」と、日本IBMの林勇太金融第二ソリューション・デリバリー 統括部長は振り返る。結果として、富士通の開発ツールで生成したプログラムに起因する大きなトラブルは1度もなかったという。

 MINORIの開発においてITベンダーは単なる手足ではない。みずほFGはプロジェクトの序盤と終盤に特別な会議体を発足し、主要ベンダーの知恵やノウハウを活用している。

図 みずほ情報総研の委託先体制

国内ITベンダーの少なくとも1割が参加
[画像のクリックで拡大表示]

左から日立製作所の服部善成事業執行役員、富士通の馬場俊介みずほ事業部事業部長、日本IBMの林勇太金融第二ソリューション・デリバリー統括部長、NTTデータの荻田直人メガバンク統括部第一開発担当部長
[画像のクリックで拡大表示]

『有識者会議を週3回ペースで開催

 最初に発足したのが、新システムのアーキテクチャーや実装方針を議論する「技術アドバイザリーデスク」。2012年11月のことだ。みずほ銀行やみずほIRのメンバー10人に加え、主要4ベンダーから各社2人ずつ、部長級の有識者が出席した。

 「所属企業の意識は捨てて、みずほ銀行にとって最適なシステムの在り方を議論してもらった」と、みずほ銀行の間仁田幹央IT・システム統括第一部次長は振り返る。ベンダーの垣根を越えて議論するため、個別にNDA(秘密保持契約)も締結。情報交換の活性化を促したという。

 技術アドバイザリーデスクでの議論は、既に採用が決まっていたSOA(サービス指向アーキテクチャー)の実現方法が中心だった。最も苦労したのが各業務アプリケーションを構成する「商品サービス」の粒度だ。利用頻度が高いサービスは粒度が小さい方が再利用性が高まる。逆にあまり使われないものは、大きい粒度でまとめた方が効率が良い。この最適解を探るため、多い時で週3回、それぞれ2時間に及ぶ議論を重ねた。

 プロジェクト終盤の2017年5月には、3つの会議体からなる「トップマネジメント定例」と呼ぶ取り組みを始めた。参加メンバーはMINORI開発の大部分を担う16社だ。「この16社が抱える問題を解決していけば、プロジェクトを正確な方向に導けると考えた」と、みずほIRの向井康真社長は話す。開発完了とシステム移行を目の前にして、開発の進捗や課題を正確に把握し、移行準備に万全を期す狙いがあった。

関連記事:みずほシステム統合の謎、勘定系の「老朽化」問題は解決したのか
関連記事:みずほシステム統合の謎、時代遅れのバッチ処理は「解体」できたのか
関連記事:みずほシステム統合の謎、メインフレームは無くせたのか』