みずほ銀行の次期システムは富士通、日立製作所、日本IBM、NTTデータの4社に分割発注 52
ストーリー by hylom
理論上はうまく行かないはずがない 部門より
理論上はうまく行かないはずがない 部門より
あるAnonymous Coward 曰く、
みずほ銀行は次期システムの開発を富士通、日立製作所、日本IBM、NTTデータの4社に分割発注して進めていくという（日経ITpro）。
IT業界で無事にいたいなら銀行に関わるなという格言（？）もあるが、次期システムでは今までは富士通が受注していたみずほ銀行と、日立が受注していたみずほコーポレート銀行、そして日本IBMが受注していたみずほ信託銀行の勘定系システムを統合するとのことで、そのへんのしがらみもあるんじゃないのとか思ってしまう。4社に分割発注されたけど実際に作業する下請けは同じだったとかいう事態が発生したら笑ってしまうのだが。
そもそも (スコア:5, 興味深い)
こういったシステムでトラブルを起こすのは、既存システムとのインターフェイスですよね。
それだけでも大変なのに、
４社が別々に開発するシステムの連携もやれと。
みずほ銀行は、エンジニアの他に、神様も雇うべきだと思う。
Re:そもそも (スコア:5, おもしろおかしい)
神様はいません
神頼みするひとばっかりです
そして見放されます
Re:そもそも (スコア:1)
問題を神棚に奉納することを
棚上げと言うらしいですよ
Re:そもそも (スコア:2)
Re: (スコア:0)
おまえ頭いいな
今日さっそく取りかかろう
Re: (スコア:0)
みずほ銀行が雇ったのは神様であってエンジニアではないです
これから神様がエンジニアを召喚使役します。
Re: (スコア:0)
神様は雇えません
Re: (スコア:0)
＞こういったシステムでトラブルを起こすのは、既存システムとのインターフェイスですよね。
それだけとも限りませんよ。
例えば。各システムのオープン時間外の取引情報は、どちらが持つかとか。
各取引毎のパフォーマンス問題とか。
通信障害時の系統振替処理とか。
むしろインタフェイスは、今回の作り直しで最適化されると期待できます。 …していいんだよね？ …させてよね？
Re: (スコア:0)
> どちらが持つか
きっちり線引きして責任分解してみたところで、みずほ様がおまえらのせいだと言えば
一蓮托生で4分割賠償が一番公平で共存共栄できるのではないかとか。
Re: (スコア:0)
> きっちり線引きして責任分解してみたところで
責任を分解してどうする！無責任体質なのか？それを言うなら分界だろ？とか思ったんだが、ぐぐるさんによれば、
責任分解点－－約 3,290,000 件
責任分界点－－約 25,000 件
と圧倒的な差がついてしまったわね。
＃ なるほど、世の中そういうもんなんだ
Re:そもそも (スコア:1)
"責任分解点" 約6,520件
"責任分界点" 約16,200件
Re: (スコア:0)
新システムは死んだ。新システムは死んだままだ。
そして開発会社が既存システムを殺したのだ。
我々はこれまで持った、最も神聖な、最も強力なブラックボックス、それが彼らの仕様によって血を流したのだ。
この所業は、我々には偉大過ぎはしないか？
こんなことが出来るためには、開発会社が人身御供にならなければならないのではないか？
ニーチェ
Re: (スコア:0)
顔が4つあるだけで元から手は沢山あるから
阿修羅を雇ったのと同じじゃね
大丈夫大丈夫
Re:そもそも (スコア:4, おもしろおかしい)
修羅場を招くだけかと…
因果はめぐる (スコア:5, 興味深い)
＞4社に分割発注されたけど実際に作業する下請けは同じだったとかいう事態が発生したら笑ってしまうのだが。
知り合いが、あるデスマの現場をようやく契約期間切れで離れたところ、数ヶ月後、別の会社の下請けで同じ現場に派遣された。
Re:因果はめぐる (スコア:2)
「経験者優遇」という求人だったりして。
Re: (スコア:0)
まあもしもの話ですが、
次の仕事がデスマ確定でないとしても、
デスマ経験者と非経験者からどちらかを採用するとしたら、
経験者の方を取るでしょうね。
「こうすれば回避できるのに」というノウハウがあるでしょうから。
Re:因果はめぐる (スコア:1)
「こうすれば回避できるのに」というノウハウはあっても、下請けの立場ではそのノウハウを実行できないっていうのが圧倒的に多いと思う。
『修正個所では必ず元のコードをコメントアウトして残す』なんて馬鹿げたことが、上位会社から『至上命題』として要求されるとか。
Re:因果はめぐる (スコア:1)
日本IBMのプロジェクトではそうでした。ええ、もちろん言ってもなおりませんよ。
2011/12/24 name MOD start
～修正内容～
2011/12/24 name MOD end
とか。なので最低1/4の確率でこのタレコミのプロジェクトでもそれにあたるのでしょう。
おお、こわいこわい
# なんでこんなダメなところしかないのか
Re: (スコア:0)
いや、この手のルールは最上位でなくても中間会社にそんなところがあればそれでアウトだ。
受け取る側は
・動いてるのなら特に気にしない
・今さらそれだけのために直せとも言えない
のどっちかだし。
Re: (スコア:0)
Re: (スコア:0)
# フォーマットもそっくり
Re:因果はめぐる (スコア:1)
え、経験者を採用するのはデスマ耐性が確認できているからではないのですかっ！！
# 回避するノウハウがあるなら、前回のデスマも回避できていたと思う。
Re: (スコア:0)
Re: (スコア:0)
雨男ならぬ「デスマを呼ぶ男」というのは居るかもしれない。
異能生存体 (スコア:1)
たとえデスマーチを生き残ったものがメンバーにいたとしても, それが次のデスマーチで自分が生き残る保証とはならない.
# 私も異能生存体の近似かもしれないのでID
Re: (スコア:0)
えっ、
「(そのデスマの)経験者優遇」
でしょ。無粋だけど書かずにはいられなかった
Re: (スコア:0)
デスマ経験者って回避できなかったから経験してしまったのでは？
Re: (スコア:0)
デスマに陥っていることを認識して
それがなぜ起きているかを認識しているのですがそれを回避する権限はないのです。
# エンジニア同士を主として上司がその下について雑事をこなせばもっと巧くいくんじゃないかなぁ
Re: (スコア:0)
デスマ環境での生存能力が高い人は増えるでしょうが、デスマの回避能力が低い人も増える可能性があります。
・・・っていうかそれ以前に、募集の時点でデスマ前提にするんじゃねぇよ。
Re: (スコア:0)
デスマの現場にて責任面がリセットされるのは精神負担の軽減になるから無駄ではなかったと思う
Re: (スコア:0)
前の職場での話だが、通信系の同一顧客で、富士通の下請けプロジェクトとNTTデータの下請けプロジェクトで、顧客の開発室で背中合わせになったことがあります。上司は社員管理が楽でいいといってましたけどね。もっとも、片方が火を噴いたら、強制的に動員されたのは苦い思い出です。
Re: (スコア:0)
何で笑うの? 当然のことでしょ?
T庁でも類似経験有
問題 (スコア:0)
問１ このプロジェクトが納期通りにリリースされ、重大なトラブルが一切発生しない確率を求めよ。
問２ このプロジェクトが原因で自殺する人数、鬱病でドロップアウトする人数を求めよ。
#ちょっとした戦争くらいの被害者でないかコレ？
３行統合 (スコア:0)
みずほの素である、富士銀・勧銀・興銀の３行統合の時に潜り込んでました。
あの時ですら、各銀行の主ベンダーで主導権争いを繰り広げて、下々の者は震えたというのに…。
＃あん時のノウハウが生きるのだろうか。
Re:３行統合 (スコア:1)
リレー・コンピュータの悪夢から10年経ってるけれど、組織の統合もシステムの統合もまったく完了していないのだな。
Re: (スコア:0)
関係の方の危惧は見事に的中して、空前の大事故で日本中の人が震える羽目になったんですよね。
# まだ統合できていなかったとは
アクセンチュアに任せないだけ増し (スコア:0)
富士通、日立製作所、日本IBM、NTTデータの4社の過去の実績に鑑みてあれこれ言う人は多いけど、アクセンチュアに任せない事だけは過去の事例 [srad.jp]に学んでいるようだ。
Re: (スコア:0)
進捗がうまくいかなくなるとアクセンチュアの出番になるよ。
PMOあたりを引き受けるとか。。。
まぁ、IBMあたりが旧IBCSの要員をだすかも。
と思ったら、みずほ総研の要員をマネージメントに出すみたい。orz
どこぞのDay2のときみたいに
IBCS→Pwc
みたいなスイッチは当然あり得るだろうから
コンサル各社は手ぐすね引いているだろうね。
Re:アクセンチュアに任せないだけ増し (スコア:1)
以前にアクセンチュアさんと仕事したことあるけど、数字作るの上手いよね。
進捗資料上は進んでるように見えるのに、プロジェクトは全く進んでない状態だった。
可視化ってなんだろうって、思ったわ。
Re:アクセンチュアに任せないだけ増し (スコア:1)
＞ ＞ 可視化ってなんだろうって、思ったわ。
＞ 見せる化。
都合良く、見せる化。
いやホント凄いって。
まぁ、それに騙されたい上の人達が居るから成り立つんだけどね
（だって誰に聞いたって、それは嘘だって分かるもん）。
無意味な金融再編だったことの証左 (スコア:0)
合併効果に期待すらしないなら合併しなきゃいいのに。
Re:無意味な金融再編だったことの証左 (スコア:2)
それぞれに歴史を持つ企業、それも都市銀や信託だから、トラブルが発生したときの社会的影響を考えると、一気に統合しようという方が余ほど危ない。なにしろ、みづほ銀行はすでにトラブルを起こした実績まである。
それに大企業が大きな仕事を発注するとき、いくつかに分割発注することはそれなりにあること。確か、東証が新システムに移行するときもいくつかに分割発注していたよね？
一社に発注してしまうと、ひとつのプロジェクトになってしまい、トラブルが発生したとき、大きな影響となる可能性もあるし、できれば一社に依存する事態も避けたい。
中小支店の統廃合の方が余ほど、簡単にできるはず。合併がなくても不定期に実施しているから、ノウハウもあるし。富士銀、第一勧銀、日本興業の組み合わせでは、都市部の支店がかなりダブったはずで、それだけでも効果は大きかったはず。
Re: (スコア:0)
一気にと言うには、統合 (とトラブル) 以降かなり時間が経っておりますが、この後どれくらいかければ「一気に」ではなくなるのでしょうか。
統合計画を立案しシミュレートし実行するだけの時間はあったと思われます。この期に及んで統合しない、というのは、旧銀行間のセクショナリズムが全く改善していないことの証左ではないでしょうか。
Re: (スコア:0)
貴方はどのような規模のシステム統合プロジェクトに参画していましたか？
また、そのときの立場は？
# まさか、経験が無くて言ってるわけじゃないよねｗ
Re: (スコア:0)
俺でも「他のメガバンクができていることが、みずほだけできない理由って、何?」と思う。
やっぱりみずほは旧銀行派閥の壁を越えられないのかなぁ、と邪推。
相応のプロジェクト経験者以外はROMっとけ、ってのは残念なことです。
Re:無意味な金融再編だったことの証左 (スコア:1)
銀行に限った話ではありませんが、
現状の業務を改善する目的もあってシステム刷新するはずなのに、
現状の業務をまるっと持ち込もうとするので、失敗します。
企業統合の場合はもっとシンプルで、
「統合後のあるべき（理想的な）業務の姿」をデザインし、
それに合わせたシステムを構想すれば良いだけの話なのですが、
現状を変えたくない人達が、「今までこうして来たから」と、
『理想の業務像』に噛み合わないノイズを持ち込むので破綻します。
もしも、業務改善ではなく統合「だけ」を目的としているのであれば、
理論上も上手く行く道理がありません。
Re: (スコア:0)
金融再編が悪いのではなくて、
非合理的なやり方をしているからでしょ。
アホが上に立つから悪い。
Re: (スコア:0)
現行システムに対する、明文化されていないノウハウを抱えていることを期待しての
現行ベンダーを含めた分割発注なんでは？
Re:無意味な金融再編だったことの証左 (スコア:1)
NTTデータって、現行システムに深く関わってましたっけ？
そうじゃないなら、実質的にプロジェクトを取り回すのがデータで、
他の3社はその下で動く体制かもしれませんね。
上記のような仕切りだとしても、3社はこれまでの経緯の手前、
下請けの契約に甘んじるのは難しいでしょうし。