アジャイルにソフトウェアを開発しようとする場合 (特に、スクラムを採用する場合)、多くのチームは「ストーリーポイント」などと呼ばれる抽象的な単位で作業を見積もると思います。この時、単純に時間の単位を相対化しただけで見積もろうとするのがよくあるパターンだと思いますが、時間よりも成果物の量を相対化した方がより正確に見積もれるのではないかという仮説が最近私の中に浮かんだのでその話を書きます。

よくある時間ベースの相対見積もり

まず、一般的に普及していると思われる、時間ベースの相対見積もりのやり方はこんな感じだと思います。

「先週機能 A を実装するのにかかった時間を 5 ポイントとすると、来週機能 B を実装するのにかかる時間は何ポイントくらいですか」
あるいは少し言い回しを変えて、「先週機能 A を実装するのにかかった時間と比べて、来週機能 B を実装するのにかかる時間は何倍くらいですか」

これはこれで悪くないのですが、時間を見積もりの尺度として使っているところにまだ不確かさが残っていそうな気がします。例えばある人は「機能 B は機能 A と同じくらいだ」といい、別の人は「機能 B は機能 A の 2 倍くらいだ」というかもしれません。このような見積もりのズレが起きた時、どのように擦り合わせますか? 単純に平均をとってそれを最終的な見積もりとするというやり方もあるでしょうが、もっと作業内容に関して深く吟味して擦り合わせたいと思ったときに「何となく機能 B は機能 A よりも大変そう」とか「いや機能 A よりも簡単でしょ」とか主観的に主張し合うだけでは正確さに対して全員が自信の持てる結論にたどり着けなそうですよね。

成果物の量で見積もる

そこで私が思ったのは、時間を基準に見積もるのではなく、作業が生み出す成果物の量を基準に見積もった方が、ズレを擦り合わせやすく正確さに自信が持てやすいのではないかということです。例えばこんな風に聞きます。

「先週機能 A を実装するのに 100 行のコード修正が必要でした。では、来週機能 B を実装するのに何行くらいコーディングが必要ですか」

このように、実際に作らなければいけない成果物がどんなものかを想像しながら語ることで、より客観的で統一された基準で見積もることができると思います。

「機能 B は機能 A と同じくらい仕様が複雑だから、コーディングする行数も大体同じでしょう」「いや、機能 B は既存の共通処理を呼び出すだけで実装できるから、コーディングは 10 行くらいで済む」みたいな議論をする方が、「時間がかかりそう」「かからなそう」と言い合うだけよりも、より正確に見積もれそうな気がしませんか。

このような成果物ベースの見積もりで重要なのは、最終的な成果物だけでなく、全ての作業の中間生成物を含めて見積もることです。そうすることで、実際にやらなければならないだろう作業を洗い出し、見積もりの精度を高めることができます。どんな中間成果物が必要になるかは現場によってまちまちだと思いますが、よくあるソフトウェア開発現場だと以下のようなものを成果物として想定することになりそうです。

仕様や設計を検討するために行う会議の議事録の量
作成・更新しなければならない設計書や仕様書の量
機能を実装するためのコーディングの量
自動テストを追加・修正するためのコーディングの量
実施する手動テストの量
ユーザー向けのリリースノートやマニュアルに記載する文章の量
チーム内で作業状況を連絡したり課題を相談し合ったりするためのコミュニケーションの量

成果物はまだ他にもあるかもしれませんが、実際に行う全ての作業に対して対応する成果物を考えて、それらを見積もることが大切です。そうすることで、見積もり時の考慮漏れや認識のズレを減らすことができます。

成果物を生まない作業

上記の見積もり方法だと、結果が成果物として現れない作業は見積もりに反映されないことになります。私はそれでよいと思っています。

例えば「設計について一人で考える」という作業がある場合、考えた結果を図や文章としてまとめるならばそれが成果物になります。ちゃんとした文書の体裁をとらずに、適当にメモ用紙とかにラフな図を描くだけで終わりという場合もあるかもしれませんが、その場合でもそのメモ用紙を成果物とみなしてよいと思います。しかし、考えた結果がどこにもアウトプットされず、作業者の脳内にしかないのであれば、その作業 (の成果物) は見積もりに含めなくて構いません。その理由は二つあります。

一つ目の理由は、具現化されない成果物の分量を見積もるのは、時間を基準に見積もるのと同じく、抽象的で、擦り合わせにくいからです。どうせちゃんと見積もれないのだから、見積もらなくてよいです。

もう一つの理由は、具現化されない成果物には価値がないからです。作業の結果が脳内にしかないのであれば、それが他の誰かの役に立つことはありません。作業の結果は、その成果物が他の何かに活用されることによって初めて価値があるのです。私たちは、そのような価値ある成果物を生み出すために作業をするのであり、価値ある成果物だけを見積もるべきです。

例えば設計を考えた後にコーディングするのを一人でやるとします。考えた結果の設計はコードに反映されるでしょうが、成果物はあくまでも書かれたコードだけです。「設計について考えてからコーディングする」のも「いきなりコーディングする」のも他人から見たら判別できないので、作業の内容は無視して、アウトプットされた成果物だけに着目すればよいです。それでもやっぱり設計作業の部分も見積もりたいと思うなら、設計結果をどんな成果物として具体化できそうか議論すべきです。