タイトルに釣られて読みましたが、確かに設計と実装を分けるデメリットは恐ろしい。昔からウォーターフォールモデルの開発形式は続いていますがシステム開発に関しての実態は上から下に一方的に流れるのではなくてＶ字型に戻ってくるのを実感しています。それも上から下へ流すのは早いけど、折り返して上っていくのには時間が掛かる。また工程のレベルと担当者が一致していることが多く良く考えられた図だなと思います。(後半上りになる工程は機能テスト→単体テスト→結合テスト→総合テスト→納品→仮運用といった内容です)
ちょっと脱線しましたが、プログラマが仕様→実装→テストを行うことができれば理想です。まず社内でこの３つ工程を請負っているならなるべく分業しないようにしたほうがいいですね。仕様の伝達コストが下がるだけでなくモチベーションに大きく影響します。実装すべきプログラムが多くて一人で出来ない場合は実装のみ社内分業して仕様とテストに専念すると良いと思います。仕様だけ決めて実装とテストを切り離すと結果的に無責任になったり仕事がつまらなくなったりしますからね。
また要件定義に関わる人は技術者とはまた違う考え方が出来る人じゃないと勤まらないというのもそうですね。以下のエントリー見てどこまで要件定義でどこから基本仕様か区別できなかった自分に反省しています。勿論顧客が基本仕様作成することもありますが、仕様を作成する人は実装能力ではなく運用経験豊富な人が必要だと最近思うようになりました。特に顧客とは別にエンドユーザが存在するシステムにおいてはユーザビリティのプロフェッショナルにUIの設計をお願いし顧客が要件定義と一緒に出してきた画面仕様に手を加えて指摘・説明・修正して欲しいと思っています。例えば個人情報の取得方法等は技術的重要度が低く要件定義のように見えるのですが実は仕様じゃないのかと思います。これも運用経験の豊富な方に仕様を決めてもらったほうが見込み客の損失を最小限にするフォームの設計をやってくれると思います。そういう意味で要件定義と基本仕様は分けた方が良いものが出来そうな気がします。これが技術者がヒアリングすると簡単に実装可能なことは顧客の言うままハイハイ聞いてそのまま仕様にしてしまいサービス開始後にエンドユーザから使いづらいとか、登録フォームの必須が多すぎて見込み客を逃しているのではないか？といった運用面の問題を指摘されたりと言った事になりかねないです。と言うかごめんなさい。私が基本設計に関わった時の一例です。
現実は要件定義から基本仕様が顧客、基本仕様丸写しの基本設計とそれを元にした詳細設計が一時請負、実装とテストが下請けという問題の多すぎる構造なんですよね。この構造だとどうしても担当している工程に大きな影響を与える上流部分が他社の作業範囲って事です。分業した筈なのにルールが干渉している…。社内だとすぐに声かけて話し合ったりレビュー実施すればいいのですが、他社になるとスケジュール合わせとメールや電話での質問とやっているうちに一週間経ってしまう事もありました。
プログラマが仕様を決めればいい - GoTheDistance
http://d.hatena.ne.jp/gothedistance/20080410/1207832176
