フェーズ分割の無茶

NTTデータ社長の話がアツい。
JavaBlackさんやtonotonotonoさんの日記で、スラッシュドットのこのコメントの存在を知る。

スラッシュドットではたくさんのコメント（しかもマジになっているの）がついているけど、この人は「シャレ」で書いていたのではなかろうか。

このようにして各フェーズ毎に必ず成果物のQAを受け、リスクを徹底的に排除すればプロジェクトに失敗は起こらないのであります。
ないはずです。

ここにシャレが凝縮されている、と自分は読んだ。「ないはずです」＝「現実はそうならないでしょ」、ということね。

手前味噌だけど、数日前にこんなことを書いた。

「基本設計の終了」はどうやって判断すればよいのですか？

答は「作ればわかる」なんだけど、基本設計フェーズだけで基本設計を完了させる（つまり、設計もれリスクを排除する）ことは実はできない。設計が完了していたら、（スラッシュドットのコメントにも書かれているけれど）あとは機械的に開発作業は完了するはずだ。でも、実際には基本設計は未完だから詳細設計とか内部設計とかいう名目で細かいことを次のフェーズに任せることになる。

知人の勤務する大手SI業者では「レビューで20件[*1]の指摘事項を得る」ことが基本設計完了の必要条件だとか。つまり、21件以上の抜けのある基本設計書はあっという間に必要条件を満たしてしまう。しかも、1件以上の抜けを残したままになる可能性は排除できない。

以前作ったのと同じプロジェクトを繰り返すのなら設計完了を設計フェーズで確認することは可能かもしれないが、ちょっとでもコンピュータをかじったことのある人ならcpとかCOPYコマンドを選択して、新規開発には踏み切らないはずだ。

「作ればわかる」「作らないとわからない」というのは、基本設計に限らず、要件定義だろうが概要設計だろうが、なんでも同じこと。作ってみなければ、設計に漏れや抜けがあるかどうかの検証はできない。要件定義段階や設計段階での成果物に対してQAを実施するというのは「開発チームで決めた記述ルールに対するチェック」に過ぎず、定義や設計に漏れや誤りがないことを保証するものではない。そもそも、設計段階で「リスクを徹底的に排除する」ことは不可能なのである。

つまり、フェーズ分割をすることで、プロジェクトはほぼ確実に失敗する。それをなんとかするために、プロジェクト後半の「モノ」が見えてきた段階で徹底的な人海戦術をとって、それまでの抜けや間違いを救済する羽目になる。人はそれをデスマーチと呼ぶ。（つづく）

*1:実際の数字はちょっと自信ない。10件だったかもしれないし、100件だったかもしれない....