まだ終わっていないけど、みずほ銀行のシステム統合プロジェクトはどこに原因があるのだろうか

プロジェクトとは、有期限性の業務的な活動です。限られた期間の中で達成したい業務目的を達成するために必要となるリソースを確保して遂行します。リソースには、人・物・金と限定した時間が含まれます。

ところで、みずほ銀行のシステム統合プロジェクトはこれまでのプロジェクトのスケジュールをさらに伸ばすことにしたようです。

itpro.nikkeibp.co.jp

 

 プロジェクトの目的はより具体的で定量的なQulity/Cost/deliveryに設定されます。このQCDは三角形で表現され三角形の頂点にQCDを配置し、この3点のうちどれを最優先事項とするのかを決めておくことで、プロジェクト全体として判断をしなければならない事態になったときにそれに従い意思決定します。

みずほ銀行のシステム統合の場合、公表されている事項から

Quality > Delivery > Cost

の優先順位がつけられていると想定できます。それは度重なるリリース時期の延期を品質の確保として公表していることからも推測できます。

1度目の延期では、開発完了を2016年3月から同年12月と、延長後の期限を示した。

 DeliveryとCostですが、Deliveryである納期はリリース時期を延伸しているので優先順位が低いことがわかります。

一方、Costについて下世話な話をすれば、期間を1日でも延長すると判断すれば、システムエンジニアが1000人いれば1000人日ですから、たった1日で人月換算して50人月の追加コストが余計に掛かるわけです。
#1000人は便宜上の数値です。

それを1回目のリリース時期の延伸を決めた時点で9ヶ月伸ばしたわけですから、1回目のリスケで450人月を追加コストをみずほ銀行のプロジェクトオーナーは承認していることになります。このリリースの延期これだけで5億以上は人件費だけで投入していることになります。

楽しい邪推はここまでにして、みずほ銀行はこのプロジェクトを実施することを公表しなければならなかったのでしょうか。

はてブのコメントで書いたとおり、行内システムの再構築として淡々とやっていればここまで騒がれなかったのではないか、と思うのです。もちろん、行内の資金を投資してプロジェクトを行うのですから、株式公開企業としては株主には説明をする必要があります。でも、それはIRの範疇でやっておけばいいわけです。預金者の立場ならATMの端末が入れ替えになればTATが早くなるとか、スマホでサービスを受けられるとかそう言ったことしか気にならないし、そう言ったことはリリース後に初めて使うときに「何か変わった」と感じるくらいでしかありません。

みずほ銀行や他のメガバンクに限らず、監督省庁には事前にご説明はして余計なお小言や横槍が入らないような対策は必要としても。

このシステム統合プロジェクトは、ウォーターフォール以外は考えにくいのは、銀行業務で新規業務のシステム化ではないからです。つまり、最初からスコープがはっきりしているプロジェクトであるということです。

であれば、システム開発手法ウォーターフォールを採用することに問題はないように思えます。それでは他にリリース時期が延伸している原因があるのでしょうか。

プロジェクトが目的を達成するためには、プロジェクトに必要なリソースが必要でそれの1つが欠ければ、他のリソースを増やすことが必要になったり、バランスが崩れれば新たなプロジェクトのリスクが増えるだけです。 

とてもベーシックなことですが、プロジェクトは目的を達成するためのチームとしてのスキルセットが必要で、それが足らなければ目的を設定したタイミングでのリソースでは実現できません。他のリソースも必要になりますがリリース時期を延伸していることから時間のリソースに制限はそれほど強くないし、資金的なリソースも品質に比べ強くはないと言えるでしょう。

チームに必要なスキルを持ったメンバ、特にキーパーソンになるポジションの人材を、ーこれにはみずほ銀行側も含まれますがー、が集められなかったことが原因でしょう。

では、なぜ集められなかったのか。銀行業務はみずほ側が知っているとしても、銀行業務を知っているシステムエンジニアはどうだったのでしょうか。3行をまとめられるPMOの体制は作れたのでしょうか。システムエンジニアにどのようはスキルとスキルレベルを持った人材がどこに必要かを誰かが見極められたのでしょうか。

リリース時期を延伸できるくらいですから資金的には問題はないのでしょうし、納期は延伸しているのですから、問題はそれを実現する人的リソースのスキルセットではないかと思うのです。

みずほ銀行のいち利用者としてはプロジェクトの立て直しを願うばかりですが。