見積が会社によって何倍も違う。どれが妥当で、どう比べればよいか

依頼文が機能の一覧程度の段階では、同じ依頼でも見積の金額は会社によって2〜3倍異なるのが普通で、金額だけを比較しても、どれが妥当かは判定できません。見積の金額は各社が依頼文から想定した開発の範囲、つまりどの機能をどの工程まで開発するかの値段です。会社ごとの金額の差の大半は、1人が1か月作業する量あたりの単価（人月単価）の差ではなく、この開発範囲の差から生じます。

依頼の前に要件を整理して同じ前提を全社に提示し、見積の内訳で開発範囲を統一してから比較します。

すでに複数の見積を受領している場合は、次の順で比較します。作業の大半は発注者が自社で実施し、開発会社への追加の依頼は最小限にします。

これは開発会社への配慮であると同時に、発注者自身の利益になります。自社で開発範囲を決定すれば、各社が同じ開発範囲を見積もるので金額をそのまま比較でき、丁寧に見積もる会社も辞退せずに応じます。決定した開発範囲は契約の範囲になるので、契約後に追加の費用が発生したときも、それが開発範囲の追加かどうかを自社で判定できます。

1. 受領した見積書の各社の前提と対象外を自社で1つの表に並記し、開発範囲の相違を特定する
2. 自社に必要な開発範囲を決定する
3. 候補の会社を選定し、その会社にだけ、決定した開発範囲を文書で提示して見積の出し直しを依頼する
4. 出し直した見積の内訳で、各社の金額の差の理由を確認し、記載の無い点だけを質問する
5. 金額の差の理由の説明と、運用する期間の費用の合計で選定する

見積の作成と出し直しは開発会社にとって、多くの場合、受注できるか分からない無償の作業です。出し直しの依頼は1回に限定し、回答の期限にも余裕を確保します。詳細な内訳の作成を辞退されたり、有償の作業として提案されたりすることもあり、それ自体は不誠実な対応ではありません。

見積の金額の何倍もの差は想定した開発範囲の差

人月は1人が1か月作業する量で、人月単価はその1人月あたりの金額です。見積の金額は人月単価と人月の積です。人月単価は会社の規模や体制によって異なり、個人の開発者と大手の開発会社の間では最大で3〜4倍の差があります。5倍、10倍の差が生じているときは単価の差だけでは説明できず、想定している作業の量が会社ごとに異なっています。

金額の差が生じる5つの要素

金額の差が生じる要素	何が異なるか	金額の差が拡大する条件
開発範囲の解釈	依頼文に記載の無い機能、画面、外部連携、データ移行を含めるか	依頼文が機能の名前だけで、対象外の記載が無い
工程の範囲	実装だけか、要件定義、設計、テスト、移行、プロジェクトの管理まで含めるか	見積の内訳が「開発一式」の1行
非機能の水準	同時に利用する人数、応答の速度、障害時の復旧、セキュリティの対策をどの水準で想定するか	依頼文に性能や稼働時間の記載が無い
不確実さへの上乗せ	確定していない部分を、後で必要になる前提で最初から見積に含めるか	要件が確定していない段階で、完成までの金額を求めた
作り方	一から開発するか、既存の製品やサービスを利用するか	依頼文に作り方の指定が無い

依頼文で縮小できる差と縮小できない差

開発範囲、工程、非機能の差は、依頼文に記載した分だけ各社の想定が一致するので縮小できます。これに対して不確実さへの上乗せは、要件の確定まで解消しません。

開発の契約には完成を約束して完成物に対価が発生する請負と、主に作業の時間に対価が発生する準委任があります。請負では契約で決定した範囲を完成させるための作業が想定より増加しても、開発会社は契約の金額のまま完成させます。範囲の追加や仕様の変更では、変更の手続きで金額と納期を協議します。

そのため要件が確定していない段階の請負では、開発会社は後で増加しそうな作業の分を最初から見積に上乗せします。たとえば「帳票の出力」とだけ記載した依頼なら、帳票が3種類か20種類かが不明なので、20種類に近い作業を想定して金額を固定する会社もあります。上乗せの量は会社がどこまでのリスクを負担するかで異なるので、要件が確定していない段階の請負の見積ほど、会社ごとの差が拡大します。

作り方の差は開発範囲を統一しても解消しません。既存の製品を利用する見積は初期の金額が低い代わりに、製品の利用料が毎月発生し、製品にできないことは実現できません。

一から開発する見積と比較するときは、初期の金額だけでなく、数年分の利用料と、実現できない機能も比較の対象にします。

開発会社は見積をどのように作成するか

見積は開発会社が依頼文から作業の量を推定したものです。

独立行政法人情報処理推進機構（IPA）のITユーザとベンダのための定量的見積りの勧めは、見積の作成の方法を、代表的な3つの方法で説明しています。どの方法で推定したかで、内訳に何が記載されるかと、金額の理由をどこまで説明できるかが異なります。

方法	何を基に推定するか	内訳に記載されるもの	適用する段階
類推	過去の類似の案件の実績の総額や人月	総額と、類似の案件との相違程度	依頼文が数行の段階の概算
積み上げ	機能と作業に分解した個々の人月	機能ごと、工程ごとの人月	機能の一覧や画面の一覧がある段階
算定式	画面、帳票、データの数のような工数を左右する要因を計数し、過去の実績から作成した式で人月に換算する	計数した要因と換算の式	要件定義の後で、実績のデータを保有する会社

内訳が総額だけか、機能ごと、工程ごとの人月まで記載されているかで、どの方法で作成した見積かを判別できます。

同じ資料は2つ以上の方法を併用して結果を相互に点検することを推奨しています。

丁寧に見積もる会社は積み上げで算出した人月を類推の結果と比較し、差が顕著な箇所では分解の不足を調査します。

類推だけで算出した金額は数日で提出できます。ただし過去の案件との相違を検討していなければ、どの機能をどこまで開発する前提なのかを見積を作成した会社自身も把握していません。その場合は金額の理由を質問しても、具体的な回答が得られません。

積み上げで丁寧に見積もる場合は、次の作業を何周も反復します。

• 依頼文を機能と作業に分解し、作業ごとに人月を積算する
• 依頼文に記載の無い点を発注者に質問し、回答の無い点は前提として記載する
• 前提が成立しなかったときに増加する作業をリスクとして特定し、該当する作業に上乗せする
• 不足している開発範囲と人月を社内の別の担当者が点検する
• 質問への回答で前提が変化すれば、分解から再実施する

IPAの超上流から攻めるIT化の原理原則17ヶ条も、見積の内容と金額の理由の明確化を受注者に求めています。

質問の中身で見積の丁寧さを判別する

開発会社の質問の内容から、その会社による依頼文の分解の程度が判明します。機能の一覧程度の依頼文に対して質問が1つも無いまま金額だけが提出されたら、その見積は類推で作成された可能性があります。

依頼文が要件定義の成果物のように詳細なら、質問の無いまま見積が提出されることもあります。

質問の有無だけでなく、何を質問してくるかも判別の材料になります。

質問の例	分かること
この機能は誰が、どの業務の、どの時点で利用するか	機能を業務の手順に分解している
既存のデータは何件あり、どこに保存されているか	移行の作業を見積に含めようとしている
何人が同時に利用し、停止が何時間まで許容されるか	非機能の水準を見積に反映しようとしている
今回は開発しない機能はどれか	範囲の区切りを確定しようとしている
予算はいくらで、何を達成すれば成功か	予算の中で何を優先するかを提案しようとしている

目的、業務、データ、非機能を質問してくる会社は、その回答を前提として見積に反映しようとしています。質問の回答がどの前提として見積に記載されたかを確認すれば、開発範囲を把握したうえでの見積かを判定できます。

相場の金額ではなく人月で判定する

相場の金額は規模によって桁が異なる

システム開発の相場として公開されている金額の多くは、開発会社や比較サイトが自社の取引から集計したもので、集計した件数や条件が示されていないものが多くあります。

件数と条件を示している調査に、ユーザー企業の団体が実施している一般社団法人日本情報システム・ユーザー協会（JUAS）のソフトウェア・メトリクス調査2025があります。この調査で既存の製品を利用せずに一から開発した、スクラッチ開発のプロジェクト99件の外注費の平均は、次のとおり規模によって桁が異なります。

工数の規模	外注費の平均
10人月未満	850万円
10〜50人月	約2,950万円
50〜100人月	約7,570万円
100〜500人月	約1億9,400万円

規模を統一せずに相場の金額と比較しても、見積の高低は判定できません。

単価はほぼ一定なので人月で比較する

同じ調査の99件の外注費を工数で除算すると、平均単価は1人月96万円でした。工数の区分別の単価は10人月未満の6件が185万円と高額です。10〜50人月は95万円、50〜100人月は109万円、100人月以上は95万円で、10人月を超えると単価は95〜109万円です。

この調査では10人月を超えると規模による単価の差は金額の桁の差より軽微なので、相場との比較は人月で実施します。ただし個々の会社の単価は平均と異なるので、受領した見積では先に各社の単価を確認し、そのうえで「この範囲をこの人月で開発できるか」を内訳で確認して判定します。

たとえば30人月の見積は96万円の単価で約2,900万円です。同じ開発範囲で900万円の見積を提出した会社には、次の4つの可能性があります。

• 10人月以下で開発する計画
• 単価が平均よりかなり低額
• 既存の製品を流用する計画
• 開発範囲の一部を含んでいない

どれなのかは内訳で判別します。

準委任で1か月の精算の時間を決定している場合は、その時間も会社ごとに異なります。同じ人月単価でも1か月の時間が少ない会社のほうが1時間あたりの単価は高額です。たとえば人月単価100万円で1か月140時間を精算する会社は1時間あたり約7,100円、180時間なら約5,600円です。見積書に精算の時間の記載が無ければ質問し、比較の前に1時間あたりの単価に換算します。

要件が確定していないなら完成までの金額は比較しない

たとえば「会員の管理機能」とだけ記載した依頼では、ある会社は会員の登録と一覧だけを想定します。別の会社は権限の管理と退会の処理まで想定します。丁寧に見積もる会社でも確定していない部分は前提を設定して推定するしかありません。この段階で完成までの金額を比較しても、各社の想定の差を比較することになります。

IPAの原理原則17ヶ条は不確定要素が多い段階の見積をプロジェクトの目標値にすべきではないとし、要件の固まり具合に応じて見積を段階的に出し直す多段階の見積を推奨しています。

この段階で比較できるのは概算の幅と各社の前提です。完成までの金額を比較するには、先に要件を整理して、各社が同じ開発範囲を見積もる状態にします。

見積を依頼する前に要件を整理する

開発会社は依頼文に記載の無い部分を想定で補完するので、整理されていない部分が多いほど、見積は会社ごとに分散します。

発注者が整理する事項

発注者が自社で整理できる事項は次のとおりです。

整理する事項	内容
目的	どの業務のどの問題を解決するか。何を達成すれば成功か
今の業務の手順	誰が、どの順番で、どのシステムや帳票で作業しているか
機能と画面の一覧	機能ごとに、誰が何をするための機能か。最初の公開に必須の機能と、後で追加してもよい機能
対象外	今回は開発しない機能、自社で実施する作業
外部連携	連携する相手のシステムと、手作業のCSVで対応するか、自動で連携するか
データ移行	移行するデータの件数と、今のデータの保存場所
非機能	利用する人数、稼働時間、障害時に許容できる停止時間
体制	自社の担当者が要件の決定とテストに確保できる時間
未決定の事項	社内でまだ決定していない事項と、決定する時期

すべてを整理できない場合も、機能の一覧と対象外の2項目だけは記載します。対象外の記載があるだけで、開発範囲の解釈の差はかなり縮小します。未決定の事項も未決定であると記載すれば、開発会社はそこを前提として明記して見積もるので、各社の前提を統一できます。

要件定義だけを先に発注する

自社で整理しきれない場合は、要件定義だけを先に発注し、要件が確定してから開発を見積もり直します。

JUASの調査では要件定義の工数は全体の15%程度なので、全体の予算の一部で、残りの85%の見積の精度を向上できます。要件定義の成果物として、機能の一覧、画面の一覧、業務の手順、非機能の要件を受領することを契約で決定しておけば、その成果物を依頼文にして、開発を複数の会社に見積もってもらうこともできます。IPAと経済産業省の情報システム・モデル取引・契約書も、工程ごとに契約を分割し、要件が明確になった段階で見積を出し直す多段階の契約を採用しています。要件定義の後に出し直すのは概算の見積で、金額の確定は外部設計の後になります。要件定義は作業の時間に対価が発生する準委任、内部設計からシステムの結合までは完成を約束する請負とし、外部設計とシステムのテストは状況に応じてどちらかを選択する分担です。外部設計は画面や帳票（システムが出力する書類）、他のシステムとの接続のような外部の仕様の設計で、内部設計はプログラムとデータの構造の設計です。

丁寧に見積もる会社が応じる依頼の仕方

見積の多くは開発会社の無償の作業

概算の見積の作成は通常は無償で、受注できなければ作業の費用を回収できません。このため丁寧に見積もる会社ほど、時間をかけるに値する依頼かを先に判定します。

ソフトウェアの業界団体である一般社団法人情報サービス産業協会（JISA）は受注チェックシートを公開しています。このチェックシートも受注の前に「顧客予算や予備費は確認できたか」「プロジェクト開始時点でRFP又は要求事項を明文化した文書が存在し、顧客と合意しているか」を確認するよう求めています。RFPは発注者が要件と条件を整理して開発会社に提示する提案依頼書です。

辞退されやすい依頼

判定の材料の無い依頼は辞退されるか、類推の概算だけが提出される可能性があります。

依頼の状態	開発会社が辞退する理由
依頼文が数行で、機能の一覧も無い	作業に分解できず、提出しても実態の無い金額になる
予算、発注の時期、決裁者が不明	発注されるかを判定できない
依頼する社数が多い、または社数が不明	受注できる確率が低く、価格の調査のための依頼とみなされる
詳細な内訳を短い期限で求める	丁寧に見積もる時間が無い

依頼の時点で提示する情報

整理した要件と一緒に、時間をかけるかを判定できる次の情報を提示します。

• 予算の目安
• 発注の時期と決裁の手順
• 依頼する社数と選定の基準
• 求める見積の精度: 概算の幅か、発注できる確定額か

予算の目安を提示すれば各社はその金額で開発できる範囲を提案するので、同一の金額を前提にした提案どうしを比較できます。概算で十分な段階で確定額を求めると、辞退されるか、不確実さを上乗せした高い金額が提出されます。

確定額を依頼するときは次の内訳での提出の希望を依頼の時点で提示します。後から追加で求めるより、最初から提示するほうが開発会社の作業は少なくなります。

• 工程ごとの人月: 要件定義、設計から実装と結合テストまで、総合テスト、移行、プロジェクトの管理
• 機能ごとの人月
• 人月単価と、準委任なら1か月の精算の時間
• 前提と対象外: 想定した開発範囲と、含んでいない作業

3社の見積の比較の例

最初に提出された見積

次は予約の管理システムの依頼に3社が見積を提出した場合の架空の例です。依頼文は10個の機能の一覧だけで、対象外の記載はありません。

	A社	B社	C社
総額	600万円	1,500万円	3,000万円
内訳	開発一式	要件定義2、設計から結合テスト9、総合テスト4人月	要件定義3、設計から結合テスト14、総合テスト5、移行2、管理2人月、リスク費400万円
人月単価	不明	100万円	100万円
前提と対象外	記載なし	既存データの移行は対象外	同時に500人が利用する前提で、障害時も停止しないようサーバを二重化する

金額は5倍異なりますが、この時点ではどれが妥当かを判定できません。最初に、A社に内訳を質問します。A社の600万円は単価80万円で7.5人月の実装と、機能ごとの動作を確認する単体テストの金額でした。要件定義と総合テストは発注者が実施し、管理者の画面も含まない前提です。

開発範囲を統一して出し直した見積

次に、発注者が自社に必要な開発範囲を決定して次の条件を3社に提示し、見積の出し直しを1回だけ依頼します。

• 要件定義から総合テスト、既存データの移行、プロジェクトの管理まで含める
• 管理者の画面を含める
• 同時に利用する人数は50人程度とし、サーバの二重化は不要とする
• 未決定の事項の一覧を添付し、開発の金額は要件定義の完了後に見積もり直す

	A社	B社	C社
要件定義	2人月	2人月	3人月
設計から結合テスト	12人月	9人月	11人月
総合テスト	4人月	4人月	5人月
移行	2人月	2人月	2人月
プロジェクトの管理	2人月	1人月	2人月
合計	22人月	18人月	23人月
総額	1,760万円	1,800万円	2,300万円

開発範囲を統一すると5倍の差は1.3倍程度に縮小し、最も低額だったA社とB社はほぼ同額になります。A社は単価の低さを人月の多さが相殺し、総額はB社と同程度です。C社の回答では二重化のための構成とその試験が3人月で、これを設計から結合テストまでの工程から除外し、14人月が11人月になります。400万円のリスク費は未確定の要件への上乗せだったので、要件定義の完了後に見積もり直す条件を提示した結果、C社が除外しました。

統一した後の選定

統一した後もC社とB社には5人月の差があります。内訳は要件定義、設計から結合テスト、総合テスト、管理で、どの工程もC社のほうが多めです。

この人月の差の理由を各社に質問し、回答から次の基準で選定します。

• 人月の差の理由を工程や機能の単位で説明できない会社は除外する
• C社のように各工程を手厚く見積もる会社は、その分の作業を実施する計画なので、自社にその作業が必要かで判定する
• 総額の差が説明できる範囲なら、質問への回答の具体性、担当者の体制、見積の前提の明確さも基準にする

最も低い見積の会社を選定しない場合は、この統一した後の比較表を社内に提示します。社内の承認者が最初に注目するのは金額の大小なので、開発範囲の差を示さなければ、承認者は高い会社を選定した理由を理解できません。

内訳から妥当性を判別する

統一した内訳を工程ごとの人月の比率に換算し、JUASの同じ調査の比率と比較します。この調査の区分での工数の比率は要件定義15、設計から結合テスト60、総合テスト25です。結合テストは複数の機能を接続して動作を確認する試験で、総合テストはシステム全体を実際の業務の手順で確認する試験です。

要件定義から総合テストまでを一括で依頼した見積で、ある工程の比率がこの半分以下なら、その工程を誰が担当する前提なのかを自社から開発会社に質問します。

内訳の特徴	想定される理由	質問すること
要件定義の人月が極端に少ない	要件は発注者が決定する前提にしている	要件を決定する作業を誰が担当するか
テストの人月が極端に少ない	総合テストを発注者が実施する前提にしている	総合テストの範囲と担当
移行とプロジェクトの管理の行が無い	開発範囲に含んでいない	移行と管理は別料金か、対象外か
機能ごとの人月が一律	機能の中身を検討せずに配分している	一番重い機能と、その理由
全体が他社の半分以下	既存のライブラリや製品を流用する、または開発範囲が不足している	流用するものと、その制約

低い見積が誤りだとは限りません。既存の製品を流用して開発の量を削減する提案なら、低価格の理由を説明できます。

理由を説明できない低価格の見積には含まれていない作業があり、その作業は契約後に追加の費用として請求されるか、実施されずに不具合の原因になるおそれがあります。

高い見積も同様に理由を質問します。非機能の水準や移行の範囲を依頼文よりも手厚く想定していないかを質問し、その想定が自社に必要なら高い見積のほうが妥当です。

極端に低い見積と極端に高い見積で実際に多い典型は次のとおりです。

見積	多い典型	確認すること
極端に低い	総合テスト、移行、プロジェクトの管理を含んでいない	内訳の工程の行と、対象外の記載
極端に低い	単価の低い、経験の浅い担当者が中心の体制で、人月の増加や品質の低下が発生しやすい	担当者の経験と体制、機能ごとの人月
極端に高い	確定していない要件の分を、リスク費や広めの想定で上乗せしている	上乗せが何を想定したものか。要件の確定後に減額されるか
極端に高い	依頼文に記載の無い非機能の水準を想定している	同時に利用する人数、停止の許容時間、サーバの二重化の有無

見積書の行の読み方

見積書には内訳の人月以外にも、比較の前に確認する行があります。

見積書の行	意味	確認すること
開発一式	開発範囲と人月が判明しない総額	工程ごと、機能ごとの人月
プロジェクトの管理	進捗の管理、会議、報告、課題の調整の作業	何の作業か。会社によっては各工程の人月に含めていて、行が無くても対象外とは限らない
リスク費、予備費	確定していない部分への上乗せ	何を想定した上乗せか。要件が確定した後に減額されるか
前提条件	見積が成立する条件	自社の想定と一致するか。成立しなかったときにどう見積もり直すか
仕様の変更	契約後に開発範囲を変更するときの扱い	変更の手順と、変更分の単価
契約不適合責任の期間（保証の期間）	検収の後に、仕様書と異なる不具合の修正や損害賠償を請求できる期間	期間の長さと、対象になる不具合の範囲
有効期限	見積の金額が有効な期間	発注の時期までに失効しないか

内訳を提出できない見積の扱い

要件が確定していない段階では、誠実な会社ほど工程別や機能別の人月を提出できません。作業の内容が確定していない間に人月を配分すると、実態の無い数字になるためです。

その場合は人月の内訳を求めず、見積書に前提と対象外の記載が無いときだけ、その記載を依頼します。

たとえば「会員の登録、一覧、退会の3機能。権限の管理と既存の会員データの移行は含まない」のように記載されていれば、何を開発する前提で、何を含んでいないかが判明し、他社の見積と開発範囲を比較できます。前提と対象外も提出できない見積は、開発範囲が判明しないので比較の対象から除外します。

見積に含まれない費用も比較する

開発の見積は通常は開発の作業の費用だけを含みます。IPAの原理原則17ヶ条も、システムを実現する費用はソフトウェアの開発だけではないとして、教育、移行、周辺のシステムとの連携の費用も計上するよう求めています。次の費用は別に発生し、会社や作り方によって金額がかなり異なるので、見積の依頼の時点で開発会社に概算の記載も依頼します。

費用	内容	会社によって異なる点
サーバとクラウドの利用料	本番と検証の環境の月額	非機能の水準と構成。二重化すると利用料も増加する
外部サービスと製品の利用料	決済、メール配信、地図、既存の製品のライセンス	既存の製品を利用する見積では、開発費が低額な代わりに利用料が高額になる
保守と運用	障害の対応、ライブラリの更新、問い合わせの対応	月額の固定か、作業の時間に応じた費用か。何が保守の範囲に含まれるか
自社の作業	要件の決定、テスト、データの準備、利用者への説明	開発会社の担当範囲が限定的な見積ほど、自社の作業は増加する

開発費が最も低額の見積でも利用料と保守を含めた数年分の合計では最も高額になることがあります。比較は開発費だけでなく、システムを利用する予定の年数分の合計で実施します。

この比較の方法を省略できる場合

前提を統一して内訳で比較する方法には手間がかかります。次の場合はこの方法を省略できます。

• 改修の範囲が画面1つや機能1つのように明確で、見積の金額も少額なので、比較の手間が差額を上回る
• 今のシステムの保守を担当している会社への追加の改修。他社は中身を把握していないので、相見積を依頼しても調査の費用が上乗せされるだけ
• 準委任で月額の上限を決定し、その範囲で開発を進行することを社内で合意している。比較するのは総額ではなく、体制、単価、1か月に何を完成させるか

見積の比較でよくある誤解

最も低い見積と最も高い見積の中間を選定すれば安全

最も低い見積と最も高い見積の中間の会社を選定しても、安全とは限りません。金額の順位は開発範囲の順位と一致せず、中間の金額の会社が中間の範囲を想定しているとは限らないので、内訳で開発範囲を統一してから比較します。

相見積は多くの会社に依頼するほど正確になる

多くの会社に依頼しても、前提を統一していなければ見積は正確になりません。金額の差の原因を判別できない見積が増加し、依頼する社数に応じて各社の受注の確率も低下するので、辞退や概算だけの回答も増加します。各社に質問へ回答する手間をかけることも考慮すると、比較できるのは3社程度です。

人月単価が低い会社ほど総額も低い

総額は単価と人月の積で、人月は会社の経験と体制によって異なります。単価の低い会社が他社より多くの人月を見積もり、総額では高くなることもあります。

要件定義とテストを削減すれば総額を削減できる

要件定義とテストの人月を削減すると見積の金額は減少しますが、作業そのものは消滅しません。要件定義を削減すれば開発の途中で仕様を決定し直す作業が発生し、テストを削減すれば公開の後に不具合の修正が発生します。金額を削減するなら工程ではなく、最初の公開に含める機能を削減します。

請負で金額を固定すれば予算を超過しない

請負で固定されるのは契約時に決定した開発範囲の金額です。開発の途中で開発範囲を追加すると、追加分は変更の見積として別に請求されます。要件が確定していない段階では、開発範囲の追加による上振れか、最初からの上乗せのどちらかが発生します。