みずほ銀行のマルチベンダー化について解説する

雑記 技術ネタ

はてブではすでにボロクソ言われてますね。フラグ立ちまくりと。ちょっとこれは解説せねばなるまいか…

以下はすべてとある人からの伝聞です。伝聞なんだってば。

みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。

［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注 | 日経 xTECH（クロステック）

周知の話だけすると、現行システムにおいては

  • 勘定系（ホスト）…富士通
  • 営業店端末システム…富士通
  • インターネットチャネル（ダイレクトバンキング）…IBM
  • 情報系システム…IBM
  • 周辺系（中継系）…IBM
  • 外部接続系…日立
  • コーポレート銀行勘定系…日立

等々、すでにここに出てきているベンダーがマルチベンダーの状態で仕事をしている。また、ここ重要なところだと思うけれども、ベンダーは

  • アプリも含めて丸投げ
  • ミドル層（あるいはフレームワーク層）まではベンダー、あとは内製化（あるいは別協力会社）

という二通りの開発体制をとっている。勘定系のコアのアプリも富士通が直接作っているわけではなかったりします。

なので、このマルチベンダー体制においても、同様の開発体制がしかれることになるでしょう。
ちなみに、別の協力会社ってのは例えば２年ほど前にポロッとみずほの次期システムのことを漏らしちゃったDTSとかそういう会社ね。

ここで重要なのは、NTTデータというのは今までみずほ銀行の仕事にあまり絡んで来なかったというところ。
ただ、この絵を見れば分かる通り、NTTデータの作ったシステムにインタフェースするシステムを作るようですから、それほど違和感はないですね。なんかパッケージ入れてちょっちょっと作る感じ。

さて、この絵なんですが、システム基盤とアプリケーションでベンダーが違うというなかなかフラグっぽい絵になっています。記事でも触れられている通り、Javaを使って作るということになっていますから、基盤がなんであっても問題無いと思いがちですが、実際には、当然ながらベンダーなりのフレームワークが導入されるので、その上に別ベンダーが開発として乗るのはやっぱりちょっと違和感がありますよね。
しかし、よく見ると日立の基盤は（Linux/AIX）となっているので、IBMの作る部分については箱はともかく、OSはIBMが乗るようです。また、富士通の基盤でNTTデータが作るってのはNTTデータ的にはいつものことなのでそれほど問題無いと思われます。
なので、ここで問題になるのは、IBMのメインフレームで富士通のアプリというイレギュラーなところ。これだけは…難しいのではないかと…
理由としては、IBMが使っているメインフレームのオンラインフレームワークであるSAILについては富士通関連の会社では技術を持っていないのではないかと思われるところと、DBがDB2になる場合、基盤周りを誰が持つのかというところです。

流動性預金のアプリケーションの動作プラットフォームには、日本IBM製メインフレームを使う。みずほ銀は「CIF（カスタマー・インフォメーション・ファイル）」や「処理フロー制御」など、各アプリケーションが共通して必要とする機能を既に「共通基盤」として日本IBM製メインフレーム上で開発している。この共通基盤上で、流動性預金のアプリケーションを動かす。

［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注 | 日経 xTECH（クロステック）

この「共通基盤」については去年の６月時点ですでにみずほ銀行から発表されています。

次期システム構築を加速し、平成２４年度末を目途に業務共通基盤を完成させます。以後、平成２７年度末を目途に順次、預金・為替・融資・外為・信託といったコンポーネントシステムをリリース、併せて基幹情報系もリリースいたします。

http://www.mizuho-fg.co.jp/release/pdf/20110629release_jp.pdf

なので、この開発においては、すでに完成した業務共通基盤を使うということになります。共通基盤を同時に開発するわけではないので、リスクについてはそれなりに限定されます。ようは、この開発って、システム刷新の開発の２段階目なんですよね、どうやら。

ここまでの話でわかるとおり、業務ごとにコンポーネント化されることになるため、それなりにベンダーごとに疎なシステムを作ることが可能となります。
ただ、従来一つのホストでやっていた取引をコンポーネントに分割する（イメージとしてはSOAでしょう）ことになるため、トランザクション分解点の問題が発生します。ミッションクリティカルなシステムにおいてトランザクション非同期は大きな問題ですから、コンポーネント間できちんと協調できるシステムを作れるかどうかが肝ですね。幸い、大枠の仕組みはできています。

ただ、一個大きな問題が。

3行が現在使う勘定系システムの担当ベンダーは、みずほ銀が富士通、みずほコーポレート銀が日立、みずほ信託が日本IBMだ。3社は結果的に、みずほ銀からの受注を継続できたことになる。

［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注 | 日経 xTECH（クロステック）

結局これだってこと。発注額の大きさとそれに伴うリスクの分散という意味では正しいことではあるんですが、果たしてそれでいいのかどうか。

この記事には出て来ませんが、みずほ銀行のシステムにおいて大きな役割を果たすのは、システム子会社であるみずほ情報総研と、そこにぶら下がる多数の（業務や現行システムを良く知っている）協力会社です。ベンダーもある意味その範疇ではあります。この開発がうまくいくかはいかにしてみずほFG、みずほ銀行、みずほ情報総研がベンダーを喧嘩させないでやっていくかというところが大きいと思うのですが、銀行のセクショナリズムは半端無いので、失敗するとしたら分割発注のせいでも、ベンダーの実力不足でもなく、そういうところが原因になるんじゃないかと思っているんですけどね。