システム開発の見積もりが高いか判断する方法原価と需要の2軸

2026年9月26日

この記事でわかること

見積もりが高いと感じたら、まず原因を5つに切り分ける
見積書の妥当性を5項目のチェックリストで判断する
相見積もりで2倍以上の差が出たら、差の出どころを分解する
依頼先の種類と選び方：会社のタイプで見積額は変わる
新規事業の開発見積もりは「需要の確度」でも判断する

システム開発の見積もりを受け取り、この金額は高いのではないかと迷っている方に向けた記事です。見積もりが高いかどうかは、原価と需要の2つの軸で判断できます。原価は、内訳・人月単価・前提条件を点検すれば、手元の見積書だけで確かめられます。新規事業のように作ったものが売れるかどうか分からない案件では、原価が妥当でも判断がつきません。その場合は、値引きを求める前に需要を確かめるという選択肢があります。

知りたいこと	答え	該当する章
この金額は相場から外れているか	相場表と比べるのではなく、内訳・単価・前提条件を点検して判断する	見積書のチェックリスト
他社と2倍違うのはなぜか	機能数・人月・単価・テスト比率・含まれない作業のどこに差があるかを分解する	相見積もりの読み方
社内にどう説明するか	4つの判断と、それぞれを選ぶ条件で示す	払う以外の選択肢の比較

見積もりが高いと感じたら、まず原因を5つに切り分ける

見積書を受け取って高いと感じたとき、その感覚の出どころは一つではありません。単価や工数が実際に多く積まれている場合もあれば、見積もりに含まれる範囲が想定より広いだけの場合もあります。原因によって取るべき行動が変わるため、交渉や相見積もりに進む前に、どれにあたるかを切り分けておくと判断が速くなります。

原因	見分け方	次の行動
原価そのものが高い	役割別の単価や工数が、他社や公開されている目安より大きい	単価と工数の根拠をベンダーに確認する
前提条件とスコープが広い	前提条件の欄に、データ移行や受入テスト支援などが含まれている	自社で担える作業と、後から発注できる作業を洗い出す
品質・非機能要件を厚く見ている	テスト工程の比率が高い、または可用性やセキュリティの水準が明記されている	求める水準が事業の実態に見合っているかを確認する
比較の相手が適切でない	比べている相手が相場表の数字や、前提の異なる他社の見積もりである	前提をそろえて見積もりを取り直す
回収の見込みが見えていない	内訳に説明のつかない点がないのに、金額に納得できない	作ったものがどれだけ売上を生むかを先に確かめる

原価そのものが高い

単価は担当者の経験や会社の体制によって決まり、工数は機能の数や作り込みの深さをどう見たかによって決まります。どちらもベンダーに根拠を尋ねれば説明が返ってくる種類の差のため、内訳があれば確かめられます。

前提条件とスコープが広い

同じ機能一覧を渡しても、どこまでを見積もりに含めるかは会社によって異なります。データ移行やマニュアル作成、リリース後の初期対応まで含めた見積もりは、含めない見積もりより金額が大きくなります。この場合の差は原価の高さではなく、引き受ける範囲の広さから来ています。

品質・非機能要件を厚く見ている

止まってはいけない業務システムや、個人情報を扱うシステムであれば、テストやセキュリティを厚く見ることには理由があります。一方で、社内の少人数が使うツールに同じ水準を求めているなら、要件のほうが事業の実態を上回っていないかを確かめる価値があります。ベンダーが前提にしている水準は見積書に書かれていないこともあるため、質問して確認しておくとよいでしょう。

比較の相手が適切でない

Web上の相場表は、案件の規模や前提をそろえた数字ではないため、自社の案件とは直接比べられません。他社の見積もりと比べている場合も、スコープや品質の前提がそろっていなければ、金額の差はそのまま割高や割安を意味しません。

4つを確認しても内訳に説明のつかない点がないのに、金額に納得できないことがあります。これは、作るものがどれだけの売上を生むかが見えていないために、判断がつかない状態だと考えられます。既存業務の置き換えであれば効果を見積もりやすいものの、新規事業では売上の見込みそのものが仮説です。そのため、新規事業の開発見積もりではこの状態になりやすく、確認方法は後半の「需要の確度」の章で扱います。

見積書の妥当性を5項目のチェックリストで判断する

原因の見当がついたら、見積書そのものを項目ごとに点検します。次の表は、確認する項目ごとに危険サインと、ベンダーにそのまま送れる質問文をまとめたものです。判断の目安となる数値は、各項目の説明で出典とあわせて示します。

確認項目	危険サイン	ベンダーへの質問文
工程別の内訳	工程が分かれていない、またはテストの行がない	工程ごとの工数と、テストに単体テストを含むかどうかを教えてください
人月単価	役割ごとの単価と人月が分かれていない	役割ごとの単価と、それぞれ何人月を想定しているかを教えてください
前提条件	見積もりに含まれない作業が書かれていない	含まれない作業と、当社側で用意するものを一覧でいただけますか
バッファ・保守費	予備費の率や、保守の対応範囲が書かれていない	予備費は何%で、どのリスクに備えたものですか。保守費にはどの作業が含まれますか
「一式」表記	金額の大きな項目が一式でまとめられている	一式の項目について、作業内容と工数の内訳をいただけますか

工程別の比率は、定義をそろえてから比べる

受託開発会社が公開している工程比率の目安は、会社によって大きく異なります。たとえばテスト工程を全体の10〜15%とする記事もあれば、開発工数の30〜50%とする記事もあります。これは、母数を全体とするか設計からテストまでに限るか、単体テストをどちらに数えるかといった定義が違うためです。

公的なデータとしては、IPAの『ソフトウェア開発分析データ集2022』が、新規開発270件の実績工数から工程別の比率を示しています。中央値は基本設計16.5%、詳細設計15.7%、製作31.6%、結合テスト20.1%、総合テスト11.9%です。結合テストと総合テストを合わせると、約32%になります。この値には要件定義が含まれていないため、見積書と比べる際は、要件定義を除いた設計からテストまでの合計を母数にして計算し直してください。そのうえでテストの比率が大きく下回っている場合は、テストの範囲をベンダーに確認しましょう。

人月単価は、役割ごとの人月とあわせて確認する

人月単価の目安は、公開している会社によって次のように幅があります。いずれも受託開発会社が自社サイトで公開している値で、統計調査によるものではありません。

役割	公開されている目安（月額）
プログラマー・若手エンジニア	40万〜100万円
中堅エンジニア	70万〜120万円
シニアエンジニア・技術責任者	100万〜180万円
プロジェクトマネージャー	85万〜180万円
海外拠点での開発（オフショア）	20万〜60万円

出典：シースリーインデックス、FIXIT、ブライセン、Timedoorの公開記事をもとに作成。

幅がこれだけ広いと、単価が目安の範囲に入っているかどうかでは妥当性を判断できません。確認したいのは、どの役割の人が何人月入る想定になっているかです。PMの単価が高くても関与が期間の一部であれば総額への影響は小さく、反対に単価の低い体制でも、人月が多く積まれていれば総額は大きくなります。

前提条件の欄で、含まれない作業を確認する

見積書の前提条件は、その条件が崩れたときに追加費用や納期の変更を認める根拠として働きます。確認したいのは、見積もりに含まれない作業、発注側が用意するもの、発注側の確認にかかる日数の想定の3点です。3点目は見落とされやすい項目です。ベンダーが数日での回答を前提にしているのに社内の決裁がそれより長くかかると、その待ち時間は追加の工数として後から返ってきます。

バッファと保守費は、率と対象を確認する

予備費（バッファ）は、着手後に判明する不確実性に備えるための費用です。PMIに掲載された論文は、固定価格のITサービス案件の予備費を15〜25%程度としています。そのうえで経験則として、10%を下回らず25%を上回らない範囲を挙げています（Cooper, 2002）。25%を超える場合は、不確実性が大きすぎるため、固定価格の契約自体が適しているかを問い直すべきだとしています。率が高いときは値引きを求めるより、どのリスクに備えたものかを聞き、そのリスクを減らす情報を渡すほうが下げやすくなります。

保守費は、受託開発会社が公開している目安が年間で開発費の5〜20%と幅があります。率を比べるより、障害対応だけか軽微な改修まで含むか、サーバー費をどちらが負担するかといった対象の範囲を確認しましょう。

「一式」の項目は、理由を添えて内訳を依頼する

金額の大きな項目が「一式」でまとめられていると、ここまでの確認がどれもできません。依頼する際は「一式の項目について、作業内容と役割ごとの工数を分けて記載いただけますか。社内稟議で内訳の説明が必要なためです」のように理由を添えると、依頼の意図が伝わります。それでも内訳が出てこない場合は、その対応自体を、相見積もりで各社を比べる際の判断材料に加えてください。

相見積もりで2倍以上の差が出たら、差の出どころを分解する

複数社から見積もりを取ると、総額に2倍以上の開きが出ることがあります。どちらかが不当に高い、または安いと決める前に、差がどの要素から来ているかを分解すると、選ぶべき会社と交渉すべき点が見えてきます。

各社に渡す情報と窓口を一つにそろえる

差を分解できるのは、各社が同じ情報をもとに見積もっている場合に限られます。口頭での補足が会社ごとに違ったり、予算を一部の会社にだけ伝えていたりすると、金額差の多くはその情報の違いから生まれます。すでに見積もりが出そろっている場合は、各社の前提を並べて食い違う点だけを全社にそろえ、再見積もりを依頼すると手間が小さくなります。

総額を5つの軸に分けて並べる

総額の差は、次の5つの軸に分けて並べると、どこから来ているかが分かります。

比較軸	差が大きいときの読み方
想定している機能数・画面数	作る範囲の解釈が違っている
合計の人月	作り込みの深さや、体制の厚さの想定が違っている
平均の人月単価	会社の体制や、担当者の経験の想定が違っている
テスト工程の比率	品質の水準の置き方が違っている
含まれない作業と予備費	引き受けるリスクの範囲が違っている

差が1つの軸に集中していれば、その軸の理由だけを各社に聞けば足ります。たとえば人月がほぼ同じで単価だけが違うなら、体制と担当者の経験を比べ、どちらが案件に合うかを判断することになります。複数の軸で差が出ている場合は、前提がまだそろっていないと考えられるため、前の手順に戻りましょう。

最も安い見積もりには、含めていない作業を聞く

最も安い見積もりには、同じ範囲を効率よく作れる根拠がある場合と、他社が含めている作業を含めていない場合があります。前者であれば、類似案件の実績や再利用できる部品といった具体的な説明が返ってきます。後者であっても、含まれていない作業を自社で担えるのであれば、安い見積もりを選ぶことには合理性があります。

依頼先の種類と選び方：会社のタイプで見積額は変わる

同じ要件でも、どのタイプの会社に依頼するかで見積額は変わります。各社には得意な案件の規模があり、その規模から外れた案件では、体制や管理の仕組みが案件に合わず、金額が高く出やすくなるためです。見積もりが高いと感じたときは、依頼先のタイプが案件に合っているかも確かめておきましょう。

開発会社のタイプごとに、見積もりが高く出やすい条件が違う

タイプ	主な案件規模の目安	見積もりが高く出やすい条件	確認すること
大手SIer	数千万円〜数十億円	小規模な案件。管理の層が厚く、間接費が乗りやすい	実際に開発する会社と担当者
中堅SIer・独立系の受託開発会社	500万〜数億円	高い可用性や厳しい規制対応が求められる案件	類似する規模・業種の実績
Web系・スタートアップ向けの開発会社	300万〜5,000万円	大規模で長期の保守が前提の案件	担当者が抜けたときの体制
海外拠点を組み合わせる会社	―	仕様が固まっておらず、やり取りが多くなる案件	日本側の設計・レビュー体制

規模の目安：FIXIT「システム開発の見積もり完全ガイド」の整理をもとに作成。海外拠点を組み合わせる会社の規模は、同記事の整理に含まれていないため記載していません。

大手SIerでは、契約した会社が要件定義と全体の管理を担い、実装を協力会社が担うのが一般的です。管理の層が厚いぶん単価は上がりますが、大規模で止められないシステムを安定して運営できるのは、この体制の強みです。一方で、小規模な会社では、提案した担当者がそのまま開発に入ることが多くなります。間接費が小さいぶん単価は下がりやすい反面、担当者に依存する度合いは高くなります。どちらが優れているかではなく、案件の規模と、許容できるリスクの種類で選ぶものだと考えています。

見積もりの妥当性を相談する先は、立場で選ぶ

見積もりの妥当性を自社だけで判断できない場合、相談先には主に次の3つがあります。

別の開発会社：相見積もりやセカンドオピニオンとして意見をもらえます。ただし相手にとっては受注の機会でもあるため、その立場を踏まえて意見を聞きましょう。
ITコンサルタント・PMO：開発を請け負わない立場から評価を受けられますが、多くは有償です。
社内外の開発経験者：費用はかかりませんが、見てもらえる範囲はその人の経験の範囲に限られます。

新規事業の開発見積もりは「需要の確度」でも判断する

ここまでは、見積もりの原価が妥当かどうかを確かめる方法を扱ってきました。ただ、新規事業や新サービスの開発では、原価に問題がなくても判断がつかないことがあります。作ったものが売れるかどうかが分からなければ、見積額が高いかどうかも決められないためです。この章では、需要がどれだけ確かかという軸から、見積もりを判断する方法を扱います。

需要を確かめる必要がある案件と、ない案件

すべての開発で需要を確かめる必要はありません。次の表のように、使う人と使い道が決まっている案件では、前半で扱った原価の点検だけで判断できます。

案件の性質	需要の確度	開発前に需要を確かめる必要
既存業務のシステム化・置き換え	利用者と業務量が分かっている	なし。原価の点検で判断する
法令や制度への対応	対応すること自体が決まっている	なし
既存顧客から要望が出ている機能	要望した顧客がいる	要望した顧客への確認で足りる
既存事業の新しい顧客層に向けた開発	その顧客層に需要があるかが仮説	あり
新規事業・新サービス	買う人がいるかどうか自体が仮説	あり

見積額を「回収に必要な成約数」に置き換える

需要を確かめる必要がある案件では、見積額を次の式で成約数に置き換えると、高いかどうかを事業の言葉で議論できます。

回収に必要な成約数＝開発見積額 ÷ 1顧客あたりの粗利（回収を見込む期間内）

たとえば必要な成約数に対して、見込み客がそもそも存在するかが分からない状態であれば、見積額が妥当でも発注の判断はつきません。反対に、その数の顧客を取れる見通しが立っていれば、見積額が相場より高くても投資として説明できます。この式に入れる数字は自社でしか持っていないため、上長に説明する際は、自社の粗利と回収期間を入れて示してください。

【実例】広告費約10万円・2週間で観測できたこと

需要をどこまで測れるかの参考として、カリアドが実施した検証の結果を紹介します。この事例はシステム開発の案件ではなく、法人向けレンタル・サプライ業の企業が、新しい顧客層に需要があるかを確かめたものです。そのため開発費を減らせた効果は示せませんが、開発の前に何をどの程度の費用で測れるかの参考になります。

検索広告と検証用のページを2週間運用し、見込み客の反応を次のように記録しました。

段階	件数	前の段階からの割合
広告の表示	約1,850回	―
クリック	129件	約7.0%
問い合わせ・資料請求	15件	約11.6%
商談	5件	約33%
成約	2件	約40%

広告費は約10万円で、問い合わせだけでなく成約まで確認できました。一方で、依頼企業が自社の強みと考えていた品質管理の設備や、小ロットでの対応を打ち出した広告は、2週間を通じて一度も表示されませんでした。これらの言葉で業者を探している人は、この期間にはいなかったということです。作る側が差別化の要素と考えているものが、見込み客の探す入口になっているとは限らないことを示しています。開発に置き換えれば、差別化のつもりで作り込む機能を、初期の範囲から外す判断材料になると考えています。ただし、本事例は開発案件ではないため、この点は推論です。

この規模の検証で分かること、分からないこと

約10万円の広告費で得られる件数には限りがあり、分かることと分からないことがはっきり分かれます。顧客層ごとのクリック率については、民泊事業者に向けた広告が約17%、業態を限定しない広告が約6%でした。統計的な誤差の幅（95%信頼区間）を計算しても両者の範囲は重ならないため、この差は偶然ではないと判断できます。

一方、クリックに対する問い合わせの割合は、民泊事業者向けが20%、業態を限定しない広告が約9%でした。こちらは誤差の幅が大きく重なっているため、差があるとは言えません。商談化率や成約率も、商談5件と成約2件から算出した値のため、目安として使える精度はありません。

また、本事例には2つの弱点があります。1つは、成約がどの顧客層から生まれたか、成約金額や成約までの期間を追跡していないことです。もう1つは、どの数値を上回れば事業を進めるかという基準を、検証の前に決めていなかったことです。そのため、結論は全体の数値と成約が発生した事実から判断しており、これが次の判定表の最初の行を置いた理由でもあります。

検証の結果をどう読み、次に何をするか

検証の結果は、次の表のどの状態にあたるかで読み分けます。どの行にも当てはまらない場合や件数が少なすぎる場合は、「判断不能」を正式な結論として扱います。二択にすると、判断がつかない結果が社内の事情で進める方向に寄せられやすくなるためです。

観測された状態	意味	次の行動	本事例
検証の前	基準がないと、結果を都合よく読めてしまう	許容できる問い合わせ単価と、進める条件を決めて社内で合意する	基準を置いていなかった
狙った言葉で表示がほぼ出ない	その言葉では探されていない	言葉を変えて再検証し、それでも出なければ開発を保留する	品質管理・小ロットの訴求
表示はあるがクリックが少ない	探されているが、訴求が響いていない	訴求と、打ち出す機能の優先度を見直す	―
クリックはあるが問い合わせがない	ページか提案内容の問題、または件数不足	クリックが少ないうちは判断不能として期間を延ばす	―
問い合わせはあるが商談にならない	見込み度の低い反応か、狙う層のずれ	問い合わせの内容を確認する	―
商談・成約まで進んだ	需要が存在する	反応した層と言葉に範囲を絞り、開発見積もりの検討に進む	成約2件
件数が少なく、どれとも言えない	判断不能	期間か予算を足すか、測り方を変える	―

新規事業の開発に進む前に、需要を数値で確かめたい方は、カリアドの無料相談をご利用ください。検索広告と検証用のページで見込み客の反応を測り、2週間で続けるかどうかの判断材料をお渡しします。

この見積もりに払う以外の選択肢を公平に比べる

見積もりが高いと感じたとき、取れる行動は発注するか値引きを求めるかの2つだけではありません。次の表は、見積もりを受け取った段階で取れる選択肢を、費用の目安と限界をそろえて並べたものです。費用の目安は、出典のある公開情報がある場合にのみ記載しています。

選択肢	費用の目安	得られるもの	限界
そのまま発注する	見積額どおり	最も早く開発に着手できる	需要が未確定なら、回収できない金額を投じることになる
範囲を削って再見積もりを取る	削る範囲によって下がる	初期費用を抑え、残りは後から判断できる	どこを削るかの根拠が社内に必要になる
相見積もり・セカンドオピニオンを取る	開発会社への相談は無料の場合が多い。ITコンサルは有償で、公開された相場は確認できなかった	金額の妥当性を外から評価できる	需要があるかどうかは分からない
SaaS・パッケージ・ノーコードで代替する	ノーコードでの業務アプリの外注は50万〜200万円程度	スクラッチ開発より安く、早く始められる	複雑な機能や独自の業務には対応しにくく、提供元の仕様に依存する
内製する	社内の人件費	開発の知見が社内に残る	開発できる人材が社内に必要になる
調査会社でアンケートやインタビューを行う	ネットリサーチは数万円〜150万円程度、インタビューは一例で150万〜170万円程度	購入の意向とその理由が分かる	答えた意向と実際の購買は一致するとは限らない
広告と検証用のページで需要を測る（自社運用・広告代理店・検証サービス）	広告費は予算次第で、本記事の事例では約10万円。ほかにページ制作と運用の費用がかかる	実際に探している人の反応と、問い合わせ以降の数値が分かる	成約の中身は営業側で追跡しないと分からない
何もしない・延期する	かからない	判断を先送りできる	機会を逃す。見積もりには通常1〜3か月の有効期限があり、延期すれば再見積もりになる

出典：ノーコードはゼロイチスタート、調査会社の費用は楽天インサイト、見積もりの有効期限はシースリーインデックスとFIXITの公開記事による。

決裁者には、4つの選択肢と条件で説明する

上の表を社内で説明する際は、選択肢を4つにまとめ、それぞれを選ぶ条件と組み合わせて示すと議論が進めやすくなります。

判断	選ぶ条件
そのまま発注する	見積書の点検で説明のつかない点がなく、需要も確定している
範囲を削って発注する	原価は妥当だが、初期に必要な機能が絞り込める
開発以外の手段で代替する	業務が標準的で、既存のSaaSやノーコードで要件を満たせる
発注の前に需要を確かめる	新規事業や新しい顧客層向けで、回収に必要な成約数が取れるかどうか分からない

見積もりを受け取ってから決裁までの判断手順

ここまでの内容を、見積書を受け取ってから決裁に出すまでの手順に並べ直すと、次のようになります。各手順で作る成果物は、そのまま上長への説明資料の材料になります。

手順	やること	成果物
1	高いと感じる原因を5つのどれにあたるかで切り分ける	原因の見立て
2	チェックリストで見積書を点検し、ベンダーに質問を送る	質問と回答の一覧
3	複数社の見積もりがある場合は、差を5つの軸に分解する	比較表
4	案件の需要の確度を判定し、必要なら回収に必要な成約数を出す	需要の確度の判定と、必要な成約数
5	選択肢を比べ、4つの判断のどれを選ぶかを決める	判断と、その条件

手順を原価の点検から始めるのは、手元の見積書とベンダーへの質問だけで進められ、費用がかからないためです。一方、需要を確かめるには費用と時間がかかります。そのため手順4は、新規事業や新しい顧客層に向けた開発のように、原価の点検だけでは判断がつかない案件に絞って行います。既存業務のシステム化であれば、手順3までの結果で判断して問題ありません。

最初の一手としては、見積書の前提条件の欄を読み、見積もりに含まれていない作業を書き出すところから始めてください。ベンダーへの最初の質問は、その一覧から作れます。