「アジャイルな見積りと計画づくり」書評 -- 顧客を黙らせる為の見積りではなく喋らせる為の見積り

翻訳者の角谷さんより献本をいただきました。ありがとうございます。

アマゾンに以下のレビューを投稿したのですが、なぜか1ヶ月以上待っても表に出てこないので、こちらに出します。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

この本が問いかけているのは「開発者にとって客は敵なのか味方なのか」という問いだと思う。

私がソフトウエアの見積りの本を読む時に、漠然と期待してしまうのは、「これで客の口を塞ぐことができるか」ということだ。つまり、自分が「これは1000万円かかりますね」と言って顧客がそれを値切ろうとした時に、「いやこの見積りは正確です。なぜなら....」と言うような、建築における構造計算のような理論武装が欲しいと思ってしまう。

こういう思考の暗黙の前提は、「開発者と顧客は敵同士である」ということだろう。

見積りも仕様も開発者と顧客の間で交わす契約である。契約とは、潜在的には利害の対立する同士が、一時的に休戦して共同作業を行なう為のものだ。だから、この言葉をダイレクトに使うことはめったにないが、「開発者と顧客は敵同士である」という暗黙の前提はソフトウエア開発者の間に広く行きわたっていると思う。

実際に、納品したソフトウエアが顧客の希望するものと違っていた場合には、「ここを直せ」「直すから金を出せ」という戦争が始まり、その時、敵の攻撃から自分を守ってくれるのは、見積りの前提となっている要件を書いたドキュメントである。

そういう意味で、顧客から開発者を守ってくれる理論を期待する人には、この本は合わない。

この本が目指しているのは、「正確で客を切り捨てる見積り」ではなくて「客が深く納得する見積りと計画」である。その為に、開発者と顧客の間のコミュニケーションを促す為の実践的なノウハウが詰まっている。

たとえば、タスク(開発者の視点によるモジュール分け)でなくフィーチャー(ユーザの視点による機能分割)を単位とせよとか、スケールとして 1,2,3,5,8のフィボナッチ数列を使えとか、リスク×付加価値の高低で4つに分類するとか、そういう具体的なノウハウが、あらゆるレベルに出てくる。

いずれも、「なるほど、これを使うと客との会話が進むだろうな」と思わせるものではあるが、「なるほど、これを使えば客はぐうの音も出ないで黙るしかないな」というものではない。

顧客と開発者がコミュニケーションを深め、不確実性とリスクに関して合意する。そこからプロジェクトをスタートすれば、顧客と開発者は利害を共にする味方同士であり、一つのチームになる。それが、この本で言う「見積りと計画作り」である。

「自分はお客様の味方としてソフトウエアを開発したい」と思っているソフトウエア開発者には必須の本だと思う。