システム開発の相見積もりの取り方｜同一条件で比較し、金額差の理由を確認して発注先を選ぶ手順

• 相見積もりは、開発範囲・対象外の機能・見積書の書式を発注側で定め、全社に同一の見積依頼書で依頼することで、同じ基準で比較できます。
• 金額差の理由は、前提条件・見積もりに含まれない作業・完成後の運用費・成果物とアカウントの名義、の4点を確認すると明確になります。
• 発注先は、見積書の提示額ではなく、条件を統一したあとの総額と、システムを自社で管理し続けられるかどうかで判断します。

システム開発の相見積もりで、金額に大きな差が出る理由

相見積もりとは、同じ業務について複数の会社から見積もりを取り、比較することです。システム開発の相見積もりでは、同じ内容を依頼したつもりでも、金額に大きな差が出ることが珍しくありません。

主な原因は、依頼内容に不足している部分を、各社がそれぞれの想定で補っていることにあります。ある会社はテストと完成後の保守を含めて見積もり、別の会社はそれらを含めずに見積もります。この状態の見積書を並べた場合、比較しているのは金額ではなく、各社の想定の違いです。

社内に技術の責任者がいない会社では、この違いに気づかないまま発注してしまう例が少なくありません。私はCTO代行として、経営者が見積もりの妥当性を判断できずに外注先の提示額で発注する例を多数見てきました。これは、完成後に高額な保守費用や、他社へ移行できないシステムの問題に直面する原因となります。

相見積もりで最初に取り組むべきことは、最も安い会社を探すことではありません。各社の見積もりを、同一の条件で比較できる状態に整えることです。

同じ基準で比較するための依頼方法

全社に同一の見積依頼書を渡し、質問への回答も全社で共有する

見積もりを依頼するときは、自社で見積依頼書を1つ作成し、見積もりを依頼するすべての会社に同じものを渡します。見積依頼書には、システム開発の目的、利用者、必要な機能を記載します。見積書に記載してほしい項目もこの中で指定し、各社には、その項目に沿って見積書を作成してもらいます。

要件定義（開発するシステムの機能や条件を、発注側と開発会社が文書で決める作業）が済んでいない場合は、その作業を見積もりに含めるかどうかも見積依頼書に明記します。この点が会社ごとに異なると、金額差の大部分がこの作業の有無から生じます。

ある会社から質問を受けた場合は、その回答をほかの会社にも同じ内容で共有しましょう。1社だけが詳しい条件を把握している状態では、見積もりの前提が揃いません。

対象外の機能を先に明記する

見積依頼書には、開発する機能だけでなく、今回は開発しない機能も記載します。私が担当した大規模な開発では、対象外の機能をまとめた「やらないことリスト」を要件定義書とは別に作成し、発注側と開発側で事前に合意しました。その結果、後からの追加要望によって開発範囲が拡大することを防げました。

相見積もりの段階でこのリストを提示すると、各社が「念のため」に盛り込む機能を減らすことができます。開発範囲の解釈の違いから、金額差が生じることも少なくなるのです。

性能と障害対応の条件を数値で示す

想定する利用者数やアクセス数、障害発生時に何時間以内の対応を求めるかは、数値で示しましょう。障害時の対応水準についての取り決めは、SLA と呼ばれます。

私が以前関わった案件では、想定アクセス数と SLA を明確にしないまま契約を結び、稼働開始後に双方の認識の違いからトラブルになりました。それ以降、性能と障害対応の条件は、必ず数値で文書化しています。条件が数値で定まっていれば、各社はその条件に合ったサーバー（ウェブサイトやアプリを稼働させ続けるコンピューター）の規模と保守体制で見積もるため、比較が容易になります。

見積書の書式を発注側で指定する

各社独自の書式で見積書を受け取ると、項目の区分がまちまちで比較できません。次の項目について、全社に同じ形式での記載を依頼しましょう。

請負契約は、定めた成果物の完成に対して代金を支払う契約です。準委任契約は、業務の遂行に対して代金を支払う契約で、完成そのものは約束しません。同じ金額でも、契約形態が異なれば、発注側が負うリスクも異なります。

工程ごとの金額の比率から見積もりの妥当性を確認する方法は、システム開発の見積もりは妥当か、工数の内訳から確かめる方法で説明しています。

開発手法が異なる見積もりは、単位を統一してから比較する

見積もりには、完成までの総額を一括で提示するものと、期間ごとの金額を提示するものがあります。後者は、アジャイル開発（小さな単位で開発して確認し、修正を重ねながら進める開発手法）で多く見られる形式です。

アジャイル開発の手法の一つであるスクラムの公式ガイドでは、作業の区切りとなる期間（スプリント）の長さを1か月以内で定め、毎回同じ長さで繰り返すとしています。作業量の見積もりは、その作業を実際に担当する開発者が責任を持つと定められています。また、作業は「完了の定義」（品質基準を満たした状態を正式に定めたもの）を満たさない限り、成果物として扱われません。

そのため、期間ごとの見積もりを提示した会社には、何回の区切りで何を開発する想定か、完了の定義をどう設定するかの記載を求めます。そうすることで、総額で提示した会社の見積もりと、同じ範囲で比較できます。

私は日本の開発会社と、フィリピンの開発チームの双方に発注してきました。週に1回、動作する画面を確認した案件では、認識のずれを早い段階で修正できました。仕様書だけを渡して任せた案件では、納品直前に想定と異なるものが提出されました。見積もりを比較する際は、金額だけでなく、開発途中に確認できる回数も判断材料になります。

開発の各段階で発注側と開発会社がどの役割を担うかについては、経済産業省と IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」に解説があります。第二版とアジャイル開発版があり、契約書のひな型も掲載されています。見積依頼書に自社が担う作業を記載する際の参考になります。

金額差の理由を確認する4つの観点

各社の見積書が揃ったら、金額差がどこから生じているかを、次の4点で確認します。

1. 前提条件：同一の内容で見積もられているか

見積書の前提条件・除外事項（その金額に含まれる作業と含まれない作業を、開発会社が明記した条件）を、会社ごとに並べて比較しましょう。確認する項目は、対象の機能、想定する利用者数、対応する端末（パソコンのブラウザ、iPhone、Android）、既存データの移行の有無、自社で用意するもの（文章・画像・テスト用のデータ）です。

前提が異なる箇所があれば、その会社に「この前提に統一した場合、金額はどう変わるか」を質問しましょう。前提を統一した金額が提示されて、はじめて比較が可能になります。

2. 含まれない作業：テストと完成後の保守が含まれているか

他社と比べて極端に安い見積もりは、テストや保守（完成後の不具合修正や、構成部品の更新などを継続する作業）の工数が含まれていない場合がほとんどです。反対に高すぎる見積もりは、開発内容が固まっていない段階で、「念のため」の予備費が上乗せされていることが多くあります。

20年ほど前、知人の起業家が、ビジネスマッチングのサイトを安い制作費で構築できたと喜んでいました。私がその中身を確認したところ、セキュリティ上の欠陥が複数見つかりました。後から修正費用が発生し、最初から適切に構築した場合よりも高額になりました。見積書にテストの工数が記載されていない場合は、どの範囲までテストを行うのかを必ず質問します。

工程ごとの比率から、見積もりに含まれていない作業を見つけた実例は、見積もりの「内訳の比率」で分かることにまとめています。

3. 完成後の運用費：見積書に含まれない利用料

システムは、完成後も毎月・毎年費用が発生します。これを運用費（ランニングコスト）と呼びます。近年のシステムは、サーバーなどを自社で保有せず、インターネット経由で借りて利用するクラウドで稼働させることが多く、その利用料は開発の見積書に含まれていない場合があります。

開発会社がよく利用するサービスの、2026年10月時点の公式料金は次のとおりです。

この表から、見積書を比較する際に確認すべき点は次の3つです。

1つ目は、無料プランを前提にしていないかです。Vercel の Hobby は個人の非商用向けで、企業での利用には Pro 以上が必要です。Supabase の Free は、1週間利用がないとプロジェクトが一時停止され、稼働できるプロジェクトも2つまでです。有料プランは、利用がなくても停止されません。見積書の月額費用が安い会社には、どのプランを前提としているかを質問しましょう。

2つ目は、利用量に応じて増える費用です。Vercel の Pro には月20ドル分の利用枠が含まれます。CDN（画像などを世界各地の近い拠点から配信する仕組み）のリクエストは月1,000万回までで、超過すると100万回ごとに2ドルから課金されます。データ転送は月1TBまでで、超過すると1GBあたり0.15ドルからです。Stripe の手数料も、売上の増加に比例して増えます。月額費用は、想定する利用量とあわせて記載するように依頼しましょう。

3つ目は、利用人数に応じて増える費用です。Vercel の Pro や GitHub の Team は、利用者数で料金が決まります。開発会社の担当者分の費用をどちらが負担するかも確認しましょう。

AWS や Google Cloud を利用する提案では、各社が公開している料金計算ツールで運用費の見積もりを作成してもらいましょう。AWS Pricing Calculator は無料で利用でき、見積もりをリンクで共有できるほか、CSV や PDF で出力できます。ただし、税金は含まれず、入力した情報のみにもとづく金額です。Google Cloud の料金計算ツールも、実際の月額請求額を正確に反映しない場合があります。そのため、計算結果だけでなく、入力した前提条件もあわせて提出するように依頼しましょう。

運用費は、前提の設定によって大きく変わります。私はあるプロジェクトで、性能を過大に見積もっていたサーバー構成を、実際のアクセスログ（利用状況の記録）にもとづいて見直し、月額費用を約半分に削減しました。「不安なので多めに」という前提で組まれた構成は、相見積もりの段階で見抜けます。サーバーの規模を何にもとづいて決めたのかを、各社に質問してください。

4. 成果物とアカウントの名義：自社名義になっているか

アカウントの所有者（オーナー）とは、サービスの契約者として権限を管理し、ほかの利用者を削除できる立場の人です。システムを稼働させるサービスの所有者が開発会社になっていると、開発会社を変更したい場合に、自社だけでは対応できません。

確認すべき点は次のとおりです。

• プログラムの保管先：リポジトリ（プログラム一式と、その変更履歴を保管する場所）を、自社の GitHub の組織（企業用のアカウント）に置くか。GitHub は、組織のオーナーの人数を最小限に抑えつつ、2人以上置くことを推奨しています。
• アプリ配信用のアカウント：Apple Developer Program に企業として登録するには、Apple と契約を結べる法人であること、D-U-N-S 番号（企業を識別するための9桁の番号）を保有していること、会社を代表して契約を締結する権限を持つ人が手続きを行うことが必要です。屋号や支店名では登録できません。Google Play は、登録時に個人用か組織用かを選択します。この手続きを誰が行うかを、見積もりに含めてもらいます。
• ドメインと各サービスの契約名義：ドメイン、Vercel、Supabase、Stripe などの契約者が、自社名義になっているか。
• 著作権：開発したプログラムの利用や改変について決定できる権利です。著作権法第61条は、著作権の全部または一部を譲渡できると定めています。一方で、譲渡契約において第27条と第28条の権利を譲渡の対象として明記していない場合、これらの権利は譲渡した側に留保されると推定されます。見積書や契約書の案に、この2つの条文の権利まで含めて譲渡する旨が記載されているかを確認しましょう。条文の解釈については、弁護士にご相談ください。

名義の確認が重要である理由は、私自身の経験にあります。日本で動画配信システムを構築した際、費用の安さを優先して、特定のデータベースから移行できない設計を選んでしまいました。その後、別のサービスへの移行を検討した際には、大規模な作り直しが必要になりました。この経験から、特定の業者に依存した場合に将来発生する費用も、見積もりの比較段階で必ず確認しています。

また、日本でライブドアに事業の譲渡を打診された際には、システムが自社開発か他社製品のライセンス利用か、特定の個人しか扱えない部分がないかが確認されました。システムの所有関係が明確であることは、将来その事業を売却する際にも評価の対象になるのです。

見積もりを比較し、発注先を選ぶ手順

1. 回答を1つの比較表にまとめる

各社の回答を、次のような1つの表にまとめます。空欄が残った項目は、全社に同じ質問をして補います。

2. 条件を統一した総額で比較する

前提を統一した初期開発費に、利用予定期間分の保守費と外部サービスの利用料を足し、その総額で比較します。初期開発費が安くても、運用費が高ければ総額は逆転します。計算は表計算ソフトを使い、全社に同じ計算式を適用しましょう。

3. 自社名義にできない会社は候補から除外する

アカウントやリポジトリを自社名義にできない会社や、著作権の扱いを明記できない会社は、金額が安くても候補から除外します。アカウントやプログラムが開発会社の名義のままだと、保守をほかの会社に切り替えられません。その状態で保守費用の値上げを求められても、断ることが難しくなるためです。

4. 開発会社そのものを評価する

金額と条件を比較したうえで、その会社が約束を履行できるかどうかも評価します。見積もりの前に開発会社について確認すべき点は、システム開発会社の選び方｜技術を知らない経営者が見積もり前に確かめる3つの点で説明しています。

よくある質問

相見積もりは何社に依頼すればよいですか

各社の回答を比較表にまとめ、不足している項目を質問して補うには、相応の手間がかかります。全社の回答を自社で比較し、質問のやり取りを継続できる社数に絞ってください。

最も安い見積もりを選んではいけませんか

前提条件・含まれない作業・完成後の運用費・名義の4点を統一したうえで安いのであれば、選んで問題ありません。見積金額だけで比較・判断するのは避けましょう。

開発会社のアカウントで開発してもらい、完成後に移管してもらえばよいのではありませんか

最初から自社名義で用意することをお勧めします。GitHub のリポジトリは、別の個人や組織へ所有者を移すこと（移管）ができ、変更履歴なども引き継がれます。ただし、移管には管理者権限が必要です。個人間の移管では、受け取る側が1日以内に確認メールから承認する必要があります。Apple Developer Program のように、企業として登録するには自社の D-U-N-S 番号や代表権を持つ人の手続きが必要なサービスもあります。完成後の移管を前提にすると、開発会社の協力がなければ手続きを進められません。

まとめ

• 相見積もりは、全社に同一の見積依頼書を渡し、対象外の機能・性能と障害対応の条件・見積書の書式を発注側で定めて依頼します。
• 金額差の理由は、前提条件、含まれない作業、完成後の運用費、成果物とアカウントの名義、の4点で確認します。
• 発注先は、条件を統一した総額で比較し、自社名義にできない会社は候補から除外します。

PH Tech AI は、社内に技術の責任者がいない中小企業やスタートアップに代わり、CTO代行・技術顧問として技術面の判断を支援しています。見積依頼書の作成、各社の見積書の比較、前提条件や名義の確認についても、発注側の立場でご支援します。見積書がお手元にある段階でも、これから依頼する段階でも、無料でご相談いただけます。お気軽にお問い合わせください。

参考・出典

• Vercel 料金ページ https://vercel.com/pricing （2026-10-12 確認）
• Supabase 料金ページ https://supabase.com/pricing （2026-10-12 確認）
• GitHub 料金ページ https://github.com/pricing （2026-10-12 確認）
• Stripe 日本の料金ページ https://stripe.com/jp/pricing （2026-10-12 確認）
• Apple Developer Program 登録の案内 https://developer.apple.com/jp/programs/enroll/ （2026-10-12 確認）
• Google Play Console ヘルプ（デベロッパーアカウントの登録料） https://support.google.com/googleplay/android-developer/answer/6112435?hl=ja （2026-10-12 確認）
• Cloudflare Registrar 製品ページ https://www.cloudflare.com/products/registrar/ （2026-10-12 確認）
• AWS Pricing Calculator ユーザーガイド https://docs.aws.amazon.com/ja_jp/pricing-calculator/latest/userguide/what-is-pricing-calculator.html （2026-10-12 確認）
• Google Cloud 料金計算ツール https://cloud.google.com/products/calculator?hl=ja （2026-10-12 確認）
• GitHub Docs（リポジトリの移管） https://docs.github.com/ja/repositories/creating-and-managing-repositories/transferring-a-repository （2026-10-12 確認）
• GitHub Docs（組織のロール） https://docs.github.com/ja/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization （2026-10-12 確認）
• e-Gov 法令検索 著作権法 https://laws.e-gov.go.jp/law/345AC0000000048 （2026-10-12 確認）
• スクラムガイド https://scrumguides.org/scrum-guide.html （2026-10-12 確認）
• IPA 情報システム・モデル取引・契約書 https://www.ipa.go.jp/digital/model/index.html （2026-10-12 確認）