失敗知識データベースにみずほ統合の事例があったんだが

お気に入り経由でいまさらながら見ましたが…

3. 負荷テスト、異常テスト等、十分なシステム稼働テストが出来なかった。
プログラム開発には必ずバグが存在する。稼動までに入念なシステム稼働テストを行いバグを取り除いて完全なシステムとするのが当然である。テストは実際運用時の条件をどれだけシミュレートして、負荷テスト、異常テスト等を実施するかが肝要。

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

これ書いたやつ出て来い！
システム開発における「完全なシステム」はニセ科学における「科学的に証明された」とほぼ同義だ。なんちゃって。
原因の項に書くことじゃないよな、こういうのは。タイトルに書かれていること以外はぜんぜん原因じゃないし。
なんか上から順に突っ込みたくなったので添削をクリスマスプレゼント。

第一勧業、富士、日本興業の３銀行のシステムを「みずほ銀行」として一本化するシステム統合で

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

「みずほ銀行」と「みずほコーポレート銀行」とするシステム統合プロジェクトでした。

それに付随したかたちで、約３万件の二重引き落とし発覚し最大級の大規模システム障害に陥った。復旧を図るも、このトラブルで顧客の混乱が長期化、1ヶ月以上も続いた。

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

これだと障害が一ヶ月以上も続いたように見えますが、障害でデータがおかしくなった一部顧客において、復旧に一ヶ月以上を要した(混乱が一ヶ月も続いたら大変だよ)ということだね。

99年12月 　　 個人・中小企業向け取引部門を担う現「みずほ銀行」の勘定系基幹システムを02年4月に第一勧銀システムに一本化する「片寄せ方式」の方針を決定。

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

これほんと？３ヶ月でこんなことに決まったんだっけ。公式発表かなあ。

02年4月 2日　オンラインATMは一旦復旧。

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

次の障害が起こることを期待させる「一旦」ですが、その後に事例がありません。

旧３行の自社システムの存続にこだわって主導権争い等で、大変なシステム統合である割りには、単に三つのシステムを繋げばよいという、タテ割り体制の弊害が見えるような、合理性を欠いたものとなった。

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

実質的には二行。単に繋げばよいという縦割り体制の弊害というのは意味がわからない。東京三菱UFJの当初のシステムも単に繋げばよいという思想。経過系としては一般的で合理的。

問題はリレーコンピュータの開発作業に遅れが生じたことにある。根本的なところで設計思想がなかった。

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

遅れたことと設計思想にどうつながりがあるのか意味不明。設計思想があれば遅れないのか遅れたことが設計思想のなさの証拠なのか。どちらととっても説明にならない。

たすき掛け人事を廃止する方針。役員数を削減して情報が素早く持ち株会社に集約できるようにする。
行動計画では、トラブル発生の原因と指摘される３行のバランスを重視した人事・組織の改革や、システム開発体制の刷新、リストラ計画の前倒しなどを盛り込む方向だ。

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

まあこれはこの対策としての記述にクレームをつけても仕方がない(ここでの提案じゃなく、銀行から示されたものだろうから)けど、実際にはうまく行ってないね。

知識化
1. システム障害は基幹システムと外部システムとをつなぐ接続部分で発生している例が多い。
2. システム稼動前に、入念なテスト( 疎通テスト、負荷テスト、強化テスト、異常テスト等)を実施しなければならない
3.システム設計はまず設計思想ありき。
4.合併・統合の条件となるシステム統合をする際は事前に合理的な対応を入念に行ない、システム統合の方針を決定する必要がある。
5. 経営トップはシステムに対する根本的な認識を改めなければならない。特にトップの経営判断において。
6. 企業の合併や経営統合においては、人事の融合と組織のスリム化が必須、たすき掛け人事バランス人事はよくない。

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

１．結果論。あるいは一般論。２．当たり前。失敗から学ぶ以前。３．自家撞着的。あと、見方にもよるけどこの件は「システム設計」ではなかった。４．当たり前。言うだけなら簡単。５．内容がない。認識とは何かを事例から示さないと意味がない。６．良くない理由が示されていない。
ぜんぜん知識化されてないというか単なる一般論でしかないぞ。事例から学べないことをわざわざ事例のデータベースとして記載する必要性が不明。

特にインターネットを舞台にした電子商取引は営業所や代理店を介さず企業と消費者を直接結ぶのが特徴である。システムも従来の汎用機による閉ざされたものではなく、オープンシステムと呼ばれる分散型の処理が求められ、その分、ネットワークの構成も複雑になっている。問題はそうしたシステム環境の変化に対し企業やメーカーが十分に対応しきれていないところにある。

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

残念ですが、インターネットバンキング起因の障害はこのとき発生していません。背景として持論をさも事例と関係あるかのように語るのは失敗知識データベースという名前に対してはルール違反じゃないですか？

データベースとしては変な持論が展開されるくらいだったら事例が書かれているだけで十分だと思うんだが。