開発の見積書の見方｜項目・内訳・チェックすべきポイント

見積書は「金額」ではなく「金額の根拠」を読む

「開発会社から見積書が届いたが、金額の妥当性を判断する材料がない」——発注担当者からよく聞く悩みです。見積書は書式が会社ごとに大きく異なり、同じ機能を作る前提でも、載っている項目の粒度や書き方はまちまちです。金額の大小だけを見て判断すると、後工程で「これは別料金です」「その範囲は含んでいません」というやりとりが繰り返され、結果として当初想定を大きく超えることになりがちです。

この記事では、非エンジニアの発注担当者が開発の見積書を受け取った際に、どこをどの順番で読み、何をチェックすべきかを整理します。金額そのものではなく「金額の根拠がどこまで書かれているか」を読むための実務チェックリストとして活用してください。

FIXIT

届いた見積書、金額を眺めるだけで頭が真っ白になっちゃった。

Shiori

最初に読むべきは金額ではなく、その根拠がどこに書いてあるかです。

FIXIT

根拠って、単価と工数のこと？

Shiori

単価・工数・前提条件・成果物・体制の 5 点が言語化されているかを見ます。

FIXIT

「開発一式」で 8,000,000 円って書いてあるんだけど……

Shiori

それは危険信号です。少なくとも工程レベル、可能なら機能レベルまで分解してもらってください。

1. 開発見積書に含まれる 7 つの構成要素

会社ごとに書式は違えど、まっとうな開発見積書には次の 7 要素がおおむね含まれています。まずはこの型を頭に入れて、届いた見積書に「何が入っていて、何が抜けているか」をチェックしてください。

構成要素	記載内容	見るポイント
表紙 (かがみ)	宛先、発行日、案件名、見積総額	案件名が自社の呼び方と一致しているか
作業内訳	工程・機能単位のタスク一覧	粒度が細かいか、抜けはないか
工数見積	各タスクの人日 / 人月	合算値だけでなく内訳が開示されているか
金額	単価 × 工数、諸経費、消費税	単価と工数が分離して書かれているか
前提条件	見積の根拠となる想定	自社の想定と食い違っていないか
有効期限	見積の有効期間	通常 1〜3 か月、延ばす場合は要再見積
支払条件	支払時期・分割条件	検収前後の支払比率、着手金の有無

このうち、金額欄と表紙だけ見て判断する方が多いのですが、実務上もっとも重要なのは「作業内訳」「前提条件」「支払条件」の 3 つです。ここに読み解きの時間を割いてください。

2. 作業内訳・単価・諸経費の読み解き方

見積書の中身で最初にチェックすべきは「作業内訳の粒度」です。粒度が細かいほど、発注側が範囲を確認しやすく、後の追加請求リスクが下がります。

作業内訳の粒度

「Web システム開発一式」と 1 行だけ書かれた見積書と、要件定義・基本設計・詳細設計・実装 (機能ごと)・単体テスト・結合テスト・受入支援・リリース作業まで工程別に分解された見積書では、後者のほうが圧倒的に安心です。

• NG 例: 「システム開発一式 8,000,000 円」
• OK 例: 「要件定義 40 万円 / 基本設計 80 万円 / ユーザー管理機能実装 60 万円 / 予約管理機能実装 120 万円 … (以下同様)」

「一式」表記が多い見積書は、後から「その作業は含まれていません」と言われる余地が大きくなります。少なくとも工程レベル、可能なら機能レベルまで分解されているかを確認してください。

単価の妥当性

金額欄では、単価と工数が分離して書かれているかを見ます。「合計 8,000,000 円」だけでは、なぜその金額なのかが検証できません。「シニアエンジニア 3 人月 × 130 万円 = 390 万円」のように、役割・工数・単価が並んでいる形が理想です。

単価の相場感は システム開発の見積相場 や 工数・人月・単価の意味 で解説しています。中堅エンジニアで人月 80〜120 万円、シニアで 120〜180 万円が国内の一般的なレンジです。ここから大きく外れる単価があれば、その理由 (体制、稼働率、リスクの取り方) を質問してよい水準です。

諸経費の割合

一般管理費・プロジェクト管理費として、工数費の 10〜20% が上乗せされるのが一般的です。これが 30% を超える、あるいは逆に 0% と書かれている場合は要注意です。前者は根拠の説明を求め、後者は「本当に管理工数が計上されていないのか、それとも他の項目に潜んでいるのか」を確認してください。

「予備費」「バッファ」「その他」といった名目の扱いは、予備費・バッファの読み方 で詳しく整理しています。

3. 「前提条件」欄で必ず確認すべき 5 項目

見積書の後半、あるいは別紙で「前提条件」「見積前提」という欄があるはずです。ここは金額欄より重要と言っても過言ではありません。前提が崩れれば、金額の根拠がまるごと崩れるからです。次の 5 項目は最低限すべてチェックしてください。

(1) 要件範囲 (スコープ)

「どの機能を含み、どの機能を含まないか」が明記されているかを確認します。「管理画面は含む / 含まない」「モバイル対応は含む / 含まない」など、境界線が言語化されていない見積書は危険です。

(2) 非機能要件

想定同時ユーザー数、レスポンスタイム、稼働率、セキュリティ要件 (脆弱性診断の有無・多要素認証など) が書かれているかを確認します。ここが空欄だと「性能要件は別途協議」となり、後から数百万円単位の追加が発生します。

(3) 成果物 (納品物)

ソースコードだけなのか、設計書・テスト仕様書・運用手順書まで含むのかを確認します。特に発注側で保守・追加開発を別会社に依頼する可能性がある場合、設計ドキュメントの有無は死活問題です。

(4) 体制 (誰が何人月)

PM 1 名、エンジニア 2 名、デザイナー 0.5 名など、稼働メンバー構成が書かれているかを見ます。総額しか書かれていない見積は、後から「担当者が変わる」「オフショアメンバーに差し替える」といった変更が起きても、発注側から異議を唱えにくくなります。

(5) 期間・スケジュール前提

「要件定義開始からリリースまで 6 か月」「発注側の意思決定リードタイムは 3 営業日以内を前提」など、時間軸の前提を確認します。発注側の返答が遅れると期間が延びる、その結果として費用が積み増しになる、という条件が入っているケースは珍しくありません。

これらの前提条件は、そもそも発注前の準備段階で自社側で言語化しておくのが理想です。詳しくは 発注前に整理すべきこと を参照してください。

4. 危険信号 (レッドフラグ) チェックリスト

次のいずれかに当てはまる見積書は、そのまま発注に進む前に必ず追加の質問と説明を求めてください。

• 総額が「開発一式」の 1 行だけで、内訳がない
• 単価が非開示 (工数と金額の関係が読めない)
• 期間・スケジュールの記載がまったくない
• 成果物 (納品物) の定義がない
• テスト工程の工数が 0、または極端に少ない (全体の 10% 未満)
• 「前提条件」欄がない、または「別途協議」だらけ
• 支払条件が「全額前払い」または「着手時 100%」
• 見積の有効期限が記載されていない
• 諸経費・管理費が総額の 30% 超、または内訳不明
• 消費税の記載がない、税抜 / 税込が不明

特に「テスト工数がゼロ」は多くの発注者が見落とす項目です。実装後にテストせずリリースする開発はほぼ存在しないので、テスト工数が計上されていない見積書は「後から別料金で請求される」か「そもそも品質を担保する意思がない」かのどちらかです。

契約形態によって、見積書に求められる書き方も変わります。特に 請負契約と準委任契約の違い は、金額の意味そのものが変わるため事前に理解しておく価値があります。

5. 複数社の見積書を横並びで比較するテンプレ

相見積を取ったとき、各社の見積書を並べても書式が違いすぎて比較できない、というのはよくある悩みです。そのときは自社側で比較表を作り直します。次の項目を列に立て、各社の情報を埋め直すだけで、桁違いに読みやすくなります。

比較項目	A 社	B 社	C 社
想定スコープ (機能数)	20 機能	18 機能	25 機能
想定工数 (人月)	12 人月	10 人月	15 人月
想定体制 (人数 × 役割)	PM1+Eng2	PM1+Eng2	PM1+Eng3
平均人月単価	100 万円	120 万円	90 万円
テスト工数比率	20%	25%	10%
諸経費比率	15%	10%	20%
期間	6 か月	5 か月	7 か月
成果物にドキュメント含む	含む	含まない	含む
想定リスクバッファ	15%	明記なし	20%

同じ金額でも、スコープが違えば意味は違います。「B 社が一番安い」ではなく、「B 社は機能数が少なくドキュメントも含まれないので、単純比較できない」と結論づけるための道具として使います。

6. 見積書を受け取った後に開発会社へ聞くべき質問リスト

見積書を受け取った直後の 1〜2 週間は、質問できる貴重な期間です。次の質問は最低限、書面で回答をもらってください。回答内容はそのまま契約時の添付資料になります。

• 見積に含まれない作業を具体的に 3 つ挙げてください
• 想定している開発チームの体制 (役割と人数) を教えてください
• 主担当者の稼働割合 (何 % コミット) を教えてください
• テスト工程はどの範囲 (単体 / 結合 / 受入支援) を含みますか
• リリース後の初期不具合対応 (無償瑕疵担保) の期間と範囲は
• 発注側で用意する必要のあるもの (環境、データ、素材) を列挙してください
• 見積前提が崩れた場合の再見積のルールはどうなりますか
• 進捗・工数の可視化はどの頻度・どの粒度で共有されますか

これらの質問への回答が明快な会社は、その後のプロジェクトでも認識ズレが起きにくい傾向があります。回答が曖昧なまま契約に進むと、実装フェーズで「言った / 言わない」の議論が発生しやすくなります。

まとめ

開発見積書は「金額」ではなく「金額の根拠」を読む書類です。作業内訳・単価・前提条件・成果物・体制・期間の 6 点が言語化されているかを基準に、「一式計上」「単価非開示」「テスト工数ゼロ」などのレッドフラグを見逃さないこと。複数社の見積を比較するときは、各社の書式に合わせるのではなく、自社で項目を揃えた比較表を作り直すこと。そして契約前に、書面で追加質問への回答をもらっておくこと。この 3 点を押さえておくと、後工程での揉め事はかなり減らせます。

AI 駆動開発のクリエイティブスタジオである FIXIT では、発注担当者と一緒に届いた見積書のレビューを行い、比較用テンプレートの作成や追加質問リストの整理までご支援しています。「渡された見積書の金額が妥当か判断できない」「複数社の見積を並べたが読み方がわからない」という段階でも構いません。無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。