見積もりは目標ではなく、コミュニケーションツールである

「これ、どれくらいかかる?」「この変更、どのくらい大変?」

こう聞かれてイライラし始めているなら、あなたはおそらくソフトウェア開発者でしょう。見積もりは苦痛です。特に、タスクの見積もりを求めてくる相手(仮に「ボブ」と呼びましょう)が、自分が何を求めているのか漠然としか把握していない場合はなおさらです。この苦痛の多くは、「ボブが本当に欲しいもの」と「あなたがボブはこう欲しいと思っているもの」のズレから生じています。

見積もりは目標ではない

開発者として、私は見積もりを「あるタスクを完了するのに、平均してどれくらいかかるか?」という問いだと捉えています。イライラするのは、その質問に答えるだけの情報が手元になく、しかも一度口にした数字は守らされると分かっているからです。見積もりを達成できるかどうかが、自分の総合的な評価の指標になると考えれば、ストレスや苛立ちが募るのも無理はありません。

見積もりはコミュニケーションツールである

世に出るすべての製品には、それに依存する何かが存在します。会社の規模にもよりますが、マーケティング、広報、ビジネス分析、将来の製品計画など、挙げればきりがありません。つまり、ボブが本当に知りたいのは「この作業が完了すると見込んで、依存関係にある計画を立て始めてよいのはいつか?」ということなのです。

私は「〜までには完了しているはずです」と答えますが、ボブが求めているのは「〜までに完了します」という答えです。

David Bryant Copeland の著書『The Senior Software Engineer』は、この点について第1章で次のように述べています。

シニアソフトウェアエンジニアは、最も重要な仕事を確実にやり遂げることを信頼され、期待されている。そのために必要なのは、自分の行うすべてのことを「成果の提供」に集中させることだ。

この視点を持ち続ければ、ボブの土俵に合わせて応じるのがベストであることが分かります。具体的には、次の3つの原則です。

• 見積もりは90%の自信で出す。50%ではダメ

  ボブは、作業の完了を見越して他の計画を立て始められるタイミングを知りたいのです。そのために見積もりにバッファを盛り込む必要があるなら(おそらく必要です)、それで構いません。1〜2時間後に改めて回答することになっても、問題ありません。

• 見積もりは「リリースまでの時間」基準で。「QA引き渡しまで」「デプロイキュー投入まで」などではなく

  これも「成果の提供」へのフォーカスにつながる話です。ボブがプロジェクトの出荷を待っているなら、QAで足止めされたままでは彼にとって何の役にも立ちません。通常、これは見積もりにさらにバッファが必要になることを意味しますが、それで構いません。

• 最良の見積もりは、しばしば「今は答えられないので、後で返事します」

  見積もりをより小さな単位に分解すれば、それぞれが理解しやすくなり、90%の自信を持ったリリース時期の見積もりを出しやすくなります。正確な見積もりを作るためのテクニックについては多くの書籍で論じられていますが、本記事の範囲外とします。

「スピードが遅い」と言われたらどうする?

私が働いてきた職場はどこでも、経営層が「もっと速く進められたらいいのに」と口にしていました。製品がどんなに速く納品されても、品質が完全に犠牲になっても、見積もりが無茶苦茶でも、1日20時間働いても、経営層はなお「もっと速く」と望むものです。開発者に求められるのは、それが単なる願望だと見抜いたうえで、速くても維持可能なペースを保ち、予測可能であり続け、成果を届け、高い品質基準を維持することです。

見積もりを大幅に余裕をもってクリアしたら、盛りすぎに見えない?

常日頃から多めに見積もる人が、それを理由に罰せられるのを目にしたことはありません。むしろ、予想以上に長引くプロジェクトが現れたときに、その「余裕」が報われます。同じ幅でも、過大見積もりは過小見積もりよりはるかにマシです(損失回避の心理に近いものを感じます)。ほとんどの場合、バックログには次の仕事が溜まっているので、前倒しで着手できます。これは良いことずくめです。

もし50%ケースを狙うなら、予期しないトラブルひとつで製品スケジュール全体が崩壊しかねません。しかも、そんな事態は半分の確率で起こるのです!一方、90%ケースを狙えば、仮に物事が悪化しても、残りのスケジュールは予定どおりに回ります。製品は時間どおりにリリースされ、誰もが満足し、昇給や昇進があり、そして最高のご褒美として――あなたはまた新たな見積もりを作ることになるのです!