6000人が作ったシステムは必ず動く：ITpro

最盛期の開発要員6000人，開発工数11万人月，投資額2500億円，取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ，勘定系システム一本化プロジェクトの成果物である。6000人のシステムズエンジニア（SE）が作り上げた巨大システムは，2008年5月の連休明けに必ず動くはずだ。
(中略)
ここまで書いて急に不安になってきた。「厄病神の告白，『私はシステム事故を招く』」に書いた通り，筆者が特定プロジェクトに言及すると必ずよくないことが起きるからだ。6000人に迷惑をかけては申し訳ない。手遅れかもしれないが，これから5月の切り替え日まで，静かに成功を祈ることにする。すでに現場を離れた方もおられるが，6000人の皆さん，健康に注意しつつ，切り替えを乗り切って下さい。
（谷島　宣之＝経営とITサイト編集長） 　[2008/04/24]

http://itpro.nikkeibp.co.jp/article/OPINION/20080423/299886/

開発やっている人間なら、どんなに人数を投入したところで一定以上は効率なんて上がらないし、規模の大きい複雑極まるプログラムは、どんなにテストしても完全は無く、実際の本番環境で思わぬ障害の一つや二つが出てくると言うのは、経験則として理解しているので、この文章を読んで思ったのは、
「関係者のハードルを無意味にａｇｅんな」と。
関連：不具合の原因は「カタカナでなく漢字だったから」――三菱東京UFJのシステム障害 - ITmedia エンタープライズ
関連：三菱東京UFJからゆうちょ銀などへの入金が不能に――現在は復旧 - ITmedia エンタープライズ
お陰で、これほどの大規模システム移行なら、絶対発生するであろう軽度障害も、ものすごく痛い話になってしまった。
テストが甘い、と「言うだけ」なら簡単であるが、膨大で複雑なテストパターンを「人間が想定して作る」以上、大規模システム開発で漏れや抜けが無いなんていう事は、まず不可能だ。
どんなにクリィティカルな社会基盤に関わる重大なシステムだろうが、人間が作る以上、絶対も完璧も無い。
だから、一番大切な部分は、設計段階で何重にも保護されている筈である。
上記の障害では、どちらも「(入金できない、預金引き出しできない等)機会損失」は発生しても、実際に預金データが失われるなどの「直接損失」は発生していない。
必要なのは、「完璧」でバグの無いシステムではなく、間違えても重要なデータは保護され復旧できる「安全」なシステムであり、その点は十分満たされて居ると思う。
無論、間違いが無いことが望ましいし、間違いを減らす努力は怠るべきではないが、取り返しの付かないものでなければ、間違えたら、直せばいい。
同じ失敗を繰り返さなければいいのである。
政治に関してもそうだけれど、日本人って「間違いを許せない」という悪癖があると思う。
何もしないから間違いゼロの政治家より、間違えるけど、間違えたら次からは同じ失敗をしない、やる気のある政治家、本来は後者の方が健全なんだけれど、後者は最初の失敗で排斥されるので、日本では政治家や優秀な官僚が育たないのではないかと思ったり。
閑話休題。
なぜプログラムの世界で、人数を投入しても効率が上がらないかについては、下記を参照。
参考：ブルックスの法則 - Wikipedia