コンテンツにスキップ
Scrum Knowledge Graph

タスク見積り (Task Estimation)

概要

Section titled “概要”

タスク見積りとは、プロダクトバックログアイテムや開発作業の完了に必要な作業量、複雑さ、リスク、工数などを評価・予測する活動である。正確な絶対時間の算出のみならず相対評価尺度などを活用し、スプリントの計画作成、優先順位付け、作業分解を支援することを主な目的とする。決定権および最終責任は作業を担当する開発者にあり、チーム自身が見積りと作業計画を自律的にコントロールすることで、過剰な負荷や非現実的な納期プレッシャーを回避し、持続可能な開発ペースを維持することにも寄与する。見積りはリファインメントなどを通じて継続的に見直される一方、大規模開発や組織導入においては、チーム不在の見積り、過度な楽観、旧来文化との摩擦、進捗管理の難しさといった課題が頻発するため、適切な運用と理解が求められる。

詳細

Section titled “詳細”
  • 見積り（作業規模・工数の評価）とは、プロダクトバックログアイテムや開発タスクの完了に必要な作業量、複雑さ、技術的依存関係、リスク、工数を評価・算出するプロセスであり、アイテムや分解された作業自体が保持する属性である[1][2][3]。リファインメントの過程などを通じてプロダクトバックログアイテムに見積り属性が追加・更新される[1]。
  • 見積りに関する最終的な決定権および責任は、実際に作業を担当する開発チーム[1][4][5][2]、または開発者[6]にある。プロダクトオーナーは意思決定やトレードオフの補足・検討のために影響を与えることはできるが[1]、開発者が適切に理解し選択できるよう助言や支援するにとどまり、見積り数値自体を命令・強制できず、決定権は作業者が持つ[5][6][2]。
  • 見積りの手法として、正確な絶対時間の予測のみならず、1から始まる修正フィボナッチ数列（1・2・3・5・8・13・21など）やストーリーポイントを用いた相対評価の尺度が頻繁に使用され、開発チームが協調して算出する[3]。
  • 見積りはプロダクトバックログのリファインメント活動[1][5][6]やスプリントプランニング[1][5][6]などを通じて継続的に実施される。見積もりはスプリントの計画作成、プロダクトバックログの優先順位付け、作業分解を支援する役割を果たし[3]、順位が上位となり項目が明確化・細分化されるにつれて見積りの精度が向上する[1][5][2]。
  • スプリントプランニングなどの反復開始時においては、選択したアイテムを実現するための作業を1日以下の単位に分解して見積もりを実施する[1]。チームメンバーが共同で見積もった結果に基づき、反復内で完了可能な作業量を現実的に計画するとともに、スケジュールを遵守できるようタスク範囲を適切に小さく分割する[7]。これがスプリント内に完了できる作業量を判断するための基礎となり[6]、進捗予測や残作業の可視化における土台となる。
  • チーム自身が見積もりとスケジューリングを自律的にコントロールすることは、仕事の負荷を平準化し、過剰な負荷や非現実的な納期プレッシャーを回避して感情的な疲労を抑制し、持続可能なペースを維持することにつながる[7]。
  • スプリント期間中における完了作業や残作業の見積りは開発チームにより随時・定期的に更新され[1][2]、残作業の推移を監視することにより、スプリントプランニングやデイリースクラムなどを通じてゴールへの進捗状況や予測を継続的に評価・追跡する[4][2]。
  • 条件変更、スプリント中止、あるいは未完成アイテムのプロダクトバックログへの戻りが発生した場合や不確実性が高い場合には、時間の経過による価値の変化や急減を防ぐ観点から再見積りが実施される[1][4][5]。
  • 大規模アジャイル環境や組織的導入の文脈においては、見積りに関して以下のような課題が指摘されている[8]。
    • 開発チーム不在の見積り: 高レベルなバックログアイテムの見積りがチームの関与なしに行われると、後工程でのチーム間の引き渡し時期に齟齬が生じる[8]。
    • 過度な楽観主義: スクラムに対する過度な期待や非現実的なプロジェクトスコープにより、リリース計画の見積もりが過大評価される[8]。
    • 旧来文化との摩擦: 従来のソフトウェア文化における「初期見積りは固定・コミットされるべきである」という前提と、アジャイルにおける変動的・反復的な見積りとの間で対立が生じる[8]。
    • 契約管理とアーンドバリューの困難さ: アジャイル開発の見積もりは進捗を直線的に測定しにくく、アーンドバリューに基づく契約管理や進捗把握が難しい側面がある[8]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Scrum Core Planning Workload
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”
  • 上位クラス（直接の親から順に）: Measurement
  • 兄弟クラス: EffortLog
  • 他の概念との関係: 未定義
  • 関連する検証ルール: 未定義
  • 関連CQ: 未対応
  • 原文: 未定義
  • オントロジー階層: オントロジー階層で見る

脚注

Section titled “脚注”

  1. Scrum Guide 2013（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  2. Scrum Guide 2011 October（ライセンス: All Rights Reserved） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering — 「見積り（Estimation）列は、プロダクトバックログを実装するために必要な工数を表す。」（原文: “The Estimation column represents the effort required to implement the product backlog.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  4. Scrum Guide 2016（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  5. Scrum Guide 2017（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. Scrum Guide 2020（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  7. Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources（ライセンス: CC BY 4.0） ↩ ↩2

  8. Systematic Literature Review Report on the Challenges of Agile Scrum（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5