もう半年以上前に「デッドライン―ソフト開発を成功に導く101の法則」（日経BP社）を楽しく読んだのですが最近になってこの本に対する私なりの意見がまとまって来たので書評です。（遅いよ）
【この本のポイント】
プロジェクトで重要なのは人であり、コミュニケーションである。
重要な仕事（設計）に、集中してもらうこと。これがプロジェクト成功の秘訣。プレッシャーや残業は無意味！
プロジェクトでもっとも大きいコストは手戻り作業。故に当初の要求定義／設計作業に多くの時間リソースをつぎ込むべき。そうすればコーディング以降一気呵成に出来上がる。
【感想】
著者の人重視の姿勢には好感が持てます。本当にそうだと思う。
プロジェクトの運営論については設計フェーズをあまりに重視しすぎ。
・柔軟に対応できる設計と取り返しのつかない設計があると思う
⇒ 手戻り覚悟で進めた方が結果的に早い／コストが安い場合があります。設計が完全に固まるまでコードを書かないのではなく、覚悟してコードに着手してしまった方がよい場合もある。（もちろんセンスと経験が必要な賭けではありますが・・・）
・技術的な実現可能性（フィージビリティ）を机上で検証するより、作って見たほうが早い。その結果手戻りが発生してもそれはしょうがない、という割り切りも必要。
私の経験では、旧来のウォーターフォール型を緩やかに運営するのがベストと思います（凡庸な意見だけどね）。スパイラル型の開発はやはり手戻りが痛い（※）・・・小規模なプロジェクトで優秀なコーダーが揃っている場合はスパイラル型が有効かもしれませんが、ちょっと画餅っぽい気がします。
（※）手戻りに強いのがスパイラル型ではないのか、と疑問に思われるかもしれません。確かにJunitで再帰テスト可能なレベルのちょっとした変更ならば問題ありませんが、設計変更レベルの手戻りはやはり厳しいものがあります。
以上。
