一番うまく見積もれるのはその仕事をする人である

ひとりがすべての作業の見積りをするようなプロジェクトを経験したことがありますか？うまくいきましたか？うまくいかなかったんじゃありませんか？

このやり方には大きな問題が3 つあります。

• よほど運がよくない限り、開発者と見積りをする人のあいだには、スキルのレベルに差があります。リードアーキテクトがすべての仕事をするのであれば、彼の見積りは正確かもしれませんが、実際に仕事をする開発者のペースはきっと違っているでしょう。
• ひとりがチーム全体を見積もると、見誤るリスクがかなり高くなります。見積りに関与する人が多ければ多いほど、見積りは改善されます。
• 開発者は不完全な見積りを手渡されて、それに合わせなければなりません。こうしたやり方を喜ぶ開発者はまずいないでしょう。

一番まずいのは、あなたがプロジェクト・マネジャーにはチームに見積りを提示する権限があると思い込んでいることです。あなたもかつては開発者だったので、適切に見積もれると思っているのかもしれません。たとえあなたが積極的に開発に関与していたとしても、よく考えましょう。先ほどのリードアーキテクトの話と同じことが当てはまります。しかも、積極的に開発していた頃から時間がたてばたつほど、あなたの見積りはどんどん間違っていきます。もし自分がよく知らない技術を使っているチームを率いているなら、自分で見積もろうなんて考えてはいけません。

私たちのプロジェクトではワイドバンド・デルファイ法を使ってグループ見積りをしています。まず最初にビジネスアナリストがフィーチャー要求について説明するところから始まります。開発チームはそれを聞いて、疑問に思ったことをクリアにするための質問を繰り返します。初期見積りの準備ができると、各自カードに見積もった値を書いていきます。全員が書き終えたら、3 つ数えて各自カードを掲げます。

そうしたら、どれだけ見積もった値が一致しているかを調べます。もし非常に近い見積りが得られていれば、そのなかで控え目な値を選びます。もし見積りに大きな違いがあれば、どうしてそう見積もったのか開発者に尋ねます。そして、さらに議論を重ねて、再度見積りをします。開発者のあいだには、そのフィーチャーを完成させるために何が必要なのか、共通の理解があるため、たいていの場合、見積りはひとつの値にまとまります。

このやり方は以下のような点で好都合です。

• チーム全員が見積りの検討に参加するため、いろいろな見方を全員で共有することができます。たいていチームメンバーは同じ意見にまとまって、すぐに共通の見積りが得られるでしょう。
• あとで実際にコーディングを開始するときには、開発者全員がその見積りに至るまでの思考プロセスを知っています。そのため、限られた人しかそのフィーチャーに取りかかれないという状況を減らせます。
• チームに見積りを「所有」させることで、反発の機会を減らせます。見積りにはまだ間違いがあるかもしれませんが、チームメンバーはあまり挑戦的な態度をとることなく、協力的に修正した見積りを受け入れてくれるでしょう。

覚えておきましょう。一番うまく見積もれるのは、その仕事をする人なのです。