顧客自身も何が欲しいか決まっていないプロジェクトを見積もる方法

まだ曖昧な案件で精密さを演じない

顧客が『新しいダッシュボードが欲しい』『業務を自動化したい』『モダンなサイトにしたい』と言うものの、何を入れるべきかは決まっていない。すぐ価格を返したくなる圧力は強いものです。難しい人や経験不足に見られたくないため、数個質問し、自分の中で妥当な案件像を作り、正確そうな数字を出してしまいます。数字はプロらしく見えますが、背後の情報はまだ仮定だらけです。

精密さと正確さは別物です。コア要件が不明なら、7,480ドルという見積より6,000〜10,000ドルという根拠付きレンジの方が責任ある場合があります。正確そうな数字は不確実性が解決された印象を作りますが、実際は隠しただけです。その後、本当のニーズが見えたとき、元scope自体が十分定義されていなかったのに、すべてがscope creepに見えてしまいます。

この段階の仕事は未来を当てることではなく、商業的な約束が意味を持つレベルまで不確実性を下げることです。15分の確認で足りる場合もあれば、有料discovery、技術監査、ステークホルダーインタビュー、プロトタイプが必要な場合もあります。未知を無料のリスクとして隠さず、プロセスの一部として扱います。

既知・仮定・未知を分ける

まず3つのリストを作ります。既知は双方が今確認できる事実です。既存システム、固定された公開日、現在ユーザー数、必須プラットフォーム、変えられない法的要件など。仮定は見積のため一時的に真と置く条件です。顧客が最終原稿を提供する、決裁者は1名、現APIが必要データを持つ、など。未知は工数に大きく影響するのにまだ答えがない質問です。

この分離により仮定が約束へ静かに変わるのを防げます。データがきれいという仮定で移行を見積もるなら、その条件を価格の近くに書きます。後で重複や壊れたレコードが大量に出ても、なぜ作業が変わるか双方が確認できます。書いていなければ、こちらは仮定を覚え、顧客は価格だけを覚えているという典型的な争いになります。

未知は影響度で優先します。すべてを調査しないと何も見積できないわけではありません。アーキテクチャ、タスク量、専門職、第三者費用、受入基準、スケジュールを変え得る質問を先に扱います。ボタンラベルが未定なのと、legacy systemにAPIがあるか不明なのは同じ種類の未知ではありません。

• 既知：双方が今確認できる事実
• 仮定：見積を可能にするため一時的に置く条件
• 未知：費用や日程を大きく変え得る未回答の質問
• 高影響の未知：構成、量、依存、受入基準を変え得るもの
• 低影響の未知：商業モデルを変えず後で決められる詳細

未知を解消する作業が高価なら、有料discoveryを使う

discoveryは名前を変えた無料営業会議ではありません。問題理解、データ調査、既存システムレビュー、関係者ヒアリング、APIテスト、業務フロー整理、要件定義に実作業が必要なら、その作業は価値を作っています。顧客のリスクを下げ、こちらが責任ある実装見積を出すための情報を作ります。前倒しで行うから無料になるわけではありません。

成果が明確ならdiscovery自体を固定価格にできます。要件マップ、技術評価、優先scope、wireframe、実装見積などです。調査自体が不確実なら上限付き時間制も使えます。大事なのは、期間無制限の調査を売るのではなく、最後に顧客が何を受け取るか定義することです。

楽観ケースと悲観ケースの差が非常に大きいときに特に有効です。統合が2日か6週間か、調べないと分からないなら、平均値を出してもリスクは公平になりません。まず小さい金額でどちらの世界かを調べ、それから実装を事実に基づいて価格化します。

一つの魔法の数字を強制せず、レンジで見積もる

不確実性が残るなら、偽の精密さよりレンジが正直です。ただし『5千から5万』のような幅だけでは役に立ちません。下限は明確な好条件、上限は特定リスクや複雑な選択に結び付けます。何が下限から上限へ動かすのか説明できるレンジは、単なる曖昧さではなく意思決定ツールになります。

不確実な個別タスクには楽観・最頻・悲観の三点見積を使えます。（楽観 + 4 × 最頻 + 悲観）÷ 6 は計画値を作れますが、式より重要なのは悲観ケースをコミット前に書く習慣です。合理的な最悪ケースが商業的に受け入れられないなら、署名前にデリバリーモデルを変えるべきです。

顧客が予算上限を必要とするなら段階承認を使います。discoveryを一定額までとし、新しい見積承認後にのみ実装を開始する。あるいは週次上限やnot-to-exceed付きtime and materialsにする。不確実性を否定せず、上限とチェックポイントで予算を管理します。

• レンジ下限を明確な好条件の仮定に結び付ける
• 上限を具体的なリスクや複雑な選択に結び付ける
• 不確実なタスクには三点見積を使う
• 予算管理が必要なら上限や承認ポイントを使う
• 見た目を整えるためだけに広いレンジの中央値を固定価格にしない

仮定と除外事項を見積書に直接書く

曖昧なscopeの見積は、それを支える仮定の質で決まります。重要な仮定を自分だけのメモに残さず、価格の近くに書きます。誰がコンテンツを提供するか、何人が承認するか、想定データ形式、利用可能なアクセス、含まれる修正回数、除外される第三者費用などです。これは法的装飾ではなく計算の入力条件です。

除外事項も同じくらい重要です。敵対的な表現ではなく、今の決定範囲を明らかにするものです。コピーライティング、翻訳、移行データクリーニング、法務レビュー、高度なanalytics、カスタム統合が含まれないなら書きます。明確な除外は、後でオプションやchange requestになり、誰かが『当然含まれると思った』という争いを減らします。

普通の言葉で書きましょう。目的は弁護士に勝つ文書ではなく、2人が同じ文を読んで似た案件を想像することです。顧客が驚く仮定なら、承認前に話します。良い見積は免責が多い見積ではなく、隠れた解釈が少ない見積です。

全部かゼロかの一括提案ではなく段階オプションを出す

曖昧な案件は、決定を分けると買いやすくなります。大きく不確実な予算を一度に承認してもらう代わりに、まず明確さを作るフェーズ、その後に定義済み解を作るフェーズを出します。どれだけ複雑さが必要か未決なら、最小scopeと拡張scopeの選択肢も有効です。

選択肢は実際のscope差であるべきで、単なる価格アンカーではありません。今は手動インポート、API検証後に自動統合、あるいはコア5ページと全コンテンツ移行などです。顧客は事業上のトレードオフを選べ、こちらは異なる仕事量を同じだと見せずに済みます。優先順位も明確になります。

段階化は自然な停止点も作ります。discoveryで希望機能が経済的に意味を持たないと分かれば、顧客は有用な結果を受け取ってそこで止められます。大規模実装に縛られません。discoveryが単なる前払いではなく独立した意思決定成果物になります。

• まずdiscovery、その後に実装見積
• 最小実用scopeと拡張scope
• 既知のコアは固定価格、不確実統合は時間制
• 次の予算前にmilestone承認
• 主成果検証後に追加できるオプションモジュール

新情報が価格と日程をどう変えるか決めておく

曖昧な案件は作業中に明確になるのが普通です。だから新情報が出たときの扱いを事前に決めます。新要件が合意済み成果と仮定の中なら既存作業の明確化かもしれません。新しい成果、依存、統合、対象ユーザー、受入基準を追加するならchange requestや再見積になります。判断基準は依頼文の短さではなく影響です。

請求時まで分類を待たないでください。新発見で必要工数が変わったら、該当作業を止め、何が変わったか、追加または減額、日程影響、新仮定を書きます。商業条件が変わるなら続行前に書面承認を取ります。実装前の2分確認の方が納品後の支払い争いより安いです。

これは利益だけでなく関係も守ります。顧客は『新しい依頼には費用がかかる』と聞くことより、突然の追加請求を嫌います。落ち着いた変更プロセスなら、承認、別項目削除、延期、元scope維持から選べます。責任追及ではなくビジネス判断になります。

実例：要件がない段階で業務ダッシュボードを見積もる

顧客は売上、在庫、スタッフ情報を1か所で見たいものの、指標、データ品質、権限はまだ定義できていません。ここで実装固定価格を出すには、こちらが答えを想像する必要があります。代わりに、ステークホルダーワークショップ、3データソースのレビュー、権限マップ、主要画面wireframe、優先実装scopeというdiscoveryを提案します。これらは価格化できる具体的成果です。

discovery後、売上と在庫は安定API、スタッフデータは不整合なスプレッドシートだと判明しました。実装を分けられます。既知2APIを使うコアダッシュボードは固定価格、スタッフデータのクリーニングと取り込みは上限付きフェーズ。顧客は狭い価格レンジを得て、自動化が追加費用に見合うか判断できます。

この進め方は決断力がないのではありません。決定を正しい順番にしているだけです。まず学ぶための作業を価格化し、次に作るための作業を価格化します。この順序が、健全な案件と、双方が別の物語を想像したままの固定価格約束との差になることがあります。

• 機能より先に事業成果を明確にする
• 実装価格固定前に高影響の未知を見つける
• 未知解消に実作業が必要ならdiscoveryを販売する
• 不確実性が残る間はレンジと上限を使う
• 仮定を書面条件に変える
• 新情報が案件を大きく変えたら再見積する