システム開発の見積もりの違い｜金額より先に見る前提と範囲

同じシステムを依頼したはずなのに、見積書を並べると会社ごとに内容も金額も大きく違う。システム開発を外注しようとすると、多くの会社がこの場面に出会います。この記事では、見積もりが違って見える理由を整理し、金額を比べる前に確かめたい「前提」と「範囲」の見方を紹介します。

見積もりの違いは、必ずしも「高い・安い」の問題ではありません。何を前提に、どこまでを含めて計算したかが、そもそも別物であることが多いのです。

見積もりが会社ごとに違うのは、同じものを見積もっていないから

見積書は「前提に対する答え」

見積書は、依頼内容に対して開発会社が出した「答え」です。ただ、新規事業の初期段階では、依頼内容そのものが「こういうサービスをつくりたい」という構想の段階にとどまっていることが少なくありません。

構想の段階では、画面の数、機能の細かさ、想定する利用者数などが決まっていません。決まっていない部分は、各社が自分たちの経験に基づいて補います。

• ある会社は、最小限の機能を想定して見積もる
• ある会社は、運用開始後に必要になりそうな機能まで含めて見積もる
• ある会社は、不明点が多いぶん余裕を持たせて見積もる

同じ依頼文でも、補い方が違えば、見積もりの中身は変わります。違いの出発点は、会社の優劣ではなく「前提の置き方」にあります。

差が出やすい6つの要素

見積もりに差が出る主な要素を、先に整理しておきます。

1. 前提条件：どんな機能・画面・利用規模を想定しているか
2. 範囲：どの工程や成果物までを含めているか
3. 品質の水準：テストをどこまで行うか、どのくらいの性能や安全性を求めるか
4. 体制と単価の考え方：誰がどのくらい関わる前提か
5. 契約の形態：請負か準委任か、固定か実費精算か
6. リスクの見込み方：不確定な部分をどの程度、金額に織り込むか

以降の章では、このうち特に差が出やすい「前提」「範囲」「出し方」を順に見ていきます。金額を見る前に、この3つをそろえて読むと、見積書の違いが「理由のある違い」として見えてきます。

金額の前に見たい「前提」

見積書には、金額の表とは別に「前提条件」「見積もりの条件」といった欄があることがあります。小さな文字で書かれがちですが、金額の根拠はここにあります。確認したい前提を4つ挙げます。

機能と画面の想定

もっとも差が出るのが、機能や画面の想定です。たとえば「会員登録機能」と一言で言っても、次のように幅があります。

• メールアドレスとパスワードだけで登録できる
• 本人確認書類のアップロードや審査が必要になる
• 外部のアカウント（SNSなど）でのログインにも対応する
• 退会、パスワード再設定、登録内容の変更まで含める

どの程度を想定した見積もりなのかが書かれていなければ、他社の見積もりとは比べられません。「会員登録機能 一式」とだけ書かれている場合は、どこまでを含むのか、具体的に聞いておきたいところです。

利用規模と動作環境

同じ機能でも、同時に使う人数やデータの量によって、必要な設計やサーバー構成は変わります。確認したいのは次のような点です。

• 公開当初に想定する利用者数と、その後の増え方
• 対応するブラウザや端末（PC、スマートフォン、アプリ）
• 扱うデータの種類と量（個人情報や決済情報を含むか）
• 稼働させる環境（クラウドの種類、既存のサーバーなど）

新規事業では、利用者数が見通せないことも多いはずです。その場合は「まずこの規模を想定し、増えたら見直す」という前提を、見積書の側で明示してもらうと、後の話がしやすくなります。

外部サービスや既存システムとの連携

決済、メール配信、認証、既存の基幹システムとのデータ連携などは、見積もりの差が出やすい部分です。外部サービスを使う前提なのか、自社で作る前提なのかによっても、費用も期間も変わります。決済まわりの考え方は、新規事業の決済システム開発｜外部サービスと自作の分け方で整理しています。

既存システムがある場合は、連携先の仕様がどこまで分かっているのか、連携先の担当者と調整が必要かどうかも、前提に含まれているかを見ておきます。

発注側が用意するもの

見積もりには、発注側の協力が前提として入っていることがあります。

• 画面のデザイン案や素材（ロゴ、文章、画像）の提供
• 既存データの提供と、その形式の整理
• 仕様の確認や判断をする担当者の確保と、回答までの日数
• 検収（納品物の確認）にかけられる時間

「発注側が決める」前提の項目が、実際には決められていない状態で進むと、後から追加の対応が必要になりやすくなります。発注側の判断を担う役割については、発注側のプロダクトオーナーとは｜役割と判断のしかたも参考になります。

「範囲」で差が出やすい項目

前提がそろっても、「どこまでが見積もりに含まれているか」が違えば、金額は比べられません。範囲の違いが出やすい項目を整理します。

工程と成果物の範囲

開発には、要件定義、設計、実装、テスト、公開作業といった工程があります。見積書によって、含まれる工程が違うことがあります。

• 要件定義や設計は別料金の別契約になっていないか
• テストは開発会社が行うところまでか、発注側の受け入れテストの支援まで含むか
• 公開（本番環境への反映）の作業は含まれているか
• 設計書や操作マニュアルなどのドキュメントは成果物に含まれるか

ドキュメントの扱いは、後で保守や引き継ぎをするときに効いてきます。この点はAI設計書の自動生成は可能？後から困らない残し方でも触れています。

見落とされやすい「周辺」の範囲

画面に見える機能以外にも、事業として運用するためには必要なものがあります。見積書に載っていないと、後から「それも必要だった」となりがちな項目です。

• 管理画面：会員や注文を確認・修正する、運営側の画面
• データ移行：既存の顧客情報や商品情報を新しいシステムに入れる作業
• 通知・メール送信：登録完了、決済完了などの自動連絡
• セキュリティ対応：権限の管理、通信の暗号化、ログの記録など
• インフラ構築：サーバーやデータベースの準備と設定
• 障害時の対応：不具合が起きたときの連絡と対応の窓口

とくに管理画面は、見積もりに含めるかどうかで差が出やすい項目です。最初にどこまで作るかの考え方は、新規事業の管理画面開発｜最初に作る範囲の見極め方で詳しく扱っています。

納品後の扱い

公開してからが、事業のスタートです。保守や運用の費用が見積もりに含まれているのか、別に必要なのかも確認しておきます。

• 納品後の不具合修正は、どの期間・どの範囲まで対応するか
• 軽微な改善や機能追加は、どのような形で依頼できるか
• サーバーや外部サービスの利用料は、誰がどのように負担するか

開発費だけを比べると安く見えても、運用開始後に別の費用が積み上がることもあります。逆に、運用まで含めた見積もりが、開発費だけの見積もりより高く見えることもあります。比べるときは、同じ期間・同じ範囲にそろえて見るのが基本です。保守や引き継ぎの確認点は、AI生成コードの保守は可能か｜引き継ぎと改修の確認点も参考になります。

見積もりの出し方と契約形態の違い

前提と範囲に加えて、金額の「出し方」にも違いがあります。同じ内容でも、出し方が違うと見積書の姿が変わります。

人月で積み上げる方式と、成果物で決める方式

システム開発の見積もりは、一般に次のような考え方で作られます。

• 人月（にんげつ）方式：1人のエンジニアが1か月働く量を「1人月」とし、必要な人数と期間を掛け合わせて積み上げる
• 成果物（固定）方式：決めた機能や成果物に対して、全体の金額を決める

人月方式は、作業量が分かりやすい反面、どの工程に何人月かかるかの前提を理解しないと、中身が見えにくくなります。成果物方式は、金額が分かりやすい反面、「どこまでを成果物とするか」の線引きが重要です。AI活用が進むなかで人月の考え方がどう変わるかは、AI開発で人月の考え方はどう変わる？工数で測れない部分で整理しています。

請負と準委任

契約の形態も、見積もりの読み方に影響します。民法上の区分では、主に次の2つがあります。

• 請負契約：決めた成果物を完成させることを約束する。成果物が契約の内容に合わない場合の責任（契約不適合責任）が問題になる
• 準委任契約：成果物の完成ではなく、業務を遂行すること自体を約束する。期間や作業量に応じて精算されることが多い

請負は仕様が決まっているときに向き、準委任は仕様を探りながら進めるときに向く、と言われます。どちらが良いかは案件によるため、見積書に書かれた金額が、どちらの契約を前提にしているのかを確かめておく必要があります。契約形態の詳細は、受託開発とは？依頼の流れ・契約形態・新規事業の選び方にまとめています。

余裕の見込み方

見積もりには、不確定な部分への備えとして、余裕（バッファ）が含まれることがあります。仕様が固まっていない案件ほど、余裕を多めに見る会社もあれば、前提を明記して「変わったら別途協議」とする会社もあります。

どちらが正しいというわけではありません。大切なのは、余裕が見込まれているのか、見込まれていないのかを、見積もりの段階で説明してもらうことです。

見積もりを見比べる手順

ここまでの見方を、実際の比較の手順にまとめます。

1. 依頼内容を同じ形で伝える

見積もりの違いを小さくする近道は、各社に同じ情報を渡すことです。次のような項目を、1枚の資料にしておくと、各社の想定がそろいやすくなります。

• 事業の目的と、このシステムで確かめたいこと
• 想定する利用者と、公開当初の規模
• 必要だと考えている機能（優先度の高いもの・後回しにできるもの）
• 連携したい外部サービスや既存システム
• 希望する時期と、決めておきたい期限（稟議や展示会など）

仕様の伝え方に迷う場合は、AI開発の仕様の伝え方｜作りたいものを言葉にする手順や、システム開発を依頼する前の準備と流れ｜新規事業編が手がかりになります。

2. 比較表で項目をそろえる

見積書が届いたら、金額だけを並べるのではなく、次のような表を作って項目をそろえます。

確認項目	A社	B社	C社
想定している機能・画面
想定している利用規模
含まれる工程（要件定義〜公開）
管理画面・データ移行の有無
テストの範囲
契約形態（請負・準委任など）
発注側が用意するもの
納品後の保守・改善の扱い
変更が起きたときの扱い
金額

金額は最後の行です。上の行がそろっていない状態で金額だけを見ると、判断を誤りやすくなります。空欄が多い会社には、その部分を質問すると、前提を詰めていく流れが生まれます。

3. 質問で前提を確かめる

見積書の読み取りで迷ったときは、次のような質問が役に立ちます。

• この見積もりでは、どのような機能・画面を想定していますか
• 含まれていない作業や、別途費用になりうる作業はありますか
• 前提が変わった場合、どの部分の見積もりが変わりますか
• 仕様が固まっていない部分は、どのように見込んでいますか
• 納品後の不具合や改善は、どのような形で対応しますか

質問への答え方も、会社を見極める材料になります。前提を具体的に説明し、含まれないものも隠さず示す会社は、後の進行でも認識のずれが起きにくい傾向があります。会社選びの全体の視点は、システム開発会社の選び方｜新規事業で失敗しない7つの視点も合わせて参考にしてください。

仕様が固まっていない段階と、変更が起きたときの扱い

新規事業は、前提が動くのが普通

新規事業では、作りながら考えが変わるのが自然です。最初の見積もりの前提が、そのまま最後まで変わらない案件のほうがまれでしょう。だからこそ、見積もりの時点で「前提が変わったらどうなるか」を決めておくことが大切です。

確認しておきたいのは、次の点です。

• 追加や変更の依頼は、どのような手順で受け付けるか
• 変更による金額や期間への影響は、誰がどのように示すか
• 軽微な変更は含まれるのか、すべて別扱いになるのか
• 変更を受け入れず、当初の範囲で完了させる選択肢はあるか

追加要望の扱い方は、システム開発の仕様変更への対応｜追加要望の扱い方で、具体的に整理しています。

言葉だけで決めるほど、見積もりは揺れやすい

仕様が固まっていない段階の見積もりは、言葉や資料だけで想像した内容に基づいています。完成形のイメージが、発注側と開発会社で少しずつ違ったまま進むと、「作ってみたら違った」が起きやすくなります。この問題は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも取り上げています。

仕様が決まっていないこと自体は、悪いことではありません。仕様が決まっていない状態で相談できるのかという疑問には、仕様が決まってないシステム開発の相談は可能かで答えています。

小さく作って確かめてから、金額を決めるという選択

見積もりの不確実さを減らす方法のひとつが、本格的な開発の前に、小さく動くものを作って確かめることです。実物を触れば、必要な機能と不要な機能が見えてきて、本開発の前提も固まります。投資判断のしかたは、新規事業の開発は小さく作って確かめる投資判断の進め方で紹介しています。

前提が固まったうえで出した見積もりは、後からのずれが小さくなり、社内で説明するときの根拠にもなります。稟議の場面での使い方は、稟議を通すシステム開発｜プロトタイプの使い方も参考になります。

まとめ

システム開発の見積もりが会社ごとに違うのは、各社が同じものを見積もっていないためです。違いの正体は、おおむね次の3つに分けて読めます。

• 前提：想定する機能・画面、利用規模、連携先、発注側が用意するもの
• 範囲：含まれる工程、管理画面やデータ移行などの周辺、納品後の扱い
• 出し方：人月か成果物か、請負か準委任か、余裕の見込み方

見積書を受け取ったら、金額の前に前提と範囲を表にそろえ、空欄を質問で埋めていく。この順番で読むと、金額の差が理由のある違いとして見えてきます。あわせて、前提が変わったときの扱いも先に決めておくと、進行中の揉めごとを減らせます。

私たちJustFit編集部が運営するJustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる受託開発サービスです。仕様が固まっていない段階や、稟議の前の段階でも相談できますので、見積もりの前提づくりで迷ったときの選択肢として、気軽にご相談ください。