「この見積もりで大丈夫か」と感じながらも、どこをどう確認すればいいか分からず、そのまま承認してしまったことはないでしょうか。
担当者の見積もりをレビューするのは、疑うためではありません。PMの役割は、見積もりの前提・対象範囲・不確実性を一緒に確認し、リスクをプロジェクト全体で把握することです。
この記事では、見積もりの妥当性ではなく前提を確認するための5つの質問を紹介します。精度管理や粗利管理の話ではなく、担当者との会話で使える実践的な問いかけです。
PMは見積もりを疑うのではなく前提を確認する
「この見積もり、甘くないですか?」という聞き方は、担当者との関係を悪化させます。担当者はベストを尽くして出してきた数字を否定されると感じます。
代わりに使うのが「前提を確認する」というアプローチです。「この工数は〇〇を含んでいますか?」という問いは、否定ではなく確認です。前提を明確にすることで、抜け漏れが見つかることがあります。その場合は担当者自身が「あ、それ入れてなかった」と気づきます。
PMが見積もりレビューで目指すのは、「自分が正しいと証明すること」ではなく「プロジェクト全体で認識を合わせること」です。
質問1:対象範囲の確認
「この見積もりに含まれているのは〇〇と〇〇で合ってますか?逆に含まれていないものはありますか?」
見積もりの中に何が入っていて何が入っていないかを確認します。特に受託開発では、「テスト工数は別途」「環境構築は含まない」などが暗黙のうちに抜けていることがあります。
対象外のものが明確になると、後でそれが追加になったときに「最初から別で見ています」という話ができます。
質問2:前提条件の確認
「この工数は、〇〇が決まっている前提ですか?仕様が変わった場合はどうなりますか?」
見積もりには必ず前提があります。「仕様が確定している」「他社APIの仕様書がもらえる」「顧客環境で動作検証が可能」など。この前提が崩れると工数は変わります。
前提を言語化しておくと、後でスコープ変更が発生したときの根拠になります。
質問3:不確実性の確認
「今の見積もりで一番不確実なのはどこですか?」
担当者自身が「ここが一番読みにくい」と感じているポイントを聞きます。そこにバッファを積むかどうかの判断材料になります。
不確実な部分をPM自身が当てにいくより、担当者に教えてもらうほうが正確です。「どこが心配ですか?」という問い方でも構いません。
質問4:レビュー・手戻り工数の確認
「レビューの工数と、指摘対応の工数は入っていますか?」
実装工数だけで見積もりが作られている場合、レビュー・指摘対応・再テストの工数が抜けていることがあります。受託開発では顧客レビューを経て修正が発生するのが通常です。
「レビューで指摘が来た場合の対応はどこに入ってますか?」という聞き方でも同じです。
質問5:依存関係の確認
「この作業を始めるために、他に完了している必要があるものはありますか?」
他タスクやチームの進捗、顧客確認などが前提になっている場合、それが遅れると見積もり工数は正確でもスケジュールがずれます。
「待ちが発生しそうなポイントはありますか?」という聞き方でも確認できます。依存関係が明確になると、全体スケジュールへの影響が見えてきます。
見積もりレビューを習慣にする
5つの質問を毎回すべて聞く必要はありません。見積もりの規模や担当者の習熟度によって、確認が必要なポイントは変わります。
新しい担当者の初回見積もりには全部確認する。経験豊富な担当者の慣れた作業には対象範囲と不確実性だけ確認する。このような使い分けが現実的です。
レビュー後は確認した前提を一言メモしておきます。「この見積もりはXXを含まない前提」「YYのAPIが使える想定」など。後でスコープ変更が起きたときに、これが根拠になります。
まとめ
担当者の見積もりをレビューするとき、PMが確認するのは前提・対象範囲・不確実性・レビュー工数・依存関係の5点です。疑うのではなく、確認する。この姿勢が担当者との信頼関係を保ちながら、抜け漏れを防ぐことにつながります。
見積もりレビューで使う一言例
| 質問 | 使いやすい一言 |
|---|---|
| 前提の確認 | 「この見積もりは〇〇の仕様が確定している前提ですか?」 |
| 対象範囲の確認 | 「レビューや修正の工数はこの中に含まれていますか?」 |
| 不確実性の確認 | 「初めての作業や不確かな部分はありますか?そこはバッファを積んでいますか?」 |
| レビュー工数の確認 | 「単体テストまで含めた見積もりですか?受入テストの対応も含みますか?」 |
| 依存関係の確認 | 「この作業を始めるために、先に完了している必要があるものはありますか?」 |
質問の語尾を「〜ですか?」にして、担当者が「はい/いいえ」と「理由」で答えやすい形にすると、確認がスムーズになります。
受託開発での見積もり管理や実務スキルを学びたい方は、受託開発PM向けの課題別パックをご覧ください。
次に読む関連記事
- 見積レビューで5つだけ見れば赤字リスクの多くは拾える — レビューを見るべきポイントに絞る方法
- 見積根拠の前提条件を作って伝える方法 — レビュー前に社内で揃える前提リスト
- 顧客要望を見積依頼の前に分解する — 見積依頼を出す前の準備としての要望分解