Estimate Proposal

estimate-proposal

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

目的

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

追加指示の扱い

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

基本方針

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

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

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

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

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

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

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

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

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

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

前提知識のロード

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

同梱物の使い方：

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

成果物と保存先

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 でソース別の戦略を選ぶ。単一ソースで完結させない。特に議事録は「話題に出た機能」しか含まないため、稼働システムがあるなら必ず実地調査で補完する。
3. 網羅性をどう担保するか、証拠（発言箇所・URL・ファイルパス）をどう残すかを決めてユーザーに提示する。

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

Phase 1: 機能棚卸し

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

Phase 2: 方針判定

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

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

Phase 3: 粒度の正規化

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

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

Phase 4: ポイント積算

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

Gotchas

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

Red flags

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

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

合理化への反論

重要な制約

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