わたしが知らないスゴ本は、きっとあなたが読んでいる: 要求仕様戦争（その4）

■開発工程をどうこうする――「要求開発」というフェーズを設ける いったい何が作りたいのか?――この問答を真摯に行う作業がすっぽりと抜け落ちている。仕様凍結ギリギリまで曖昧なままにしておこうとする顧客と、早い段階で仕様をFIXさせてしまおうとする開発側の、両方から引っ張られ、要求仕様決めが考慮されていないのが実情。 これまで後工程に埋め込まれ、属人的に処理されている「仕様のカケラから要求を復元する作業」「経営課題から要求まで洗練する作業」に名前を付けよう。それだけでなくその作業を一つのフェーズとしてキチっと定義しよう…そんな提言を行っているのが要求開発アライアンス[参照]。 例えば、システムをいかに効率的に作るかについては、開発手法、プロセス、開発支援環境が編み出され、適用されている。例えば、Eclipse はコード書きのためのツールだけでなく、テスター、QC（品質管理）、生産物、バグトレー

[takatoshiono]

何を作るかが曖昧モコモコのままだったら、まともなブツができるはずがない。まちがった要求を正しく作っても仕方がない。で、

[nitsuji]

何を作るかが曖昧モコモコのままだったら、まともなブツができるはずがない。まちがった要求を正しく作っても仕方がない。で、

[Schuld]

わたしが知らないスゴ本は、きっとあなたが読んでいる: 要求仕様戦争（その4）

[takets]

- 要求は開発するモノ