スクラムを利用した開発で見積もりを絶対値から相対値に変えたら、チームの議論が深まった話

こんにちは。認証・権限管理基盤チームでソフトウェアエンジニアをしている坂本です。

私たちのチームではスクラムを採用しており、毎週のスプリントプランニングではエンジニア全員でプランニングポーカーによる見積もりを実施しています。

今回の記事では、見積もりの基準を「絶対値（作業時間）」から「相対値（他タスクとの比較）」に変えただけで、見積もりの品質やチームの議論がどう変わったのかを紹介します。

この記事はカケハシ Advent Calendar 2025 の 17 日目の記事です。他の記事も合わせて楽しんでいただけたら嬉しいです。

なぜ見積もりを実施するのか

そもそも、なぜ私たちは見積もりを行うのでしょうか？
単にスケジュールを引くためだけではなく、以下の3つの要素を整理し、チーム内の認識齟齬を埋める重要な役割があると考えています。

作業量
- 「どれくらいの作業が必要か」という量的な側面。
- 例：似たような画面を1つ作るのと3つ作るのでは、後者の方が作業量は多くなります。
複雑さ
- 「どれくらい頭を使うか」という質的な側面。
- 例：単純な表示機能よりも、複雑な計算ロジックを実装する機能の方が複雑さは高くなります。
不確実性
- 「どれくらい未知の要素やリスクがあるか」という側面。
- 例：初めて使う技術の調査が必要なタスクや、仕様がまだ曖昧なタスクは不確実性が高くなります。

当初、私たちのチームでは絶対値（時間）を基準に見積もりを実施していました。具体的には以下のような基準です。

1pt = 1営業日とするのは直感的に分かりやすいメリットがある反面、運用していく中で以下の課題が浮き彫りになりました。

人によって作業スピードが異なるため、「Aさんなら1日だけど、Bさんなら2日」といった属人的な議論になりがちでした。結果として、タスク本来の「作業量・複雑さ・不確実性」についての議論が深まりません。

スプリントごとに会議の多さが異なるため、「結局、1営業日あたり何時間作業できるのか？」という前提条件が毎回揺らいでしまい、見積もりの精度が安定しませんでした。

これらの課題を解決するため、相対見積もりを導入しました。
絶対見積もりとの最大の違いは、時間を直接見積もるのではなく、「基準となるタスクと比較して、どれくらいのサイズ感か」を考える点です。

これを実現するためにやることは1つだけです。

相対見積もりでは基準となるタスクを決定する必要があります。私たちのチームでは、1ptの基準となるタスクを、スプリントごとにチーム内で決定する ことにしています。

具体的には、「全員が内容を認知しており、かつ1スプリント内で確実に完了できるサイズのタスク」を選びます。

ベースとなるタスクは必ずしも毎回変える必要はありません。
しかし、直近のスプリントで完了したものなど、記憶に残っている鮮度の高いタスクをベースにした方が比較イメージが湧きやすいため、定期的に変更することをオススメしています。

「誰がやるか」ではなく「タスクそのもの」に集中できるようになった

時間という軸を外したことで、「誰が担当するか」という属人性を排除できました。純粋にタスクの難易度や複雑さについて議論できるようになり、仕様の曖昧な点がプランニングの段階で発見しやすくなりました。
例えば、1ptと3ptでポイントが割れた場合、タスクに対する認識にズレが発生している可能性が高いです。その場合は両者の意見を聞くことで認識を揃え、必要があれば再度見積もりを実施します。