システム開発の見積もりがなぜ年々高くなるのか。中小企業が知っておくべき単価上昇の構造と対策

3年前に作ってもらったシステムの追加開発を、同じ開発会社に見積もり依頼したら、当時の1.5倍近い金額が出てきた。担当者は驚き、「うちの要求が特別高くなったわけでもないのに、なぜこんなに上がるのか」と疑問を持ちます。相見積もりを取っても、どの会社も似たような水準の金額を提示してくる。「足元を見られているのでは」と勘繰りたくなる気持ちも分かりますが、実際には多くの中小企業が同じ壁にぶつかっています。

この記事は、システム開発やアウトソーシングの見積もりを見て「なぜこんなに高くなったのか」と感じている担当者、あるいはこれから発注しようとして相場観がつかめず不安な担当者に向けて書きました。専門用語は初出時に言い換えます。結論から言うと、見積もりが年々高くなっているのは、御社への交渉が下手だったからでも、担当者の見る目がなかったからでもありません。業界全体の構造的な要因が積み重なった結果であり、そのことを理解しているかどうかで、次の発注での判断の質が大きく変わります。

この記事で分かること

先に、要点をまとめます。

• システム開発の単価が上がっているのは、エンジニアの人手不足による人件費上昇と、AI・クラウド等の専門技術への需要集中が主な要因です
• 単価上昇そのものを止めることはできませんが、見積もりの内訳を分解して交渉できる部分を見極めることと、発注の仕方そのものを工夫することで、実質的な負担を抑えることは可能です
• ただし、単価の安さだけを追いかけて発注先を選ぶと、後で「安物買いの銭失い」になりやすい落とし穴があります。この点は記事の後半で具体的に説明します

なお、単価が上がっているという事実は複数の業界データで確認できる一方、上昇率そのものは会社・地域・技術領域によって幅があります。以下で示す金額は、公開されている複数の相場情報をもとにした目安であり、実際の見積もりはこの記事の内容を踏まえたうえで、必ず個別に確認してください。

なぜシステム開発の見積もりは年々高くなるのか

疑問形で言えば「見積もりが高くなっているのは発注側の問題ではないのか？」ですが、答えは「多くの場合、発注側ではなく市場側の構造変化が主因」です。

システム開発の見積もりは、基本的に「人月単価 × 開発期間 × 開発人数」という工数積算で算出されます。つまり見積総額を左右する最大の変数は、エンジニア1人を1ヶ月稼働させたときの単価そのものです。この単価が、ここ数年で継続的に上昇しています。

背景にある要因は、大きく3つに整理できます。

1. エンジニアの人手不足による処遇改善

DX(デジタルトランスフォーメーション)を推進する企業が増え続けている一方、それを担えるエンジニアの供給は追いついていません。人手不足の職種では、企業が優秀な人材を確保するために提示する待遇そのものが上がります。この処遇改善分は、当然ながら開発会社が受託する際の見積もりにも転嫁されます。

2. AI・クラウドなど専門技術への需要集中

生成AI・大規模言語モデル(LLM)を組み込んだ開発や、クラウド基盤(AWS・Azure・GCP等)を前提とした設計・運用のスキルを持つエンジニアへの需要が急増しています。こうした専門技術に対応できる人材は市場全体でも希少なため、単価にはっきりとした差が生まれています。「同じ人月数」でも、扱う技術領域によって見積もりの水準が変わってくるのは、この需要の偏りが理由です。

3. 業界内の職種別単価差の拡大

同じ「エンジニア」という括りでも、経験年数・専門領域によって単価には大きな幅があります。公開されている業界の単価情報を見ると、経験の浅い層(概ね3年未満)で月30万円台〜、中堅層(3〜7年程度)で月60万円台〜90万円程度、上級層(7年以上)になると月90万円〜150万円程度という水準が一つの目安として示されています。プロジェクトマネージャーやITコンサルタントのような上流工程を担う職種は、これよりさらに高い水準になる傾向があります。

つまり、御社が依頼する開発の中身が「上流の設計・要件整理を厚く必要とする案件」なのか、「決まった仕様をコーディングするだけの案件」なのかによっても、動員される人材の単価構成が変わり、結果として見積もりの総額が変わってくるということです。

この構造は、開発会社1社の営業方針や利益率で決まっているものではありません。開発会社にとっても、優秀なエンジニアを確保し続けるためには相応の処遇を用意する必要があり、その原資は当然、受託する案件の見積もりから捻出されます。つまり単価上昇は、発注者と開発会社のどちらか一方が得をする話ではなく、業界の人材需給という外部環境の変化を、発注者・開発会社の双方が分かち合っている構図だと理解しておくと、見積もり交渉の場でも冷静に臨みやすくなります。

御社の場合、もし過去の見積もりと比べて金額が上がっていたとしても、それだけで「この開発会社は信頼できない」と判断するのは早計です。まずは次の章で説明する内訳の分解を通じて、上昇分がどこに由来しているのかを確認することから始めてください。

ただし、単価上昇が発注者側にとって「もっぱら不利な話」というわけでもありません。単価が上がっている領域ほど、開発会社の側も受注確保のために提案内容を工夫する動機を持ちます。実際、単価の高いAI・クラウド領域では、複数の開発会社が「まず小さく試してから本契約に進む」という段階発注の提案を積極的に行うようになってきています。この記事の後半で、発注者側からこの流れを活用する方法を説明します。

契約形態によっても、単価の乗り方が変わる

見積もりの内訳を理解するうえで、もう一つ押さえておきたいのが契約形態です。システム開発の契約は、大きく請負契約と準委任契約の2つに分かれ、どちらの形態で契約するかによって、単価上昇の影響の受け方が変わってきます。

請負契約は「完成させること」自体に対して報酬が支払われる契約形態です。見積もり時点で開発会社側が完成までの全工数を見積もり、そこに単価上昇分を織り込んで総額を提示します。発注者から見ると、契約後に追加費用が発生しにくい(=総額が確定しやすい)反面、見積もり段階で開発会社がリスクを見込んで単価を高めに設定する傾向があります。仕様が固まっている案件に向いた形態です。

準委任契約は「業務の遂行」自体に対して報酬が支払われる契約形態で、多くの場合、稼働した工数(人月・人日)に単価を掛け合わせて費用が確定します。仕様変更が発生しやすい案件、あるいはアジャイル型で段階的に開発を進める案件でよく使われます。この形態では、エンジニアの人月単価がそのまま総額に直結するため、単価上昇の影響をより直接的に受けます。

どちらが「得」というものではなく、案件の性質に応じて選ぶべき契約形態が異なります。仕様が明確で完成物のイメージが固まっている案件は請負、要件が流動的で試行錯誤しながら進める案件は準委任が向いているのが一般的な目安です。両者の違いをより詳しく知りたい場合は、関連記事の請負契約と準委任契約の違いを参照してください。

いずれの契約形態でも、見積もりの根拠となる作業範囲を明確にした書面(SOW（作業範囲記述書）)を契約前に確認しておくことが、単価上昇局面ではより重要になります。作業範囲があいまいなまま契約すると、「ここまでは含まれていたはずだ」という認識のズレが、追加費用の請求という形で表面化しやすくなるためです。

見積もりの内訳、どこが上がっていてどこが交渉の余地があるのか？

見積もりの上昇要因は主に人件費部分であり、進行管理費・保守費は比率が大きく変わりにくい一方、要件定義や機能範囲は交渉の余地が残っています。

システム開発の見積書は、一般的に次のような内訳で構成されます。

この内訳のうち、発注者側が直接コントロールしやすいのは「要件定義・設計」と「実装」の対象範囲です。ここが交渉の余地になります。

具体的には、次のような工夫で総額を抑えられる可能性があります。

• 機能の要否を「必須(Must)」と「あったら良い(Want)」に分けて依頼する: 初期リリースをMustの機能だけに絞り込むことで、実装費用の対象範囲そのものを小さくできます。Wantの機能は後日の追加開発に回す判断です
• 要件定義の精度を発注者側で事前に高めておく: 「使いやすいシステムにしてほしい」のような抽象的な依頼では、開発会社側が要件を詰めるための工数(=見積もりに乗る要件定義費用)が膨らみます。「誰が、どんな場面で、何をするための機能か」を事前に言語化しておくほど、この部分の見積もりは圧縮できます
• 既製のSaaS・パッケージで代替できる範囲を切り分ける: 全機能をフルスクラッチで作る前提を疑い、汎用的な機能(勤怠管理・請求書発行等)は既存のSaaSに任せ、自社固有の業務ロジックだけをスクラッチ開発する設計にすると、実装対象そのものが減ります

一方で、進行管理費・保守費のように「案件の性質上、必ず一定比率が必要になる」項目は、値切り交渉の対象にしにくい部分です。ここを無理に削らせようとすると、後述する「安さの代償」につながりやすいので注意してください。

業種・技術領域によって、上昇幅に差があるのはなぜか

専門性の高い技術領域ほど単価上昇の幅が大きく、汎用的な業務システムの開発は相対的に上昇が緩やかです。

すべてのシステム開発案件が、同じ比率で値上がりしているわけではありません。ここでも押さえておくべきなのは、単価は「技術領域ごとの需給バランス」で決まるという原則です。

• 生成AI・LLMを組み込む開発: 対応できる人材が市場全体で希少なため、上昇幅が最も大きい領域です。RAG(社内データを参照させる仕組み)の構築など、専門性の高い実装が絡む案件ほど単価は高くなる傾向があります
• クラウド基盤の設計・運用: AWS・Azure・GCP等の設計スキルを持つ人材への需要も高く、オンプレミス(自社サーバーでの運用)からの移行案件は上昇幅が相対的に大きくなりやすい領域です
• 業務システムの汎用的な機能開発: 勤怠管理・在庫管理・請求書発行のような、確立された設計パターンがある機能の開発は、専門技術領域ほどの急激な上昇は見られにくい傾向があります

御社が発注しようとしている案件が、この3分類のどこに近いかを事前に整理しておくと、見積もり金額が妥当な水準かどうかの当たりをつけやすくなります。汎用的な業務システムの開発なのに、専門技術領域並みの単価を提示された場合は、その理由を開発会社に確認する価値があります。

もう一つ押さえておきたいのが、地域による単価差です。都市部に拠点を置く開発会社は、オフィス賃料・人材獲得競争の激しさから、単価水準がやや高めに設定される傾向がある一方、地方拠点の開発会社やリモート主体で稼働する開発会社では、同じ技術領域でも単価が抑えられているケースがあります。ただし、単価の地域差だけを理由に発注先を選ぶと、対面での打ち合わせ頻度やレスポンスの速さといった別の要素で不便が生じることもあるため、金額と対応のしやすさを総合的に比較することをおすすめします。

相見積もりを取っても金額が横並びなのはなぜ？

単価上昇は業界全体の構造要因のため、まっとうに見積もる会社ほど似た水準の金額になるのが自然です。

「3社に相見積もりを取ったのに、どこも似たような金額だった」という状況に遭遇すると、談合を疑いたくなる担当者もいますが、実際には別の理由であることがほとんどです。

前述の通り、単価上昇の主因はエンジニアの人手不足という市場全体の構造変化です。この構造変化はどの開発会社にも等しく影響するため、同じ工数・同じ技術領域の案件であれば、相場観を正しく反映して見積もる会社ほど、金額は自然と近い水準に収束します。むしろ極端に安い見積もりが1社だけ出てきた場合のほうが、警戒すべきサインです。

ある製造業の総務担当者は、3社から見積もりを取ったところ、2社は近い金額だったものの、1社だけ突出して安い金額を提示してきました。「一番安いところに決めよう」と考えかけたところ、社内の別部署から「その安さの理由を聞いてから決めた方がいい」と助言を受け、確認したところ、テスト工程と保守契約の期間が他社より大幅に短く設定されていたことが分かりました。結果的に、他社と条件を揃えたうえで再比較し、真ん中の金額の会社に発注したといいます。

反対に、あるサービス業の担当者は、3社の見積もりがほぼ同水準だったことから「どうせ同じ金額なら」と提案内容を比較する手間を省き、最初に連絡をくれた会社にそのまま発注しました。開発が進む中で、その会社が想定していた運用イメージと自社の業務実態にズレがあることが分かり、追加の仕様調整が発生。結果的に、当初の見積もりより2割ほど総額が膨らんだといいます。金額が横並びだった場合こそ、提案内容の中身を比較する意味が大きいことを示す事例です。

相見積もりを取る本来の目的は、金額の比較だけでなく提案内容・技術力・対応範囲の違いを比較することにあります。金額差だけに気を取られると、対応範囲の違いを見落としたまま「安いから」という理由だけで発注先を決めてしまうリスクがあります。この点は、関連記事の相見積もりの取り方と比較の観点でさらに詳しく扱っています。

単価上昇局面で発注者がやりがちな失敗と回避策

単価が上がっている局面だからこそ陥りやすい失敗パターンがあります。あらかじめ知っておくことで、同じ轍を踏まずに済みます。

失敗例1: 安さだけで発注先を決めて、後から追加費用がかさむ

見積もりの総額だけを見て、他社より大幅に安い会社を選んだところ、契約時点では想定していなかった機能が「別途見積もり」として次々と追加され、結果的に当初の相場並みかそれ以上の総額になってしまうケースです。安い見積もりは、多くの場合「対応範囲を絞って安く見せている」だけであり、後から必要になった機能を追加すれば、その分の費用は当然発生します。

回避策は、契約前に見積書に含まれる機能の範囲を明文化した書面(作業範囲記述書に相当する資料。前章で触れたSOWと同じ考え方です)を確認し、範囲外の作業が発生した場合の追加費用の算出方法まで、契約前に確認しておくことです。

失敗例2: 単価上昇を理由に、保守・運用の質を落とした会社を選んでしまう

「単価が上がっているから仕方ない」という理由付けを鵜呑みにして、本来必要な保守体制・障害対応の質を確認しないまま契約してしまうケースです。単価上昇の説明自体は業界の実態として正しくても、それが「保守対応の質を落としてよい理由」にはなりません。値上がりの説明と、対応範囲の縮小は別々に確認すべき事柄です。

失敗例3: 社内向けの説明で「なぜ高くなったか」を言語化できず、稟議が通らない

現場担当者は市場相場の変化を理解していても、それを経営層や決裁者に説明できず、「前回より高い」というだけの理由で稟議が差し戻されてしまうケースです。この記事で説明したような客観的な相場情報(人手不足による人件費上昇、専門技術への需要集中)を根拠として添えることで、社内説明の説得力を高められます。稟議を通す際の説得材料の作り方は、関連記事の稟議で社内の反対を乗り越える説得材料の作り方にまとめています。

ただし、単価上昇の話をそのまま鵜呑みにして「相手の言い値」を無条件に受け入れるのも危険です。次の章で、実際に交渉・確認すべきポイントを整理します。

発注前に確認しておくべきこと

単価上昇局面において、発注者側が事前に確認・準備しておくべき事項を整理します。

1. 自社の要件を「Must」と「Want」に分けて言語化しておく: 前述の通り、要件が具体的なほど見積もりの精度が上がり、無駄な工数が乗りにくくなります
2. 3社程度から相見積もりを取り、金額だけでなく提案内容・対応範囲を横並びで比較する: 2社では比較材料が不足し、5社以上では調整に時間がかかりすぎます
3. 見積書の内訳(要件定義・実装・進行管理・テスト・保守)がどう構成されているかを確認する: 内訳の見方は関連記事のシステム開発の見積書、この内訳の見方で損を防ぐで扱っています
4. 保守・運用費が開発費の何%として設定されているかを事前に確認する: 年間の保守費用まで含めた総コストで比較しないと、初期費用だけを見て判断を誤ります
5. 既製のSaaS・パッケージで代替できる範囲がないか、発注前に洗い出す: フルスクラッチとパッケージの使い分けはフルスクラッチとパッケージ、どちらを選ぶ？を参考にしてください

これらを事前に整理しておくと、開発会社との初回打ち合わせの質も上がります。何を確認すべきかは開発会社との初回打ち合わせで聞くべきことにもまとめていますので、あわせて参考にしてください。

御社の場合、もし今回の発注が過去の案件の延長(追加開発・リプレイス等)であれば、当時の見積もりとの単純比較ではなく、上記の内訳の中でどこが変化しているのかを個別に洗い出すところから始めることをおすすめします。

なお、単価上昇分そのものを補助金でまかなえないかと考える担当者もいますが、公的な補助金は対象となる経費・要件が制度ごとに細かく定められており、単純に「見積もりが高くなった分を補填する」ものではありません。自社の案件が対象になり得るかどうかは、関連記事のIT導入補助金でシステム開発はできるかで確認してから検討してください。

社内の決裁者に、単価上昇をどう説明するか

現場担当者が単価上昇の背景を理解していても、決裁者(経営層・上長)にそれをうまく伝えられなければ、稟議が通らず発注そのものが止まってしまいます。ここでは、社内説明で押さえておきたいポイントを整理します。

説明で避けるべき言い方

• 「開発会社がそう言っているので」(第三者の説明を鵜呑みにしているだけに見え、発注者側の検証が伝わらない)
• 「相場なので仕方ない」(思考停止した印象を与え、コスト意識がないと受け取られやすい)

説明で使いたい言い方

• 「エンジニアの人手不足と、AI・クラウド領域への需要集中という業界全体の構造変化が背景にあります。3社から相見積もりを取り、水準を確認した上での金額です」(客観的な根拠+自社での検証プロセスの両方を示す)
• 「見積もりの内訳を確認したところ、要件定義と実装の範囲を必須機能に絞ることで、当初案より◯割圧縮できています」(交渉・工夫の跡を数字で示す)

決裁者が最も懸念するのは「言い値をそのまま払っているのではないか」という点です。内訳の分解・相見積もりの比較・機能範囲の絞り込みといった、この記事で説明してきたプロセスを経たことを示せれば、単価上昇という事実自体への納得は得やすくなります。社内合意形成の材料の作り方全般は、関連記事の稟議で社内の反対を乗り越える説得材料の作り方もあわせて参考にしてください。

小さく試す発注で、単価上昇の影響を抑える

単価そのものが上がっている以上、総額を大きく圧縮する魔法のような方法はありません。しかし、発注の仕方そのものを工夫することで、単価上昇の影響を受ける対象範囲を小さくすることは可能です。

代表的なのが、最初から本番規模の全機能を発注するのではなく、必要最小限の範囲(MVP（実用最小限の製品）と呼ばれる、実用に足る最小限の機能に絞った試作)を先に発注し、実際に使いながら段階的に機能を追加していく進め方です。この進め方であれば、初回発注時点での見積もり総額を小さく抑えられるだけでなく、要件の手戻りによる追加コストのリスクも下げられます。

小規模な発注から始める考え方は、関連記事の小さく発注して試す: PoC発注のすすめでも詳しく扱っています。単価が上がっている局面だからこそ、「まず全部を一度に発注する」という発想自体を見直す価値があります。

金額だけでなく、開発会社の対応力も見比べる

単価が上がっている局面では、見積もり金額の比較に意識が向きがちですが、同じ金額水準の中でどの開発会社を選ぶかという判断も、これまで以上に重要になります。単価上昇によって開発会社側の受注競争が激しくなっている領域ほど、「金額は同水準でも対応力に差がある会社」が混在しやすくなるためです。

見積もり金額以外に確認しておきたい観点を整理します。

• 要件の詰め方: 初回の打ち合わせで、御社の業務内容についてどれだけ具体的な質問をしてくるか。抽象的な要望をそのまま受け入れて概算を出してくる会社より、業務の細部まで確認しようとする会社のほうが、後工程での手戻りが少ない傾向があります
• 見積もりの説明の透明性: 内訳を尋ねたときに、要件定義・実装・進行管理・保守それぞれの根拠を具体的に説明できるか。「一式でこの金額です」としか答えられない場合、単価上昇分がどこにどれだけ乗っているのか、発注者側から検証できません
• 保守・運用体制の具体性: リリース後の障害対応の連絡フロー、対応時間帯、追加開発時の単価水準まで、契約前に確認できるか。単価上昇局面では、保守フェーズに入ってからの単価改定リスクも事前に確認しておく価値があります

これらは、見積書の金額欄だけを見ていては分からない情報です。危険な兆候を見抜く観点は、関連記事の危険な開発会社のサイン10選にもまとめていますので、発注先を最終的に決める前に確認しておくことをおすすめします。

まとめ

この記事で持ち帰れることは次の3点です。

• システム開発の見積もりが上がっている理由を、エンジニアの人手不足・専門技術への需要集中という業界構造で説明できるようになったこと
• 見積もりの内訳のうち、要件定義・実装の対象範囲は交渉の余地がある一方、進行管理費・保守費は無理に削るべきではないという判断基準を持てたこと
• 相見積もりが横並びになる理由と、極端に安い見積もりに潜むリスクを見極める視点を持てたこと

単価上昇そのものは、御社1社の努力で止められるものではありません。ですが、内訳を分解して交渉できる部分を見極め、発注の範囲や進め方を工夫することで、実質的な負担を抑える余地は十分に残っています。

まずは今回届いている見積書を1枚、この記事で紹介した内訳の表と照らし合わせて眺めてみてください。どの項目が総額を押し上げているのかが見えてくると、次の交渉や社内説明の材料が具体的になります。そのうえで、契約内容や進め方について整理しきれない部分が残るようであれば、要件整理の段階から相談できる開発会社に一度話を聞いてみるのも一つの選択肢です。