「見積もりを出したときと状況が変わって、工数が倍になった。でも顧客は見積もり通りに作れと言う」
受託開発のPMがよく経験するトラブルです。見積もりを出した時点での前提が変わっているのに、顧客は変わっていないと思っている。PM側も「前提が変わった」という証拠がない。結果として「見積もりが甘かった」という話になってしまう。
見積もりの失敗は、数字の計算より「前提の合意と記録」で起きることがほとんどです。
見積もりの失敗は数字より前提で起きる
見積もりが大きく外れる案件を振り返ると、工数計算の式が間違っていることはほとんどありません。外れる理由の多くは以下のどれかです。
- 見積もり時点での前提が文書化されていなかった
- 顧客が追加要望を「当然含まれているもの」と理解していた
- システム連携や既存機能の調査工数を見ていなかった
- 「○○は顧客側でやること」という前提が後から変わった
これらは、見積もり前に前提条件リストを作って顧客と合意しておけば、多くが防げます。
前提条件・制約・除外事項の違い
前提条件リストを作る前に、3つの概念を整理します。
前提条件（Assumption）
「○○であることを前提にこの工数を算出している」という、成立を仮定している条件です。この前提が崩れると工数・スコープが変わります。
例：「既存APIは正常に動作することを前提とする」「テストデータは顧客が準備する前提」
制約条件（Constraint）
プロジェクト外から与えられている制限です。変更できないものです。
例：「本番環境へのアクセス権は週1回の定時作業のみ」「使用技術はXXに限定」
除外事項（Exclusion）
今回のスコープに含まれていないことを明示したものです。
例：「既存機能の改修は対象外」「モバイル対応は今回スコープに含まない」
この3つを分けて書くことで、顧客との認識のズレを見つけやすくなります。
前提条件リストの項目例
前提条件リストには以下の項目を入れます。
| カテゴリ | 前提条件の内容 | 成立しない場合の影響 |
|---|---|---|
| インフラ | 本番・検証環境は顧客が準備する | 環境構築工数が○人日追加 |
| データ | テストデータは顧客が用意する | データ準備工数が追加 |
| 連携 | 連携先APIの仕様変更は今回スコープ外 | 仕様変更対応工数が追加 |
| 要件 | 要件確認は週次定例のみ | 確認待ちが発生し進捗が止まる |
| スコープ | モバイル対応は対象外 | 対象に含める場合は別途見積もり |
顧客に確認するタイミング
前提条件リストは見積もり提出時に一緒に出すのが最もよいタイミングです。
「この見積もりは以下の前提で算出しています。内容をご確認ください」という形で添付します。顧客が「この前提は違う」と指摘してくれれば、着手前に修正できます。確認なしに着手すると、後から「そんな前提は聞いていない」という話になります。
また、要件定義・設計の各フェーズでも、前提が変わっていないかを確認するタイミングを設けます。特に「顧客側の作業」として前提にしているものは、プロジェクトが進むにつれて変化することが多いです。
変更管理につなげる方法
前提条件リストを変更管理と連動させると、実務で使いやすくなります。
前提が変わった場合の対処：
- 変更内容を記録する（何の前提が・どう変わったか・いつから）
- 工数・スコープ・納期への影響を算出する
- 顧客に「前提変更による影響」として提示する
- 対応方針を合意してから動く
「前提が変わりました、工数が増えます」という主張は、変更管理のプロセスと連動することで初めて顧客に受け入れてもらいやすくなります。
見積・変更管理系講座で実践力を高める
前提条件管理・変更管理スキルは以下で学べます。
見積もりの「前提条件」が崩れたときの対処法
プロジェクトが進む中で、見積もりの前提条件が変わることは珍しくありません。「担当者が変わった」「要件が追加された」「外部サービスのAPIが変わった」など、当初の前提が崩れた場合は、見積もりを再評価する必要があります。
前提条件リストを常に参照できる状態に保つことで、「前提が変わった」という変化を素早く検知でき、見積もりの再計算と関係者への報告がタイムリーに行えます。前提条件の管理が、見積もりの信頼性を維持します。
見積もりの「根拠」を共有する文化を作る
「なんとなく3日かかりそう」という感覚的な見積もりより、「○○の実装に1日、テストに1日、バッファとして0.5日、合計2.5日」という根拠のある見積もりが、チーム内の信頼を生みます。
見積もりの根拠をチームで共有する文化が育つことで、個人依存の見積もりから「チームとして見積もる力」へと成熟します。見積もりの根拠が共有されることで、チームメンバー全員が見積もりに当事者意識を持てます。
見積もりの精度を振り返る「振り返りの習慣」
プロジェクト完了後に「見積もりと実績の差異」を振り返ることで、見積もり精度が継続的に向上します。「見積もりより2日多くかかったが、その理由はレビューサイクルが想定より多かったため」という具体的な分析が、次の見積もりの精度を上げます。
振り返りを個人ではなくチームで行うことで、チーム全体の見積もり力が向上します。見積もり精度の向上が、プロジェクトのスケジュール安定性を高めます。
「前提条件の合意」がステークホルダーの信頼を生む
見積もりの前提条件をステークホルダーと合意した上でプロジェクトを進めることで、後から「なぜ遅れたのか」という追求を防げます。「当初の前提では3週間でしたが、○○の前提が変わったため2日追加が必要です」という説明が、透明性のある変更管理として機能します。
前提条件の合意と変更管理が、ステークホルダーとの信頼関係を長期的に維持する基盤になります。
「チームで見積もる」文化の価値
見積もりをPM一人で行うより、担当するエンジニアと一緒に見積もることで、より現実的な数字が得られます。現場に最も近いエンジニアが「この部分は思ったより時間がかかる」「ここは自動化できるので早い」という具体的な情報を提供することで、見積もりの精度が高まります。
チームで見積もるプロセス自体が、タスクの共通理解を生み、実行フェーズでの手戻りを減らします。見積もりに参加したエンジニアが「自分が決めた数字」として責任感を持って実行することで、期限遵守率も向上します。チームでの見積もりが、計画と実行の両方の質を高めます。
まとめ：前提条件の管理が見積もりの信頼を守る
見積もりに込められた前提条件を明示し、管理し、変化に応じて更新することが、見積もりの信頼性を長期にわたって維持する鍵です。前提条件の透明な管理が、ステークホルダーとの信頼関係を強化し、変化への対応力を高めます。見積もりを「数字」ではなく「前提条件と数字のセット」として扱う意識が、PMとしての誠実さと専門性を示します。
見積もりの前提条件を丁寧に管理するPMが、プロジェクトの信頼性と予測可能性を高めます。前提条件の管理を見積もりの一部として習慣化することで、PMとしての誠実さと専門性が示されます。
見積もりの透明性を高めることへの継続的な取り組みが、PMとしての信頼を長期にわたって維持します。前提条件の管理を通じた誠実さが、最終的に最も価値あるPMとしての評判を作ります。
見積もりへの信頼が高いPMが、より大きなプロジェクトの計画を任される機会を得ます。この機会が、PMとしての経験とキャリアをさらに積み上げます。