「同じ要望を伝えたのに、A社は100万円、B社は300万円だった」
「安いほうを選んでいいのか、高いほうに理由があるのか判断できない」
初めてシステム開発を外部に頼む方から、私たちが最もよくいただくご相談です。
判断の材料がないまま、総額の大小だけで比べてしまうケースは少なくありません。
この記事では、システム開発の見積書の見方を、開発会社の立場から順に説明します。
金額の相場を覚える必要はありません。
見積書の構造と用語の意味がわかれば、手元の見積書が妥当かどうかをご自身で判断できます。
なぜ見積もりの金額にここまで差が出るのかは、動画でも解説しています。
なお、規模別・種類別の金額の目安を知りたい方は、システム開発の費用相場の記事をご覧ください。
この記事では「受け取った見積書をどう読むか」に絞って解説します。
システム開発の見積もりが会社によって3倍も違う理由
見積金額の差は、ほとんどの場合「見積もっている中身の違い」から生まれます。
どちらかが不当に高い、あるいは安いとは限りません。
差が生まれる原因は、主に次の4つです。
| 差が出る原因 | よくある例 | 見積書で確かめる場所 |
|---|---|---|
| 作る範囲の解釈 | 一方はデータ移行やスマホ対応を含み、もう一方は含まない | 前提条件・対象外の記載 |
| 工程の有無 | 安い見積もりにテストや要件定義が入っていない | 工程別の内訳 |
| 単価と体制 | 役割ごとの単価の違い、下請けを重ねる多段構造 | 単価の内訳・実際の開発者 |
| 開発費以外の費用 | サーバー費や保守費を含むかどうか | 諸経費・保守費の記載 |
つまり、総額を並べるだけでは比べられません。
次の章から、見積書を分解して読む方法を順に説明します。
見積書は「工数 × 単価 ＋ 諸経費」に分解して見る
システム開発の見積書は、項目が多く複雑に見えます。
ただし、金額の中身は突き詰めると次の3つしかありません。
- 工数：その開発に何人が何か月かかるか（作業量）
- 単価：携わる人の1か月あたりの費用
- 諸経費：サーバー費用、外部サービスの利用料、交通費など
金額の大部分を占めるのは、工数と単価の掛け算です。
見積書を比べるときは、総額を見る前にこの3つへ分解してください。
分解してみると、片方が必要な作業を見積もりに入れていなかっただけ、というのはよくあることです。
逆に、この3つに分解できない見積書は比べようがありません。
「システム開発一式」とだけ書かれた見積書が問題なのは、高いか安いかを判断する手がかりがないからです。
見積書の「人月」の見方
見積書を読むうえで避けて通れないのが、「人月（にんげつ）」という単位です。
「3人月」「0.5人月」といった表記を目にされたことがあるかもしれません。
1人月＝1人が1か月かけて行う作業量
人月は作業量を表す単位です。
1人月は「1人が1か月かけて行う作業量」を指し、3人月なら1人が3か月かけて行う量になります。
注意したいのは、1人月を何時間とみなすかが会社によって違う点です。
一般的には140〜180時間ほどの幅があります。
人月表記がある見積書では、1人月が何日・何時間を指すのかを確認してください。
この定義が見積書や契約書に書かれている会社は、後から認識がずれにくい会社です。
「3人月」は「3人で1か月」ではない
「3人月」と書かれていると、3人を入れれば1か月で終わると読みたくなります。
実際はそうとは限りません。
システム開発は、人数を増やした分だけ期間が縮む仕事ではないからです。
- 前の工程が終わらないと進めない作業がある
設計が固まる前に作り始めることはできません。 - 人が増えるほど、情報共有の手間が増える
3人なら3人分の打ち合わせと引き継ぎが発生します。 - 途中から加わった人は、経緯を理解する時間が必要
参加した日からすぐ戦力になるわけではありません。
ソフトウェア開発では「遅れているプロジェクトに人を足すと、さらに遅れる」とまで言われます。
納期を縮めたい要望に対して、人数を増やす案だけを出してくる会社には注意が必要です。
現実的な短縮方法は、機能に優先順位をつけて、必要なものから段階的にリリースすることです。
工数と期間は別のもの
人月は作業量であって、期間ではありません。
「6人月・開発期間4か月」なら、平均1.5人が4か月関わるという意味です。
工数と期間の両方が書かれているか、両者の関係に無理がないかを確認しましょう。
期間の目安はシステム開発の期間の目安で解説しています。
見積書の単価の見方｜同じ要望でも会社によって違う理由
単価は、金額差の理由が最も見えにくい部分です。
ここでは金額の相場ではなく、なぜ差が生まれるのかをお伝えします。
この観点があれば、提示された単価をご自身の案件に照らして判断できます。
役割によって単価が違う
システム開発には、次のような役割の人が関わります。
- 業務を聞き取り、システムの仕様を決める人
- 全体の構造を設計する人
- 実際にプログラムを書く人
- 動作を検証する人
- 全体の進行を管理する人
求められる経験も責任の範囲も違うため、単価も変わります。
役割ごとに単価が分かれている見積書は、内訳を正直に開示している見積書です。
全員が同じ単価なら、平均化した数字の可能性があります。
開発の体制によって差が出る
見積書を出した会社が、実際に開発するとは限りません。
受注した会社が別の会社に依頼し、その会社がさらに別の会社に依頼する多段の構造もあります。
階層が深くなるほど、各段階で管理費が上乗せされます。
「実際に開発するのはどなたですか」と聞いてみると、体制が見えてきます。
案件の性質によって差が出る
個人情報を大量に扱うシステムや、止まると業務が完全に止まるシステムは、設計と検証の手間が増えます。
特殊な知識が必要な領域では、対応できる人が限られる分だけ単価が上がる傾向もあります。
単価を判断するときは、金額そのものより「その単価で、どんな人が、何をするのか」の説明があるかを見てください。
説明できる会社は、体制を把握したうえで見積もっています。
見積書の内訳（工程）の見方｜抜けやすい工程を探す
見積書に並ぶ工程名が、それぞれ何をする時間なのかを整理します。
工程の意味がわかると、見積書から「抜けているもの」が見えるようになります。
| 工程 | 何をするか | 抜けていると起きること |
|---|---|---|
| 要件定義 | 業務を聞き取り、システムで解決する範囲を決める | 完成したものが想定と違う |
| 設計 | 画面の構成やデータの持たせ方、他システムとのつなぎ方を決める | 作り直しが増え、追加費用になる |
| 開発（実装） | 実際にプログラムを作る | （ここが抜けることはまずない） |
| テスト | 正しく動くか、想定外の操作や大量データで問題が出ないか確かめる | 納品後に不具合対応が続く |
| 導入・教育 | データ移行、操作説明、マニュアル作成 | 現場で使われず定着しない |
| 保守・運用 | 納品後の不具合対応、法改正への対応、サーバー管理 | 契約後に別費用として発覚する |
要件定義が独立した項目になっているか
要件定義は、発注する側にとって最も重要なのに、最も軽く扱われやすい工程です。
ここが曖昧なまま進むと、完成後に「思っていたものと違う」となります。
見積書に独立した項目としてあるかを、最初に確認しましょう。
要件の整理の仕方は要件定義は3層で考えるで解説しています。
テスト工程があるか
見積書でまず探していただきたいのが、テスト工程です。
テストは「やらなくても、とりあえず動くものは完成する」工程です。
省けば見積金額は下がりますが、その分の不具合対応が納品後に発生します。
開発（実装）は、見積書全体に占める割合が思ったほど大きくありません。
前後の工程の合計のほうが大きくなることも珍しくないため、極端に安い見積書は「どの工程が省かれた結果の金額か」を確かめてください。
見積書で確認すべき7つのチェックポイント
ここまでの内容を踏まえ、手元の見積書で確認したい点を7つにまとめます。
どれも見積書を見るだけで、その場で確認できるものです。
1. 「一式」でまとめられていないか
「システム開発一式」「その他一式」が多い見積書は、内訳が読み取れません。
後から「それは一式に含まれていません」という食い違いの原因にもなります。
工程ごとの内訳を出してもらえるか依頼してみてください。
2. 前提条件が書かれているか
見積書には、金額を出した前提が書かれているはずです。
- 想定している利用者数、データ量
- 発注側で用意するもの（画像、原稿、既存データなど）
- 打ち合わせの回数や方法
- 修正・変更に対応する回数の上限
前提条件が書かれていない見積書は、後から金額が変わる余地が大きい見積書です。
3. 対象外の作業が書かれているか
含まれるものだけでなく、含まれないものが書かれているかを見てください。
「既存データの移行は含みません」「スマートフォン表示は含みません」といった記載です。
これを書く会社は、追加請求になりうる箇所を先に伝えている会社です。
4. テスト工程が独立しているか
前の章で述べたとおりです。
項目がない場合は「テストはどの工程に含まれていますか」と聞けば、その会社の考え方がわかります。
5. 検収条件が書かれているか
検収とは、納品物を確認して「これで完成」と認める手続きです。
ここが曖昧だと「まだ直してほしい」「もう完成している」という食い違いが起きます。
何をもって完成とするか、確認期間は何日か、期間内に指摘がない場合の扱いを確認しましょう。
6. 保守費用が別に示されているか
保守費は開発費とは別に、月額や年額で見積もるのが一般的です。
金額だけでなく、不具合対応のみか、機能の変更も含むか、障害時の対応時間はどうかまで確認します。
保守費の考え方はシステム保守費用の削減方法で詳しく解説しています。
7. 有効期限と契約形態が書かれているか
見積書には通常、有効期限があります。
社内の検討に時間がかかりそうなら、期限を過ぎたときの扱いも先に確認しておきましょう。
請負契約か準委任契約かによって、仕様変更時の費用の考え方も変わります。
違いは準委任契約と請負契約の違いをご覧ください。
良い見積書と注意が必要な見積書の比較
| 確認項目 | 良い見積書 | 注意が必要な見積書 |
|---|---|---|
| 内訳 | 工程ごとに分かれている | 「一式」でまとまっている |
| 前提条件 | 利用規模・提供物・修正回数が明記 | 記載がない |
| 対象範囲 | 含まれないものも書かれている | 含まれるものしか書かれていない |
| テスト | 独立した項目としてある | 項目が見当たらない |
| 検収 | 完成の基準と確認期間が明記 | 記載がない |
| 保守 | 開発費と分けて金額と内容を提示 | 触れられていない |
| 有効期限・契約形態 | 明記されている | 記載がない |
すべてを満たす見積書ばかりではありません。
ただ、当てはまらない項目が多いほど、後から金額や範囲が動く可能性が高いとお考えください。
相見積もりで見積書を比較する手順
複数の会社から見積もりを取るときは、比べ方を先に決めておくと判断が速くなります。
相見積もりで大切なのは、全社に同じ条件で依頼することです。
条件がそろっていなければ、金額の差が「中身の差」なのか「前提の差」なのか見分けられません。
- 依頼内容を文書にまとめる
目的、必要な機能、利用者数、希望の時期と予算感を1枚にまとめます。書き方は中小企業向けRFPの書き方が参考になります。 - 同じ文書を全社に渡す
口頭の説明だけだと、会社ごとに受け取り方が変わります。 - 届いた見積書を「工数 × 単価 ＋ 諸経費」で並べる
総額ではなく、どこで差がついているかを表にします。 - 差の理由を各社に質問する
下の質問例を使い、回答のわかりやすさも比べます。
| 聞く相手 | 質問の例 |
|---|---|
| 安い会社 | 「なぜこの金額でできるのですか」「テストやデータ移行は含まれていますか」 |
| 高い会社 | 「どの工程に費用がかかっていますか」「削るとしたらどこですか」 |
| 全社共通 | 「1人月は何時間ですか」「実際に開発するのはどなたですか」「対象外の作業は何ですか」 |
質問への答え方そのものが、会社を見極める材料になります。
根拠を把握している会社は、内訳を具体的に説明できます。
システム開発の見積書に関するよくある質問
Q. 一番安い見積書を選んでも大丈夫ですか？
A. 金額だけで決めるのはおすすめしません。
安い理由が「工程の省略」や「対象範囲の狭さ」なら、省いた作業は納品後に追加費用として戻ってきます。
まず7つのチェックポイントで、他社と同じ範囲を見積もっているかを確かめてください。
Q. 「一式」と書かれた見積書は避けるべきですか？
A. 一式表記そのものが悪いわけではありません。
問題は、何が含まれるかが見えなくなることです。
工程別の内訳と対象外の作業を説明してもらい、納得できれば問題ありません。
Q. 見積もりは何社から取ればよいですか？
A. 比較のためには2〜3社が目安です。
社数を増やすほど説明と比較の手間が増えるため、同じ依頼文書を渡せる範囲にとどめるのが現実的です。
Q. 見積もりを取ったあとで金額が上がることはありますか？
A. 前提条件が変わったときや、対象外の作業を追加したときに上がります。
前提条件と対象外の作業が見積書に書かれていれば、どんなときに上がるかを事前に把握できます。
まとめ｜見積書は構造がわかれば判断できる
システム開発の見積書は、次の順番で読むと判断しやすくなります。
- 金額を「工数 × 単価 ＋ 諸経費」に分解する
- 1人月が何時間かを確認する
- 単価について「どんな人が何をするのか」の説明を求める
- 工程の内訳を見て、抜けている工程を探す
- 7つのチェックポイントで前提と範囲を確かめる
金額の相場を知らなくても、見積書の構造がわかれば妥当性は判断できます。
自社のケースがどの価格帯に入るかを先に知りたい方は、AI料金シミュレーターで概算を出せます（登録不要）。
みんなシステムズでは、内訳をご理解いただいたうえでご判断いただけるよう、工程別の見積書をお出ししています。
他社から受け取った見積書の見方がわからない、という段階のご相談も歓迎しています。
「まだ発注するかも決まっていない」という状態でも、お気軽にお声がけください。
