Akio's Log

ソフトウェア開発、プロジェクトマネジメント、プログラミング、ランニングなどなど

みずほ銀行次期システム関連のまとめ(2016/11/24 追記あり)

(追記1:2016/7/11 7/7以降のブログ記事などを追加)
(追記2:2016/11/24 延期発表の記事を追加)


こんばんは。SE兼PM見習いです。
例のみずほ銀行の次期システム開発が話題になってますね。

blog.livedoor.jp
blog.livedoor.jp


毎年この時期に、みずほ案件がグダグダだよね、という情報が出てくるのはもう恒例行事となってますが、開発工程終盤を迎えていよいよヤバイ状況が隠しきれなくなっているようです。


趣味が悪いと言われますが、デスマウォッチャーでして、特にこのみずほ銀行案件をウキウキとウォッチングしているのですが、ここでブックマークしている過去の情報を時系列に振り返ってまとめてみたいなと思います。

2002年〜合併時のシステム障害〜

次期システム案件の話に入る前に、みずほ銀行合併時の大規模システム障害に触れておく必要があります。


https://ja.wikipedia.org/wiki/%E3%81%BF%E3%81%9A%E3%81%BB%E9%8A%80%E8%A1%8C#2002.E5.B9.B44.E6.9C.88.E3.81.AE.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0.E3.83.88.E3.83.A9.E3.83.96.E3.83.ABja.wikipedia.org

  • 自行のATMの停止(通信エラー)が大半の店舗で断続的に発生(前月にも旧第一勧銀店で小規模な停止が発生していた)。
  • ATMで現金の預け入れ操作をすると取引未完了のまま(残高反映されず)となり、現金が返却されない。
  • ATMで預金引き出しの操作をすると、残高が反映されているのに現金が出金されずエラーとなる。
  • メインコンピュータおよび全銀協ネットへの接続が不安定となり、ATMが稼働していても振込操作が行えない。
  • みずほ銀行キャッシュカードでE-net・BANCS・MICS提携ATMでの取引が出来ない。
  • 銀行振込入金の日数単位での遅延。

障害対応にあたっていたSEの方が過労自殺にまで追い込まれました。

発生した技術的な問題や原因などはこちら。
d.hatena.ne.jp

根本的な問題として、合併した3行の勢力争いが原因のようです。
news.livedoor.com

書籍にもなってます。

システム障害はなぜ起きたか~みずほの教訓

システム障害はなぜ起きたか~みずほの教訓

失敗事例データベースにも詳しいです
www.sozogaku.com

2009年〜先行した東京三菱UFJ銀行〜

みずほに先駆けて、三菱東京UFJ銀行が11万人月・2500億円という大規模統合プロジェクトを問題なく完遂しました

itpro.nikkeibp.co.jp

プロジェクトに参加した技術者は、銀行とシステム関連会社の要員、IT企業の社員を含めピーク時には6000人に達する。投資額は2500億円、開発期間は3年弱、総工数は11万人月に及んだ

こちらも書籍化

システム統合の「正攻法」

システム統合の「正攻法」

書籍へのコメント

http://dain.cocolog-nifty.com/myblog/2010/05/post-f2ae.htmldain.cocolog-nifty.com

Day2は、プロジェクトとしては最悪の経営判断が下されていたにもかかわらず、成功させてしまった事例なのだ。最悪の判断とは、システム統合の方式だ。どちらかのシステムに合わせる片寄せ方式ではなく、元のシステムを残したまま東京三菱系列のシステムを元に差分開発したという。そして、その差分を載せた新システムに東京三菱系(IBM)とUFJ系(日立)を統合したのだそうな。

2011年〜再び大規模なシステム障害〜

東日本大震災で日本中が大変だったときにも、派手にやらかしてます。

https://ja.wikipedia.org/wiki/%E3%81%BF%E3%81%9A%E3%81%BB%E9%8A%80%E8%A1%8C#2011.E5.B9.B43.E6.9C.88.E3.81.AE.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0.E3.83.88.E3.83.A9.E3.83.96.E3.83.ABja.wikipedia.org

東北地方太平洋沖地震(東日本大震災)直後の2011年(平成23年)3月15日(火曜日)未明、東日本大震災義援金受付口座への振り込み件数が、設定上限数を超えたことにより、夜間バッチ処理が予定時刻の朝5時までに終わらず、約38万件の処理が積み残された

義援金振込が殺到して、バッチ処理が時間内に終わらず、いわゆる「バッチ突き抜け」になってしまいました
business.nikkeibp.co.jp

みずほ銀行は、費用がかかるのを嫌い20年以上にわたって「勘定系システム」の刷新を怠った。
義援金の振り込みが集中したことをきっかけに、老朽化した勘定系システムの「弱点」が表面化、振り込み処理の遅延やATM(現金自動預け払い機)の全面停止を招いた。経営陣は「店舗の休業」や「ATMサービスの休止」など、障害の復旧に必要な措置を決断することができず、ゆえにシステム障害の影響が拡大。10日間にわたって混乱が続いた。

itpro.nikkeibp.co.jp

根本的な原因は、みずほ銀行とみずほフィナンシャルグループの歴代経営陣のIT軽視、あるいはITへの理解不足だ。技術の詳細について分かっていないということではない。経営陣として、自社の情報システムとそれを支えるシステム部門の強みや弱み、課題などを把握していない、知ろうとしていなかったのである。

itpro.nikkeibp.co.jp
itpro.nikkeibp.co.jp

みずほ銀のSTEPSは1988年に稼働を開始した。当時は、ATMの24時間稼働も、インターネットバンキングも、携帯電話を用いた振り込みサービスも存在しなかった。その後、これらのサービスを追加する一方、みずほ銀はバッチ処理の上限値の設定を、23年間一度も見直さなかった

diamond.jp

みずほ銀は、旧第一勧業銀行、旧富士銀行、旧日本興業銀行という合併した3行が内部闘争を繰り返したすえ、一度は旧一勧が採用していた富士通のシステムに、勘定系システムの根幹部分を統一していた。
 にもかかわらず、その周辺部分は旧行時代の取引先だった「ベンダーに気をつかい、偏りなく、バランスを取った」(同)揚げ句に、結局は“元の木阿弥”状態になってしまったというのだ。

日経コンピュータからまた出版されました。常連ですね。

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

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

読んだ人の感想
daiksy.hatenablog.jp
「システム障害防止についての提言」の10箇条は、会社の壁に貼っておきたいですね。


調査報告が公表されまして、その解説が詳しく書かれてます
http://oresen.sakura.ne.jp/2011/05/29/extreme-mizuho/oresen.sakura.ne.jp

2012年〜みずほ、復活への再挑戦〜

信頼回復に向けて、勘定系システムの全面刷新・統合プロジェクトが動き始めました

itpro.nikkeibp.co.jp

みずほは1年間がかりで再発防止策を講じ、現在は大手銀初となる勘定系システムの全面刷新・統合を進める。

itpro.nikkeibp.co.jp

大規模障害の再発は本当に防げるのか。世界最大規模となることが確実な刷新・統合プロジェクトを、やり抜けるのか。そして長年の課題である、ITガバナンスを強化できるのか。みずほ復活に向けた再挑戦を追う

富士通、日立製作所、日本IBM、NTTデータの4社に分割発注することが判明
itpro.nikkeibp.co.jp

みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。ハードウエアの調達とアプリケーションの開発を分離し、さらに預金や融資といった機能ごとに開発委託先を変える。大手4社に発注を分散させることで、総額4000億円を超えるとみられる大規模プロジェクトにおける技術者確保などに万全を期す。

最大8000人規模。多重下請けのピラミッド下部まで恩恵が及ぶとのこと
itpro.nikkeibp.co.jp

こうした超大型案件は、受託ソフト開発というIT業界の“旧勢力”にはまさに干天の慈雨。プライムコントラクターのSIerはもちろん、一次請け、二次請けなど業界のピラミッド構造の隅々にまで恩恵が及ぶ。みずほの案件だけで、最盛期には8000人の技術者が動員される見通しという。これだけの人員がバキュームされるとなると、人月商売である受託開発の需給はかなり引き締まる。かくして恩恵は業界に広く行き渡る。

なお、はてブコメントを見ると、不安視するコメント多数

日経コンピュータの2015年12月号あたりの「動かないコンピュータ」で特集されてそう

なんてコメントも。

マルチベンダーで取り組むことについての解説
d.hatena.ne.jp

この開発がうまくいくかはいかにしてみずほFG、みずほ銀行、みずほ情報総研がベンダーを喧嘩させないでやっていくかというところが大きいと思うのですが、銀行のセクショナリズムは半端無いので、失敗するとしたら分割発注のせいでも、ベンダーの実力不足でもなく、そういうところが原因になるんじゃないかと思っているんですけどね。

マルチベンダーとなった経緯など
biz-journal.jp

みずほ銀のシステム統合は、これまで2回の大規模なトラブルを招いた。
4社による次期システムの分担体制は、うまく機能するのだろうか。
諺にいう。2度あることは3度ある。

金融系IT、銀行SEという仕事
anond.hatelabo.jp
d.hatena.ne.jp
d.hatena.ne.jp

2013年

これまでの経緯と問題点の整理など

d.hatena.ne.jp

そんな状況で物事を決めるためには、共通のお財布を持った人が適切な判断で振り分けていく必要があるんですけど、巨大なプロジェクトで事業部レベルで違う人達が対応していてベンダーも違うのにお財布を共通化できるわけがありませんよね。これが最大のネックになって、次期システムの開発が頓挫するようなことがないように業界人として祈っておきます。

7月1日、旧みずほ銀行と旧みずほコーポレート銀行が合併。
www.huffingtonpost.jp
この時点では、次期勘定系システムが稼働するまでは、当面の間両システムを並行稼動させるという暫定的なもの。


なお、この時期は、次期システムについてのブクマは少ない。要件定義、基本設計中の模様。

と思ったら、銀行本体で真っ黒い不祥事発生。

kabumatome.doorblog.jp

(1)提携ローン(注)において、多数の反社会的勢力との取引が存在することを把握してから2年以上も反社会的勢力との取引の防止・解消のための抜本的な対応を行っていなかったこと
(2)反社会的勢力との取引が多数存在するという情報も担当役員止まりとなっていること、等

みずほ伝説まとめ
kabumatome.doorblog.jp

2014年

構築完了を当初予定の2016年3月から同12月に9カ月間延期する、と発表

itpro.nikkeibp.co.jp

次期システムの開発工期が当初予定よりも9カ月延びる見通し。2016年春にはシステム統合を終えて既存システムを移行させる予定だったが、9カ月〜1年間ずれ込む。

itpro.nikkeibp.co.jp

要件定義を終え設計工程がある程度進んだ段階で、「今後のスケジュールをゼロから見直した結果、詳細設計・製造やテストについて、それぞれ数カ月の期間を追加する」


問題の分析など
getlife.hateblo.jp

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

d.hatena.ne.jp

もう開発も佳境を迎えてからの延伸はかなりやばいです。品質がリリースできないくらいヤバイか、設計に致命的な欠陥があったかのどちらの可能性が高いからです。
一方、初期段階でのスケジュール延伸はまだましです。とりあえず予定通り工程を進めましょうってのが最大の死亡フラグであることは知ってますよね?そこでストップできるのはまだ何か正しい力が働いています。もっとも、工程が伸びるけどリリースは伸びないという恐ろしい事態の方がよく発生しますけれども…


「桜田ファミリア」と命名

kabumatome.doorblog.jp


この頃から、2chスレが盛り上がってきているようです。順調に破綻中との声が多数

blog.livedoor.jp

883 名前:非決定性名無しさん[sage] 投稿日:2014/09/14(日) 17:17:36.35
システム全体がスパゲッティによる論理で成立してるから難しいだろうね

906 名前:非決定性名無しさん[sage] 投稿日:2014/09/15(月) 21:08:26.87
要件定義終わってないから

928 名前:非決定性名無しさん[sage] 投稿日:2014/09/17(水) 20:00:03.50
オリンピックの最中に全世界にシステムトラブルが中継されるんだろうなぁ 個人的にはみずほ銀行の騒動で全世界に日本のITゼネコンの実態を報道して欲しいわ

「20万人月」という数字は、おそらくこの日経の記事から?
www.nikkei.com

ここまでに要する開発工数は実に「20万人月」(加藤部長)。人月とはシステム開発の仕事量を示す単位で、技術者1人が1カ月でこなす仕事量が「1人月」。20万人月とは、1万人がかりで臨んでも20カ月かかる仕事量。これまで史上最大のシステム統合とされた三菱東京UFJ銀行のケースでも開発工数は11万人月。みずほ銀行のプロジェクトはその1.8倍に達する。世界的にも前例のない大規模案件というわけである。


このプロジェクトの影響で、IT業界では技術者不足が深刻化。

www.nikkei.com

「技術は新人レベルでもいいので、とにかくシステムエンジニアを集めてほしい。仕事は、みずほ銀向けのシステム開発だ」
 みずほ銀向けのシステム開発とは、基幹システムの統合作業のこと。みずほ銀は当初、2016年春の作業完了を目指していたが、作業に万全を期すため、2月になって計画を1年間ほど延期する方針を決めた。一見、開発スケジュールに余裕ができたようにみえるが、この幹部は心配している。


でも単価は上がらない
d.hatena.ne.jp

リーマン・ショックからこのかた、銀行のシステム案件(銀行に限らずではあるけど特に)は「単価低減」要請との戦いと言っても過言ではない世界でした。現場では「単価下げたらクズしか残んないよ」という懸念は出ていたにも関わらずですよ。下げないと評価に関わると言われて戦える人はいないでしょう。結果として、銀行案件は高リスク低リターン(ただし規模だけは出る)と見做されているのが現状です。

2015年問題、2016年問題、2020年問題。ずっとずっと人が足りない
business.nikkeibp.co.jp

IT技術者が数万人規模とされる人手不足は、「2015年問題」「2016年問題」「2020年問題」とも呼ばれ、20万人月(人月とは、1人のシステムエンジニアが1カ月働く作業量)とも言われるみずほ銀行の基幹システムの統合や、マイナンバー関連のシステム構築など、近々に控えている超巨大プロジェクトによる需給関係の逼迫で人手不足が予測されている

2015年

かつての勢力争いについて
diamond.jp

みずほでかつて、首脳9人総退陣という“政変”があった。みずほホールディングス(HD)にぶら下がっていた日本興業銀行、富士銀行、第一勧業銀行の旧3行が統合する直前の2001年11月末のことだ。
 この人事こそが、みずほという巨大銀行の歯車を狂わせ、今日に至る混乱の歴史の幕を開けたといっても過言ではない。

求人サイトに本案件のPMの募集がかかっていて大きな話題に

bigdata-navi.com

■スキル要件:
・大手ベンダーをプロジェクトマネージャとしてのベンダーに適切な指示をし成功に導いてきた実績(必須)
・問題解決力に長けていること(必須) 難易度の高いマネジメントの経験
・統制がとれていない現状から、マネジメントの基盤作りプロジェクトに浸透されるためタフなメンタルが必要
・銀行業界経験あればBetter
・プロジェクト管理/PM/PMOのいずれかの経験必須

これについてのコメント
getlife.hateblo.jp
novtan.hatenablog.com
hamusoku.com


メガバンク再編とITベンダー勢力

biz-journal.jp

みずほ銀行の発足では富士銀行(IBM)のシステムへの片寄せが有力視されていたが、第一勧業銀行(富士通)が巻き返した。コンピュータについての知識がなかった3行の頭取は、社内の政治力学で判断した。3行それぞれの勘定系システムを残し、それをリレーコンピュータでつなぐ暫定方式を採用。3行のメンツを立てた妥協の産物だった。そしてこのボタンのかけ違いが、みずほ銀行が02年4月1日の開業初日に大規模なシステム障害を引き起こす伏線となった。


みずほと東京三菱UFJの比較
togetter.com

みずほ銀行ネタがまだRTされてるので、三菱UFJとどうやってかのネタも投下、エース級社員集めて強力なコントロールタワー置いて、一旦並存させつつも最終的に一本化。しかも2年掛けて移行


次期システム案件では、どうやら超高速開発ツールなるものを採用しているとのこと。2chでは散々叩かれていたけど。
itpro.nikkeibp.co.jp

その工夫の一つが超高速開発ツールの採用だった。次期勘定系システムを支える12個のアプリケーションのうち、勘定系システムの心臓部ともいえる総勘定元帳を抱える「流動性預金アプリケーション」など6個の開発を、富士通の超高速開発ツール「FUJITSU Software Interdevelop Designer」を使っていた。

日経コンピュータのみずほ次期システム特集3連発
itpro.nikkeibp.co.jp

 深刻なトラブルが見つかれば、1年後の開発完了は先延ばしにする羽目に陥るし、場合によっては暗礁に乗り上げる可能性もゼロではない。統合と刷新を同時にこなす史上最難級のプロジェクトという道を選択したみずほ銀が正しかったかどうかは、本番稼働の日を迎えるまで分からない

itpro.nikkeibp.co.jp

現時点では1年半程度をかけて移行する見込みで、全店舗が新システムを利用するのは早くても2018年夏ごろになりそうだ。


itpro.nikkeibp.co.jp

みずほは結合テストの前半を2015年夏ごろに終えており、コンポーネント間の処理などに問題がないかを確認する後半の作業に既に入った。2016年4月にも次の段階の総合テストに進む見通しだ。システム開発そのものは2016年12月に完了する。

2016年

2011年のシステム障害を振り返る記事
kabumatome.doorblog.jp



スケジュール的には春時点で総合テストに入っているはずだが・・・。


きっかけは雑誌の特集。
「プロジェクトが破綻」、「開発費4000億円がパー」などと内部告発的な記事が雑誌「選択」にすっぱ抜かれる。
年間購読が高いのでまだ読んでいませんが。

www.sentaku.co.jp


みんな、読んでもいないのに大盛り上がり
blog.livedoor.jp

選択出版に掲載された「みずほ「システム更新」が絶望的に。完成のメドなく「四千億円」がパー」という記事が話題。マルチベンダーによる弊害、赤裸々なデスマの現状、その破綻劇がすっぱ抜かれている。

blog.livedoor.jp

21: シャイニングウィザード(茸)@\(^o^)/ 2016/07/05(火) 17:41:05.36 id:XumXMhTn0.net
系列会社の富士通に任せたらボロクソだったから、分割発注したらもっとボロクソになった。
でも分割発注したおかげで責任の所在も不明になったので問題ない。

めでたし、めでたし

17: テキサスクローバーホールド(茸)@\(^o^)/ 2016/07/05(火) 17:38:33.77 id:huXFNXhu0.net
この案件だけはとってくんなよと営業にずっと言ってるわ

86: ラ ケブラーダ(大阪府)@\(^o^)/ 2016/07/05(火) 18:21:31.26 id:HyhUB8hN0.net
指揮系統がわからないまま、完成形も謎のピラミッドを作り続けてる。
多分出来上がっても崩れる

286: テキサスクローバーホールド(庭)@\(^o^)/ 2016/07/05(火) 19:29:13.13 ID:/i1XPCKG0.net
今回のシステム統合は最初から無理難題
・マルチベンダ体制でNTTデータ、日本IBM、日立、富士通の分割発注
・ハードウエアとシステムで開発委託先を分散
・さらに預金や融資などの機能レベルでも委託先を分散
・アーキテクチャレベルからの新規開発
・アプリケーションはCOBOLからJavaに置き換え
・工数20万人月という、クフ王のピラミッド建設と同規模のプロジェクト

(追記1 2016/7/11)


anond.hatelabo.jp

家を建てる時にさ、大工と左官職人と配管職人とガラス屋と設備屋が居るから完成しないとか、無いでしょ。
それぞれの職人にそれぞれの指示をして、結果として一つの建物ができるのはそんなに珍しく無い。
(もちろんちゃんと連携しとかないと穴空いてないから換気扇付けられんとかあるんだけど)
だから、誰かが主導権を握れば普通に完成するよ。
例えば、みずほ銀行の現頭取の林さんは富士銀行の人。
だもんで、日本IBMのプロジェクトマネージャーに全権委任して、組み直せば終わるよ。
みずほ銀行内の揉め事は、全部林さんがOK/NG決めて、IBMのPMが采配して進める。
要は、クライアント(依頼主)側の意思統一ができていないのが一番の問題。
これは、ベンダーがーとか多重請負構造がーとか、そういう問題じゃない。
第一勧業銀行と富士銀行と日本興業銀行の合併が終わってないのが問題。
(外面の話じゃなくて、内部的に一つにまとまってるかってことね)

大規模システム開発案件のデスマーチは、どうしてこんなにつらいのか - あいむあらいぶ

孫請け以下、開発工程から入った場合、一担当者がプロジェクトを建てなおすことは到底不可能です。だから、一番の対策は、君子危うきに近寄らず。会社としてデスマーチ案件に参画しないことです。

d.hatena.ne.jp

 では本当はどうすればいいのかと言うと、みずほ銀行はまず一度大手SIerとの付き合いを保留にして、自社で完全なシステム構築ができる人材を雇うべきです。
 クライアントとベンダーでは基本的に利害が対立するので、これほど巨大なシステムを無駄なくつくり上げようというときに複数のベンダーで利害の奪い合いをしていたらどんどん無駄なコストが膨れ上がります。

d.hatena.ne.jp

とにかく、3.11以来金融庁がうるさいので、ちょっと計画変えますって話もなにか問題があるのかどうなってるんだ報告しろで貴重な時間と金を吹っ飛ばすことになりかねないので計画を変えることに対して及び腰になってしまうという問題があるんじゃないかと思うんですよね。つまり、金融庁が余計な口を出さなければ計画が適正になるんじゃないの?

anond.hatelabo.jp

当然みずほ銀行は、この勧告に対して対応する責任があるわけでして、いくつかの対応策を発表したわけですが、その対応策のひとつが「サーバシステム全面刷新」でした。それぞれの出身銀行が持ち寄った古く非効率な電算システムを捨てて、新しいみずほ銀行としてみんなで仲良く効率的で顧客に安心感を与えるちゃんとしたシステムを作るぞー! だから今回の不祥事はごめんなさいしてね。そういう発表でした。カシコイ!

まあ、しかし、今まで派閥闘争してたひとは1mmも反省してないので、新しいシステム開発などできるわけもないのでした。そもそも、業務の要件をまともに定義できる人もいないのです。というのも、いくつもの派閥が自分たちに都合のいいような仕様を押し付けようとするからです。というか、もはや都合がいいとか悪いではなく、敵対派閥が進めようとした作業の妨害をしたり、仕様変更したりするのが、社内での出世ゲームになっていたのでした。コワイネ。

この「つっちー先生」という方は、内部の関係者ではないにしても、金融系システム全般に関してかなりのご経験をお持ちの方のようでして、相当詳しい解説が書かれてます。
togetter.com


itpro.nikkeibp.co.jp

「開発完了」を掲げる2016年12月まで残り半年となった6月14日、結合テストの終了と総合テストへの移行を役員会が承認した。3000億円強を投じる過去最大級のプロジェクトは、失敗が許されないという至上命題を抱えながら最終局面に突入する(写真)。

 次期勘定系システムについては、開発の遅れを指摘する声もある。元みずほ関係者は、「テスト段階で相当な手戻りが生じ、今年に入ってスケジュールの見直しが必要かを検討したこともあったようだ。感覚的には3カ月は遅れている」とする。

7月にリークされた情報では「破綻」とされていたけど、3ヶ月遅れだけで済みましたよ、との反論が出てきました。


(追記2 2016/11/24)


itpro.nikkeibp.co.jp

みずほ銀行が、2016年12月に開発完了を予定している勘定系システムの刷新プロジェクトを巡り、スケジュールを見直す検討に入った。同行は同年6月から総合テスト工程に入っているが、一部のテストを2017年1月以降に持ち越す可能性が出てきた(図)。みずほ銀行は2014年に、当初2016年3月としていた開発完了時期を約9カ月間延期している。再延期が確定すれば開発コストの増加を招くほか、老朽化した現行システムの利用が長引くことになる。

12月の開発完了直前に、やっぱり終わらなさそう、とのリークあり。

itpro.nikkeibp.co.jp

会見の席上で同社の佐藤康博社長は、2016年12月の開発完了を目指していた次期勘定系システムについて、「一部の開発完了確認が数カ月遅れる」ことを明かした。
 次期勘定系システムの開発を巡っては、開発完了を延期する検討に入ったと一部で報道されていた(関係記事)。進捗が遅れている原因としては、振込業務の24時間化やFinTechサービスへの対応が追加的に発生していることを挙げ、「根本的なトラブルが生じているわけではない」と強調した。旧システムから新システムへの移行時期は明言しなかったものの、「元来の計画への影響はない」とした。

社長自ら遅延を発表。追加要件が発生した事が要因とのこと。

itpro.nikkeibp.co.jp

 1度目の延期では、開発完了を2016年3月から同年12月と、延長後の期限を示した。しかし、今回は「数カ月延びる」とするにとどまっており、いつ開発完了とするつもりなのかは定かではない。

しかし、みずほ銀行はいつの間にか、肝心の移行時期を言わなくなってしまった。佐藤社長は、「システム移行の時期に影響はない」としているが、その実態はベールに包まれているため、今回の延期に係る影響を推し量ることは困難だ。

スケジュールを見直したとしても、開発終盤を迎えた段階で何もトラブルがないというのであれば、システム移行の時期はより具体的に計画を立てられるはずなのに、そうなっていないということは、本当にトラブっているんだろうな、と推測してます。

最後に

「破綻しそう!」とは言っても、これだけの規模のプロジェクトがそう簡単に中断するわけはないでしょうが、一番最悪なのは今の状況のまま仕切り直さずにずるずると継続してしまう事かなと思います。現場のエンジニアの方々がただただ使い潰されるだけです。とは言っても、マルチベンダー体制で責任の所在が曖昧ですし、過去の経緯からすると、銀行もベンダーもどこもかしこも責任を取りたがらず、下請けにすべてを押し付けてしまいそうです。それこそ金融庁からの鶴の一声がないとどうにもならないんでしょうか。

現場のエンジニアの皆さん、どうか無事に帰還してください。世の中にはもっとまともなプロジェクトがいっぱいありますので、とっとと脱出してください。

では。

人月の神話【新装版】

人月の神話【新装版】

ピープルウエア 第3版

ピープルウエア 第3版

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理

手戻りなしの要件定義実践マニュアル[増補改訂版](日経BP Next ICT選書)

手戻りなしの要件定義実践マニュアル[増補改訂版](日経BP Next ICT選書)

動かないコンピューター ― 情報システムに見る失敗の研究

動かないコンピューター ― 情報システムに見る失敗の研究

失敗から学ぶプロマネ技術 36のQ&A

失敗から学ぶプロマネ技術 36のQ&A

ITプロジェクトを失敗させる方法―失敗要因分析と成功への鍵

ITプロジェクトを失敗させる方法―失敗要因分析と成功への鍵

もはや限界 日本のSI業界(日経BP Next ICT選書) 日経コンピュータReport

もはや限界 日本のSI業界(日経BP Next ICT選書) 日経コンピュータReport

システムインテグレーション崩壊 ?これからSIerはどう生き残ればいいか?

システムインテグレーション崩壊 ?これからSIerはどう生き残ればいいか?

システムインテグレーション再生の戦略 ?いまSIerは何を考え、どう行動すればいいのか?

システムインテグレーション再生の戦略 ?いまSIerは何を考え、どう行動すればいいのか?

もはや限界 日本のSI業界(日経BP Next ICT選書) 日経コンピュータReport

もはや限界 日本のSI業界(日経BP Next ICT選書) 日経コンピュータReport