開発の見積もりは、なぜ会社ごとに違うのか：見積もる側が置く前提と、3社を同じ物差しで比べる方法（Excel つき）

「同じ内容で3社に見積もりを頼んだら、420万円、650万円、680万円と出てきた。どれが妥当なのか分からない」。業務システムの開発を頼もうとしている会社から、こうした相談を受けることがあります。

クリーヴァは、見積もりを出す側の会社です。見積もりを作るとき、依頼の文書に書いていないことは、自分たちで前提を置いて埋めるしかありません。この前提の置き方が会社ごとに違うので、金額も違ってきます。発注する側からは前提が見えにくいので、金額だけが並んで見え、比べようがなくなります。

この記事は、業務システムの開発をはじめて複数の会社に見積もってもらう、中小企業の担当者に向けて書いています。次のことを順にまとめます。

• 見積もる側が、何から金額を出しているか
• 金額が会社ごとに違う5つの理由
• 公的な資料が勧める見積もりの取り方
• 3社の見積もりを、同じ物差しで比べる手順

見積書の一般的な項目や、相見積もりの頼み方・断り方は、SucSak の「システム開発の見積もりの見方とサンプル・工数・妥当性を解説」と「システム開発の相見積もりは何社取る？頼み方と断り方まで解説」にまとまっています。この記事では、見積もる側の目線から見た金額の差の正体と、それをそろえて比べる手順に絞ります。

結論：金額の差は、前提の差。前提をそろえてから、3年間の合計で比べる

先に結論を書きます。

• 見積もりの金額は、依頼の文書と、見積もる側が置いた前提から出ています。前提が会社ごとに違うと、同じ依頼でも金額は大きく違います
• 差が出やすい前提は、範囲の読み方、件数や画面の数、含めた作業（データの移行・テスト・環境・打ち合わせ）、作り方、段階の分け方の5つです
• 比べる前に、同じ依頼書・機能の一覧・回答の様式を各社に渡し、前提が書いていない所を聞いて埋めます
• 金額は、初期費用だけでなく、月額と「見積もりに入っていない作業」を足した3年間の合計で比べます。初期費用の安い順と、3年間の合計の安い順は、入れ替わることがあります

見積もる側は、何から金額を出しているか

まず、見積もりを作る側が何をしているかを書きます。会社によって細かいやり方は違いますが、クリーヴァの場合はおおむね次の順で進めます。

1. 機能を書き出し、種類と大きさで数える

依頼の文書と打ち合わせのメモから、必要な機能を1つずつ書き出します。「お客様の一覧」「修理の受付」「訪問の予定」のような単位です。それぞれの機能を、登録と一覧のような基本の機能か、承認の流れがある機能か、外のサービスとつなぐ機能か、といった種類に分け、扱うデータの量や例外の多さから大きさを決めます。種類と大きさが決まると、作る手間の見込みが出ます。

2. どの案件にも要る作業を足す

機能を作る手間のほかに、どの案件にも要る作業があります。ログインと権限、サーバーや環境の準備、テスト、打ち合わせと進行の管理、作った後の手直しの余裕です。IPA の「実務に活かすIT化の原理原則17ヶ条」も、原理原則の6番目に「システム化実現の費用はソフトウェア開発だけではない」を挙げ、受注する側の行動規範として「見積りに含まれる内容と根拠を明確化する」と書いています。

見積もりが安く見えるときは、この共通の作業が抜けていないかを、見積もる側も最初に疑います。

3. 分からない所に、前提を置く

依頼の文書には、必ず書いていないことがあります。移すデータは何件か、職人はスマホから使うか、夜間も使うか、承認は何段階か。打ち合わせで聞ける範囲は聞きますが、残った所は「お客様の一覧は約2,500件、移す作業は含む」のように前提を置いて数えます。前提を置かずに止まると、いつまでも見積もりが出せないからです。

4. 後から増えそうな所を、先に書く

前提を置いた所は、外れると金額が変わります。クリーヴァでは、後から追加になりそうな所を、見積もりの時点で書いて伝えるようにしています。後から「実は追加の費用が」と切り出すのは、発注する側にとって一番困ることだからです。

5. 最初は範囲を決める段階、その後に作る段階

要件が固まる前の見積もりは、どうしても幅が出ます。クリーヴァでは、最初の段階で業務を整理して作る範囲とやらないことを決め、社内の説明や稟議に使える見積もりを出し、そのうえで作る段階に進む形をとっています。必要なものを必要な分だけ作るためです。

ここまでを読むと分かるとおり、見積もりの金額は、見積もる側が置いた前提の上に立っています。前提が違えば、金額も違って当たり前です。

金額が会社ごとに違う、5つの理由

同じ依頼でも金額が違うとき、差はたいてい次の5つのどこかから来ています。

1. 範囲の読み方

依頼の文書に「訪問の予定を管理したい」と書いてあるとき、予定の重複の警告や、お客様への前日の連絡まで含むと読むかどうかは、会社によって違います。読み方が広い会社ほど、金額は上がります。機能の一覧に優先度（必須・できれば・後で）を付けて渡すと、この差はかなり小さくなります。

2. 置いた前提

件数、画面の数、使う人の数、承認の段数など、依頼に書いていない数字は、見積もる側が置きます。少なめに置いた会社は安く、多めに置いた会社は高くなります。前提が見積もりに書いてあれば、そろえることができます。書いていなければ、聞いて書いてもらいます。

3. 含めた作業

データの移行、テスト、環境の準備、打ち合わせ、操作の説明。これらを見積もりに入れるか、別料金にするか、発注する側の作業とするかは、会社ごとに違います。IPA の17ヶ条が言うとおり、費用はソフトウェアを作る部分だけではありません。入っていない作業は、後で誰かがやることになります。

4. 作り方

既製のサービスを設定して使う方法と、個別に作る方法では、お金のかかり方が違います。既製のサービスは初期費用が抑えられる代わりに、月額の利用料がかかり続けることが多く、個別の開発は初期費用が大きくなりがちです。どちらが良いかは業務によって違うので、初期費用だけで比べず、月額を含めた期間の合計で比べます。

5. 段階の分け方

要件定義から作るところまでを一括で見積もる会社は、まだ決まっていない所の分の余裕を、金額に含めざるを得ません。要件定義だけを先に見積もり、作る段階は要件が決まってから見積もる会社は、最初の金額が小さく見えます。後者は、作る段階の金額がまだ決まっていないことを忘れずに比べます。

公的な資料は、見積もりをどう取ることを勧めているか

見積もりの取り方については、IPA とデジタル庁の資料に、発注する側が知っておきたい考え方が書かれています。

見積もりは、段階を追って精度を上げるもの

IPA と経済産業省の「情報システム・モデル取引・契約書〈第二版〉」は、作り方の方針として「多段階契約（工程ごとに個別契約を締結する。）と再見積り（曖昧さがある段階の見積りを、要件が明確になった段階で見積りなおす。）の考え方を採用した」と書いています。同じ契約書の解説は、画面や帳票などを決める外部設計の段階で確定した見積もりができる、という考えも示しています。

IPA の「ユーザのための要件定義ガイド 第2版」も、見積もりの精度は時間がたつにつれて上がるとして、都度見積もり直すべきだとしています。17ヶ条の5番目は「多段階の見積りは双方のリスクを低減する」で、本文には「多段階とは、受注先をその都度変えるということではなく、固まり具合に応じて見積り精度をあげていこうということです」とあります。

モデル契約の解説は、流れも具体的に書いています。要件定義の段階では、発注する側が要件定義の支援を準委任で頼み、できた要件定義書をもとに提案依頼書を各社に示して、まず「概算見積」を受ける。画面や帳票が決まる外部設計の後に、確定した見積もりを出す。要件定義書がない状態で取る見積もりは、この概算よりもさらに前の段階のものだということになります。

つまり、要件が固まる前に出てくる見積もりは、もともと幅のあるものです。最初の見積もりで1社に決め打ちし、その金額を動かせない予算にしてしまうと、要件が固まったときに困ります。最初の見積もりは、予算の枠と進め方を決める材料と考えるのが現実的です。

見積もりを頼むときは、必要な情報を渡す

デジタル庁の「デジタル・ガバメント推進標準ガイドライン」は、国の調達のためのルールですが、民間の発注にもそのまま役立つ書き方をしています。事業者から見積もりを取るときは、実現したい業務や機能の内容、規模、サービスのレベル、日程など、見積もりに必要な情報を渡すこと。原則として、複数の事業者の見積もりを比べること。

渡す情報が少ないほど、見積もる側が置く前提が増え、会社ごとの差が広がります。何を渡すかは「提案依頼書（RFP）を書く前に決めること」で詳しく書いています。

同じ様式で出してもらい、内訳ごとに比べる

デジタル庁のガイドラインの解説書（実践ガイドブック）は、さらに具体的です。見積もりの内訳を「一式○○円」と書くのではなく、妥当性を確かめられる粒度で書いてもらうこと。同じ粒度で比べられるように、発注する側が見積もりの様式を指定して提出を求めるのが望ましいこと。見積もりの合計額を単純に平均するのではなく、内訳の項目ごとに、見積もりの対象や前提条件、制約条件まで確かめること。

発注する側が様式を決めて渡す、というのがこの記事の手順の中心です。

3社の見積もりを、同じ物差しで比べる手順

ここからは、実際に3社の見積もりを比べる手順です。記事の最後に、この手順をそのまま使える Excel を用意しています。

手順1：同じ3点を、全社に渡す

各社に渡すのは、提案依頼書、機能の一覧、回答の様式の3点です。機能の一覧には優先度を付け、今のやり方（Excel・紙・電話など）も書きます。今のやり方が書いてあると、見積もる側は作る量を読みやすくなります。

手順2：回答の様式で、金額と前提を返してもらう

回答の様式には、費目ごとの金額（要件定義・設計・開発・テスト・データの移行・環境の準備・打ち合わせと進行の管理）、月額（利用料・保守）、そして前提について12の問いを並べます。

• 機能の一覧の「必須」は全部入っているか
• 見積もりで置いた前提（件数・画面の数など）
• 発注する側にお願いする作業
• 見積もりに入っていない作業
• 段階の分け方
• 契約の形（請負か準委任か）
• 契約不適合責任の期間（公開した後に見つかった不具合を無償で直す期間）
• ソースコードの著作権
• 体制（実際に入る人）
• 期間
• 支払いの条件
• 前提が変わったときの扱い

提案書や見積書が別の形で届いても構いません。この並びで書き写せれば、比べられます。

手順3：質問は、全社に同じ答えを返す

見積もりの途中で、各社から質問が届きます。ある会社の質問に答えた内容は、ほかの会社にも同じように返します。1社だけが知っている前提があると、その会社の見積もりだけ前提が違ってしまうからです。

手順4：前提の確認を ○△× で付け、△ と × を聞いて埋める

届いた回答を、前提の確認の12項目で ○（書いてある）・△（一部）・×（書いていない）に分けます。△ と × は、金額を比べる前に聞いて埋めます。とくに「見積もりに入っていない作業」と「発注する側の作業」は、聞かないと出てきません。

手順5：3年間の合計で比べる

金額は、次の式で比べます。

• 3年間の合計 ＝ 初期費用 ＋ 月額 × 36か月 ＋ 見積もりに入っていない作業を別に頼んだときの金額

業務システムは、作った後も使い続けるものです。初期費用が安くても、月額が高ければ、数年で逆転します。

記入例：初期費用の安い順と、3年間の安い順が入れ替わる

架空の設備会社（従業員40名）が、修理の受付と訪問の予定を管理するシステムを3社に見積もってもらった例です。金額は書き方を示すためのもので、相場ではありません。

初期費用だけ見ると B社が一番安く、3年間の合計で見ると A社が一番安くなります。ただし A社は、前提が書いていない所が7つあり、発注する側の作業や、前提が変わったときの扱いも書いていません。聞いて埋めると、金額が動く余地が一番大きいのは A社です。3社の3年間の合計の差は2%以内なので、この例では、前提の明確さと進め方で選ぶのが妥当です。

一番安い見積もりを見たときに、確かめること

一番安い見積もりが悪いわけではありません。ただ、安さの理由を確かめずに選ぶと、後から費用が増えます。次の4つを確かめます。

1. 必須の機能が全部入っているか：入っていない機能があれば、別に頼んだときの金額
2. データの移行とテストが入っているか：入っていなければ、誰がやるか
3. 発注する側の作業が多くないか：マスタの入力やテストを、社内でどれだけ担う前提か
4. 月額がいくらか：既製のサービスの利用料が、使う人の数で増えないか

IPA の要件定義ガイドは、「一番安いから」といった理由でベンダーを選んでしまう例を、よくない選び方として挙げています。金額は大事な物差しですが、物差しの目盛りをそろえてから当てるものです。

見積もりの差を小さくするために、発注する側でできること

見積もりの差の多くは、依頼の文書の書いていない所から生まれます。発注する側でできることは、次の4つです。

• 機能の一覧に優先度を付ける：必須・できれば・後でを分けると、範囲の読み方がそろいます
• 件数と人数を書く：データの件数、使う人の数、1日の件数。おおよそで構いません
• やらないことを書く：範囲の外を書くと、各社の前提がそろいます
• 予算の枠を伝えるかを決める：伝えると、各社が同じ枠の中で、何を入れて何を外すかを提案します

それでも、要件が固まる前の見積もりには幅が残ります。その幅は、要件定義の段階で小さくしていくものです。要件定義で社内にまとめておくことは「要件定義とは：開発会社に頼む前に、社内でまとめておくこと」で書いています。

金額の外で、比べておく3つのこと

見積もりの金額が近いときほど、金額の外の条件で差がつきます。回答の様式で聞いた項目のうち、次の3つは契約のときに効いてくるので、比べる段階で見ておきます。

契約の形：請負か、準委任か

IPA のモデル契約の解説は、2つの違いを「請負ではベンダは仕事（受託業務）の完成の義務を負うのに対し、準委任ではベンダは善良な管理者の注意をもって委任事務を処理する義務を負うものの、仕事の完成についての義務は負わない」と説明しています。モデル契約自体も、要件定義は発注する側の作業を開発会社が支えるものとして準委任型、外部設計は準委任型か請負型、内部設計からプログラミング、テストまでは請負型と、工程ごとに形を分けています。同じ金額でも、どの工程がどちらの形かで、開発会社が引き受ける責任の範囲が違います。一括の見積もりで、全部が請負になっているのか、要件定義だけ準委任なのかを確かめます。

契約不適合責任の期間

公開した後に、約束どおりに動かない所が見つかったとき、無償で直してもらえる期間です。モデル契約の条文はこの期間を空欄にしていて、解説も、一律の期間に固定するのではなく、当事者が適切な期間を決めることを想定しています。各社の見積もりで期間が違えば、その差も比べる材料です。

ソースコードの著作権

モデル契約は、著作権をどちらに置くかについて、いくつかの案を並べています。そのうえで、発注する側が著作権を譲り受けたいときは、事前に提案依頼書でその旨を明らかにすることを求めています。将来ほかの会社に保守を頼む可能性があるなら、見積もりの段階で各社の扱いを確かめておきます。くわしくは「ソースコードの著作権は誰のものか」で書いています。

見積もりを頼んでから決めるまでの日程

日程に余裕がないと、前提を聞いて埋める時間がなくなり、結局金額だけで決めることになります。3社に頼む場合、次のくらいの日程を見ておくと、手順の1から5まで進められます。

見積もりを作る側から見ると、回答までの期間が短すぎる依頼では、分からない所を聞く時間がとれず、前提を多めに置かざるを得ません。その分、金額は高めに出やすくなります。

社内で予算を通すときの説明

見積もりを比べた結果を社内で説明するときは、次の4つをそろえると話が進みやすくなります。

1. 何のためのシステムか：困っていることと、うまくいったと言える数字（例：予定を組む時間を半分に）
2. 3社の比較の表：3年間の合計と、前提が書いていない所の数
3. 選んだ理由：金額だけでなく、前提の明確さ、進め方、保守の内容
4. 金額が動く所：要件定義の後に見積もり直す部分と、その幅

とくに4つ目を先に伝えておくと、要件定義の後に金額が変わっても、社内で「聞いていない」となりにくくなります。

おわりに

見積もりの金額が会社ごとに違うのは、見積もる側が置いた前提が違うからです。金額に戸惑ったら、まず前提を見ます。同じ依頼書・機能の一覧・回答の様式を全社に渡し、質問の答えは全社に返し、前提が書いていない所を聞いて埋めてから、3年間の合計で比べてください。

そのまま使える「開発の発注準備シート」の Excel を用意しました。提案依頼書のひな形、機能の一覧、各社に書いてもらう回答の様式、3社の見積もりを12項目と3年間の合計で比べる表、質問と回答の記録の5つが入っています。架空の設備会社の記入例つきです。

Excel を開かずに、ブラウザで数字を入れて試せる「開発の見積もりの比較」もあります。入力した数字はどこにも送りません。

開発の発注準備シートの Excel をダウンロードする

登録は要りません。中身の説明は「開発の発注準備シート」のページにまとめています。はじめて開発会社に相談するときの準備は「開発会社に初めて相談する前に」で説明しています。依頼の文書づくりや、届いた見積もりの読み方のご相談は、クリーヴァでもお受けしています。

出典（2026年11月11日に確認）

• IPA・経済産業省「情報システム・モデル取引・契約書〈第二版〉」（2020年12月、2025年4月更新）
• IPA「ユーザのための要件定義ガイド 第2版」（2019年12月）
• IPA「実務に活かすIT化の原理原則17ヶ条」（2010年10月）
• デジタル庁「デジタル・ガバメント推進標準ガイドライン」と実践ガイドブック（2026年6月12日版）