みずほのトラブル原因が明らかに 49
ストーリー by Oliver
主導権争い 部門より
主導権争い 部門より
mubi 曰く、 "日経コンピュータの記事によると、みずほ銀行のシステム障害の原因は、１．ＡＴＭの障害は旧第一勧銀の対外接続系システム（富士通のメインフレームを利用）の修正ミス。２．口座振替の障害は第一勧業情報システムが中心になってソフト会社の協力を得て作成を進めた新規導入のプログラム（日立製メインフレーム上で稼動）の開発に失敗したこと。ということのようだ。
いずれにしても、どうもＣＯＢＯＬの修正ミスや、時間切れによるチェック漏れの感が否めないように見える。現場のことを知らない高給取りの上層部の責任はきっとあるでしょう。"
最大の原因は (スコア:3, 興味深い)
半年で稼動させようとしたのが、そもそもの間違い。
発表から２年もあったのだから、１年くらいは時間を割くべきでしたね。
これで、現場の人間が割を食うようでは、今後、銀行システムには人が集まらなくなるのでは。
いまの銀行は「機械仕掛けの銀行」であることをトップは自覚すべきだと思ふ。
いや、それよりも (スコア:3, 興味深い)
Re:いや、それよりも (スコア:2, 興味深い)
「時間不足のせいで社員が睡眠不足になっても働かなければならなかったこと」
でしょう。親コメント [srad.jp]は「おもしろおかしい」と評価されていますが、重要な内容を示唆していると思います。
funny よりもむしろ interesting （趣がある？）かと。
鵜呑みにしてみる？
個人的には (スコア:1)
酒ばっかり飲んで遊んだあげく、時間切れになって睡眠不足のデスマーチに
突入してしまい、挙げ句、間に合わなかった……、
と言う感じではないかと思ってるんですがね。 :-p
＃日本人的？？
Re:最大の原因は (スコア:3, 興味深い)
納期予算要件等でユーザ部門が無茶言うのは、
開発規模の大小に関わらず、どこの企業の
システム開発でも同じではないかと感じます。
勢力争い云々も問題視されてるようですが、
その程度の視野の狭い人間を黙らせることが
できないようではプロマネ失格と考えます。
# みずほのケースは相当酷かったのかもしれませんが
なんのためにみずほに統合するのか、
統合にあたってどのような課題があるのか、
課題の解決に要するリソース（人、物、金、時間等々）は
どのくらいか、
等々を経営的視点で分析計画立案し、統合実現に向けて
プロジェクトを確実に推進実行する経営層のプロマネが
何らかのミスを犯したか、そもそも能力が足りなかったか
ということだと思います。
# 執行役員のような責務の人間はいなかったのか？
システム修正ミスやら、テスト時間不足に伴うチェック漏れは
発生した問題を解決するための調査分析結果にすぎず、
適切な対処を施せばよいだけのことで、そもそもその問題が
発生した要因がどこにあるかを分析する必要があります。
開発ベンダに責任を被せるだけでは根本的な原因は
解決されません。
みずほという銀行が失った信頼を回復するためには
内部の膿を洗い出し、解消する必要があると思います。
開発に関わった方々、お疲れ様。
なかなか進まないとうこともあったのでは (スコア:1, 興味深い)
実際に会議を持っても決まらない。結局最後になって、この短い期間で本番稼働できることはほとんど無理というような状態でギリギリ本番にするということが多いです。
そういうとき、何日も会社に泊まり、超人的に働く人がいたりします。何度もそういった修羅場を切り抜けてきているんですね。最近リストラが進んで、そういう人がいなくなってきたのも影響しているかもしれません。
Re:なかなか進まないとうこともあったのでは (スコア:3, 参考になる)
システム統合プロジェクトによく見られる光景ですね。
大抵、個々のシステム開発部門が自分達の管轄システムの修正を
最小限にとどめ、もっともらしい理由をこじつけて、相手方の
システムを修正させようとする醜いエゴのぶつけ合いだったり
することが多いですけど。
あるいは業務部門と開発部門との衝突であったり。
個々の部門レベルの主張として聞く分には、一見正しそうに
聞こえるからなおさら会議がまとまらないなんてこともしばしば。
個別業務 or システムのレベルで分析する視野の狭さが問題で、
視野を企業全体レベルに広げて検討する必要があります。
企業としてのビジネス戦略にもとづいて投下可能なリソースから
考えればおのずと答えが見つかるはずで、その判断は経営層の
プロマネが下す必要があると思います。
よって進められないプロマネに問題があるのです。
本稼動直前になって、連日連夜不眠不休で働く超人に
頼らなければシステムが稼動できないプロジェクトなど、
極端に言えばプロマネの存在など不要です。
数人～十数人月程度のシステム開発ならそれでも可能かも
しれませんが、銀行の経営統合に伴うシステム統合レベルの
開発では不可能でしょう。
企業利益向上を目指して経営統合するわけですから、
それに応えるシステムを構築することが求められ、業務もそれに
対応することが求められます。
個々の業務 or システム開発部門の主張がこれに適合するもので
あれば経営レベルで判断すればよし、適合していなければ
なんのために開発するのかを周知徹底させ、再検討させればよい。
# 最初から周知徹底できていない時点でプロマネ失格ですが。
最終的に開発部門に皺寄せが集まり、しかも今回のみずほの
ようにシステム上の不備でもあろうものなら目の敵にされて
しまうのですが、問題の根本原因は開発部門ではなく、
プロマネにあると考えます。
まぁ、個々の部門担当者が開発（統合）目的を理解していない
（視野が狭くて理解できない）か、目先の手間を惜しんで手を
抜いた可能性もあるかもしれませんが。
今日的超人 (スコア:2, 興味深い)
それが、本当の成果主義ってものだと思います。
Re:なかなか進まないとうこともあったのでは (スコア:1)
ただそういうのって結局お客さんの無理な要求に対して無茶な働きをして乗り切ってるわけでもしその人が倒れていたり、もうちょっと負荷が大きくなったりとかした場合にはやはり失敗していただろうし、今回の件が、その失敗してしまった例なのかもしれません。
もし、他のコメントの方々がおっしゃるように旧銀行の派閥間の綱引きで仕様が固まらず、開発期間が不足したと言うことであるなら、下手に超人がいて無理に乗り切ってしまわない方が良かったのかもしれません。
超人って不幸よね。 (スコア:2, すばらしい洞察)
その超人って、今回起きた損害に見合う程度の評価は
もらえないんでしょうねぇ。被害が起きなかったときは
被害を算定できないもんね。当たり前のことなんだけど
なんだか理不尽な気がする。
Kiyotan
Re:最大の原因は (スコア:2, 興味深い)
# Civ3的に言うと、「汚職と浪費が極限状態」ですな
Re:最大の原因は (スコア:1)
上の方で責任問題の所在についてありますけど、十分なテスト時間を設けられないスケジューリングで開発させた銀行側が、やっぱイチバンの戦犯かな、と個人的には思う。
Re:最大の原因は (スコア:0)
時間不足なんて言っても、１００年あっても動かないものは動かない。
問題なのは、いつ動かすかであって、それに間に合わないなら、
様々な責任の取り方があるはず。
自分のクビと引き換えに時期を延期するような漢はいないんか！
Re:最大の原因は (スコア:0)
居ても既にクビになっているか、少なくとも昇進はできなかった、に一票。 ゴマすりばかり確定申告してる世界さ。
うーん (スコア:3, 興味深い)
いくらなんでも相手は銀行屋さんなんだから、時間がないとかCOBOLのプログラムミスとか、いわゆるスキル不足でここまでひどくなることはないと思うよ。
これが元になって合併がご破算になったらと、密かに思っている人もいるのではないでしょうかね。合併 → 経営陣の余剰人員 → 後は考えるまでもなく。
Re:うーん (スコア:0)
時間がないのはスキルとは関係ないと思う
経験上、ど
Re:うーん (スコア:0)
# 恐いので A.C.
Re:うーん (スコア:0)
たしかに公共事業系は経験ないですね
そんなに開発期間に余裕があるもんなんですかぁ
余裕なしと有名になるのが怖い (スコア:0)
Re:うーん (スコア:0)
＃これもコワイのでA.C.
責任、賠償問題 (スコア:2, 参考になる)
みずほの場合、狭義の「実害」だけならそれほどの額にはならないかもしれないけ ど、「失墜した信頼」についてまで賠償を求められたら巨大な額になるでしょうね。 そもそも、発注側と受注側の責任を区分すること自体がむつかしいそう。
佐藤亮一 in Frankfurt Germany
Re:責任、賠償問題 (スコア:1, 参考になる)
「うちの責任じゃねー」
という念書を取ったようですが。
最終的には情報子会社の責任になって、それも含めて旧経営陣あたりが焼かれて終わるに１カノッサ。
Re:責任、賠償問題 (スコア:0)
Re:責任、賠償問題 (スコア:0)
よっぽどのことがないかぎり、受注側が発注側を責めることはありえないし.....
＃この前も名古屋と九州に１日で謝りに行かされたとこだ....（マシン壊したのは先方だったが（爆））
つか、時間切れくらいしかあり得んが.... (スコア:1, すばらしい洞察)
で、結局、最後は殺人的スケジュールに突入と
ま、エンジニアに責任がいかないことを切に願っていますけどね。ほんとに悪いのは彼等じゃないし。
実は，時間切れなどでは無かった。 (スコア:2, 参考になる)
それによると，システムの設計，開発は２００１年６月に終了して，あとはテストを行っていたとのこと。該当部分の議事録はこちら [srad.jp]にコピーしてあります。
この議事録よんでて，けっこうげんなりしているんですが，ようするに，前田社長は事前の不具合なんて聞いていないし，テストも十分にやったし，スケジュールも順当なものだったということのようです。
斜点是不是先進的先端的鉄道部長的…有信心
Re:実は，時間切れなどでは無かった。 (スコア:1)
うじゃうじゃ
フリーのエリアに記事が出た也。 (スコア:1)
穿ったことを言わせてもらえば、統合方針が固まっていなかったから仕様の最終確認ができなかったり、エラーコレクションが極端に複雑になったりしたのではないか、とも思える。(公式の情報がない段階で乱暴な言いぐさなのはご容赦下さい。)
なお、「日経コンピュータ」中の特集サイト [nikkeibp.co.jp]も作られている。
「開発に失敗」とは？ (スコア:0)
うーん、「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」「開発失敗」。。。。
何度言ってみても変な表現だ。。。。
技術屋の世界で長くいたせいか、具体的表現でないとナットクしない、ということもあるかもしれないが。
Re:「開発に失敗」とは？ (スコア:2, おもしろおかしい)
「鉄砲の『開発に失敗』しました」とか。
Re:「開発に失敗」とは？ (スコア:1)
「開発に失敗」という語彙を私が素直に聞くと「動かないコンピュータ状態になって開発プロジェクト自体がキャンセル」という状況に聞こえてしまいます (普通はそういうときに「開発に失敗」と言うと思うのですが)。
これだと「具体的」だと思うのですが、今回の事態はこれと異なるわけですし...多分、取材源の「原文のママ」ではないかと勝手に想像しているのですが、そうすると具体的に踏み込むと、生傷に触れるか業務上の機密事項に触れると判断したのかも知れません。
まあそのうちインサイダーな方が補足して下さるのを待ちましょう。
Re:「開発に失敗」とは？ (スコア:5, 興味深い)
ちなみに巷で言われていたリレーコンピュータには不具合はなく正常に動いていたそうだ。
あと、この前まで日経産業新聞で今回のトラブルのことを何回かに分けて連載してましたが、技術的云々より旧一勧と旧富士銀の主導権争いもかなり熾烈だったようで、現場は「早く仕様をfixしてくれないと....」状態だったみたい。(日経産業新聞によると旧一勧が呼んだSIベンダが会議の席でシステム接続の提案説明をしていると旧富士銀側が『我々にコンピュータのイロハを説教してるつもりか』と罵倒の嵐。これが本当なら現場の士気は落ちる一方だ)
＃同じネタでタレコんだんだけど却下されたの(^^;
Re:「開発に失敗」とは？ (スコア:1, 参考になる)
この手の話は多いと思う。
外される予定の派閥＋メーカーが、意図的に仕様 Fix を遅らせて妨害したんじゃないかな。
Re:「開発に失敗」とは？ (スコア:2, 参考になる)
私の経験したところ、普通こういったシステムの開発って、よっぽどトンでもない物が出来あがらない限り、何とかして表向きは納入（開発成功？）する。その後、細かいところはなんとかする、ってものだと思うのですが、それも出来ないほど致命的に完成していなかったのでしょうね。
（契約によっては違約金もあるでしょうが、動かないと困るのは、結局発注元だから）
＃ちょっとヤバメなのでAC
Re:「開発に失敗」とは？ (スコア:1)
この場合のメリットは、期間内での３行のシステム統合だったかと。
絶対に止めてはいけないシステム (スコア:1)
投稿者です。
ほとんど、日経コンピュータの記事のままに書いたつもりです。
”～によると”の部分ですので。ただ、金融や医療、交通機関
などのシステムは何重にもバックアップ体制（ハードや回線など）
を用意するなど絶対に間違ったり、止めたりしてはいけない類の
システムではないかと。（社会的影響がとても大きいですよね。）
『うまく動かないものを新規に作成してしまった。』
ということは”開発に失敗”でもおかしくはないと思うのですが。
いかがでしょう。
PAXNetの記事はインチキだった！ (スコア:0)
Re:PAXNetの記事はインチキだった！ (スコア:2, 参考になる)
ある意味「オープンシステムなら何でも上手く行く」みたいなイメージで営業してる部分もある訳で、そういうイメージ先行が材料になっていた所にとっては悪材料という話を書いているだけだと思います。ま、表現的に正確さを欠いてるとは思いますがね。
UNIXだろうがなんだろうが (スコア:2, すばらしい洞察)
それに、この程度のヨタ記事でUNIX全般のシェアに大きな影響があるとは、たとえみずほの問題がUNIXに起因したものであったとしても、思えないもんねぇ。もしも、なにかの意図があっての記事であれば、それは徒労以外の何者でもない。
「デタラメ」になっちゃうのは、元の知識がデタラメな記者が書くわけだし、その記事を出すかどうか判断する編集長(というかその同等の職責の人ね)も、たいした知識もなさそうだし、それは仕方ないんじゃないかな。まるでメクラの夫婦が道案内なしに知らない土地を歩くようなものだね。
要するに、PAXnetの書き方は、
１．誤報と誤解によるもの
２．意図的に誤解を生むように書いた
３．正確で必要な知識が欠けていた
のどれか、あるいは複数の要因によるものだから、結果、
ただのヨタ記事
になっちゃったんだね。
不明な人は自分が不明であることさえわからない。
これを極楽トンボの法則
って言うんだよ。知ってた？
日経BPとかの著名なところでもけっこう同じような人や事件や記事はみかけるし、よくあることでしょ。
しかし、システムを必要とする会社の役員も「不明」、その間違いを身をもって阻止しようとした人もいなかった(あるいはつぶされた)、という点でみずほのシステム屋も「不明」、そして、その記事を書く記者や出版社も「不明」。そしてこのIT立国を目指す国の大事件を国会でまともに追求できない「日本の国の代表者」も「不明」。つくずく、勉強不足を棚にあげた「責任者」の多すぎる不幸な国に住んでると思うな。
若い連中が自暴自棄になって、問題起こすわけだな。
おれもそうしたいよ。
Re:PAXNetの記事はインチキだった！ (スコア:1)
記事に別段の問題はないと思うんですが。
UNIX自体が悪いとはどこにも書いてないし、(w
コンピュータが人の争いを解決してくれるわけじゃないしね。
φωφ)/
φωφ)/
Re:PAXNetの記事はインチキだった！ (スコア:0)
リレーコンピュータ自体は複数システムの統合手段としちゃ、そんなに無茶なもんでもないしなぁ.....
（つか、１０システムくらいを、それ使って統合する作業に従事したこともあるけど（Iの電算センターなんかがそう）、トラブルなんか聞いたこともないなぁ）
Re:PAXNetの記事はインチキだった！ (スコア:0)
少なくとも、IとSとかHとかのUNIXサーバのメーカーには何の影響も出てませんな。ま、Hは合併騒ぎで別の意味で影響を受けてはいるみたいだが（笑）
経営陣の責任について (スコア:0)
Re:経営陣の責任について (スコア:2, すばらしい洞察)
「みずほ銀行のトラブルはビジネス・チャンス」，富士通副社長が語る [nikkeibp.co.jp]
副社長曰く
トラブルが発生してからの1カ月間，当社の秋草社長に対して，ユーザー企業の経営トップから相談の電話や面談の申し込みが相次いでいる。
だそうです。
Re:経営陣の責任について (スコア:1)
こーゆーこと言う人が経営している会社には行きたくない。
とゆーか、よく経営できるな。
...先日まで就職活動をしていた学生より。
Re:経営陣の責任について (スコア:0)
なにかとトップの解任ばかり声高にさけぶ日本の風潮は
どうかとおもうが？
富士通を黒字にするには、いまのままだとさらなる大量解雇しかないのに、
会社を赤字にしてでも社員を雇ってるやさしい社長といえるんじゃない？
Re:経営陣の責任について (スコア:1, おもしろおかしい)
Re:経営陣の責任について (スコア:0)
真意は違うとの記事があったはず
でもそれもちょっと外しているような気がしなくもあらず
シリコンバレーの人が働くのはそれだけのインセンティブがあるからだし