本書には、公式のプロセスを採用すべきではないという記述がいくつかあるが、これはデスマーチプロジェクトに対してであって、通常のプロジェクトに対するアドバイスではない。もし、一般論としてISO-9000 やCMM などの品質管理が不要なものであると受け取ったとしたら筆者はがっかりするだろう。その他にもソフトウェアメトリックスやCASE ツールも状況によっては有害であると述べているだけで、一般論として否定しているわけではない。私はむしろ、ソフトウェア開発を業として行う組織は明確に定義されたソフトウェア開発プロセスを持つべきだと考えている。（それ以前に明確に定義された業務プロセスが必要なことは言うまでもない。）
その他、興味をもったキーワードとしては見積もりとリスク管理があります。多くの開発組織では、見積もりをどんぶり勘定で行って、プロジェクト完了後に精度について検討することもない。これでは永遠に精度の高い見積もりはできない。見積もりは単にお客さんからもらう金額を計算するだけのことではなくて、対象の量と複雑さの推定、それに必要な資源やコストの推定、達成すべき品質の定義などを考慮して行う必要がある。それは単純な計算式やツールが自動的に算出してくれるようなものではなく、日々の測定値に基づいて統計的な手法によって行う。つまり、日常的に測定を行ってデータを収集しなければならないのだ。しかし、成果物の量もかかった時間もコストも品質も何一つ測定していないことが多い。
また、「リスク管理」は見積もりと強く関連してる。リスクの高いプロジェクトは、それだけ見積もり金額も高くすべきだが、何の根拠もなく「リスクが高いから2倍くらいにしよう」などという見積もりをしていては、お客様のためにも自分達のためにもならない。ではどうやったら根拠を示せるのだろうか。小規模な組織でも、トータルすれば年間数十件のプロジェクトやタスクをこなしている。それらの１ つ１ つからデータを収集し、蓄積すればそれなりに意味のある統計がとれるはず。大雑把でも、何もしないのとは大違いだ。さらに、リスクを軽減させる努力も必要だ。これも、日頃の統計データの収集がなければ、リスクが減ったということを判断する基準もないことになる。こうして、プロジェクトの開始に先だってリスクの可能性を調査し、できる限り排除しなければならない。
以上の考え方は当たり前のことのようだけれども、当たり前のことをきちんとすることが何より大事だと思う。
