1. 本記事のゴール
- 三点見積もり法（PERT）の考え方と計算方法を理解する
- チームで取り入れる際の実践手順を知る
- よくある見積もりミスを認識し、改善ポイントを理解する
- 1点見積りとの比較で三点見積もりの価値を理解する
- 「最も良いタスクの進め方」と、見積もり精度を高めるコツを共有する
2. なぜ見積もりは難しいのか
条件として以下が挙げられます。
- 仕様の不確実性
- メンバーの経験値の差
- 過去事例が再利用できない
- 希望と現実の混同
- 「見積もり」と「ターゲット（期待値・期限）」の混同による会話のすれ違い
3. やりがちな見積もりミス、起こりがちパターン
3-1. 楽観的すぎる見積もり
- 「今回はうまくいくはず」という根拠のない期待
- 過去のトラブルを織り込まない
3-2. タスクが粗すぎてブレる
- 巨大タスクは精度が落ちる
- 本当は 3〜5 個に分割できるのにそのまま見積もる
3-3. 不確実性をゼロ扱いにする
- 要件の不明確さ: 顧客からの要望が抽象的であったり、開発途中で仕様変更が発生したりする場合を見積もり時に加味しない
3-4. 「見積もり」と「ターゲット」を混同する
👨💼 マネージャー「今回 3 日でいける？」
🧑💻 エンジニア「（3 日は無理だから）5 日かな…」
→ これは見積もりではなく 交渉 になっている
- 見積もり = 現実的に必要な作業時間
- ターゲット = ビジネスとして必要な期限・期待値
- この2つは必ず分離して扱う必要がある
3-5. 実績を振り返らない
- 見積もり精度が上がらない最大の原因
- 差分分析をしないため学習効果が薄い
4. 三点見積もり法とは
3つの観点から時間を出し、期待時間とばらつきを算出する手法。
| 名称 | 内容 |
|---|---|
| 楽観値（最短） | 最もうまくいった場合の最小時間 |
| 最頻値（通常） | 通常の進め方で最も起こりやすい時間 |
| 悲観値（最長） | トラブル発生時の最大時間 |
一点見積りと三点見積もりの比較
| 観点 | 一点見積り | 三点見積もり |
|---|---|---|
| 方式 | 単一の時間を提示 | 三つの値から期待時間とばらつきを算出 |
| 不確実性の扱い | 基本的に無視 | 明確に数値化 |
| リスク説明 | 感覚的 | 標準偏差で説明可能 |
| 精度 | バラツキが大きい | データ蓄積で安定 |
| チーム合意 | 個人差が大きい | 値の違いから議論しやすい |
5. 計算方法
三点見積もりでは以下の三つを使用します。
- 楽観値 = 最短時間
- 最頻値 = 通常かかる時間
- 悲観値 = 最長時間
5-1. 期待時間（実際に最も起こりやすい平均的な時間）
期待時間 ＝ （楽観値 ＋ 最頻値 × 4 ＋ 悲観値） ÷ 6
5-2. ばらつき（作業時間の不確実性の大きさ）
ばらつき ＝ （悲観値 － 楽観値） ÷ 6
5-3. 範囲の解釈
- 計画時は 期待時間 ± ばらつき を使う
- さらに安全側をとる場合は 期待時間 ± ばらつき × 2
6. サンプル計算
例：API 機能追加
- 楽観値：2時間
- 最頻値：5時間
- 悲観値：10時間
期待時間
(2 ＋ 5×4 ＋ 10) ÷ 6 = 5.33時間
ばらつき
(10 − 2) ÷ 6 = 1.33時間
計画例
- 基本計画：5.33時間
- リスク考慮：6.66時間（期待時間 ＋ ばらつき）
- 保守的計画：7.99時間（期待時間 ＋ ばらつき × 2）
三点見積りテンプレート（例）
| タスク名 | 楽観 | 最頻 | 悲観 | 期待時間 | ばらつき | リスク |
|---|---|---|---|---|---|---|
| API追加 | 2h | 5h | 10h | 5.3h | 1.3h | 外部仕様が未確定 |
7. チームでの取り組み方法
7-1. スプリント計画での使い方
- タスクを小さく分割
- 各メンバーが楽観・最頻・悲観を出す
- 差分を議論して合意値にまとめる
- 期待時間とばらつきを算出
- チームの工数に反映
7-2. メンバー間の認識を合わせる
- 最頻値は「普通にやった場合」
- 悲観値は「トラブルを全部含む最大ケース」
- 楽観値は「障害ゼロでの最短ケース」
7-3. 過去実績を蓄積して精度を上げる
- 見積りと実績を比較
- 誤差の原因を整理
- 続けるほど改善する
8. 見積りとターゲットの混同への対処
8-1. 混同が起こる理由
- 両者とも「日数」で語られるため誤解が発生
- マネージャーは「期限」、エンジニアは「必要工数」を答えている
8-2. 明確に切り離す
| 種類 | 目的 | 決める人 | 根拠 |
|---|---|---|---|
| 見積り | 作業に必要な時間 | エンジニア | 技術的根拠 |
| ターゲット | ビジネスとして必要な期限 | マネージャー | 顧客・市場 |
8-3. 三点見積もりが有効な理由
- 期待時間とばらつきで「現実的な作業時間」を説明できる
- 楽観・悲観値を使い「どこまで短縮可能か」も提示できる
- 感覚的な交渉を減らし、合理的な会話ができる
9. 三点見積もりを活かしたタスクの進め方
9-1. タスクを細かくする
- 2〜8時間以内に収まる粒度にする
- 精度が急上昇する
9-2. 不確実な部分を先に分離する
- 調査タスク（Spike）でリスクを無くす
9-3. 新情報が出たら見積りを更新
- スプリント内でも更新できる文化が重要
10. 三点見積り導入で変わること
- 感覚的な見積りから脱却
- 不確実性が可視化される
- 説明責任や根拠がはっきりする
- 計画の精度が上がり、問題が早期発見される
11. 他の見積もり方法
三点見積もり以外にも、状況に応じて使い分けられる見積もり手法があります。ここでは主要方式を簡単に紹介します。
11-1. 1点見積もり
- 最も一般的でシンプル
- 単一の時間を提示する方式
- 不確実性を扱えず精度が低くなることが多い
- 小さくよく理解されたタスクには有効
11-2. 類推見積り（アナロジー見積り）
- 過去の類似タスクを参考に見積もる手法
- 「前回のAPI追加が6時間だったので今回も同じくらい」など
- 過去データが豊富なチームで効果大
- 逆にデータが少ない場合は精度が落ちやすい
11-3. パラメトリック見積り（係数モデル）
- 作業量をパラメータ化して計算する方式
- 例：画面1枚 = 4時間、API1本 = 6時間
- 工程の標準化ができているチームで強力
- 初期の係数調整に手間がかかる
11-4. プランニングポーカー（ストーリーポイント）
- アジャイルチームでよく使われる相対見積り
- 数値ではなく「難易度」で測る（1, 2, 3, 5, 8…など）
- チーム全体の感覚を合わせるのに有効
- 工数換算には慣れが必要
11-5. ワイドバンドデルファイ法
- チーム全員が匿名で見積もりを出し、集約し、また議論する方式
- 偏見や上下関係の影響を受けにくい
- 重要タスクや高リスク案件に向いている
- 実施にはやや時間がかかる
11-6. バッファ（安全係数）方式
- 「見積りの○％をバッファにする」というシンプルな手法
- リスク多めのプロジェクトで便利
- 適用根拠が曖昧になりがちなので乱用には注意
11-7. 三点見積もりとの比較観点
| 手法 | 精度 | 不確実性の扱い | 必要なデータ | チーム合意形成 |
|---|---|---|---|---|
| 1点 | 低 | なし | 少 | しやすいが根拠に乏しい |
| 類推 | 中 | 過去次第 | 中〜多 | 比較的容易 |
| パラメトリック | 中〜高 | パラメータへ吸収 | 多 | 標準化が必要 |
| プランニングポーカー | 中 | 相対尺度で吸収 | 少 | とても良い |
| ワイドバンドデルファイ | 高 | 全員の知識を統合 | 中 | 非常に良い |
| 三点見積り | 中〜高 | 明確に扱える | 少 | 議論しやすい |
11-8. どれを使えばよいのか？
- 少人数・開発初期: 三点見積り + 類推
- 仕様が固まり、繰り返し作業が多い: パラメトリック
- スクラムチーム: プランニングポーカー + 三点見積りの併用
- 不確実性が高い重要タスク: 三点見積り + ワイドバンドデルファイ
- 小さく明確なタスク: 1点見積りで十分
まとめ
三点見積もりは「不確実性を数値として扱える」ことが最大の強みです。
ただし状況によって他の見積もり手法と組み合わせることで、より高い精度と合意形成が可能となります。
チーム内で「どういう基準で見積もるか」を共有することで、プロジェクト全体の安定性が向上につながります。
プロダクトに向き合い、ユーザーとつながる開発を。
ネットネイティブでは、そんなエンジニアを歓迎しています
https://www.wantedly.com/companies/mdpr