はじめに
開発の見積もりで難しいのは、実装そのものより手戻りの扱いです。
最初の見積もりはそれなりに妥当に見えても、途中で仕様確認や設計の見直しが入ると、数字はすぐに崩れます。
それでも現場では「手戻り込みで何日ですか」と聞かれます。
この記事では、手戻りを雑なバッファで済ませず、説明可能な形で見積もるための考え方を整理します。
考え方の土台としては、『ソフトウェア見積り 人月の暗黙知を解き明かす』を参考にしています。
関連:
なぜ人は点で見積もりたがるのか。見積もり運用から考える
この記事とのつながり
関連の記事では、見積もりを点で固定すると前提が消えやすくなること、そして見積もりは更新運用まで含めて設計する必要があることを整理しました。
今回のテーマである手戻り見積もりは、その続きにあたります。
要点は次の3つです。
- 手戻りを固定バッファで処理せず、想定内と想定外に分けて扱う
- 代表値だけでなくレンジを持ち、数字の意味を共有する
- 見積もり提出時点で更新条件をセットにして、後で説明可能にする
つまり、手戻りの見積もりは「何日足すか」ではなく、「どの条件でどこまで更新するか」を決める作業です。
手戻りが見積もりに乗りにくい理由
手戻りが難しいのは、次の性質があるからです。
- 発生条件が工程の後半で判明しやすい
- 発生しても影響範囲が読みにくい
- 原因が外部依存にある場合、制御しにくい
- 作業時間より待ち時間が支配的になることがある
つまり、手戻りは「発生するかどうか」だけでなく、「発生したときにどこまで広がるか」が見えにくい問題です。
もう1つ厄介なのは、手戻りが連鎖しやすいことです。
要件の修正が設計へ波及し、設計の変更が実装とテストを再実行させる、という形で後工程ほど影響が大きくなります。
この連鎖を見積もりに入れないと、序盤では妥当に見える数字でも終盤で破綻しやすくなります。
まず分けるべきは2種類の手戻り
手戻りは一括りにせず、最低でも次の2つに分けて見積もると精度が上がります。
1. 想定内の手戻り
レビュー指摘の反映、軽微な仕様調整、文言調整のような、ある程度は毎回起きる手戻りです。
これは初期見積もりに織り込む対象です。
2. 想定外の手戻り
要件の再定義、外部仕様の変更、既存実装の制約発覚のように、発生時の影響が大きい手戻りです。
これは初期見積もりに固定で入れるより、発生条件を明示して更新運用で扱うほうが安全です。
見積もりの基本手順
実務で回しやすいのは、次の手順です。
手順1: 基本工数を出す
まずは手戻りを含めず、素の作業工数を出します。
要件整理、設計、実装、テストを分けて見積もるのが前提です。
手順2: 想定内手戻りを係数化する
過去実績から、工程ごとに手戻り率を置きます。
たとえば次のように設定します。
- 設計: 10%
- 実装: 15%
- テスト: 20%
この係数は感覚で決めず、過去数案件の実績から更新していくのがポイントです。
手順3: 想定外手戻りは条件付きで別枠にする
想定外の手戻りは、初期値として無理に日数化しないほうが説明しやすいです。
代わりに次を明記します。
- どの条件で発生するか
- 発生時にどの工程へ波及するか
- いつ再見積もりするか
手順4: 代表値とレンジをセットで出す
最終報告は1つの数字が必要でも、内部運用はレンジで持ちます。
代表値だけを提出すると、手戻り前提が消えてしまうためです。
手戻り率を現場データから作る方法
手戻り率は経験則だけで決めるとぶれやすいため、簡単な実績管理を入れておくと安定します。
最低限、案件ごとに次の2つを残します。
- 予定工数
- 手戻りに使った実工数
3〜5案件分でも集まれば、工程ごとの傾向が見えます。
たとえば実績が次のようだったとします。
- 設計: 予定10日に対し手戻り1.2日
- 実装: 予定20日に対し手戻り3.4日
- テスト: 予定8日に対し手戻り1.6日
この場合の初期係数は、おおむね次のように置けます。
- 設計: 12%
- 実装: 17%
- テスト: 20%
重要なのは、正確な係数を1回で作ることではなく、案件終了ごとに更新していくことです。
更新を続けると、見積もりがチームの資産になります。
具体例
例として、API改修と画面修正を含む小規模案件を考えます。
基本工数:
- 要件整理: 1.5日
- 設計: 2.0日
- 実装: 4.0日
- テスト: 2.0日
- 合計: 9.5日
想定内手戻りを加味:
- 設計 2.0日 × 10% = 0.2日
- 実装 4.0日 × 15% = 0.6日
- テスト 2.0日 × 20% = 0.4日
- 手戻り合計: 1.2日
この時点の見積もりは 10.7日です。
さらに想定外手戻りとして、外部API仕様変更リスクを別枠で管理します。
このリスクが発生した場合は、影響調査0.5日と実装修正1.0日を追加し、最大で12.2日まで上振れする、という形で示します。
この出し方なら、なぜ数字が変わるのかを説明しやすくなります。
手戻りを説明可能にするテンプレ
見積もり時に次のフォーマットを使うと、会議でのすれ違いが減ります。
- 代表値: 10.7日
- 想定レンジ: 9.5日〜12.2日
- 想定内手戻り率: 設計10%、実装15%、テスト20%
- 想定外リスク: 外部API仕様変更
- 更新条件: 要件確定時、設計レビュー完了時、実装50%時点
「日数」だけでなく「更新の条件」までセットで出すのが重要です。
このテンプレは、レビュー時に次の順で説明すると通りやすくなります。
- まず代表値を示す
- その数字の前提を示す
- 上振れ条件と更新タイミングを示す
この順番にすると、数字の妥当性と運用ルールを同時に合意しやすくなります。
合意を壊さないための運用ポイント
手戻り見積もりは、計算よりも運用で崩れやすいです。
次のポイントを最初に決めておくと、途中で揉めにくくなります。
- 見積もり変更を「失敗」ではなく「観測結果の反映」として扱う
- 更新時は差分の理由を1行で残す
- 追加要件と手戻りを同じ箱で管理しない
- 代表値だけが報告資料に残らないよう、レンジも併記する
特に「追加要件」と「手戻り」の混同は、議論を不毛にしやすいポイントです。
前者はスコープ変更、後者は同じスコープ内での再作業なので、管理を分けるだけで説明しやすさが大きく変わります。
よくある失敗
一律で30%足して終わる
一律バッファは簡単ですが、根拠が残りません。
後で説明できない数字は、チーム内の信頼を落としやすくなります。
手戻りを個人の努力で吸収する前提にする
見積もりの不備を現場の残業で埋める運用は、短期的には回っても再現性がありません。
手戻りは仕組みで扱う必要があります。
更新ルールを決めない
見積もりを更新する条件がないと、数字だけが独り歩きします。
結果として、予測が約束に変わってしまいます。
まとめ
手戻り見積もりの要点は、予測不能なものを無理に固定値へ押し込まないことです。
想定内は係数で扱い、想定外は発生条件と更新ルールで管理する。
この2段構えにすると、見積もりは現場で使える情報になります。
点見積もりに引っ張られて手戻りを見えなくするより、前提と更新条件を明示して管理するほうが、結果として説明責任を果たしやすくなります。
最初から完璧な精度を目指すより、更新しやすい形で出すほうが実務では強いです。
見積もりを提出して終わりにせず、更新前提の運用を回していくことが、手戻りをコントロールする最短ルートだと思います。