II発注構造・費用の仕組み

見積もりの単価だけ見て発注先を選ぶ危うさ

公開日:2026年9月22日最終更新日:2026年9月26日サイバーコネクト編集部

複数社に見積もりを取って、一番安いところに決めたはずなのに、後から「これは別途費用です」と言われて総額が逆転した。そんな経験に心当たりはないでしょうか。「安いから」という理由だけで発注先を選んだことを、少し悔やんでいる方もいるかもしれません。

実はこの違和感、単価の高い安いという話ではなく、その単価が「どこまでの作業を含んでいるか」という範囲の違いに理由があると考えると整理しやすくなります。見積書に並ぶ数字は同じ「一式〇〇円」でも、中身の作業範囲がまったく違うことがあるからです。

この記事では、見積もりの単価だけで発注先を比較することがなぜ危ういのか、その構造と、比較する際にどこを確認すればよいかを整理します。

なぜ「単価が安い」だけで選ぶと危ういのか

見積書に書かれている金額は、依頼した作業に対する対価です。しかし「依頼した作業」の解釈が発注側と受注側でずれていると、同じ項目名でも金額の前提がまったく違うものになります。

例えば「画面設計一式」という項目ひとつをとっても、ある会社は画面のデザインからワイヤーフレーム作成、レビュー対応まで含めている一方、別の会社は画面数のカウントに基づく作業工数だけを計上していることがあります。後者のほうが金額は安く見えますが、レビューのやり取りや修正対応が別途発生する可能性があります。

単価だけを横並びで比較すると、こうした前提の違いが見えなくなります。表面上の金額差は、実は「含まれている作業の量の差」であることが少なくありません。ここは、次に複数社の見積もりを並べるときに思い出したい視点です。

単価の裏にある「作業範囲」の違い

見積もりの単価差を生む要因は、大きく分けると次のようなものがあります。

  • 含まれる工程の範囲:要件定義や設計段階の作業を単価に含めているか、それとも実装工数だけを見積もっているか
  • 修正・レビューの回数:仕様確認や修正のやり取りが何回まで単価に含まれているか、それ以降は追加費用になるか
  • 保守・運用の扱い:納品後の軽微な修正対応が含まれているか、別契約になるか
  • 体制の違い:直接契約する担当者が実務を行うのか、複数の協力会社を経由する体制なのか

こうした違いは、見積書の金額欄だけを見ていても分かりません。項目の名称は同じでも、その中身の定義が会社ごとに異なるためです。ここを揃えずに金額だけを比較すると、比較そのものが成立していないことになります。

見積もりの中身の比較については、SIer・フリーランス・自社開発、見積もりの中身を比べるでも整理していますので、あわせて確認してみてください。

比較する前に確認しておきたいこと

単価の前提を揃えるために、見積もりを受け取る段階で以下を確認しておくと、後からの認識ずれを減らせます。

  1. その単価に含まれる工程を書き出してもらう:「一式」の中に何が入っているか、具体的な作業項目を文章で説明してもらう
  2. 修正回数の上限を確認する:仕様確認や画面修正が何回までなら追加費用が発生しないかを聞く
  3. 保守・運用の扱いを分けて聞く:納品後の軽微な修正が別料金かどうかを事前に確認する
  4. 前提となる要件の詰め方を揃える:そもそもの要件定義の粒度が発注先ごとに違うと、見積もりの土台自体がずれてしまいます。単価を比べる前に、依頼内容の粒度を発注側でもある程度そろえておくことが必要です

この4点を確認しておくだけでも、「安いと思って選んだら実は範囲が狭かった」という事後のずれを減らせます。単価そのものより、単価が指している範囲を先に揃えておくことが、比較を成立させる前提になります。

なお、契約範囲の線引きが曖昧になりやすい背景には、発注側から作業範囲が見えにくいという構造があります。取引の適正化という観点では、発注内容をできるだけ明確にし、書面で認識をすり合わせておくことが望ましいという考え方が、下請取引に関する行政の指針でも一般的に示されています。契約前に作業範囲を書面で確認する習慣は、この観点からも意味があります。

まとめ

  • 見積もりの単価差は、金額の高い安いではなく「含まれている作業範囲の違い」であることが多い
  • 「一式」という表記の中身は会社ごとに定義が異なるため、比較する前に作業範囲を揃える必要がある
  • 発注前に工程・修正回数・保守の扱いを具体的に確認しておくことで、後からの認識ずれを防ぎやすくなる

執筆

サイバーコネクト編集部

誇張や決めつけを避け、現場で実際に判断材料になる情報だけをお伝えします。

監修

木村 真之

株式会社サイバーコネクト 代表取締役社長

エンジニアとしてキャリアを開始。自ら事業を立ち上げた経験から、システム開発では事業の目的・顧客の課題・収益構造まで理解することが重要だと考え、技術と事業の橋渡し役となるPMとして活動。2021年11月に同社を設立。

運営者情報を見る

まずはお話をお聞かせください。要件が整理されていない段階でもご相談いただけます。

お問い合わせ

情報の取り扱いと免責:本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません。 統計・数値等は出典を明記したもの以外は掲載していません。内容は公開時点の一般的な傾向を示すものであり、 実際の発注・契約にあたっては個別の事情に応じて専門家・取引先とご確認ください。