「見積もりを依頼したものの、何を聞けばいいかわからない」——システム開発の発注経験が少ない中小企業の経営者から、繰り返し聞く悩みです。見積もり精度は、発注側が投げかける質問の質でほぼ決まります。同じ業務でも、聞き方ひとつで300万円の幅が動くケースは珍しくありません。本記事では、見積もり依頼時にベンダーへ必ず投げかけるべき7つの質問と、理想的な回答の特徴を、経営者目線で整理します。
この記事の結論（3行）
- 見積もり精度の8割は発注側の質問の質で決まり、聞かない情報は見積もりに反映されない
- 7つの質問（人月単価・工数内訳・予備工数の根拠・運用費・体制・契約形態・追加費用条件）が必須
- 7問すべてに即答できるベンダーは、構造的に透明な見積もりを出せる組織であるサイン
なぜ「何を聞けばいいかわからない」状態になるのか
システム開発の見積もり依頼で迷子になる原因は、発注側の知識不足ではなく、業界の見積もり慣行そのものにあります。聞き方を知らないまま依頼を始めると、ベンダー主導で話が進み、提示金額の妥当性を判断できないまま契約に至る構造です。
- 業界用語と一般用語のギャップ
- 「お任せします」が招く工数膨張
- 比較軸が見えないまま3社見積もりを取ってしまう
ベンダーは「過去案件のフォーマット」を持ち込んで提示してきます。発注側がそのフォーマットの中身を質問できなければ、提示金額がそのまま既成事実になってしまうのが現実です。
業界用語と一般用語のギャップ
「人月」「リスクバッファ」「保守運用」——システム業界の見積もりには、一般的なビジネス用語と意味が微妙にずれる単語が並びます。「保守」と聞くと故障対応のみを想像しがちですが、業界の保守には小規模改修・データ調整・問い合わせ対応まで含まれます。用語の境界をベンダーと揃えるだけで、見積もり後のトラブルが大幅に減る構造です。
「お任せします」が招く工数膨張
要件を「お任せします」と伝えると、ベンダー側はリスクを取らないために、想定される最大ケースで工数を積むことになります。実際には半分の工数で済む業務でも、要件があいまいなまま見積もりを取ると保険料込みの金額が出てきます。手元の業務イメージを1ページにまとめるだけで、提示金額は2〜3割下がるケースが普通にあります。
比較軸が見えないまま3社見積もりを取ってしまう
比較軸を持たないまま3社並べても、金額の高い低いしか見えてきません。A社400万・B社1,200万・C社2,000万という見積もりを前にして、なぜ3倍の差が出るのかを構造で説明できなければ、結局「真ん中」を選ぶ判断になりがちです。本記事の7つの質問は、3社見積もりを意味のある比較に変える共通フォーマットとして機能します。
見積もり依頼時に投げかけるべき7つの質問
ここからが本題です。見積もり依頼の場で、ベンダーへ必ず投げかけるべき7つの質問を順に整理します。質問の意図と、理想的な回答の特徴を併記しています。
| 番号 | 質問 | 質問の意図 | |---|---|---| | Q1 | 御社の人月単価はいくらですか | 工数換算の透明性を確認 | | Q2 | 工数の内訳を項目別に教えてください | 何にいくら払うかの可視化 | | Q3 | 予備工数の根拠を3行で説明してください | リスクバッファの妥当性検証 | | Q4 | 納品後の運用費は3年でいくらですか | 隠れたランニングコスト把握 | | Q5 | 実装するのは自社社員ですか、外部の方ですか | 中間マージン構造の確認 | | Q6 | 契約形態は請負・準委任のどちらですか | 責任範囲と追加費用リスク | | Q7 | 追加機能・仕様変更の費用条件は | 契約後の青天井請求の予防 |
表は質問の全体像です。手元の見積もり書をこの7軸で点検したい場合は、業務改善・システム見積もりAI適正診断で項目別に整理できます。次に、それぞれの質問が「なぜ重要か」「理想的な回答はどんな特徴を持つか」を順に解説します。
Q1：御社の人月単価はいくらですか
質問の意図は、見積もり総額を工数に分解する起点を作ることです。「1人のエンジニアが1ヶ月稼働した時の金額」が即答できないベンダーは、見積もり総額の根拠を工数で説明できない構造を持っています。理想的な回答は「ジュニア60万・シニア100万の2階層」のように階層別の人月単価を提示できる答え。「ケースによる」「総額で見てください」と返してくるベンダーは、後から「追加で人月分が必要」と請求してくる余地を残します。業界相場はフリーランス60〜80万・中堅Web開発80〜120万・大手SIer150万〜が目安です。
Q2：工数の内訳を項目別に教えてください
「設計一式」「開発一式」と書かれた見積もりは、内訳を分解する質問で初めて中身が見えてきます。理想的な回答は、要件定義・設計・開発・テスト・管理・運用支援・予備工数の7区分で人月数を提示してくれる答えです。コーディング工数が総額の3〜4割で、設計・テスト・管理が均等に並んでいる見積もりが業界標準と整理できます。
Q3：予備工数の根拠を3行で説明してください
予備工数（リスクバッファ）は必要なものですが、根拠なく積まれているケースが業界には多く存在します。理想的な回答は「○○の要件があいまいなため○○人月」のように、項目別の根拠を3行以内で説明できる答えです。「全体の20%を一律で置いています」という回答は、リスクの所在を考えずに保険料として上乗せしている構造で、見直し対象になります。
Q4：納品後の運用費は3年でいくらですか
「初期費用1,200万円」だけを見て契約すると、運用フェーズに入ってから想定外のコストが膨らみます。理想的な回答は、サーバー代・保守費用・小規模改修費を月額または年額で提示し、3年トータル金額を明示できる答えです。サーバー代月3万・保守費月5万・年間改修50万で計算すると、3年で約340万円のランニングコストが追加になります。
Q5：実装するのは自社社員ですか、外部の方ですか
質問の意図は、多重下請け構造の有無を確認することです。理想的な回答は「弊社の自社社員が設計から実装まで担当します」と即答できる答えです。「協力会社のエンジニアが対応します」という回答が出てきたら、中間マージンが見積もり総額の3〜5割を占めている可能性があります。元請け30〜50%、2次請け10〜20%のマージンを取る構造は業界の標準です。
Q6：契約形態は請負・準委任のどちらですか
請負は「成果物の納品を約束する契約」、準委任は「作業時間に対して報酬を払う契約」です。理想的な回答は、案件の性質に応じて使い分けの理由を説明できる答え。要件が固まっている案件は請負、要件が動く可能性がある案件は準委任という整理が一般的です。請負の場合は「完成の定義」を、準委任の場合は「想定工数の上限」を必ず契約書に明記してください。
Q7：追加機能・仕様変更の費用条件は
契約後に「やっぱりこの機能も入れたい」となった時の追加費用ルールを、契約段階で明文化しておくべき質問です。理想的な回答は、「人日単価いくら・最小単位は半日・申請から実装までの最短期間は1週間」のように、追加発注のプロセスと金額を即答できる答えです。「その時に都度提示します」という回答は、契約後の値付け権限がベンダー側に集中する構造を許してしまいます。
7つの質問への回答パターンで見抜く「良いベンダー」
7つの質問への回答を3社並べてみると、ベンダーごとの透明性レベルが手に取るようにわかります。金額だけでは見えない「組織としての見積もり姿勢」が、回答パターンで浮かび上がる構造です。
- パターンA：7問すべてに具体的な数字で即答できる
- パターンB：4〜5問は答えられるが残りはあいまい
- パターンC：「総額で判断してください」と内訳開示を避ける
3つのパターンは、ベンダーが普段から見積もりを構造で組み立てているかどうかを反映します。
パターンA：7問すべてに具体的な数字で即答できる
このパターンのベンダーは、見積もりを「過去の感覚」ではなく「工数と単価の構造計算」で組み立てる組織です。質問への回答が早く、数字が一貫しており、根拠が説明できる構造を持っています。提示金額が他社より高くても安くても、その理由を構造で説明できるため、発注側は判断材料を揃えた状態で決断できる立場に立てます。
パターンB：4〜5問は答えられるが残りはあいまい
業界で最も多いタイプです。人月単価と工数内訳は答えられるが、予備工数の根拠や追加費用条件はあいまい、という回答が並びます。組織として見積もり構造の標準化が不十分な状態を反映しています。発注前に「あいまいだった項目」を契約書に明文化することで、リスクを抑えて発注できる相手です。
パターンC：「総額で判断してください」と内訳開示を避ける
このパターンのベンダーは、見積もりの透明性が低く、契約後の追加請求リスクが高い構造を持ちます。「業界の標準的な金額です」という説明で押し切ろうとするケースがあれば、要注意です。総額の中身を質問しても答えが返ってこない時点で、契約後にトラブルが発生した時の対応も期待できない構造と考えてください。
経営者目線で考える「見積もりの取り方」
ここからは技術論ではなく、経営の話です。見積もりの取り方は、経営者にとって、社員の採用面接や設備投資の稟議と同じくらい重要な「経営スキル」と整理できます。ベンダー側がどんなに丁寧な提案をしても、「これは自社にとって何を解決する投資か」「3年で回収できる金額の上限はいくらか」を経営者側が握っていないと、見積もり比較は単なる金額の足し算引き算で終わります。
経営者として持っておくべき視点は3つです。第一に、見積もりは「もらうもの」ではなく「設計するもの」だという視点。発注側が何を聞き、何を整理して渡すかで、見積もりの精度は2〜3倍変わります。第二に、金額だけでなく構造を見る姿勢を持つこと。1,200万円の見積もりが妥当か判断するには、人月単価・工数内訳・予備工数・運用費の4軸を必ず確認することになります。第三に、ベンダーの「答え方」を経営判断に組み込むこと。7つの質問への即答力は、その会社が普段から構造的に仕事をしているかどうかを示す強力な指標です。
ぷらすわんの実例：ある製造業A社の見積もり比較案件
弊社が支援したある製造業A社では、業務システム開発の見積もりを3社から取得した際、本記事の7つの質問をそのまま使って比較を行いました。A社（大手SIer）が1,800万円、B社（中堅Web開発会社）が900万円、C社（弊社）が550万円という3社並びの状態からのスタートです。
最大の差を生んだのはQ1（人月単価）とQ5（実装者）の回答でした。A社は「人月単価は案件によって変動」「実装は協力会社が中心」と回答し、内訳の透明性が低い構造。B社は「人月単価100万円・自社社員中心」と即答できたものの、Q3（予備工数の根拠）で「全体の25%を一律バッファ」と答え、根拠が薄い回答に。弊社は「人月単価75万円・自社代表が設計と実装を担当・予備工数は外部API連携部分の0.5人月のみ」と項目別に提示しました。期間3.5ヶ月・Claude Code活用によるコーディング工数3割削減・Supabaseでの認証/DB構築という構成で、550万円・3年トータル720万円の見積もりを実現しています。経営者として得た学びは、「見積もりの差は技術力の差ではなく、構造の透明度の差として最初に現れる」という1点です。手元のシステムを診断することで、構造の差を具体的な数字で把握できます。
7つの質問を活かすための4つの事前準備
最後に、7つの質問を最大限活かすために、ベンダーへの依頼前に発注側が済ませておくべき4つの準備を紹介します。
- 準備1：業務フローを紙1ページにまとめる
- 準備2：必須機能と将来機能を分けておく
- 準備3：3年トータルの予算上限を決めておく
- 準備4：質問シートを印刷して打ち合わせに持参する
4つはいずれも紙とペンでできる作業で、1〜2週間の準備で完了します。準備を済ませた発注は、見積もり総額が当初想定の半分以下になるケースも珍しくありません。
準備1：業務フローを紙1ページにまとめる
「誰が・いつ・何を入力し・誰に渡すか」を紙1ページに書き出してください。これが書ければ、ベンダーへの説明が短時間で終わり、要件定義の工数が大幅に削減できます。書けない業務は、そもそも整理が足りていない業務と整理できるため、システム化の前に業務整理から着手する判断もできます。
準備2：必須機能と将来機能を分けておく
業務上「これがないと運用できない」機能だけを必須機能として分け、それ以外は「あったら便利」「将来の検討」に振り分けてください。必須機能だけで発注すれば、初期コストは想定の40〜60%まで下がる構造です。発注前にこの3層分けができていれば、Q2（工数内訳）が機能ごとの値付けを引き出す強力なツールに変わります。
準備3：3年トータルの予算上限を決めておく
初期費用だけでなく、3年間のサーバー代・保守費・想定改修費を含めた予算上限を、発注前に決めておいてください。「3年で1,000万円以内」「初期は500万円以内」のように、上限を持って打ち合わせに臨むだけで、Q4（運用費）の回答を経営判断に直結させやすくなります。
準備4：質問シートを印刷して打ち合わせに持参する
7つの質問を1枚の紙にまとめ、打ち合わせの場に持参してください。質問を口頭で並べるよりも、紙でベンダー側に渡したほうが、回答の質が上がる傾向にあります。最初に「この紙に沿って質問させてください」と伝えるだけで、ベンダー側は構造的な回答を準備する姿勢に切り替わります。
まとめ
システム開発の見積もりは「もらうもの」ではなく「設計するもの」です。発注側が投げかける7つの質問——人月単価・工数内訳・予備工数の根拠・運用費・実装者・契約形態・追加費用条件——を押さえれば、提示金額の妥当性を構造で判断できる立場に立てます。経営者として大事なのは、金額だけを比較するのではなく、回答の即答力と構造性で発注先を選ぶ視点を持つことです。次に取るべき1ステップは、7つの質問を1枚の紙にまとめ、次回の打ち合わせに持参すること。手元に複数社の見積もりがある段階なら、現在の見積もりを診断することで、適正レンジと構造的な改善余地を数字で把握できます。