読者です 読者をやめる 読者になる 読者になる

プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

とりあえず、移行が1年延期が発表されたみずほ銀行のシステム統合の行方を占ってみる

みずほ銀のシステム統合、1年遅れる見通し 開発に手間:朝日新聞デジタル

 

みずほ銀行のシステム統合&刷新プロジェクトですが、いろいろトラブっているみたいですね。。。

 

オッサンの過去のシステム刷新やシステム統合の経験から、ちょっと状況を占ってみようかと思います。

 

※決して中の人ではないので、あくまでも以下の記載は推測なので注意。

 

おさらい:みずほ銀行が今行っているシステム統合&刷新プロジェクト

システム統合における最大のポイントは、勘定系システムを全面刷新することだ。既存の業務にとらわれず、銀行業務のあるべき姿を描き、それを実現するシステムを構築する。

みずほ、復活への再挑戦 - 史上最大級のシステム統合に挑む:ITpro

 

みずほ銀行では、過去のシステムの老朽化と複雑化によるシステム負債の解消のためにアプリケーションを作り直すシステム刷新と、みずほ銀行(BK)、みずほコーポレート銀行(CB)、みずほ信託銀行(TB)との合併のためのシステム統合を同時に実施しようとしております。

 

新システムの開発と、システム統合のための移行、2種類の要件が異なる対応が重なっているわけですね。非常に難易度が高い対応です。

 

 

考えうる遅延原因『フィット&ギャップ分析の不調』

さて、みずほ銀行のプロジェクトですが、スタートは2012年末から。

おおよそ、現在の時点でマル1年経った状態です。

 

もともと予定していた移行日は2016年春であることから、正常にプロジェクトが進捗していれば、おそらく開発・単体テストが概ね完了し、刷新後の新システムでコンポーネント同士をつないだ連結テストが開始している頃かと思います。

 

ところが、ここに来ておおよそ1年の計画後ろ倒しとなってます。

一般に、要件の増加など、システム開発の遅延原因となる原因は幾つか考えられますが、今回はシステム刷新であることを考えると「フィット&ギャップ分析の不調」があるんじゃないかなって予想してます。

 

今回の様なシステム刷新を行う場合、通常であれば過去のシステムの機能を移植したり、システム要件から作り直すことが多いです。この時、フィット&ギャップ分析*1を行うのですが、往々にして要件が漏れる部分だったりします。

  

例えば、端数計算。個々の取引金額ごとに端数を丸めて計算し合算するのか、取引金額を合計して端数を計算し丸めるのか、など計算の流儀がシステムによって違ったりします。

こういった細かいギャップ分析は、一番最初の対応方針を決める段階では見つからなかったものが具体的に設計開発を行っていく中で見つかったりします。

 

今回マルチベンダー開発を行っていたということで、各サブシステムは資産再利用のため元のベンダーが担当するシステムを引き継ぎつつ再設計されていると予想されます。おそらく、最も業務影響の大きいBKのシステムが基本となるのでしょうけど、要所要所にはCBやTBのシステム仕様が持ち込まれると予想してます。

となると、必然的に無数のギャップが混在しており、かつBKに仕様を揃えるとCBやTBなどからの持ち込み仕様は作り直しなんて自体がアチラコチラで起きているんじゃあないかなと推測できますね。

マルチベンダーにより、元々のシステム知識を持つ人材を上手く活用しようとしたのでしょうけど、裏目に出て自分の担当している元々のシステム仕様を守りに動き出すとプロジェクトは途端に停止してしまいますしね。

 

BKやCBやTBのユーザまでが、自分らのシステム領域を守ろうとして旧システムの仕様を固持すると、システム要件を巡ってのドロドロとした政治劇の始まりです。

 

このようなマルチベンダー、マルチユーザ、かつ、メガバンク特有の縦割りなど利害関係者が複雑な状況、よっぽど高スキルなPMがいないとプロジェクトは大炎上。塵も残りませんね。。。

おそらく、今回のプロジェクト、マネジメントは情報子会社のみずほ情報総研(MHIR)が担当しているんでしょうけど、おそらく絶賛炎上中なのじゃあないかなあ

 

 

とまあ、システムギャップは厄介です。全てを洗い出し仕様確定しないと個別のサブシステム設計には入れません。

そういった意味では、設計に手間取っているとの報道ですけど、おそらく要件定義に手間取っているが正解かなって気がします。

 システム刷新でよく見かける光景ですね。

 

今後のスケジュール予測

とまあ、こんな感じでおそらく要件定義と仕様設計の段階でおそらく手間取っているのではないだろうかと予想しているのですが、計画開始から1年たち、1年の延長を発表したことを考えると、おおよそのフィット&ギャップ分析は完了したのではないか、と考えられます。

 

結果、スケジュールは以下のように変更したのではないかなと思われます。

f:id:getlife:20140228011350p:plain

 ※システム刷新&移行プロジェクトという特性からテスト期間は長めでしょうね

 

影響調査などの要件策定部分が長引いた形となるのでしょうけど、結果として全体の開発規模は微増との見通しがたった、単純に開発工程が後ろ倒しになったけど、移行の時期めどが立ったって感じで移行延期が発表されたのじゃないかなと予想です。

 

おそらく、監督省庁(金融庁)からの監視の目も厳しいんじゃないんでしょうか。 このようなプレッシャーの中、プロジェクトが進展していることを強調するためにも発表があったのかなとも伺えます。

 

 

さて、上記のような形で要件定義の延期がおおよそ予想される現在、今後のプロジェクトの行方ですが。。。まだまだ厳しいんじゃないかなって思われます。

 

おそらく、まだ本格的な開発に着手できてないです。

となると、まだまだ開発リスクが残っている状態です。スケジュールは障害などによりいかようにも遅れます。

また、アプリケーション開発以上に厄介な移行開発が残ってます。おそらくこちらの要件定義までは手が回ってないんじゃあないかなあ。。。

となると、移行要件を策定するあたりでまた一揉めするんじゃあないかなと予測。

 

移行まで完全に終わらせようとするとなると、もう一度ぐらいはスケジュール変更のお知らせが来てもおかしくないんじゃあないかなと思われます。

 

※多分、来年の夏ぐらい、システムテストを行いながら、移行テストを実施しているあたりで。。。

 

 まとめ

とまあ、みずほ銀行システム統合プロジェクトの行方を占ってみたんですけど、まだまだ厳しそうな気がします。

  • おそらく、プロジェクトは仕切り直しでほぼスタート状態付近。まだまだ開発リスクは残った状態かな
  • 移行要件など、大物への対応はこれから。また問題が発生する恐れもある

 

ただ、今回のプロジェクトは、過去の第一勧銀の時のシステム統合と異なり、プロジェクト延期を宣言出来るだけましとも言えます。

 

正直、対応されているベンダーの方の苦労が忍ばれます。

このような遅延プロジェクトでは、プロマネのストレスは恐ろしいことになりますね。。。まだまだ先は厳しいと思いますけど、がんばってください。

 

※繰り返しですが上記内容は、部外者のオッサンの勝手な占いなので、あくまで推測と理解してお読みください。

 

以上

 

 

追記

神秘かつ壮大な銀行システム建造物、みずほ銀行の「桜田ファミリア」 : 市況かぶ全力2階建

 

こちらでもまとめられてましたね。。。

 

システム障害はなぜ二度起きたか みずほ、12年の教訓

システム障害はなぜ二度起きたか みずほ、12年の教訓

 
銀行大統合 小説みずほFG (講談社文庫)

銀行大統合 小説みずほFG (講談社文庫)

 

 

*1:フィット&ギャップ分析 ・・・ パッケージなど、新たに導入するシステムと現在のシステムで提供している機能との比較を行い、業務ギャップを洗い出す分析のこと。要件定義で実施

広告を非表示にする