プログラマが知るべき97のこと/見積りとは何か
自分の担当業務に関して見積りを行い、見積り結果をマネージャや同僚、ユーザなどに伝えるのはプログラマの義務です。彼らはその見積り結果を踏まえ、目標達成のために時間やお金、機器等のリソースがどのくらい必要かを判断します。見積りが正確でなければ正しい判断はできません。
正しい見積りをするためには、当然のことながら、そのための方法を学ぶ必要があります。しかし、それよりも先にまず知らなくてはならないのは「見積りとは何か」そして「見積り結果はどう利用すべきか」というごく基本的なことです。実に不思議なのですが、プログラマやマネージャの中に、この2つを正しく理解している人はさほど多くないのです。
それは、たとえばプロジェクトマネージャ(PM)とプログラマの間で、次のような会話が交わされることが決して珍しくないということからもわかります。
PM「機能xyzの件だけど、開発期間はどのくらいだと見積もってる?」 プログラマ「1ヶ月ですね。」 PM「長すぎる。1週間で何とかならないか。」 プログラマ「どんなにがんばっても3週間は必要ですよ。」 PM「2週間、それ以上は無理だな。」 プログラマ「わかりました。それで手を打ちましょう!」
プログラマは、はじめは自分の見積もった数字を言っていたのに、結局はPMの求める数字を受け入れてしまっています。しかも、かたちの上では、PMがプログラマに譲歩したことになっているため、プログラマはこの数字に責任を負わなくてはなりません。上の会話がおかしなものだと気付けるのは、見積もり、ターゲット、コミットメントという言葉の正しい意味を知っている人だけでしょう。3つの言葉は次のように定義出来ます。
見積り: 「見積り」とは、何かの価値、数字、量、程度などについて概算、あるいはおおまかな判断をすることを指します。見積りのためには「事実の裏づけに基づく測量」が必要です。具体的には、信頼のおける数値データや、過去の経験などに基づく予測のことです。裏づけを基に得られた判断からは、希望や願望が排除されなければなりません。また、見積りは、あくまで概算、おおまかな判断なので、ある程度以上の正確さは期待できません。たとえば「機能Aの開発に要する時間は234.14日」というような見積りはあり得ないのです。
ターゲット: 「ターゲット」とは、実現したいビジネス上の目標を明文化したものです。たとえば「システムAは、同時に400人のユーザが利用できなければならない」というのはターゲットと言えます。
コミットメント: 「コミットメント」とは、「約束」と言い換えてもいいでしょう。「ある機能を、ある期日までに(あるいは、あるイベントまでに)、一定以上の品質で提供する」と約束することです。たとえば「製品の次のリリースまでに、検索機能を利用可能にする」というのはコミットメントでしょう。
見積り、ターゲット、コミットメントは元来、互いにまったく無関係なものです。しかし、ターゲットとコミットメントは、見積りを基にしたものであるべきでしょう。Steve McConnellは「ソフトウェア見積りの主目的は、プロジェクトの結果を予言することではない。見積りを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである。」と言っています。ターゲット、コミットメントを現実的なものにすることが、見積りの目的とも言えます。そして正しい見積りが土台にあれば、適切な管理、プランニングができます。
先の会話の場合、PMは、実はプログラマに見積りを求めているのではなく、コミットメントの設定を求めているのです。しかも、そのコミットメントの基になるターゲットはPMの頭の中だけにあり、はっきりと言葉にはされていません。見積りに基づかないターゲットを達成することは非常に難しいでしょう。見積りを求められた時には必ず、相手が「見積り」「ターゲット」「コミットメント」という言葉の意味を正しく認識しているかを確認すべきです。そうすればプロジェクトが成功する確率も上がるはずです。プロジェクトに関わる人たちが「見積り」という言葉の意味を正しく認識しない限り、どれだけ素晴らしい見積りをしても無意味でしょう。