「〇〇のシステムを作ってほしいんですが、いくらになりますか？」
こういう依頼を受けたとき、即座に見積もり金額を出せる状態ではないはずです。「〇〇のシステム」という一言の中に、どれだけの機能・条件・制約・前提が含まれているか、聞いただけでは分からないからです。
このまま担当者に「見積もっておいて」と渡すと、担当者も「どの範囲で見積もればいいか」が分からず、広く取りすぎたり、逆に狭すぎて後で追加が発生したりします。
この記事では、見積もり依頼を渡す前にPMが行う顧客要望の分解を解説します。要件定義の全プロセスではなく、「見積もれる状態に整理する」ための分解です。
要望をそのまま見積もると危ない理由
「要望を分解せずに見積もる」とどうなるか。
担当者は「たぶんこのくらいの範囲だろう」という仮定で見積もります。その仮定が顧客の期待と異なっていた場合、見積もり後に「それも含まれてると思ってた」という話になります。これがスコープクリープの典型的な入口です。
また、分解前の要望は「認識のズレ」を含んでいることが多いです。顧客が「在庫管理システム」と言っていても、PMが想定している「在庫管理」と顧客が想定している「在庫管理」が異なる場合があります。分解することで、この認識のズレを見積もり前に確認できます。
分解1：目的
「顧客がこの機能・システムを作りたい理由は何か」を確認します。
目的が分かると、何をどの水準で作るべきかが見えてきます。「業務効率化のために帳票を自動化したい」という目的なら、帳票の精度よりも処理速度が重要かもしれない。「顧客への報告用に使いたい」なら、見た目の品質が重要かもしれない。
「何のために使いますか？」「これがあると何が解決しますか？」という問いかけで確認できます。
分解2：対象範囲
「この要望でどこからどこまでが対象か」を確認します。
「在庫管理システム」なら、「入庫・出庫・在庫照会・棚卸しのうち、どの機能が対象か」「既存システムとの連携は含むか」「スマホ対応は必要か」などが対象範囲に関わります。
対象外の明示は、後の「それも含まれると思っていた」を防ぐ最も手軽な方法です。「〇〇は含まない」という確認を一言入れておくだけで、検収時の余分な交渉を避けられます。
分解3：成果物
「この依頼で最終的に何を納品するか」を確認します。
「システム」と一言で言っても、ソースコード・ドキュメント・テスト結果・操作マニュアルなど、含まれるものは様々です。特に受託開発では、「動くもの」だけでなく「引き渡すもの」の全体を確認します。
成果物の一覧を確認しておくと、見積もりが網羅的になります。
分解4：制約
この依頼を進める上での制約を確認します。
主に次の3つを確認します。
- 期限：「いつまでに必要か」。急ぎのものは通常よりコストがかかる場合があります。
- 予算：「予算感はありますか」。予算上限が分かると見積もりの方向性が変わります。
- 技術的制約：「使用しているシステム・言語・インフラに指定はあるか」。
制約を先に確認しておくと、「この予算ではここまでしかできません」という提案も可能になります。
分解5：未確認事項
分解した後に残る「まだ分からないこと」を確認します。
「設計を始めるために確認が必要な情報」「顧客に判断してもらう必要がある選択肢」「外部システムから取得が必要な情報」などが、未確認事項として残ります。
未確認事項が多ければ、「この状態では見積もれません、まず〇〇を確認させてください」と正直に伝えます。見積もれない理由を明確にすることで、顧客も「何を決めれば見積もりが出るか」が分かります。
見積依頼に渡す形
分解した内容を担当者に渡すとき、次の形式で伝えると伝達漏れが減ります。
- 目的：〇〇（一文で）
- 対象機能：A・B・C（対象外はD・E）
- 成果物：〇〇・〇〇（一覧）
- 制約：期限〇月〇日、予算〇〇万円目安、使用言語〇〇
- 未確認事項：〇〇は確認中
この形式で渡せば、担当者は「どこまで見積もればよいか」が分かった状態で作業に入れます。
まとめ
顧客要望を分解してから見積もりを依頼することで、後のスコープ変更・追加依頼・認識ズレを減らせます。
「目的・対象範囲・成果物・制約・未確認事項」の5点を整理するのに、大きな時間はかかりません。30分の確認会話ができれば十分です。
受託開発での見積もり管理や顧客折衝の実務スキルを学びたい方は、受託開発PM向けの課題別パックをご覧ください。