第5章:見積もりと計画
更新日:2025年12月7日
1. アジャイル見積もりの考え方
1.1 従来手法との違い
従来のソフトウェア開発では、工数(人日・人月)による絶対見積もりが一般的であった。しかし、この手法には多くの課題がある。Table 1に従来手法の課題を示す。
Table 1. 従来の見積もり手法の課題
| 課題 | 説明 |
|---|---|
| 不確実性の高さ | プロジェクト初期は情報が不足し、精度が低い |
| 個人差の影響 | スキルレベルにより大きく変動する |
| アンカリング | 最初に出た数字に引きずられる |
| プレッシャー | コミットメントと混同され、圧力を受ける |
アジャイルでは、これらの課題に対処するため、異なるアプローチを採用する。
1.2 相対見積もり
相対見積もりは、作業項目同士を比較して相対的な大きさを評価する手法である。「AはBの2倍の複雑さ」のように比較することで、より直感的で一貫性のある見積もりが可能になる[1]。
相対見積もりの利点をTable 2に示す。
Table 2. 相対見積もりの利点
| 利点 | 説明 |
|---|---|
| 人間の得意分野 | 人間は絶対値より比較の方が得意である |
| チーム間の差を吸収 | ポイントはチーム固有の単位として機能する |
| 複雑さを反映 | 時間ではなく作業の複雑さ・リスクを表現する |
| 見積もり速度 | 詳細分析なしで素早く見積もれる |
一般的には「ストーリーポイント」という単位が使用される。フィボナッチ数列(1, 2, 3, 5, 8, 13, 21...)が採用されることが多い。数字が大きくなるほど間隔が広がるため、見積もりの不確実性を反映できる。
2. 見積もり手法
2.1 プランニングポーカー
プランニングポーカーは、チームで合意形成を行いながら見積もりを行う手法である[2]。Fig. 1にプランニングポーカーの進め方を示す。
プランニングポーカーの手順を以下に示す。
2.1.1 準備:各メンバーがフィボナッチ数列のカード(1, 2, 3, 5, 8, 13, 21, ?, ∞)を持つ。
2.1.2 説明:プロダクトオーナーがストーリーを説明し、質問に回答する。
2.1.3 見積もり:各メンバーが同時にカードを出す(一斉に見せる)。
2.1.4 議論:最大と最小を出したメンバーが理由を説明する。
2.1.5 再見積もり:議論を踏まえて再度カードを出す。合意するまで繰り返す。
「?」は情報不足を、「∞」は大きすぎて分割が必要なことを示す。
2.2 Tシャツサイズ
Tシャツサイズは、より粗い粒度で素早く見積もる手法である。XS, S, M, L, XLなどのサイズで分類する。Table 3に特徴を示す。
Table 3. Tシャツサイズ見積もりの特徴
| 特徴 | 説明 |
|---|---|
| 用途 | ロードマップ作成、初期見積もり、大量のバックログ処理 |
| 利点 | 直感的で議論が収束しやすい |
| 欠点 | 精度が低く、ベロシティ計算には不向き |
| 変換 | 後でストーリーポイントに変換することも可能 |
3. ベロシティ
3.1 定義と計測
ベロシティは、チームが1スプリントで完了できるストーリーポイントの量を表す。過去の実績に基づいて計測され、将来の予測に使用される。
ベロシティの計算方法を以下に示す。
3.1.1 スプリント終了時に完了したストーリーのポイントを合計する。
3.1.2 複数スプリントの実績を記録する。
3.1.3 直近3〜5スプリントの平均値を算出する。
Table 4にベロシティの計測例を示す。
Table 4. ベロシティ計測例
| スプリント | 完了ポイント | 備考 |
|---|---|---|
| Sprint 1 | 18 | 立ち上げ期 |
| Sprint 2 | 22 | - |
| Sprint 3 | 25 | - |
| Sprint 4 | 20 | 休暇あり |
| Sprint 5 | 24 | - |
| 平均 | 21.8 | 直近5スプリント |
3.2 活用と注意点
ベロシティの活用方法と注意点をTable 5に示す。
Table 5. ベロシティの活用と注意点
| 項目 | 内容 |
|---|---|
| 適切な使い方 | リリース時期の予測、キャパシティプランニング |
| 不適切な使い方 | チーム間の比較、パフォーマンス評価 |
| 安定化までの期間 | 新チームは3〜5スプリント程度かかる |
| 変動要因 | メンバー増減、技術的負債、休暇 |
ベロシティはチーム固有の数値であり、他チームとの比較は意味がない。ポイントの基準がチームごとに異なるためである。
4. 計画立案
4.1 リリース計画
リリース計画は、プロダクトバックログの範囲をいつ頃リリースできるかを予測するものである。Fig. 2にリリース計画の概念を示す。
リリース計画の立て方を以下に示す。
4.1.1 リリースに含める範囲(スコープ)を決定する。
4.1.2 範囲内のストーリーポイントを合計する。
4.1.3 ベロシティで割り、必要なスプリント数を算出する。
4.1.4 バッファを加味してリリース日を設定する。
計算例:合計100ポイント ÷ ベロシティ22 ≈ 5スプリント(+バッファ1スプリント)= 6スプリント
4.2 スプリント計画
スプリント計画は、各スプリントで取り組む作業を決定するプロセスである。スプリントプランニングで行われる。
スプリント計画のポイントをTable 6に示す。
Table 6. スプリント計画のポイント
| ポイント | 説明 |
|---|---|
| キャパシティの考慮 | 休暇、会議、他プロジェクト作業を差し引く |
| ベロシティを参考に | 過去の実績を超える楽観的な計画を避ける |
| バッファの確保 | 予期せぬ作業に備え、80%程度に留める |
| スプリントゴール | 単なるタスクの集まりではなく、明確な目標を設定 |
計画は約束ではなく予測である。状況に応じてスコープを調整しながら、スプリントゴールの達成を目指す。次章では、アジャイルチームに求められる文化と行動様式について解説する。
References
[1] M. Cohn, "Agile Estimating and Planning," Prentice Hall, 2005.
[2] J. Grenning, "Planning Poker or How to avoid analysis paralysis while release planning," 2002.
本コンテンツは2025年12月時点の情報に基づいて作成されている。見積もり手法や計画立案の実践は、チームやプロジェクトの特性に応じて適切にカスタマイズされたい。