【悲報】見積書の「一式」、そのまま承認すると後で揉めます
システム開発の見積書は合計金額を見ても妥当性が判断できません。人月単価の相場、工数の算出根拠、諸経費の中身、前提条件と除外事項、契約形態——発注側が押さえるべき5つのチェック視点を、そのまま使える質問リスト付きで解説します。

この記事でわかること
- 見積書は合計金額ではなく「単価×工数」に分解して読む。職種別の人月単価は初級SE65〜75万円、PM110〜150万円が目安
- 工数の算出根拠は4手法(積み上げ・類推・係数・FP法)のどれか。「一式」表記は根拠なしのサイン
- 安い見積もりは値引きではなく工程が抜けているだけのことが多い。テスト・移行・教育の有無を確認する
- 金額が動く原因は前提条件と除外事項に書かれている。契約形態(請負か準委任か)とセットで読む
3社から見積書が届いた。金額は280万円、420万円、650万円。——この状態で「真ん中が無難」と選んでしまうのが、発注側の一番よくある失敗です。金額差の理由は合計欄ではなく、内訳と前提条件に書かれています。 この記事では、見積書を受け取ったときに何をどう見ればいいかを5つの視点に整理します。
大前提:見積書は「単価 × 工数」に分解して読む
日本のシステム開発の見積もりは、ほとんどが工数見積もりです。作業量を「人月」(エンジニア1人が1か月働く量)で表し、そこに単価を掛けて金額を出します。
費用 = 作業工数(人月)× 人月単価
つまり見積金額が高いときの原因は2つしかありません。単価が高いか、工数が多いかです。この2つを切り分けずに「高い/安い」を論じても話が進みません。
職種・スキル別の人月単価は、おおむね次のレンジが目安とされています。
| 職種・スキル | 人月単価の目安 |
|---|---|
| テスター | 45〜60万円 |
| システムエンジニア(初級) | 65〜75万円 |
| システムエンジニア(中級) | 65〜90万円 |
| システムエンジニア(上級) | 90〜110万円 |
| プロジェクトマネージャー | 110〜150万円 |
出典によって幅があり、SEを70〜100万円、PMを100〜150万円とする調査もあります。単価は「誰が作業するか」で決まるので、見積書に職種別の単価が書かれていない場合は、その一点だけでも聞く価値があります。なお発注先の規模による単価差については、システム開発の見積もりはなぜ高いのかで整理しています。
視点1:工数の算出根拠が示されているか
同じ機能でも「3人月」と言う会社と「6人月」と言う会社があります。差がどこから来るのかは、見積もり手法を聞けば見当がつきます。
| 手法 | やり方 | 特徴 |
|---|---|---|
| 積み上げ(ボトムアップ) | 作業を細分化して工数を積み上げる | 精度が高い。作業内容まで見えている証拠になる |
| 類推見積もり | 過去の類似案件から推定する | 初期段階で速い。担当者の経験に依存し根拠が曖昧になりやすい |
| 係数見積もり(パラメトリック) | 数式モデルに規模を当てはめる | 属人性が低い。前提の妥当性が結果を左右する |
| ファンクションポイント法 | 機能の数と複雑さを点数化する | 言語や環境に依存せず比較できる。ベンダー比較の根拠に使える |
要注意は「開発費 一式 400万円」型の見積書です。これは手法以前に根拠が示されていません。少なくとも機能単位・画面単位まで分解された明細を求めてください。分解を渋る会社は、社内でも分解していない可能性があります。
視点2:工程が抜けていないか
安い見積もりが本当に安いとは限りません。多くの場合、値引きではなく工程が入っていないだけです。次の工程が見積書にあるか、指を折って確認してください。
- 要件定義
- 基本設計・詳細設計
- 実装(開発)
- テスト(単体・結合・総合)
- 既存データの移行
- マニュアル作成・操作説明
- リリース作業・本番環境の構築
- 稼働後の初期サポート(不具合対応の期間)
太字にした4つが、抜けていて後から追加費用になりやすい典型です。特にデータ移行は、既存Excelや旧システムの中身次第で工数が跳ねるため、「移行対象のデータ量と形式」を握らないまま見積もった数字は当てになりません。
視点3:「諸経費」「プロジェクト管理費」に何が入っているか
見積書の末尾に置かれがちで、しかし金額の大きい項目です。プロジェクト管理費は全体の2割程度を目安とする解説もありますが、そもそも何を管理費と呼ぶかが会社ごとにバラバラなので、比率だけを見て高い安いを判断するのは危険です。
聞くべきはシンプルに一つ、「この管理費には具体的に誰の何時間が入っていますか」です。進捗管理・定例会議・品質チェックといった実作業が入っているなら妥当ですし、答えが返ってこないなら実質的な値引き余地の可能性があります。
視点4:前提条件と除外事項を先に読む
実務では、ここが最重要です。金額が後から動く原因は、ほぼすべて前提条件欄に書いてあります。
チェックすべき代表例は次のとおりです。
- 画面数・帳票数の上限(「画面10本まで」の11本目から追加費用)
- デザインの修正回数(何回まで無償か)
- 対応ブラウザ・OS・端末(スマホ対応が別料金になっていないか)
- 他システムとの連携(API連携の有無、相手側の仕様調査は誰の負担か)
- 発注側の作業範囲(データ整理・テスト協力・素材提供は自社の仕事になっていないか)
- 見積もりの有効期限
最後の「発注側の作業範囲」は見落とされがちですが、自社の担当者が何十時間も取られるなら、それは見えないコストです。金額だけでなく自社に発生する負荷まで含めて比較してください。
視点5:契約形態と支払条件
同じ金額でも、契約形態でリスクの持ち方が変わります。
- 請負契約 — 成果物の完成に責任を負う形態。仕様が固まっているフェーズ向き。
- 準委任契約 — 専門家として作業を遂行することに対して報酬を払う形態。要件定義や、変更が前提のアジャイル開発で使われます。
IPA(情報処理推進機構)が公開する「情報システム・モデル取引・契約書」では、工程ごとに契約を分ける多段階契約が示されています。開発途中の仕様変更の影響を小さくでき、工程ごとに発注先を変えることもできる考え方です。「要件定義だけ先に準委任で発注し、固まってから開発を請負で発注する」は、発注側にとって現実的な進め方です。
支払条件も忘れずに。着手金の比率、検収の基準、瑕疵(契約不適合)対応の期間——このあたりが空欄の見積書は、そもそも書類として不十分です。
見積書が届いたら聞く5つの質問
長くなったので、そのまま使える形にまとめます。
- 職種別の人月単価と、それぞれ何人月かを教えてください
- この工数はどう算出しましたか(積み上げ/類推/係数)
- テスト・データ移行・マニュアル作成・リリース作業は含まれていますか
- 管理費・諸経費には具体的に誰のどんな作業が入っていますか
- 追加費用が発生するのはどんなときですか(前提条件と除外事項)
この5問に淀みなく答えられる会社は、社内でプロジェクトを分解できています。逆に答えが曖昧な会社は、着手後に「想定外でした」が出てくる確率が高い、と考えて差し支えありません。
なお、相場観そのものを持たずに1社の見積書だけ見ても判断はできません。当社では作りたいものを入力するとAIが約3分で概算を出すAI見積もりを無料公開しています。他社の見積書の妥当性を測る「ものさし」としての利用も歓迎です。補助金の活用を検討している場合は、デジタル化・AI導入補助金2026の対象範囲も合わせて確認してください。
出典(2026年8月時点)
よくある質問
- システム開発の人月単価の相場はいくらですか?
- 職種によって異なり、初級SEで65〜75万円、PM(プロジェクトマネージャー)で110〜150万円が目安です。合計金額ではなく「単価×工数」に分解して、どの職種が何人月アサインされているかを見てください。
- 見積書の「一式」という表記はどう扱えばいいですか?
- 算出根拠がないサインとして扱ってください。工数の出し方には積み上げ・類推・係数法・FP法の4つがあり、まともな会社ならどれで出したか答えられます。答えられない場合は根拠のない数字です。
- 一番安い見積もりを選んで問題ありませんか?
- 安さの理由が値引きなのか工程の欠落なのかを確認してください。実務ではテスト・データ移行・操作教育が抜けているだけ、というケースが多く、あとから追加費用になります。
- 請負契約と準委任契約はどちらが有利ですか?
- 有利不利ではなく、要件の固まり具合で選びます。完成物が明確なら請負、要件を固めながら進めるなら準委任が向きます。請負は完成責任を負う代わりに見積もりにリスク分が乗る点に注意してください。
- 見積もり金額はあとから変わりますか?
- 変わる条件は前提条件と除外事項の欄に書かれています。ここを読まずに合計金額だけ見ると、あとで「これは範囲外です」と言われます。契約形態とセットで必ず読んでください。
自社の場合、いくら?
作りたいものを入力するだけで、AIが約3分で概算見積もりを作成します。一般的なSIer相場との比較つき、無料・営業からのしつこい連絡はありません。
AIで概算見積もり(無料) →先に費用の目安を知りたい方は用途別の費用相場へ。