# Estimate Proposal

> 受託開発の概算見積と、客先提出用の見積書兼提案書を作成するスキル。Only use when the user explicitly invokes /estimate-proposal (or $estimate-proposal in Codex). Never auto-invoke. 現行システム・議事録・RFP などから機能を棚卸しし、踏襲/改良/新規/統合/廃止の方針を判定し、粒度を機能単位へ正規化してからポイント積算し、機能一覧スプレッドシートと Google Docs の見積書まで生成する。受注後の実装向け詳細要件定義は define を使う。

- Skill: `efoo-team/estimate-proposal` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add efoo-team/estimate-proposal`
- Raw SKILL.md: https://api.skillmd.com/api/skills/efoo-team/estimate-proposal/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: efoo-team (https://skillmd.com/u/efoo-team)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/efoo-team/estimate-proposal

---


# estimate-proposal

受託開発の概算見積を、**根拠が全て追跡可能な状態**で作り、そのまま客先提案として通用する見積書兼提案書に落とすスキル。

## 目的

見積の数字そのものより、**その数字がどう作られたかを追跡できる状態**を作る。積算の根拠はスプレッドシート上に機能単位で持ち続け、客先へは「何を作り、何を作らないか」のスコープと、機能群単位の金額で提示する。「一式 500万円」は交渉の余地しか生まないが、「104機能を棚卸しし、17機能は作らないと確定させた」というスコープの明示は合意の土台になる。

## 追加指示の扱い

ユーザーが引数で渡した情報（案件名・入力ソース・既に決まっている金額など）は、本スキル内の他の方針より優先する。ただし「Gate を飛ばす」「棚卸しを省いて金額だけ作る」など下記の重要な制約に反する指示は、実行せず停止して確認を求める。

## 基本方針

### 1. 作らないものを先に確定する

費用と期間を最も大きく動かすのは、実装する機能の見積精度ではなく**実装しない機能の確定**である。10年動いたシステムには必ず「過去の事業形態の名残」が堆積しており、それを黙って引き継ぐと見積が膨らむだけでなく、新システムの運用者の認知負荷になる。廃止判定は Phase 2 の中心作業であり、廃止一覧は客先資料の中心コンテンツになる。

### 2. 積算は機能単位、開示は機能群単位

すべての金額はスプレッドシート上で機能単位の積算に分解する。後から範囲変更が起きたときに増減を計算できる基盤はここにある。一方、**見積書には積算の詳細（pt・係数・単価・工数・削減率）を記載しない**。開発の単価はクライアント業界の人件費相場と大きく乖離することがあり（実例: 飲食系クライアントに対する時間単価1万円）、数字そのものが違和感と反発の火種になる。客先への開示は機能群単位の小計と合計まで。ただし「システム開発一式」1行の見積は逆の極端であり、これも作らない。

### 3. 粒度を正規化してから積算する

棚卸し直後の一覧には「機能」と「機能の中の細かいロジック」が必ず混在する。そのまま積算すると、たまたま細かく分解された領域だけが過大になる。**必ず機能単位へ正規化した一覧を作り、そちらで積算する**（詳細一覧は根拠として残す）。

### 4. 推測で埋めず、要確認マーカーで残す

見積書は客先に出る文書である。確定情報と自分の想定が読み手に見分けられない形で混ざるのが最悪の状態。埋まらない項目は `【要確認：理由】` で残し、人が埋めてから提出する。

### 5. 求められていない成果物を約束しない

UAT支援・テスト報告書・運用マニュアルなど、クライアントが明確に求めていない工程・成果物を標準で盛り込まない。良かれと思って足した工程は金額を膨らませ、後から削られる。品質確認は開発側のテストと定例での報告で担保し、クライアント側の作業工数を要求する工程は、求められたときだけ入れる。

## 前提知識のロード

工程ごとに必要なものだけを読む。全部を先に読まない。

| いつ | 読むもの |
|---|---|
| Phase 0〜1 | [references/inventory-sources.md](references/inventory-sources.md) — 入力ソース別の棚卸し戦略と網羅性の担保手段 |
| Phase 2〜3 | [references/disposition-and-normalization.md](references/disposition-and-normalization.md) — 方針5分類の判定規則と粒度正規化の規約 |
| Phase 4〜5 | [references/estimation-model.md](references/estimation-model.md) — 標準係数表と積算式、金額化の手順 |
| Phase 6 | [references/proposal-writing.md](references/proposal-writing.md) — 各章の埋め方と開示方針の判断 |
| Phase 1・4・6 | [references/deliverable-tooling.md](references/deliverable-tooling.md) — gog CLI でのシート構築と Docs 生成 |

同梱物の使い方：

- `assets/proposal-template.md` — **コピーして埋める雛形**。Phase 6 で作業ディレクトリへコピーしてから編集する。原本は書き換えない
- `scripts/verify_estimate_sheet.py` — **実行するスクリプト**。Phase 4 の検証で使う。ソースを読んで手で再実装しない

## 成果物と保存先

| 成果物 | 実体 | 所有者 |
|---|---|---|
| 機能一覧スプレッドシート | Google Sheets（詳細タブ＋正規化タブ） | **内部の積算根拠。客先には共有しない**（単価・pt・係数を含むため） |
| 見積書兼提案書 | Google Docs | 客先提出物 |
| 作業用 Markdown | リポジトリ内の原本ファイル（配置は各プロジェクトの規約に従う） | Docs の原本として再生成に使う |

Google Docs は Markdown 原本から生成する。**Docs を直接編集して原本と乖離させない**（再生成で消える）。

## 実行手順

進捗管理用のチェックリスト。応答に貼って使う。

```
- [ ] Phase 0: 入力ソースの判定と棚卸し戦略の決定  → Gate A
- [ ] Phase 1: 機能棚卸し（詳細一覧の作成）
- [ ] Phase 2: 方針判定（踏襲/改良/新規/統合/廃止） → Gate B
- [ ] Phase 3: 粒度の正規化（機能単位へ集約）      → Gate C
- [ ] Phase 4: ポイント積算 + スクリプト検証
- [ ] Phase 5: 金額化（係数・単価・リザーブ）      → Gate D
- [ ] Phase 6: 見積書兼提案書の生成
```

### Phase 0: 入力ソースの判定と棚卸し戦略

1. 何が手元にあるかを確認する。議事録・録画、稼働中のシステム、RFP・要件定義書、既存コードベース、口頭ヒアリングのみ、のいずれか（複数のことが多い）。
2. [references/inventory-sources.md](references/inventory-sources.md) でソース別の戦略を選ぶ。**単一ソースで完結させない**。特に議事録は「話題に出た機能」しか含まないため、稼働システムがあるなら必ず実地調査で補完する。
3. 網羅性をどう担保するか、証拠（発言箇所・URL・ファイルパス）をどう残すかを決めてユーザーに提示する。

**Gate A**: 入力ソースと網羅性の担保手段に合意を得るまで Phase 1 に進まない。

### Phase 1: 機能棚卸し

1. 選んだ戦略で機能を列挙し、**詳細一覧**を作る。この段階では粒度を揃えようとしない。取りこぼしを防ぐことが目的である。
2. 各行に証拠を付ける。議事録なら発言箇所へのリンク（タイムスタンプ付き）、サイトなら実在確認済みの URL、コードならファイルパス。**証拠が無い行には「x」等の明示的な印を置き、空欄にしない**（空欄は「調べていない」と「証拠が無い」の区別がつかない）。
3. スプレッドシートに書き出す。列構成とシート操作は [references/deliverable-tooling.md](references/deliverable-tooling.md)。
4. 現行システムがある場合、**過去に使っていたが現在は使っていない機能**を必ず区別して記録する。これが Phase 2 の廃止判定の材料になる。

### Phase 2: 方針判定

1. 全行に **踏襲 / 改良 / 新規 / 統合 / 廃止** のいずれかを付ける。判定規則は [references/disposition-and-normalization.md](references/disposition-and-normalization.md)。
2. 「保留」を作らない。判断できないなら、判断できない理由を方針メモに書いた上でいずれかに倒す。
3. **方針メモは客先向けの文章として書く**。廃止行のメモはそのまま見積書の「廃止理由」列になる（例:「数年利用ゼロ」「1校舎のみのため不要」「外部サービス運用を継続」）。
4. 廃止候補のうち、実利用の有無を自分では確定できないものは `要クライアント確認` と明記する。

**Gate B**: 廃止一覧をユーザーに提示し、合意を得るまで Phase 3 に進まない。ここが金額を最も動かす。

### Phase 3: 粒度の正規化

1. 詳細一覧を機能単位へ集約する。集約規約（命名・含まれる要素の書き方・マスタの切り出し）は [references/disposition-and-normalization.md](references/disposition-and-normalization.md)。
2. 正規化シートには **対応詳細No** 列を持たせ、詳細一覧のどの行を吸収したかを追跡可能にする。
3. 廃止と判定した行は正規化シートに載せない（載せると積算対象に混ざる）。

**Gate C**: 正規化後の機能一覧に合意を得るまで Phase 4 に進まない。

### Phase 4: ポイント積算

1. [references/estimation-model.md](references/estimation-model.md) の係数で、正規化シートの各行に特性列を入力する。
2. 小計pt・AI削減率・最終工数pt は**セル数式**で持たせる。手計算した値をベタ書きしない（係数を変えたときに追随せず、静かに矛盾する）。
3. **丸めは最後の1回だけ**。行ごとに `ROUND` を掛けてから合計しない。
4. 検証を実行する:

   ```
   python3 <skill>/scripts/verify_estimate_sheet.py <spreadsheetId> <正規化タブ名>
   ```

   `RESULT: PASS` になるまで次へ進まない。FAIL の内容を修正して再実行する。**PASS でも WARN が1件以上ある場合は、各 WARN の根拠をユーザーが承認するまで Phase 5 へ進まない。** 承認は WARN ごとに理由を記録して得る（「小計pt 直接入力の根拠がシートに残っていることを確認した」など）。

### Phase 5: 金額化と機能群集約

1. 最終工数pt に PM係数・工数換算・単価を適用する（[references/estimation-model.md](references/estimation-model.md)）。**単価・換算前提はシート内部の情報であり、見積書には載せない。**
2. 換算の前提（1pt が何人日か、1人日が何時間か、1人月が何人日か、単価は時間単価か人日単価か）を**シート上のセルとして明示する**。ラベルと数式の実体がずれていないか `--render FORMULA` で確認する。
3. 積算額に対して不確実性リザーブを適用するか、するなら何倍かを決める。**リザーブが吸収する不確実性の要因を列挙できないなら、その倍率は使わない**。リザーブも見積書では提示額に織り込み、内訳として開示しない。
4. 開示用に、正規化した機能を業務のまとまりで **8〜12 の機能群**へ集約し、提示額を最終工数pt の構成比で按分する（estimation-model.md の集約・按分手順）。
5. 積算額・リザーブ・提示額・機能群集約案（群の切り方・名称・各群金額）をユーザーに提示する。提示額は経営判断であり、こちらで決めない。

**Gate D**: 提示額と機能群集約案に合意を得るまで Phase 6 に進まない。**群の切り方はユーザーが違和感を持ちやすい箇所**であり、必ず表（群名・対象機能・金額）で見せて確認する。

### Phase 6: 見積書兼提案書の生成

1. `assets/proposal-template.md` を作業ディレクトリへコピーする。
2. [references/proposal-writing.md](references/proposal-writing.md) を読みながら各章を埋める。数値はすべて Phase 4〜5 のシートから取る（暗算しない）。
3. 完成した本文を全文検索し、**pt・ポイント・単価・削減率・人日・人月・係数・算定・リザーブの語が残っていないこと**を確認する。1語でも残っていれば内部情報の漏れである。
4. 客先名・自社情報は一次情報で確認する（客先サイトの会社概要・特商法ページ、自社サイトの会社概要）。**社名や住所を記憶から書かない。**
5. 埋まらない項目は `【要確認：理由】` で残す。
6. Markdown を Google Docs へ変換する（[references/deliverable-tooling.md](references/deliverable-tooling.md)）。表がネイティブ表として入っているか、見出し階層が保たれているかを確認する。**既存の Docs を更新する場合は、書き戻す前に必ず Docs の最新をエクスポートして差分を取り込む**（ユーザーが直接微調整していることがあり、差分確認なしの再生成はそれを消す）。
7. ユーザーへの報告で、**自分が入力なしに埋めた項目を全て列挙する**。文中に「想定」と書いてあっても、報告では改めて列挙する。

## Gotchas

実案件で実際に起きた失敗のみを載せる。一般論は書かない。

| 事象 | 何が起きたか | 対処 |
|---|---|---|
| 数式のない行が混在 | 見た目は数字が入っているが手入力だった行があり、係数を変えても追随せず総額が過小になった | `verify_estimate_sheet.py` で全行の数式有無を検査する |
| 行ごとに丸めてから合算 | 34行ぶんの丸め誤差が累積し、総額が実態とずれた | 行の数式に `ROUND` を置かない。丸めは最終表示のみ |
| 「保留」判定の量産 | 判断を先送りした結果、11行が保留のまま積算対象か不明になった | 保留を選択肢に置かない |
| 詳細タブと正規化タブの取り違え | 正規化タブで再計算する依頼に対し、詳細タブを書き換えた | シート操作の前に必ずタブ名を読み上げて確認する |
| 集約時の表記ゆれ | 「講師管理」と「講座登録・編集」が同じ一覧に並び、機能単位に見えなくなった | 命名規約を先に決める（管理画面は「◯◯管理」、ユーザー画面は名詞） |
| ラベルと数式の不一致 | `人日単価 ¥10,000` というラベルのセルが、数式では8時間を掛けた**時間単価**として使われていた | 金額に関わるセルは `--render FORMULA` で実体を読む |
| URL を拡張子なしで記載 | `/school/list` と書いて404。客先に渡す直前だった | 文書に載せる URL は必ず HTTP ステータスで実在確認する |
| 単一ソースでの棚卸し | sitemap だけを見て「講師詳細ページは存在しない」と結論し、実際には存在した | Phase 0 で複数ソースを義務づける |
| 単価・積算詳細を見積書に記載 | 時間単価1万円がクライアント業界（飲食）の人材単価と乖離しすぎ、違和感を与えるとの判断で見積書を全面差し替えた | 見積書は機能群小計まで。pt・係数・単価はシート内部に留める |
| 求められていない工程を標準搭載 | UAT支援・テスト報告書を良かれと思って盛り込み、不要と判断されて削除・金額の付け替えが発生した | 基本方針5。クライアント側の工数を要求する工程は求められたときだけ |
| 機能群の集約を自分の感覚で確定 | 集約の切り方に違和感があるとして、提出前にユーザーが組み替えた | Gate D で集約案（群名・対象機能・金額）を必ず表で確認する |
| 客先向け文書にITジャーゴン | 「分界」「リストア」「課金」が客先向け文書に残り、一般的な日本語への修正指示を受けた | 業務担当者が読む前提で通読する（proposal-writing §11） |

## Red flags

以下を自分がやりかけていたら、手を止めて Phase を戻る。

- 「だいたいこのくらい」で pt を置いている（→ 係数表のどのセルに当たるかを言えるようにする）
- 目標金額に合わせて係数や削減率を調整している（→ 積算は積算として出し、差は提示額の判断で吸収する）
- 廃止候補を「念のため残す」に倒している（→ 残す理由を客先に説明できないなら廃止候補のまま提示する）
- 見積書に「一式」と書こうとしている
- 見積書に pt・単価・係数・削減率を書こうとしている（→ シート内部に留め、開示は機能群小計まで）
- クライアントに求められていない工程・成果物（UAT支援・報告書等）を盛り込もうとしている
- スケジュールや体制を、根拠なく埋めている（→ `【要確認】` にする）
- Gate をまとめて1回の確認で済ませようとしている

### 合理化への反論

| 出そうになる言い訳 | 反論 |
|---|---|
| 「概算だから細かく分解しなくていい」 | 分解しない見積は、範囲が動いたときに増減を説明できない。概算だからこそ分解する |
| 「廃止判定は客先が決めることだから全部残しておく」 | 全部残すのは判断の放棄であり、客先の費用を増やす。判断して提示し、客先に覆させる |
| 「急ぎなので Gate は後でまとめて」 | Gate B（廃止一覧）を飛ばすと、金額の前提が合わないまま Phase 5 まで進み、全部やり直しになる |
| 「スケジュールは埋めておかないと提案書として弱い」 | 根拠のない工期は、守れなかったときに信用を失う。要確認で出して埋めてもらう方が強い |

## 重要な制約

- **各 Gate でユーザーの明確な回答を得るまで次の Phase に進まない。** 選択式で答えを得た場合、それは当該 Gate への回答であって、以降の工程の包括承認ではない
- **提示額を自分で決めない。** 積算額とリザーブの選択肢を出し、決めるのはユーザー
- **客先に出る文書に、確認していない事実を書かない。** 社名・住所・実績・URL は一次情報で確認する
- **様式の参考文献（他社ブログ等）は見積書本文に載せない。** ただしチャット報告には出典を残す
- **積算スプレッドシートを客先に共有しない。** 単価・pt・係数を含むため。共有が必要なら棚卸し（詳細一覧・方針判定）タブのみを複製した共有用シートを作る
- 検証（`verify_estimate_sheet.py` の PASS）未実施のまま金額を確定しない