エンジニア出身PMのための開発見積もり入門
はじめに
エンジニアからプロジェクトリーダーになったとき、最初に戸惑うのが「見積もり」です。
コードを書くことには慣れていても、「このタスクは何時間かかりますか？」「このプロジェクト、いつ終わりますか？」と問われると、自信を持って答えられない。かといって大きめに答えれば「もっと短くできないか」と圧縮を求められる。
この記事では、開発現場でよく使われる見積もり手法を体系的に整理し、見積もりとどう向き合うかをまとめます。
なぜ見積もりは難しいのか
未知のタスクを数値化する行為だから
見積もりとは、まだやっていないことを数値に変える行為です。仕様が曖昧なまま工数を出すこともあれば、使ったことのない技術を使う前提で見積もることもあります。不確実性が高いほど、見積もりは外れやすくなります。
これはエンジニアの能力の問題ではなく、見積もりという行為の本質的な難しさです。
楽観バイアスが働くから
人は物事を楽観的に見積もる傾向があります。「うまくいけばこのくらいで終わるだろう」という最良のシナリオを、無意識に基準にしてしまいます。しかし実際の開発では、仕様の認識齟齬・環境構築の手間・レビュー指摘によるやり直しなど、想定外の出来事が必ず発生します。
「早く」という圧力で見積もりが歪むから
見積もりを出した後、「もっと短くできないか」と圧縮を求められることがあります。このとき、根拠なく数字を削ってしまうと、バッファのない計画が生まれます。後から破綻したとき、「見積もりが甘かった」と評価されるのはエンジニアです。
見積もりは予測であって、約束ではありません。この認識を関係者と共有することが、PM の重要な役割のひとつです。
代表的な見積もり手法
ストーリーポイント
スクラム開発でよく使われる手法です。タスクの工数を「時間」ではなく「複雑さ・不確実性の相対的な大きさ」で表します。
単位は点数（ポイント）で、フィボナッチ数列（1・2・3・5・8・13・21）を使うことが多いです。
基準タスク：ユーザーの一覧取得 API = 3 ポイント
これより少し複雑な検索 API = 5 ポイント
これより大幅に複雑な決済処理 = 13 ポイント
時間ではなく相対値で測る理由は、人によって 1 時間でできる作業量が違うためです。「5 時間」という見積もりはエンジニアによってブレますが、「あのタスクの 2 倍の複雑さ」という相対評価はチームで揃えやすくなります。
チームが毎スプリントに消化できるポイント数（ベロシティ）を計測し続けることで、スケジュールの予測精度が上がっていきます。
プランニングポーカーは、ストーリーポイントをチームで見積もるための手法です。全員が同時にカードを出すことで、声の大きい人に引きずられずに独立した意見を集められます。見積もりが大きくばらついたタスクは、認識の齟齬があるサインなので、議論して認識を合わせます。
三点見積もり（PERT 見積もり）
1 つの見積もり値ではなく、3 つのシナリオから計算する手法です。
| シナリオ | 意味 | 例 |
|---|---|---|
| 楽観値（O） | 何もトラブルが起きない最善のケース | 3 日 |
| 最頻値（M） | 最もよくある通常のケース | 5 日 |
| 悲観値（P） | 最悪のトラブルが重なるケース | 12 日 |
この 3 値から期待値を次の式で求めます。
期待値 = (O + 4M + P) / 6
= (3 + 4×5 + 12) / 6
= (3 + 20 + 12) / 6
= 5.8 日
最頻値の 5 日より少し大きい 5.8 日になります。悲観値のリスクを織り込んだ結果です。
ストーリーポイントが「相対的な複雑さ」を測るのに対して、三点見積もりは「実際の日数・時間」を出すのに向いています。ステークホルダーへの説明や、スケジュール表の作成に使いやすい手法です。
類推見積もり
過去の似たタスクの実績をもとに見積もる手法です。
過去実績：ユーザー管理 CRUD の実装 → 5 日
今回タスク：商品管理 CRUD の実装 → 5〜6 日（少し複雑なので +1 日）
シンプルですが、実績データが蓄積されているチームには非常に有効です。「前回と同じくらいの規模」「前回の 2 倍ほど複雑」という判断が、数値の根拠になります。
類推見積もりの精度を高めるには、見積もりと実績を記録し続けることが前提になります。記録がないと「なんとなくこのくらい」という感覚頼りになり、外れやすくなります。
バッファの考え方
バッファは「サボり」ではなく「リスク対策」
見積もりを大きめに出すと「水増しだ」「サボる気では？」と思われることがあります。しかし、適切なバッファは不確実性へのリスク対策です。
開発では必ず想定外のことが起きます。
- 仕様の認識違いが発覚してやり直しになる
- 外部 API の仕様が変わっていて対応が必要になる
- レビュー指摘が多くて修正に時間がかかる
こうしたリスクをゼロとして計画を立てると、ひとつトラブルが起きただけでスケジュールが破綻します。バッファは「予備のサボり時間」ではなく「トラブルが起きたときの吸収材」です。
MoSCoW 法でスコープの優先度を整理する
圧縮要求への対応をする前に、そもそも何が「必須」で何が「あれば嬉しい」のかを整理しておくと交渉がしやすくなります。MoSCoW 法は要件を 4 つに分類する手法です。
| 分類 | 意味 | 例 |
|---|---|---|
| Must have | 絶対に必要。これがないとリリースできない | ログイン機能・決済処理 |
| Should have | 重要だが、なくてもリリースはできる | 通知メール・検索フィルター |
| Could have | あれば嬉しいが、なくても困らない | ダークモード・CSV エクスポート |
| Won't have | 今回はやらない（将来の候補） | 多言語対応・高度な分析機能 |
プロジェクト開始時にステークホルダーと MoSCoW の分類を合意しておくと、圧縮を求められたときに「Should have をフェーズ 2 に回す」という具体的な交渉ができます。工数を根拠なく削るのではなく、スコープの取捨選択で納期に応える形です。
圧縮要求への向き合い方
「もっと短くできないか」と言われたとき、根拠なく削るのは危険です。代わりに以下のアプローチを取ります。
スコープを削る交渉をする
「工数を削るのは難しいですが、この機能を
フェーズ 2 に回せば 3 日短縮できます」
リスクを明示した上で短縮案を出す
「5 日を 3 日にするには、レビューを簡略化する必要があります。
品質リスクが上がりますが、それを許容できますか？」
見積もりを削るのではなく、削るなら何を犠牲にするかを明示するのがポイントです。PM は見積もりの根拠を持ち、圧力に対して根拠で返せる状態を作ることが大切です。
見積もり精度を上げるコツ
タスクを小さく分解する
大きなタスクほど見積もりは外れます。「ユーザー管理機能の実装」という粒度では不確実性が高すぎます。「一覧取得 API」「登録 API」「バリデーション追加」のように分解すると、それぞれの複雑さが見えてきます。
1 タスクが 1〜2 日以内に収まる粒度が目安です。
見積もりと実績を記録して振り返る
見積もりを出して終わりにせず、実際にかかった時間を記録します。スプリントのふりかえりなどで「見積もり 5 ポイントのタスクが実際は 8 ポイント相当だった」という差分を分析すると、次回の精度が上がります。
不確実性が高いタスクを早めに特定する
プロジェクト開始時に「このタスクはよくわからない」という項目を明示しておきます。不確実性の高いタスクは、早めにスパイク（調査タスク）を入れて不確実性を下げてから本実装の見積もりをし直すと、精度が上がります。
まとめ
| 手法 | 向いている場面 |
|---|---|
| ストーリーポイント | スクラムなどのイテレーション開発・チームのベロシティ管理 |
| 三点見積もり | 納期重視・ステークホルダーへの説明が必要な場面 |
| 類推見積もり | 過去実績がある・素早く概算を出したい場面 |
見積もりは当てるものではなく、不確実性を管理するためのツールです。外れることを前提に、バッファを持ち、実績を記録して精度を上げ続けることが PM に求められる見積もりとの向き合い方です。
Discussion