上から下まで一貫して担当した方が、みんなハッピー♪になるよね？

最近、とみに感じていることです。

工程が分かれてしまっていることの弊害は計り知れなくて色んな問題を引き起こしていると思うのだが、特に思うのが上流工程だけでも下流工程だけでもつまらないんだけど、上流から下流を全部担当するとこれほど面白いものはないということ。
（中略）
結果としてとても品質の高いシステムができると思う。
プログラマが仕様を決めればいい - GoTheDistance

ものすごく賛成！

ただ、今のプロジェクト*1の方針は逆ですね。

基本設計（者）⇔詳細設計（者）⇔プログラマ *2

という流れではっきり分断されています。つまり、詳細設計をした者はそのコーディングはできないということです。その理由はいくつかあるけど、プロジェクトリーダいわく、仕様的なチェックを最低2回はしたいのだと。なので、詳細設計者とプログラマを分離して、基本設計者と詳細設計者でチェックを行う体制にしているみたい*3。

ただ、このやり方だと詳細設計者⇔プログラマのコミュニケーションロスが考慮されていないんですよね。そのために、詳細設計者がそのままプログラムするのと比較して、どうしても品質の面で落ちることとなります。ロスを許さず漏らすことなく伝えようとすると、（リンク先でも触れられてるように）作業が増えすぎて死ねますｗ

と、ここまで考えて思ったのですが、これも人月問題に代表されるように、エンジニアの入れ替えが可能であるということを前提としているのですよね。1人で詳細設計1ヶ月・コーディング1ヶ月をかかったのならば、2人でやれば合わせて1ヶ月で済むよねって、そりゃ単純計算だとそうでしょうけど…orz「9人の妊婦を集めても、1ヶ月で赤ちゃんを出産することはできない」んですよ*4。

設計者とプログラマを分けたことによって仕様の二重チェックというのは達成しているのですが、その結果コードの品質が悪くなっちゃ意味がないような気が…

結論からすると、上から下まで一貫して手がけた方が開発側も楽しいし、顧客側もいいものができあがってハッピー♪になるのではと思ってます。

ただ一つ疑問なのは、大規模プロジェクトでも適用できるのかなってこと。それぞれの開発者が全て要件定義から設計・開発まで全て行うとしても、大規模プロジェクトで開発者が全員顧客のところに群がってもてんやわんやだよなぁ、とか思いつつ。人には得手不得手があるから、ある程度は分業化して得意分野に注力した方がいいかもしらんし。

そういや、この辺金曜日にAmazonから届いたばかりの「受託開発の極意」でちらっと触れられていたっけ？明日の通勤中でも読んで、ちょっと考えてみようかな。