Code Completeの著者、Seteve MｃConnellによる、ソフトウェア開発における見積りについての本。名著です。
日経BPソフトプレス (2006/10)
売り上げランキング: 8268
アートとしての見積もりこの本は「『サイエンス』としての見積りよりも、『アート』としての見積りに主眼をおいている」と書かれています。つまり、大規模プロジェクト向けにプロの見積り担当者が行う見積りではなく、専門家でないにもかかわらずとりあえず見積りをしろと命じられたプロジェクトマネージャや開発者のための見積りテクニック、ということです。要するに、見積りのテクニックや論理について教科書的に語った本ではないうことです。
とはいえ、この本を読んでの僕の感想は、「すべてのプロジェクトにおいて、これだけキッチリとした手法で体系的に見積りをしていれば、もっといろんなことが上手くいくだろうなあ」というものでした。どうなんでしょう、中規模以下のプロジェクトで、日本でこれだけキチンとした見積りをやっているところって、どのくらいあるんですかね？個人的に経験した範囲では、PMがチームリーダーに「自分の担当範囲の工数を見積もっておいて」といわれて、後でそれを足し合わせて、適当に余裕率を掛ける、みたいな見積りしか見たことがありません。大規模プロジェクトは別としても、中規模以下のプロジェクトではどこもそんなもんなんじゃないかと思います。ましてや、プロジェクトの途中や終了後に、次回の見積りのために見積りと実績の差異データを収集するということをキチンとやれているところは、ほとんどないんじゃないんでしょうか。
とりあえずこの本を読めば、ソフトウェア開発における見積りの重要性がひしひしと実感できます。そして、今までとはひと味もふた味も違う見積りができるような気にもなれます（実際にやれるかは、今後の仕事で試してみたいと思います！）。この本は三部構成になっていますが、第一部「見積りの考え方」だけでも十分役立つしおもしろいので、コンピュータ関連の仕事をしている人は、是非読んでみるとよいと思います。
僕が一番「ほほう」と思ったのは、冒頭の冒頭、4ページ目に出てくる次の言葉。
「見積り」、「ターゲット」、「コミットメント」はそれぞれ異なるものであると認識しよう。
「見積り」は「このソフトウェアの工数は15人月で、開発に5ヶ月間かかる」というもの、「ターゲット」は「顧客との契約上、4ヶ月後に納品しなくてはならない」というもの、それに対して「コミットメント」は「ではある程度機能を削って、残業やエース技術者の投入を条件に、4ヶ月で納品しましょう」というもの。これをごっちゃにしちゃうと、開発者やPMに無茶なプレッシャーを掛けて気合いで開発させようとか、統計的な管理手法を取らずに「締め切りは決まっちゃってるんだから、とりあえずがんばれ！」みたいなメンタリティが横行しちゃうということです。
「日本のソフトウェア開発は、要件の変更頻度が高いことと、求められる品質の度合いが高いことから、米国流のサイエンティフィックでメソドロジカルな設計・開発・プロジェクト管理手法は、日本では通用しない」という意見が多く聞かれます。まあ確かにそういう面もあるんでしょうが、それで結局どうするかというと、残業と休日出勤と気合いのカミカゼ作戦しかないというのであれば、それはあまりにお粗末です。そんな職場ではまともな技術者は働きたくないだろうし、まともな技術者であればもうちょっと「ものごとをよくする方法」を考えるものではないでしょうか。
そして最近ますます、周囲でメンタルヘルスの問題をよく耳にします。「忙しくて勉強する暇なんて無い」という声も聞こえてきますが、それでもみんながもうちょっと「うまいやり方」を勉強すれば、いろんなことが少しずつまともになるんじゃないかなあと僕は思います。本当に役立つことが書かれている本って、世の中にたくさんあるし。
見積りやメトリクスの重要性が認識できたという意味で、個人的に大収穫の本でした。
コメントする