システム開発の見積もりは、受け取ってから困ることが多い書類です。金額が妥当なのか、なぜ会社によって 3 倍も開くのか、どこまで交渉できるのか。この記事は、発注担当者が見積もりについて判断するために必要なことを 1 本にまとめたものです。
必要な章だけ拾って読めるように構成しています。まず全体像を掴みたい方は「1. 相場」から、既に見積もりを受け取っている方は「2. 見積書の読み方」から読んでください。
1. 相場 — 見積もりは「工数 × 単価 + 諸経費」で決まる
システム開発の見積もりは、機能ごとの定価があるわけではありません。必要な作業量 (工数) に、担当者の単価を掛け、そこへ諸経費を乗せるという構造で決まります。
「1 人月」とは、エンジニア 1 人が 1 か月フルタイムで作業したときの作業量です。「3 人月」なら「1 人で 3 か月」または「3 人で 1 か月」で終わる想定量を指します。暦の 1 か月ではなく、平日 20 日・1 日 8 時間を前提とした概念です。
| 単位 | 意味 | 目安 |
|---|---|---|
| 1 人時 (MH) | 1 人が 1 時間作業した量 | 1 時間 |
| 1 人日 (MD) | 1 人が 1 営業日作業した量 | 約 8 時間 |
| 1 人月 (MM) | 1 人が 1 か月作業した量 | 約 20 営業日・160 時間 |
役割別の人月単価
単価は担当者の役割と経験で変わります。同じ「Web システム開発」でも、担当者の構成次第で総額が 1.5〜2 倍変わるのはこのためです。
| 役割 | 人月単価の目安 |
|---|---|
| ジュニアエンジニア (実務 2〜3 年) | 60〜80 万円 |
| 中堅エンジニア (実務 3〜7 年) | 80〜120 万円 |
| シニア / テックリード | 120〜180 万円 |
| PM / PL | 100〜160 万円 |
| UI / UX デザイナー | 80〜130 万円 |
| オフショア (東南アジア) | 30〜60 万円 |
見積もりの末尾には、一般管理費やプロジェクト管理費として工数費の 10〜20% 程度が乗るのが一般的です。この項目自体は不当なものではなく、進行管理や品質管理にかかる実費です。
相場を知る意味
相場感がないまま見積もりを受け取ると、「A 社は 300 万円、B 社は 900 万円」と 3 倍以上開いたときに判断ができません。相場は値切るための材料ではなく、桁違いの見積もりを見抜くための物差しとして使ってください。
2. 見積書の読み方 — 金額ではなく「金額の根拠」を読む
見積書で最初に見るべきは総額ではありません。その金額がどう組み立てられているかです。
見積書に含まれる構成要素
一般的な開発見積書は、次の要素で構成されます。
- 作業項目 (要件定義・設計・実装・テスト・移行・運用引き渡し)
- 各項目の工数 (人月または人日)
- 役割別の単価
- 諸経費 (一般管理費・プロジェクト管理費)
- 前提条件
- 有効期限
- 支払い条件
このうち最も重要なのは「前提条件」欄です。金額は前提条件の上に成り立っているため、ここを読まずに総額だけ比較しても意味がありません。
前提条件で必ず確認すること
- 想定しているユーザー数・データ量
- 対応するブラウザ・OS の範囲
- テストの範囲 (どこまでを開発会社が担保するか)
- 発注側が用意するもの (素材・アカウント・環境)
- 意思決定にかかる日数の想定
最後の項目は見落とされがちです。「1 営業日で返す」前提で組まれた見積もりに対して、実際は稟議や役員確認で 1 週間かかる場合、その待ち時間は工数として跳ね返ります。
危険信号
次のような見積書は、後から追加費用が発生する可能性が高いと考えてください。
- 総額しか書かれておらず、工数と単価の内訳がない
- 「一式」という表記が多用されている
- テスト工程の記載がない、または極端に薄い
- 前提条件欄が空欄、または一般論しか書かれていない
- 運用引き渡しやドキュメントの扱いが書かれていない
3. なぜ会社によって数倍違うのか
「同じ要件で相見積を取ったのに、A 社は 300 万円、B 社は 900 万円、C 社は 1,500 万円だった」という相談は珍しくありません。3 倍以上の差を前にすると「どこかが吹っかけている」と考えたくなりますが、多くの場合はどちらも正しいというのが実情です。
差が生まれる要因は 4 つあります。
要因 1: 単価の差
エンジニアの人月単価は、会社の体制・所在地・保有スキルで大きく変わります。自社の正社員だけで組む会社、協力会社を使う会社、オフショアを組み合わせる会社では、同じ工数でも金額が変わります。
要因 2: 想定スコープの差
「同じ要件」を渡しても、各社が想定する作業範囲は揃いません。たとえば「会員登録機能」と書いてあるだけでは、メール認証の有無、退会処理、管理画面での会員管理まで含むかどうかが会社ごとに異なります。
要因 3: 品質水準の差
自動テストのカバレッジ目標を 80% に置く会社と、手動テストで最低限確認する会社では、テスト工数が 2〜3 倍違います。一般的な受託開発では、テスト工程は開発工数の 30〜50% を占めるため、ここの前提差が総額に直結します。
要因 4: 積算方法の差
「経験ベースでざっくり」出す会社と、作業を細かく分解して一項目ずつ積む会社では、同じ機能でも 1.3〜1.8 倍の差が出ることがあります。
開発会社のタイプによる傾向
| タイプ | 単価傾向 | 特徴 |
|---|---|---|
| 大手 SIer | 高 | 体制が厚く、大規模・高信頼性に強い |
| 中堅システム開発会社 | 中 | 業務システムの実績が豊富 |
| Web 系開発会社 | 中 | モダンな技術、スピード重視 |
| オフショア活用型 | 低 | 単価は安いが、仕様伝達の負荷が発注側に寄る |
| フリーランス / 小規模 | 低 | 小回りが利くが、体制リスクがある |
安い会社が悪い、高い会社が良い、という話ではありません。 案件の性質と、自社が許容できるリスクで選ぶものです。
4. 見積もりが高い / 安い要因と、安すぎる見積もりの見分け方
金額を左右する 5 要因
- 要件の明確さ。曖昧なほどリスク分が積まれます
- 非機能要件。性能・可用性・セキュリティの水準で決まります (第 7 章で詳述)
- デザインの作り込み。UI 工数は 2〜3 倍の差が出やすい領域です
- 外部連携の数。連携先が増えるほど検証工数が増えます
- 意思決定のスピード。確認待ちが長いほど期間が延び、費用が増えます
このうち 1・3・5 は発注側でコントロールできます。要件を具体的に書く、デザインを標準化する、社内の決裁ルートを事前に整える。この 3 つだけで見積もりは動きます。
安すぎる見積もりの構造
複数社から見積もりを取ったとき、1 社だけ他社の半分以下を提示してくることがあります。安さ自体は問題ではありませんが、その理由が説明できるかを確認してください。
危険なのは、次のスコープが抜けているケースです。
- テスト工程 (開発工数の 30〜50% を占める)
- 非機能要件への対応
- ドキュメントの作成
- 運用引き渡しと保守の初期対応
- データ移行
これらが抜けたまま契約すると、総額が 1.5〜2 倍に膨らむことは珍しくありません。「小さな仕様変更」でも 1 件あたり数十万円が積み上がり、5〜10 件たまると初期見積もりを超える追加請求になります。
年間保守費が開発費の 30% を超えるような提示になっている場合も、初期の安さを保守で回収する設計になっている可能性があります。一般的な保守費の目安は年間で開発費の 15〜20% です。
5. 概算見積と本見積 — 精度が違う
初期相談で受け取った「概算 300 万円」と、後日出てきた「本見積 620 万円」。この 2 つは矛盾していません。そもそも精度が違う書類だからです。
| 種類 | 出てくる時点 | 精度 | 用途 |
|---|---|---|---|
| 概算見積 | 相談〜初回ヒアリング後 | ±30〜50% | 予算感の確認、社内の企画通し |
| 本見積 | 要件定義完了後 | ±10〜15% | 契約金額の根拠、正式な稟議 |
| 確定見積 | 契約締結時・着手直前 | ±5% 以内 | 実際の契約金額 |
概算が単一の数字で示されていても、実際には ±30〜50% のレンジを内包していると考えるのが妥当です。本来は「300〜500 万円」のように幅で提示されるべきものです。
概算で意思決定する罠
最も危険なのは、概算の数字をそのまま稟議に通してしまうことです。要件が固まった段階で本見積が上振れし、稟議のやり直しに追い込まれます。
対策は 2 つあります。
- 稟議上限を、概算の中央値ではなく上限値 + 10〜15% で通しておく
- 初期ヒアリングの時点で情報を厚く渡し、レンジ自体を絞る
後者は効果が大きく、±50% だったレンジが ±20% 程度まで絞れることも珍しくありません。何を渡すべきかは第 10 章で扱います。
6. バッファと予備費 — 「その他」の中身
見積もりの末尾にある「予備費」「バッファ」「その他」。工数費の 10〜20% を占めることもあり、削れないかと気になる項目です。
結論から言うと、バッファは削るべきものではありません。開発には、着手してみないと分からない部分が必ずあります。バッファがない見積もりは、原価ぎりぎりで組んでいるか、後の追加請求を前提にしているかのどちらかです。
妥当なバッファ率
| 案件タイプ | バッファ率 | 理由 |
|---|---|---|
| 要件が固まった小規模改修 | 5〜10% | 影響範囲が読み切れる |
| 要件定義済みの新規開発 | 10〜15% | 一般的な Web システム |
| RFP ベースの中〜大規模開発 | 15〜20% | 前提未確定の項目が残る |
| 新技術・PoC 要素あり | 20〜30% | AI・データ基盤・新規プロトコル |
| リプレイス案件 | 20〜30% | 既存仕様の掘り起こしコスト |
10% 未満は過小、30% 超は過大のサインです。前者は追加請求のリスク、後者は情報不足で会社側がリスクを高く見積もっている可能性を示します。30% を超えている場合は、値引きを求めるより「どの部分が読めていないのか」を聞き、その不確実性を潰す情報を渡すほうが、結果的に金額が下がります。
7. 非機能要件 — 指定 1 つで工数が数十%変わる
見積もりの差を生む要因のうち、発注側が最も無自覚なまま金額を動かしているのが非機能要件です。同じ会員登録機能でも、可用性 99.0% と 99.99% では設計も冗長化構成も別物になります。
| 分類 | 影響レンジ | 主な内容 |
|---|---|---|
| 可用性 | +5〜30% | 冗長化構成、24 時間 365 日監視 |
| 性能・拡張性 | +10〜40% | 同時接続数の想定、負荷試験、キャッシュ設計 |
| 運用・保守性 | +5〜20% | 監視ダッシュボード、ジョブ管理、運用手順書 |
| 移行性 | +5〜25% | 既存データ移行、並行稼働、切戻し設計 |
| セキュリティ | +10〜50% | 脆弱性診断、監査ログ、暗号化、鍵管理、規格準拠 |
| システム環境 | +0〜15% | オンプレ制約、業界固有の設置要件 |
具体例を挙げます。開発費 1,500 万円の中規模 Web システムで、可用性を「99.9% (月 43 分の停止許容)」から「99.99% (月 4.3 分)」へ引き上げるだけで、200〜400 万円の上振れが発生します。
過剰スペックを避ける
「念のため 10 倍」で指定すると、そのまま 10 倍の設計になります。BtoC の Web サービスでも、キャンペーンを除けば登録ユーザーの 5〜10% が同時利用というのが現実的な上限です。
一方で、設計の初期に決めておくかどうかで、同じゴールに到達する工数が 2〜3 倍変わります。後から追加すると作り直しになる領域なので、「決めない」のではなく「現実的な水準を早期に決める」のが正解です。
8. 契約形態 — 見積もりが何を保証しているか
契約形態は、その見積もりが何を保証しているかを決める土台です。
| 形態 | 責任の所在 | 見積もりの性質 |
|---|---|---|
| 請負 | 成果物の完成に責任を負う | リスク分が上乗せされる |
| 準委任 | 作業の遂行に責任を負う | 実際の稼働に応じた費用 |
| SES | 人員の提供 | 稼働時間に対する支払い |
請負は完成責任を開発会社が負うぶん、バッファが厚めに積まれます。準委任は柔軟に進められる反面、発注側が仕様の判断を担う必要があります。
判断の軸は 3 つです。
- 仕様が固まっているか。固まっていれば請負、動くなら準委任が向きます
- 発注側が判断に関与できるか。関与できないなら請負を選びます
- 途中で方向を変える可能性があるか。あるなら準委任が噛み合います
不確実性の高い初期フェーズは準委任、仕様が安定してから請負へ切り替える、という組み合わせも現実的です。
9. 相見積 — 値切るためではなく妥当性を判断するため
相見積の目的は値引きではありません。1 社だけでは、その金額が高いのか安いのか判断する物差しがないからです。
| 社数 | 向いている場面 | 注意点 |
|---|---|---|
| 1 社 | 既に信頼関係があり判断できるとき | 相場との照合ができない |
| 2 社 | 予算感の当たりを付けたいとき | 中央値が取れず判断が難しい |
| 3〜4 社 | 発注先を本格的に選定するとき | 各社対応の工数を確保する |
| 5 社以上 | RFP 形式で公募するとき | 一次選考の仕組みが必要 |
現実的なレンジは 2〜4 社です。2 社だと片方が極端な場合に検知できません。3 社以上あれば金額と提案内容の分布が見えます。
揃えるべきこと
比較を成立させるには、各社に同じ情報を、同じ形式で渡す必要があります。口頭で説明する内容が会社ごとに違うと、そもそも比較になりません。渡す情報は第 10 章、書式は第 11 章で扱います。
避けるべきこと
- 他社の見積金額をそのまま伝えて値引きを迫る
- 発注する気がない会社から数合わせで取る
- 各社に違う条件を伝える
いずれも、その後の関係と提案の質を落とします。
10. 依頼の準備 — 見積もりの質は依頼前に決まる
見積もりのブレは、多くの場合発注側の情報の曖昧さに起因します。準備を整えるだけでレンジが縮み、結果として金額も下がります。
発注前に決めておく 5 項目
- 解きたい業務課題 (機能ではなく課題で書く)
- 使う人と規模 (誰が何人、どのくらいの頻度で使うか)
- 予算のレンジ
- 希望する時期と、その理由
- 社内で誰が決裁するか
予算は伝えたほうが安くなります。 伝えないと、開発会社はリスクを見込んで高めに出すか、逆に受注のために薄く出して後から追加請求する構造になりやすいためです。
用意すると精度が上がる 3 つの資料
- 業務フロー図。現状の業務の流れと、システム化したい範囲を示します
- 画面遷移案。手書きで構いません。どんな画面が何枚必要かを示します
- 既存の資料。現在使っているエクセルや帳票の実物が有効です
特に業務フロー図と画面遷移案は効果が大きく、これがあるだけで各社の想定スコープが揃います。完璧である必要はありません。間違っていても構わないので、たたき台があることが重要です。
11. RFP — 複数社に同じ条件で依頼する
相見積を取るなら、RFP (提案依頼書) の形で条件を揃えるのが確実です。RFP に盛り込む項目は次のとおりです。
- 背景と目的
- 現状の課題
- システム化の範囲 (やること・やらないこと)
- 機能要件
- 非機能要件 (第 7 章の 6 分類)
- 前提条件と制約
- 予算のレンジ
- スケジュール
- 提案してほしい内容と形式
- 選定の基準とスケジュール
「やらないこと」を明記するのが要点です。範囲の下限が示されていないと、各社が独自に想定して見積もりがばらつきます。
RFP を作るほどではない規模なら、依頼メールに次を書けば足ります。目的・課題・使う人と規模・希望時期・予算レンジ・添付資料の一覧・回答期限。この 7 項目があれば、開発会社は見積もりを作れます。
12. 交渉 — 金額ではなくスコープを動かす
見積もりの交渉で最も大事なのは、何を動かすかの選択です。
単純に「もう少し何とかなりませんか」で下がる金額は、経験上総額の 5〜10% が限界です。これは開発会社の利益を削る交渉なので、関係も悪くなります。
一方、スコープを動かせば 30〜50% 圧縮できるケースは珍しくありません。
効く打ち手
- 機能を削る / 後回しにする。初期リリースの機能を半分に絞ります
- デザインを標準化する。UI 工数は 2〜3 倍の差が出やすい領域です
- 対応範囲を絞る。両 OS 対応をやめるだけで工数が 30〜40% 下がります
- 期間を延ばす。繁忙期を避けられ、体制の組み方に余裕が生まれます
最も早い方法
実務上、予算を伝えて「この範囲で何ができるか」を設計してもらうのが最短です。金額を下げる交渉ではなく、予算に合う構成を一緒に作る話に切り替わるため、双方に無理がありません。
13. 仕様変更と追加見積
開発が始まると、仕様変更や追加要望は必ず発生します。問題は変更そのものではなく、変更が見積もりにどう反映されるかが事前に決まっていないことです。
「小さな変更なのに高い」理由
画面 1 つの変更でも、影響範囲の調査、設計の修正、実装、テスト、既に通っていた箇所の再確認 (回帰テスト) が発生します。特に回帰テストの工数は見えにくく、「表示を変えるだけ」に見える変更が数十万円になるのはこのためです。
妥当性を確認する
変更見積を受け取ったら、次を確認してください。
- 影響範囲がどこまでと想定されているか
- 回帰テストの範囲
- その変更を後回しにした場合の費用差
3 つ目が重要です。まとめて後のフェーズで対応したほうが安い変更もあります。
変更を安定させる
変更が頻発する案件では、変更管理のルールを契約時に決めておくのが有効です。何をもって変更とするか、いくらまでは追加費用なしで対応するか、判断は誰がするか。この 3 点が決まっていれば、都度の交渉が不要になります。
まとめ
システム開発の見積もりは、金額の大小ではなく前提条件を読む書類です。
- 見積もりは「工数 × 単価 + 諸経費」で決まる。単価より前提の差で総額が数倍動く
- 会社ごとに 3 倍開くのは吹っかけではなく、単価・スコープ想定・品質水準・積算方法の差
- 概算は ±30〜50%、本見積は ±10〜15%。概算をそのまま稟議に通さない
- バッファ 10〜30% は削るべきものではない。過小はむしろ危険信号
- 非機能要件の指定 1 つで工数が数十%変わる。過剰スペックを避ける
- 値引きで下がるのは 5〜10%。30〜50% 下げたいならスコープを動かす
- 見積もりの精度は、依頼前に渡す情報でほぼ決まる
FIXIT は AI 駆動開発のクリエイティブスタジオとして、見積もりの前提を明示したうえでご提案しています。要件が固まりきっていない段階でも、業務課題と予算のレンジを共有いただければ、実現できる範囲を一緒に設計します。お問い合わせ からお気軽にご相談ください。
関連リソース
- AI 駆動開発の費用と期間: AI 駆動開発の費用・期間はいくら?料金相場と見積もりの内訳
- 発注先の見極め: AI 受託開発の会社を選ぶときの 5 つのチェックポイント
- 契約前の実務確認: AI 開発の発注前に確認する 10 項目
- 業務システムの発注先比較: 業務システム 受託開発の比較・選び方