estimate-calibrator

見積もりキャリブレーター

単一の点推定を、構造化された三点見積もりに置き換えます。作業を最小単位に分解し、それぞれについて最良・最頻・最悪のケースを見積もり、不確実要素と前提を特定し、PERT を使って全体の範囲を計算し、明確な根拠に基づいて信頼度を割り当てます。

参照ファイル

ファイル	内容	読み込むタイミング
references/estimation-methods.md	PERT の計算式、三点見積もり、モンテカルロ法の基本	常に
references/unknown-categories.md	技術、スコープ、外部、組織に関する不確実性の種類	不確実要素の特定時
references/calibration-tips.md	見積もりにおける認知バイアス、過去データによる調整、バッファ戦略	常に
references/sizing-heuristics.md	一般的なタスク規模のパターン、複雑さの指標、参照クラスのデータ	迅速な規模見積もりが必要なとき

前提条件

• 作業項目の説明（機能、タスク、プロジェクト）
• 分解済みのタスク（または、先に task-decomposer スキルを使用）
• コンテキスト：チームの習熟度、技術スタック、既存のコードベース

ワークフロー

フェーズ 1：作業の分解

作業項目がまだ最小単位に分解されていない場合：

1. タスクに分割する — 各タスクは個別に見積もれるようにします。
2. 適切な粒度にする — タスクの所要時間は 1 時間から 3 日程度にします。大きなタスクは不確実性が高いため、さらに細分化します。
3. 依存関係を特定する — クリティカルパス上のタスクによって、最短所要期間が決まります。

フェーズ 2：三点見積もり

各タスクについて、次の 3 つのシナリオを見積もります。

シナリオ	定義	考え方
最良ケース	すべてが順調に進み、予想外のことがありません。	「これとまったく同じことを以前に行ったことがある場合」
最頻ケース	通常の摩擦があり、小さな障害がいくつかあります。	「典型的なつまずきを考慮した現実的な見通し」
最悪ケース	深刻な問題は起こりますが、壊滅的ではありません。	「マーフィーの法則が当てはまるが、災害には至らない場合」

重要なルール： 最悪ケースとは「すべてがうまくいかない」ケースではありません。現実的に悪いシナリオ（90 パーセンタイル）であり、終末的なシナリオ（99 パーセンタイル）ではありません。

フェーズ 3：不確実要素の特定

見積もりに影響する不確実要素を分類します。

カテゴリー	例	影響
技術	「このライブラリを使うのは初めてです」	最頻ケースが膨らみ、最悪ケースはさらに大きくなります
スコープ	「要件が変わる可能性があります」	すべての見積もりが変わる可能性があります
外部	「パートナーからの API アクセスに依存します」	ブロックされるリスクがあり、全体が遅れる可能性があります
統合	「本番データでテストしていません」	統合時に隠れた複雑さが明らかになります
組織	「デザインの承認が必要です」	作業時間ではなく、暦上の所要時間に影響します

フェーズ 4：範囲の計算

個々のタスクには、PERT の計算式を使用します。

Expected = (Best + 4 × Likely + Worst) / 6
Std Dev = (Worst - Best) / 6

全体（プロジェクト）の見積もりでは、次を使用します。

• 期待値の合計：全体の期待所要期間
• 標準偏差の二乗和の平方根：全体の不確実性

フェーズ 5：信頼度を割り当てる

信頼度	意味	該当する場合
高	±20% 以内の可能性が高い	タスクを十分に理解しており、チームに経験がある
中	±50% 以内の可能性が高い	不明点がいくつかあり、ある程度の経験がある
低	±100% 以上の可能性が高い	不明点が多く、新しい技術を使う

出力形式

## Estimate: {Work Item}

### Summary
| Scenario | Duration |
|----------|----------|
| Best case | {time} |
| Likely case | {time} |
| Worst case | {time} |
| **PERT expected** | **{time}** |
| **Confidence** | **{High/Medium/Low}** |

### Task-Level Estimates

| # | Task | Best | Likely | Worst | PERT | Unknowns |
|---|------|------|--------|-------|------|----------|
| 1 | {task} | {time} | {time} | {time} | {time} | {key unknown or "None"} |
| 2 | {task} | {time} | {time} | {time} | {time} | {key unknown} |
| | **Total** | **{sum}** | **{sum}** | **{sum}** | **{pert}** | |

### Key Unknowns

| # | Unknown | Category | Impact on Estimate | Mitigation |
|---|---------|----------|-------------------|------------|
| 1 | {unknown} | {Technical/Scope/External} | +{time} if realized | {spike, prototype, early test} |

### Assumptions
- {Assumption 1 — what must be true for this estimate to hold}
- {Assumption 2}

### Risk Factors
- {Risk}: If realized, adds {time}. Likelihood: {High/Medium/Low}.

### Confidence Rationale
**{High/Medium/Low}** because:
- {Specific reason — e.g., "Team has built 3 similar features"}
- {Specific reason — e.g., "External API is a new integration"}

### Recommendation
{Commit to PERT expected with {X}% buffer, or spike the top unknown first.}

見積もりの調整ルール

1. 1つではなく、3つの値を示してください。 単一値の見積もりは必ず誤ります。3つの値を示すことで、不確実性という見積もりで最も重要な要素を伝えられます。
2. 最悪のケースは99パーセンタイルではなく、90パーセンタイルです。 「隕石がオフィスに落ちる」は、役に立つ最悪のケースではありません。「API のドキュメントが間違っていて、プロトコルをリバースエンジニアリングする必要がある」は、現実的な最悪のケースです。
3. 既知の難しさより、不明点のほうが見積もりを大きく膨らませます。 難しくても十分に理解されているタスクのほうが、簡単でも未経験のタスクより予測しやすいです。
4. 見積もりは確約ではありません。 期限ではなく、範囲を伝えてください。関係者が単一の数値を必要とする場合は、PERT の期待値に信頼度に応じたバッファを加えてください。
5. 不明点は早めに調査してください。 1つの不明点が見積もり範囲を大きく左右する場合は、残りを見積もる前に1～2日かけて調査してください。

エラー処理

問題	解決策
作業項目が分解されていない	まず3～8個のタスクに分解してください（または task-decomposer スキルを提案してください）。
過去の参考例がない	既知のタスクと比較して見積もってください：「これは認証機能のおよそ2倍です」。
関係者が単一の数値を求めている	信頼度に応じたバッファを加えた PERT の期待値を提示してください（高：+20%、中：+50%、低：+100%）。
見積もりが大きすぎるように見える	タスクリストにスコープクリープがないか確認してください。必須でないタスクを削除し、後回しにできる項目を特定してください。
チームにこの種の作業経験がない	信頼度を「低」としてください。見積もりを確約する前に、調査を行うことを推奨してください。

見積もりを行うべきでない場合

次の場合は、異議を伝えてください。

• 作業が探索的なもの（調査、スパイク）である場合 — 見積もるのではなく、時間を区切ってください
• 要件がまったく定義されていない場合 — まずスコープを定義してください
• 大規模プロジェクトについて、ユーザーが時間単位の精度を求めている場合 — 見せかけの精度ではなく、範囲を提示してください
• 不確実性を認識せずに、見積もりが確約として使われる場合