システム開発の見積もりの見方｜内訳の割合・高い安いの検算・比較のコツ

システム開発の見積書を受け取っても、「この金額が高いのか安いのか分からない」という方は少なくありません。見積もりは金額の大小より、中身が明確かと工数が妥当かで見ます。この記事では、見積書の読み方を、内訳の割合・高い安いの検算・比較のコツ、そして追加費用を防ぐ確認のしかたまで具体的に解説します。読み終えたころには、届いた見積書のどこを指差して質問すればいいかが分かるはずです。

見積書は「工程ごとの内訳」で見る

まともな見積書は、作業が工程ごとに分かれています。おおまかな費用割合の目安は次の通りです。

工程	内容	費用割合の目安
要件定義	何を作るか整理する	約10〜20%
設計	画面・データ構造を設計	約10〜15%
開発（実装）	プログラミング	約40〜50%
テスト	動作確認・不具合修正	約15〜20%
プロジェクト管理	進行・調整・連絡	約10〜15%

開発（実装）以外が半分近くを占めるのが健全な内訳です。「開発一式」で実装だけが計上され、要件定義やテストが抜けている見積もりは、あとで追加される可能性が高いので注意します。この割合は「開発だけが仕事ではない」ことを示しています。作る前に決める工程と、作った後に確かめる工程がそれぞれ十分に積まれているか——ここが見積書の背骨です。

割合だけでなく、各項目が「何にお金を払っているのか」を理解すると、抜けや水増しに気づけます。上の5工程に、見積書でよく別枠になるインフラと保守を加えて、1つずつ読み解きます。

• 要件定義：作るものの範囲・機能・優先順位を文書に固める工程。ここが曖昧だと後工程がすべてぶれます。「打ち合わせで済ませる（＝計上なし）」場合は、認識ズレのリスクを発注側が引き受けている状態だと考えてください。要件定義の中身は要件定義とは何をするかで解説しています。
• 設計：画面のレイアウト、データの持ち方、外部サービスとのつなぎ方などを決める工程。設計が薄いと「作ってみたら想定と違う」が頻発します。
• 開発（実装）：実際にプログラムを書く工程。金額が最も大きくなりますが、ここだけが突出して全体の8割を超えるような見積もりは、他工程が削られているサインです。
• テスト：仕様どおり動くか、異常な操作でも壊れないかを確認し不具合を直す工程。削られやすい割に、削ると納品後の不具合対応でかえって高くつきます。
• プロジェクト管理（PM）：進行管理・課題整理・定例連絡など、開発を止めないための調整費。ゼロだと「連絡が来ない」「進捗が見えない」開発になりがちです。
• インフラ：サーバー・ドメイン・SSL証明書・各種クラウド利用料など、動かし続けるための土台。初期構築費と月額の運用費が分かれているか、月額がいくらかを必ず確認します。
• 保守：納品後の不具合対応・小さな改修・障害監視など。多くの会社で**別料金（月額）**になっており、初期見積もりに含まれないのが普通です。「保守込みなのか別なのか」を最初に確認しないと、運用が始まってから想定外の固定費が出ます。

見積書を読むときは、この7項目のうちどれが計上され、どれが「含まない」と書かれているかを線引きするだけで、比較の精度が一段上がります。特にテスト・要件定義・保守の3つは「あるのが当たり前」ではなく、意図的に省かれていることがあるため、行そのものが存在するかを最初に確かめてください。

この見積もりは高い？安い？ざっくり検算する方法

金額の妥当性は、人月単価を使って逆算できます。

• 人月単価の目安：初級40〜60万円／中堅60〜100万円／上級100〜160万円（1人が1ヶ月働く作業量＝1人月）
• 総額 ÷ 人月単価 ≒ 想定されている人月

例えば「500万円」の見積もりなら、単価100万円として約5人月（1人で5ヶ月／2人で2.5ヶ月ぶんの作業量）。その規模の機能を作るのに5人月が妥当か——と考えると、極端に高い・安いの当たりが付きます。人月の意味は人月・人月単価とはで解説しています。

規模感の目安も持っておくと検算しやすくなります。あくまで幅ですが、次のように考えると当たりを付けやすいでしょう。

作るものの規模	目安の人月	総額の目安（単価80万円換算）
問い合わせフォーム＋簡単な管理画面	約1〜3人月	約80〜240万円
予約・在庫など業務システム（小）	約4〜8人月	約320〜640万円
会員機能・決済つきのサービス	約8〜15人月	約640万〜1,200万円

この表に自社の見積もりを当てて、**人月が明らかに少なすぎる（＝安すぎ）／多すぎる（＝高すぎ）**を疑います。安すぎる場合はテストや要件定義が抜けている、高すぎる場合は不要な機能や過剰な体制が乗っている、という仮説を立てて質問に進みます。費用全体の相場観はシステム開発の費用相場も参考にしてください。

**例：予約システムで300万円と提示されたケース。**単価80万円で割ると約3.7人月。ログイン・予約カレンダー・管理画面・決済連携まで含むなら、3.7人月はやや少なめです。内訳を見ると「テスト」と「要件定義」の行がなく、開発だけで計上されていました。ここで安いと飛びつかず、「テストと要件定義はどこに含まれるか」を質問すると、実は別見積もりで+120万円——つまり実質420万円だった、というのはよくある展開です。検算は金額を疑うためではなく、質問すべき場所を見つけるために使います。

「一式」見積もりから内訳を引き出す質問

「システム開発一式 ◯◯万円」とだけ書かれた見積もりは、内訳が見えず危険です。次の質問で中身を引き出しましょう。

• 要件定義は含まれますか？
• テストは何を、どこまで行いますか？
• 修正・調整は何回まで料金内ですか？
• 納品後の保守は含みますか、別料金ですか？
• どうなったら「追加費用」になりますか？
• インフラ（サーバー・月額利用料）は誰が負担しますか？
• 完成したソースコードの権利はこちらに渡りますか？

これらに快く、具体的に答えてくれるかが、信頼できる会社かの分かれ目です。渋る・話をそらす・「そこは進めながら」とはぐらかす場合は、内訳を出せない事情がある可能性を疑ってよいでしょう。逆に、口頭の回答をその場で見積書やメールに書き足してくれる会社は信頼できます。「一式」は金額の安心材料ではなく、不確実性が隠れている状態だと捉えるのが安全です。

追加費用が発生する典型パターン

当初見積もりが安くても、次のパターンで総額が膨らみます。契約前に条件を確認しておきましょう。

追加が起きる条件	よくある状況	事前に聞くこと
仕様の追加・変更	後から機能を足す・画面を変える	変更1件あたりの費用の考え方、無料修正の回数
外部連携の追加	決済・会計・地図などの連携が増える	連携先ごとに費用が変わるか
データ移行	既存データの取り込みが想定外に発生	移行対象の件数・形式、移行費は別か
急ぎ対応	短納期で人員を増やす	特急料金の有無、通常納期との差額
環境差異	対応OSやブラウザ、端末が増える	対応範囲はどこまで含むか

追加費用そのものが悪いわけではありません。問題は**「どうなったら追加になるか」が契約前に文書化されていないこと**です。ここが曖昧な見積もりは、当初金額が安く見えても最終的に膨らみやすいと考えてください。特に注意したいのが「仕様の追加・変更」で、開発が始まってから「やっぱりこうしたい」が積み重なると、当初の何割増にもなり得ます。だからこそ要件定義の段階で作るものを固め、変更の扱い（1件いくら／何回まで無料か）を見積書か契約書に書いてもらうことが、総額を守る一番の防御になります。この取り決めは口頭ではなく必ず文面に残しましょう。発注全体の流れは発注の流れ、契約時の注意点は開発契約の注意点も参考になります。

相見積もりを正しく比較する（依頼のそろえ方）

相見積もりは有効ですが、各社に同じ前提を渡さないと比較になりません。依頼時に次をそろえましょう。

• 目的（何を解決したいか）
• ほしい機能のリスト（わかる範囲で）
• 予算感と希望納期
• 「含めてほしい範囲」（要件定義・テスト・保守）

そのうえで、金額だけでなく範囲をそろえて比べます。社数は2〜3社が目安。多すぎると各社への説明と比較検討だけで疲弊し、かえって判断が雑になります。比べるときは総額の1行だけを見ず、「同じ機能・同じ範囲でいくらか」に換算します。次の例のように、範囲まで並べて初めて本当の高い安いが見えます。

比較項目	A社	B社
提示総額	400万円	500万円
要件定義	含まない	含む
テスト	簡易のみ	一通り実施
保守（月額）	別途5万円	3万円込み（3ヶ月）
ソースコード	原則渡さない	納品

一見A社が100万円安く見えますが、A社は要件定義とテストが薄く、保守も割高です。抜けを埋めていくと、実質はほぼ並ぶか逆転することも珍しくありません。安いだけで選ぶと、抜けていた工程が後から追加費用として戻ってくるのです。会社の見極め方はシステム開発会社の選び方、悪い会社の兆候は悪い開発会社の見分け方もご覧ください。

見積もりの精度を上げるために発注側が伝えること

見積もりが荒くなる最大の原因は、発注側の情報不足です。渡す材料が薄いほど、会社は「たぶんこのくらい」と余裕を大きく取り、金額は高く・幅は広くなります。次を用意して渡すと、精度が上がり、各社の比較もしやすくなります。

• 目的と背景：何に困っていて、何が解決すれば成功か
• 使う人と規模：想定ユーザー数、社内利用か一般公開か
• ほしい機能の一覧：わかる範囲でよいので箇条書きに
• 既存の仕組み：今使っているExcelやツール、連携したいサービス
• 予算感と希望納期：上限を隠すより、レンジで伝えた方が現実的な提案になる
• 優先順位：全部同じではなく「絶対に要る／あれば嬉しい」を分ける

すべてを完璧に固める必要はありません。「決まっていないこと」を正直に伝えるだけでも、会社は前提の置き方を説明でき、見積もりの根拠がはっきりします。要件の整理が難しければ、そこから相談に乗ってくれる会社を選ぶのも手です。

そして見積書が届いたら、金額を見る前に次のチェックリストを上から順に確認してください。半分以上に「はい」と言えないなら、質問して埋めてから比較に進みます。

• 工程ごと（要件定義・設計・開発・テスト・管理）に内訳が分かれているか
• 「一式」でごまかされている項目がないか
• 総額を人月単価で割った工数が、規模に対して妥当か
• テストの範囲（どこまで確認するか）が書かれているか
• 修正・調整が何回まで料金内か明記されているか
• 保守・インフラ（月額）が含むか別かが明確か
• 「追加費用になる条件」が文書に書かれているか
• 納期・支払条件・納品物（ソースコードを渡すか）が書かれているか
• 各社に同じ前提・同じ範囲で依頼できているか

この9項目は、金額の高い安い以前の「見積書として成立しているか」のチェックです。ここが埋まって初めて、価格比較に意味が出ます。逆に言えば、多くのトラブルは金額そのものではなく、この線引きが曖昧なまま契約に進んだことから起きています。確認した内容は口頭で終わらせず、見積書の改訂版やメールとして残しておくと、後で「言った言わない」を避けられます。失敗の典型はシステム開発の失敗事例でも紹介しています。

値引き交渉より「範囲を削る」が正解

総額を下げたいとき、単価の値切りはテストや品質の削減につながりがちで危険です。単価を無理に下げても、会社はどこかで帳尻を合わせます。多くはテスト・要件定義・PMといった「見えにくい工程」が薄くなり、結果として不具合や手戻りで高くつきます。安全に安くするなら、**作る機能を減らす（MVPに絞る）**方が健全です。「最初のリリースで本当に要る機能」だけに絞り、あれば嬉しい機能は後回しにする——これなら品質を保ったまま総額を下げられます。安さの裏のリスクは安いシステム開発は危険？で詳しく解説しています。

一律料金なら、見積もりの読み解き自体が要らない

見積もりが読みにくいのは、会社ごとに前提や内訳がバラバラで、しかも**「追加でいくら増えるか」という不確実性が最後まで残る**からです。ここまで見てきた検算・質問・チェックリストは、突き詰めればこの不確実性を減らすための作業でした。

D-oneAppは料金が一律100万円（大規模なプロプランは一律200万円）で、追加費用なし・着手前に総額が確定します。つまり、見積書の内訳を疑って質問したり、相見積もりの範囲をそろえて検算したりする必要が、そもそもありません。総額が動かないぶん、悩む対象は「何を優先して作るか」だけになります。さらに完成したソースコードの権利は顧客に渡るため、あとで別の会社に引き継ぐこともできます。100万円でどこまでできるかは100万円でできること、費用の全体像はシステム開発の費用相場もご覧ください。

まとめ

見積もりは、①工程ごとの内訳が示されているか、②人月で検算して工数が妥当か、③追加費用の条件が明確か——で見ます。「一式」には質問で内訳を引き出し、相見積もりは前提をそろえて比較を。安すぎ・高すぎは人月で検算し、総額を下げるなら値切りより機能を絞るのが正解です。そして見積もりの精度は、発注側が渡す情報の質でほぼ決まります。

要するに、見積書を読む作業の大半は「隠れた不確実性を洗い出す」ことに費やされます。総額があらかじめ固定されていれば、その手間そのものが不要になります。見積もり比較に疲れたら、総額が最初から決まる無料相談で「100万円でどこまでできるか」を整理しましょう。