「システム開発を何社かに相談したら、見積書の金額に大きな差があった」
初めてシステム開発を外部に依頼される方から、私たちが最もよくいただくご相談です。同じ要望を伝えたはずなのに、なぜ会社によって金額が違うのか。安いほうを選んでよいのか、それとも何か理由があるのか。判断する材料がないまま、金額の大小だけで比べるしかない——そんな状態になりがちです。
この記事では、システム開発の見積書をどこから読めばよいのかを、開発会社の立場から順を追って説明します。相場の金額を暗記していただく必要はありません。見積書の構造と用語の意味さえ分かれば、手元の見積書が妥当かどうかをご自身で判断できるようになります。
見積書は「工数 × 単価 ＋ 諸経費」に分解して見る
システム開発の見積書は、一見すると項目が多く複雑に見えます。しかし、金額の中身は突き詰めると次の3つしかありません。
- 工数 — その開発に何人が何か月かかるか（作業量）
- 単価 — 携わる人の1か月あたりの費用
- 諸経費 — サーバー費用、外部サービスの利用料、交通費など
金額の大部分を占めるのは工数と単価の掛け算です。見積書を比べるときは、総額を比べる前に、まずこの3つに分解してください。
たとえば2社の見積金額に差があったとき、原因は必ずこのどれかにあります。
- 工数が違う — 作る機能の範囲や、想定している作り込みの深さが違う
- 単価が違う — 携わる人の役割や、開発の体制が違う
- 諸経費が違う — 一方はサーバー費用を含み、もう一方は含んでいない
この3つのどこで差がついているのかが分かれば、「安いから良い」「高いから悪い」という判断から抜け出せます。分解してみたら、実は片方が必要な作業を見積もりに含めていなかっただけ、というのはよくあることです。
逆に言えば、この3つに分解できない見積書は、比べようがありません。「システム開発一式」とだけ書かれた見積書が問題なのは、金額が高いか安いかを判断する手がかりが、どこにもないからです。
「人月」とは何か
見積書を読むうえで、避けて通れないのが「人月（にんげつ）」という単位です。「3人月」「0.5人月」といった表記を目にされたことがあるかもしれません。
1人月 ＝ 1人が1か月かけて行う作業量
人月とは、作業量を表す単位です。1人月は「1人が1か月かけて行う作業量」を指します。3人月なら、1人が3か月かけて行う量、ということになります。
ここで注意していただきたいのが、1か月が何日を指すのかは、実は会社によって定義が違うという点です。土日祝日を除いた稼働日で数えるのが一般的ですが、その日数や1日あたりの想定時間は、各社の考え方によって差があります。
見積書に人月表記がある場合は、1人月が何日・何時間を指すのかを確認してください。同じ「3人月」でも、前提が違えば実際の作業量は変わります。この定義が見積書や契約書に明記されている会社は、後から認識のずれが起きにくい会社だと考えてよいでしょう。
「3人月」は「3人で1か月」ではない
もうひとつ、発注する側が誤解しやすい点があります。「3人月」と書かれていると、「3人を投入すれば1か月で終わるのだな」と読みたくなりますが、そうとは限りません。
システム開発は、人数を増やせばその分だけ期間が短くなる仕事ではないからです。理由はいくつかあります。
- 前工程が終わらないと次に進めない作業がある — 設計が固まっていない段階で作り始めることはできません
- 人が増えるほど、情報を共有する手間が増える — 3人なら3人分の打ち合わせと引き継ぎが発生します
- 途中から加わった人には、それまでの経緯を理解する時間が必要 — すぐに戦力になるわけではありません
これはソフトウェア開発の世界では古くから知られている性質で、「遅れているプロジェクトに人を追加すると、さらに遅れる」とまで言われます。
ですので、納期を短くしたいというご要望に対して、単純に人数を増やす提案をしてくる会社には注意が必要です。現実的な短縮方法は、機能の優先順位をつけて、まず必要なものから段階的にリリースすることです。
期間と工数は別のもの
人月は作業量であって、期間ではありません。この2つは見積書の中で別々に書かれているはずです。
「6人月・開発期間4か月」という見積書であれば、平均して1.5人が4か月間関わる、という意味になります。工数と期間の両方が書かれているか、そして両者の関係に無理がないかを確認してください。
同じ要望でも会社によって単価が違う理由
単価は、見積金額の差が最も分かりにくい部分です。ここでは具体的な金額の相場ではなく、なぜ差が生まれるのかという観点をお伝えします。この観点があれば、提示された単価が高いのか安いのかを、ご自身の案件に照らして判断できます。
役割によって単価が違う
システム開発には、複数の役割の人が関わります。
- お客様の業務を聞き取り、システムの仕様を決める人
- 全体の構造を設計する人
- 実際にプログラムを書く人
- 動作を検証する人
- 全体の進行を管理する人
これらは求められる経験も責任範囲も異なるため、単価も異なります。役割ごとに単価が分けて書かれている見積書は、内訳が正直に開示されている見積書です。逆に全員が同じ単価で書かれている場合は、平均化された数字である可能性があります。
開発の体制によって差が出る
見積書を出した会社が、実際に開発するとは限りません。受注した会社が別の会社に依頼し、その会社がさらに別の会社に依頼する、という多段の構造になっている場合があります。
この階層が深くなるほど、各段階で管理費用が上乗せされます。同じ人が作業していても、間に入る会社の数によって最終的な単価は変わってきます。「実際に開発するのはどなたですか」と質問してみると、体制が見えてきます。
案件の性質によって差が出る
扱う情報の種類や、求められる信頼性の水準によっても単価は変わります。個人情報を大量に扱うシステムや、止まると業務が完全に停止するシステムでは、設計と検証にかける手間が増えるためです。
また、特殊な知識が必要な領域では、対応できる人が限られるぶん単価が上がる傾向があります。
判断するときの考え方
単価の妥当性を判断するときは、金額そのものより「その単価で、どんな人が、何をするのか」が説明されているかを見てください。説明できる会社は、体制を把握して見積もっています。説明が曖昧な会社は、根拠なく数字を置いている可能性があります。
内訳の項目は何を表しているのか
ここからは、見積書に並ぶ工程名が、それぞれ何をする時間なのかを説明します。この工程の意味が分かると、見積書から「抜けているもの」が見えるようになります。
要件定義
何を作るのかを決める工程です。お客様の業務を聞き取り、現状の課題を整理し、システムで解決する範囲を確定させます。
この工程は、発注する側にとって最も重要でありながら、最も軽視されやすい工程です。ここが曖昧なまま進むと、完成したものが想定と違う、という結果になります。要件定義が見積書に独立した項目として存在するかは、最初に確認すべき点のひとつです。
設計
決めた要件を、どう実現するかを具体化する工程です。画面の構成、情報の持たせ方、他のシステムとのつなぎ方などを決めていきます。
設計は、家を建てるときの図面にあたります。図面なしで建て始める大工がいないのと同じで、この工程を省略することはできません。
開発（実装）
実際にプログラムを作る工程です。多くの方が「システム開発」と聞いてイメージされるのが、この部分だと思います。
ただし、見積書全体に占める割合は、思っているほど大きくありません。前後の工程のほうが合計では大きくなることも珍しくないのです。
テスト
作ったものが正しく動くかを検証する工程です。正常に使えるかだけでなく、想定外の操作をされたときにどうなるか、大量のデータが入ったときに問題が起きないかなども確認します。
見積書でまず探していただきたいのが、このテスト工程です。ここが独立した項目として書かれていない見積書は、注意が必要です。テストは「やらなくても、とりあえず動くものは完成する」工程だからです。省けば見積金額は下がりますが、そのぶんの不具合対応が納品後に発生します。
導入・教育
作ったシステムを、実際に使える状態にする工程です。既存のデータを移し替える作業、現場の方への操作説明、マニュアルの作成などが含まれます。
新しいシステムを入れても現場が使いこなせなければ意味がありません。特に、今まで紙やExcelで行っていた業務を置き換える場合、この工程の有無が定着を大きく左右します。
保守・運用
納品後の工程です。不具合が見つかったときの対応、法改正などに伴う修正、サーバーの管理などが含まれます。
保守は開発費とは別に、月額または年額で見積もられるのが一般的です。開発費だけを比較して契約したあとに、保守費用の存在を知って総額が想定と変わってしまう、というのは避けたい事態です。
見積書で必ず確認したい7つのポイント
ここまでの内容を踏まえて、手元の見積書で確認していただきたい点を7つにまとめます。どれも、その場で見積書を見るだけで確認できるものです。
1. 「一式」でまとめられていないか
「システム開発一式」「その他一式」といった表記が多い見積書は、内訳が読み取れません。金額の妥当性を判断できないだけでなく、後から「それは一式に含まれていません」という認識のずれが起きる原因にもなります。
工程ごとに分けた内訳を出してもらえるか、依頼してみてください。出せない理由が明確に説明できない場合は、見積もり自体が概算である可能性があります。
2. 前提条件が書かれているか
見積書には、金額を算出した前提が書かれているはずです。
- 想定している利用者数、データ量
- お客様側で用意していただくもの（画像、原稿、既存データなど）
- 打ち合わせの回数や方法
- 修正・変更に対応する回数の上限
前提条件が書かれていない見積書は、後から金額が変わる余地が大きい見積書です。前提が明示されていれば、それが自社の実態と合っているかを確認できます。
3. スコープ「外」が明記されているか
含まれるものが書かれているのは当然として、含まれないものが書かれているかを見てください。
「この見積もりに、既存データの移行は含まれません」「スマートフォン向けの表示対応は含まれません」といった記載です。一見すると不親切に見えますが、これを書く会社は、後で追加請求になる箇所を事前に伝えている会社です。
4. テスト工程があるか
前章で述べたとおりです。テストが独立した項目として存在するか、確認してください。項目がない場合は「テストはどの工程に含まれていますか」と質問すれば、その会社の考え方が分かります。
なお、極端に安い見積書を見かけたときは、金額の低さそのものよりも、どの工程が省かれた結果その金額になっているのかを確認してください。省かれた作業が消えてなくなるわけではなく、多くの場合は納品後に別の形で発生します。
5. 検収条件が書かれているか
検収とは、納品されたものを確認して「これで完成」と認める手続きです。ここが曖昧だと、「まだ直してほしい」「いや完成している」という食い違いが起きます。
- 何をもって完成とするのか
- 確認していただく期間はどれくらいか
- 期間内に指摘がなかった場合はどう扱うか
これらが書かれているかを確認してください。
6. 保守費用が別に示されているか
納品後の保守費用が、開発費とは別に示されているかを見てください。示されている場合は、その保守費で何をしてもらえるのかも併せて確認します。
不具合対応のみなのか、機能の追加や変更も含むのか。サーバーの監視は含まれるのか。障害が起きたときの連絡先と対応時間はどうなっているのか。ここは会社によって内容の幅が大きい部分です。
7. 有効期限が書かれているか
見積書には通常、有効期限があります。期限が書かれていない見積書は、そもそも書式が整っていない可能性があります。
また、社内での検討に時間がかかりそうな場合は、期限を過ぎたときにどうなるのかを事前に確認しておくと安心です。
良い見積書と、注意が必要な見積書
ここまでの7点を、対比の形で整理します。
| 確認項目 | 良い見積書 | 注意が必要な見積書 |
|---|---|---|
| 内訳 | 工程ごとに分かれている | 「一式」でまとまっている |
| 前提条件 | 利用規模・提供物・修正回数が明記 | 記載がない |
| 対象範囲 | 含まれないものも書かれている | 含まれるものしか書かれていない |
| テスト | 独立した項目としてある | 項目が見当たらない |
| 検収 | 完成の基準と確認期間が明記 | 記載がない |
| 保守 | 開発費と分けて金額と内容を提示 | 触れられていない |
| 有効期限 | 明記されている | 記載がない |
すべてを満たす見積書ばかりではありませんが、該当しない項目が多いほど、後から金額や範囲が動く可能性が高いとお考えください。
まとめ
システム開発の見積書は、次の順番で読むと判断しやすくなります。
- 金額を「工数 × 単価 ＋ 諸経費」に分解する
- 人月の定義（1人月が何日か）を確認する
- 単価について「どんな人が何をするのか」の説明を求める
- 工程の内訳を見て、抜けている工程がないか探す
- 7つのチェックポイントで、前提と範囲の記載を確認する
金額の相場を知らなくても、見積書の構造さえ分かれば妥当性は判断できます。そして、これらの質問に丁寧に答えられる会社は、自社の見積もりの根拠を把握している会社です。質問への答え方そのものが、その会社を見極める材料になります。
私たちは、お客様に内訳をご理解いただいたうえでご判断いただきたいと考えています。他社様からお受け取りになった見積書の見方が分からない、という段階でのご相談も歓迎しております。「まだ発注するかどうかも決まっていない」という状態でお声がけいただいて構いません。
お困りのことがございましたら、お気軽にご相談ください。
