業務システム開発単価相場｜システム開発の相場は工数より仕様変更の回数で見たほうがいい

2026年8月26日

朝比奈蒼

この記事のポイント

✓業務システム開発の単価相場を
✓工数だけでなく仕様変更の回数という切り口で解説します
✓単価交渉で損をしないための考え方を客観的なデータとともに整理しました

結論から言います。業務システム開発の単価相場を調べるとき、多くの人は「工数（何人日かかるか）」だけを見て金額の妥当性を判断しようとします。しかし、実際の現場で見積もりが膨らむ最大の要因は、工数の見積もり精度よりも、仕様変更が何回発生するかです。この記事では、一般的な相場の内訳を押さえつつ、なぜ仕様変更の回数という視点が重要なのかを、データを交えて解説していきます。

業務システム開発の費用相場、まず全体像から

業務システム開発の費用は、「わかりにくい」という声が非常に多い分野です。

システム開発はお金がかかるというイメージを持っている人が多いですが、実際にどの程度の予算がかかるのかわからないという人も多いのではないでしょうか。出典: hipro-job.jp

正直なところ、この分かりにくさには理由があります。業務システム開発は、家電製品のように定価があるものではなく、要件によって作業量が大きく変動する「オーダーメイド」の仕事だからです。小規模な業務改善ツールであれば数十万円程度で収まることもあれば、複数部署をまたぐ大規模な基幹システムであれば数百万円から数千万円規模になることもあります。

一般的な受託開発の相場感として、中小企業向けの業務システムでは100万円から500万円程度の価格帯が中心になるケースが多いという業界の実感があります。

なお、当社の実績では中小企業向けの業務システムは100～500万円の価格帯が中心です。実際の開発事例と金額は本記事の実例セクションで詳しくご紹介します。出典: minna-systems.co.jp

ただし、これはあくまで一つの目安です。個人のフリーランスが業務委託で受ける改修案件やミニマムな開発案件であれば、数万円から数十万円規模の案件も多く存在します。単価を考える際は、自分がどの規模の案件を対象にしているのかを最初に整理することが大切です。

費用の内訳を理解する

見積もり金額の妥当性を判断するには、そもそも費用がどのような要素で構成されているのかを理解しておく必要があります。

人月単価という考え方

システム開発の見積もりでは、「人月単価」という指標がよく使われます。これは、エンジニア1人が1ヶ月フルタイムで作業した場合の費用を指す単位です。この人月単価に、想定される作業月数を掛け合わせることで、大まかな見積もり額が算出されます。

人月単価は、エンジニアのスキルレベルや、開発する言語・技術によっても変動します。基本的な実装作業を担当するエンジニアと、要件定義やシステム全体の設計を担当する上級エンジニアでは、人月単価に大きな差があるのが一般的です。

工程ごとの費用配分

業務システム開発の工程は、要件定義、基本設計、詳細設計、実装、テスト、リリース、という流れで進みます。それぞれの工程にどれだけの費用が配分されるかは案件によって異なりますが、一般的には実装とテストの工程が全体の費用の中でも大きな割合を占める傾向があります。

一方で、要件定義や設計にかける時間を十分に確保しない案件は、後工程での手戻りが発生しやすく、結果的に総額が膨らむリスクを抱えることになります。この点が、次に説明する「仕様変更の回数」というテーマにつながっていきます。

なぜ工数より「仕様変更の回数」が重要なのか

ここが、この記事で一番お伝えしたい核心部分です。

工数の見積もりは、当初から不確実性を含んでいる

見積もりの段階で算出される工数は、あくまで「その時点で分かっている仕様」を前提にした数字です。しかし、業務システム開発では、開発が進む中で新たな要望が出てくることが非常に多くあります。「実際に画面を見てみたら、この項目も必要だと気づいた」というのは、決して珍しい話ではありません。

つまり、最初に提示された見積もり工数がどれだけ精緻であっても、その後の仕様変更の回数が多ければ、最終的な総コストは当初の見積もりを大きく超えてしまいます。逆に言えば、仕様変更の発生を抑える仕組みさえあれば、多少工数の見積もりが粗くても、結果的な総コストは想定内に収まりやすくなります。

仕様変更が単価に与える具体的な影響

仕様変更が発生すると、単に追加の実装作業が増えるだけでなく、それまでに作った部分を作り直す「手戻り」のコストも発生します。この手戻りコストは、開発が進んだ段階で発生するほど大きくなる傾向があります。設計段階での仕様変更であれば影響は限定的ですが、実装がほぼ完了した段階での仕様変更は、テストのやり直しまで含めて、当初の想定を大幅に超える追加費用につながることがあります。

正直なところ、これはクライアント側にも受注者側にも、あまり知られていない事実だと感じます。多くの人が「工数さえ正確に見積もれば、予算オーバーは防げる」と考えがちですが、実際には仕様変更の発生頻度をコントロールすることのほうが、最終的な費用に与える影響は大きいのです。

仕様変更の回数を抑えるための実務的な工夫

では、単価を安定させるために、実務上どのような工夫ができるのでしょうか。

段階的なリリースで「気づき」を早める

先ほど触れた「実際に画面を見てから気づく」というパターンを減らすためには、開発の初期段階で、簡易的な画面イメージや試作版（プロトタイプ）をクライアントに見せることが有効です。文書だけの仕様確認では気づけなかった問題点を、実際に動く画面を見ることで早期に発見できれば、その分だけ後工程での大きな仕様変更を防げます。

最小構成（MVP）から始めるアプローチ

最初からすべての機能を作り込むのではなく、必須機能だけの最小構成でリリースし、運用しながら段階的に機能を拡張していく方法も、単価の安定化に有効です。

最初からすべての機能を作り込むのではなく、「必須機能だけの最小構成（MVP）」でリリースし、運用しながら段階的に拡張する方法です。初期費用を抑えられるだけでなく、実際に使ってみてから優先順位を見直せるため、無駄な機能開発を防げます。当社の実績でも、100万円台で最小構成から始めて拡張していった事例が多くあります。出典: minna-systems.co.jp

このアプローチのメリットは、初期費用を抑えられることだけではありません。運用しながら実際の使用感をもとに優先順位を見直せるため、机上の想定だけで作り込んで後から大幅に手直しするというリスクを減らせる点も大きな利点です。

契約段階で「仕様変更のルール」を決めておく

受注者側としてできる最も実務的な対策は、契約段階で「仕様変更が発生した場合の取り扱い」を明文化しておくことです。例えば「基本設計完了後の仕様変更は、追加見積もりの対象とする」というルールを事前に合意しておけば、後々の交渉がスムーズになります。

このルールがないまま作業を進めてしまうと、「せっかく作ったのだから、この程度の変更くらいサービスでやってほしい」という圧力に晒されやすくなります。仕様変更のたびに適切な追加費用を請求できる体制を整えておくことが、単価を守るための実務的な防御策になります。

開発するシステムの種類による相場の違い

一口に業務システムといっても、種類によって費用構造は大きく変わります。ここでは代表的なシステム種類ごとの相場感を整理します。

在庫管理・販売管理システム

在庫や販売の情報を一元管理するシステムは、既存の業務フローとの整合性を取る作業に時間がかかる傾向があります。既存のExcel運用や紙の帳票をどうシステム化するかを丁寧にヒアリングする必要があるため、要件定義の工程が長引きやすく、その分の費用も相応にかかります。

顧客管理（CRM）システム

顧客情報を管理し、営業活動やマーケティングに活用するCRMシステムは、既製のクラウドサービスをカスタマイズする形で導入するケースと、完全に独自開発するケースとで、費用感が大きく異なります。既製サービスのカスタマイズであれば比較的低予算で始められますが、独自の業務フローに合わせた作り込みが必要な場合は、費用が膨らみやすくなります。

勤怠管理・給与計算システム

勤怠管理や給与計算のシステムは、法改正への対応が定期的に必要になるという特徴があります。開発時の費用だけでなく、その後の保守費用も含めて総合的に見積もる必要がある分野です。労働基準法や社会保険関連の制度変更に対応するための改修は、単発の開発費用とは別に、継続的な予算として発注者側も想定しておくべき部分です。

予約・受付システム

飲食店や医療機関などで使われる予約システムは、比較的機能がシンプルなことが多く、既製のテンプレートをベースにしたカスタマイズであれば、小規模な予算でも実現可能なケースが多い分野です。ただし、決済機能や外部カレンダーとの連携など、追加機能を求められると、想定より費用が膨らむこともあります。

見積もり書の読み方：チェックすべき5つのポイント

発注者側から提示された見積もり書、あるいは自分が作成する見積もり書について、どこを確認すればよいのかを整理します。

まず1つ目は、工程ごとの費用内訳が明記されているかどうかです。総額だけが提示されている見積もりは、後から「この部分にこんなに費用がかかっているとは思わなかった」というトラブルにつながりやすくなります。

2つ目は、仕様変更が発生した場合の追加費用のルールが記載されているかどうかです。この記事で繰り返し強調しているポイントですが、見積もり書自体にこのルールが明記されていない場合は、契約前に必ず確認しましょう。

3つ目は、保守・運用フェーズの費用が別枠で示されているかどうかです。開発費用だけを見て安いと判断しても、リリース後の保守費用が高額に設定されている場合、トータルコストでは割高になることがあります。

4つ目は、テスト工程にどれだけの工数が割り当てられているかです。テスト工程を極端に短く見積もっている見積もりは、リリース後に不具合が多発するリスクを抱えている可能性があります。

5つ目は、見積もりの有効期限です。システム開発の見積もりは、市場の状況やエンジニアの稼働状況によって変動するため、有効期限が明記されているかを確認し、期限を過ぎた見積もりをそのまま使い回さないよう注意しましょう。

発注先の選び方と単価の関係

発注先の規模によっても、単価の傾向は変わります。大手のシステム開発会社に依頼する場合は、品質管理やプロジェクトマネジメントの体制がしっかりしている分、単価は高めになる傾向があります。一方、フリーランスや小規模なチームに直接依頼する場合は、中間コストが少ない分、同じ予算でもより多くの作業を依頼できる可能性があります。

ただし、フリーランスへの直接発注では、品質管理やスケジュール管理を発注者自身がある程度担う必要が出てきます。単価の安さだけで発注先を選ぶのではなく、自社でどこまでのプロジェクト管理ができるかも踏まえて判断することが大切です。

単価相場を調べる際に見るべき情報源

自分が受けようとしている案件の単価が妥当かどうかを判断するには、複数の情報源を比較することが大切です。

エンジニアのランク（経験年数やスキルレベル）によって単価がどう変わるかを整理した情報も参考になります。未経験に近いレベルであれば比較的低めの単価から、経験豊富な上級エンジニアであれば高めの単価まで、幅があることを理解しておきましょう。

エンジニアにシステム開発を依頼する場合、単価決めの基準とは？出典: minna-systems.co.jp

ソフトウェア作成者の年収・単価相場では、職種別の相場データを確認できます。自分のスキルレベルや担当工程に応じた相場感を掴んでおくことで、提示された単価が適正かどうかを冷静に判断できるようになります。

案件の探し方についても、業務内容によって相場の幅が変わってきます。Web・業務システム開発のお仕事では、どのような案件が多く出回っているか、傾向を紹介しています。

隣接する職種の単価も参考になります。SaaS開発案件の単価相場と成功の秘訣！2026年最新ガイドやUI/UX 案件の獲得術！単価相場と高収入デザイナーになる全ステップでは、それぞれ異なる切り口から単価の考え方を紹介しています。プロジェクトマネジメントの立場から単価を考えたい方にはPM 副業ガイド！単価相場と未経験からの始め方・案件獲得のコツも参考になるでしょう。

発注者側で起きがちな見積もり超過の典型例

よくあるのが、社内向けの業務ツールを外部に依頼したケースです。当初の見積もりは工数ベースで妥当な金額だったにもかかわらず、開発が進む中で発注者側の担当者が「この画面にはこの項目も表示したい」という要望を何度も追加し、結果的に費用が当初より3割近く膨らみ、納期も延びてしまうという流れです。

この例から分かるのは、発注者側にも仕様変更のコストに対する自覚が必要だということです。受注者から「この変更を加えると、追加費用と納期の延長が発生します」と明確に伝えられれば、発注者は要望の優先順位を考え直すきっかけを得られます。単価交渉の場面で受注者が仕様変更のコストを毅然と説明することは、結果的に発注者のためにもなるのです。

費用を抑えたい発注者との向き合い方

受注者として案件を選ぶ立場からすると、「費用をできるだけ抑えたい」という発注者の要望自体は自然なものです。問題は、コストを抑える方法として「単価を値切る」以外の選択肢が発注者側に見えていないケースが多いことです。

実際には、単価そのものを下げるより、開発範囲を絞り込む、あるいは前述のMVPアプローチで段階的に進めるほうが、双方にとって納得感のある費用の抑え方になります。受注者側から「まずはこの機能だけに絞って、様子を見ながら拡張しませんか」と提案できると、発注者との信頼関係を保ちながら、適正な単価を維持しやすくなります。

見積もりを安くしたいという相談を受けた際、闇雲に単価を下げるのではなく、こうした代替案を提示できるかどうかが、フリーランスとしての交渉力の差につながります。

独自データから見る単価と継続率の関係

在宅ワーク求人サイトを長年運営してきた立場から見ていると、単価の高さだけを基準に案件を選んでいる人より、仕様変更のルールをきちんと事前に取り決めている人のほうが、結果的に長期的な収入が安定している傾向があります。

一見矛盾するようですが、高単価の案件を受けても、仕様変更への対応ルールが曖昧なままだと、実質的な時給換算では割に合わない働き方になってしまうケースが少なくありません。逆に、単価自体は平均的でも、仕様変更のたびに適正な追加費用を交渉できる関係を築けている人は、長期的に見て収益性の高い働き方ができています。

もう一つ興味深い傾向として、直接契約で発注者とやり取りしている人ほど、仕様変更の交渉をスムーズに行えている印象があります。仲介会社を挟むと、仕様変更の交渉自体に仲介者を通す必要があり、意思疎通に時間がかかることが多いためです。手数料0%で直接やり取りできる環境は、単に中間マージンがかからないという金額面のメリットだけでなく、仕様変更のような繊細な交渉をスピーディーに行えるという運用面のメリットも持っています。運営者として見てきた限りでは、この「交渉のしやすさ」こそが、直接取引の本質的な価値だと感じます。

継続的な保守契約と単価の関係

システム開発は、納品して終わりではなく、その後の保守・改修フェーズも収益の重要な柱になります。単発の開発案件だけで収入を組み立てるより、保守契約を継続的に結べる関係を築くことのほうが、長期的な単価の安定につながります。

保守契約の単価は、月額固定制と、対応が発生した都度の従量制の2種類が主流です。月額固定制は、収入の見通しが立てやすいというメリットがある一方、対応量が少ない月は割安に、多い月は割高になるという特徴があります。従量制は、対応量に応じて公平に費用を請求できる反面、月々の収入が不安定になりやすいというデメリットがあります。

自分の生活スタイルや、案件数のバランスを考えながら、どちらの契約形態が向いているかを見極めることも、単価戦略の一部として考えておくとよいでしょう。

自分の単価を決める手順

ここまで相場と仕様変更の考え方を見てきましたが、実際に自分の単価を決めるときは、次の手順で進めると迷いにくくなります。

手順1：生活に必要な金額から最低ラインを出す

まず、フリーランスとして生活するために必要な月の金額を出します。生活費に加えて、国民健康保険や国民年金、所得税や住民税、仕事で使う機材やソフトウェアの費用も含めて考えます。会社員時代の手取りと同じ感覚で単価を決めると、税金と社会保険料の負担で手元に残る金額が想定より少なくなりがちです。

手順2：実際に請求できる時間を見積もる

次に、月に何時間を請求対象の作業にあてられるかを見積もります。フリーランスは、営業活動、見積もり作成、打ち合わせの準備、請求書の発行、学習の時間など、請求できない作業にも一定の時間を取られます。稼働時間のすべてを請求できると考えず、実際に請求できるのは全体の6割から7割程度と見込んでおくと、計画が崩れにくくなります。

手順3：最低ラインを請求可能時間で割る

手順1の金額を手順2の時間で割ると、自分が下回ってはいけない時間単価が出ます。この数字が、案件を受けるかどうかの判断基準になります。提示された金額を想定工数で割ってこの基準を下回るなら、範囲を絞る交渉をするか、見送るかを検討します。

手順4：相場と照らし合わせて調整する

最後に、同じ工程を担当するエンジニアの相場と比べます。相場より大きく低い場合は、自分の価値を低く見積もりすぎている可能性があります。逆に相場より大きく高い場合は、その金額に見合う実績や専門性を提案の中でどう示すかを考える必要があります。

仕様変更に強い見積もり書のつくり方

受注者として見積もりを出すときは、仕様変更が起きることを前提にした書き方にしておくと、後の交渉が楽になります。

前提条件を文章で書き出す

見積もりの金額は、特定の前提のもとで成り立っています。対象となる画面数、帳票の数、連携する外部サービス、対応するブラウザや端末の範囲などを、前提条件として文章で書き出しておきましょう。前提が変わったときに「見積もりの前提から外れたため、再見積もりが必要です」と説明しやすくなります。

含まないものを明記する

見積もりに含まれる作業だけでなく、含まれない作業も明記しておきます。データ移行、既存システムの調査、操作マニュアルの作成、利用者向けの説明会などは、発注者が当然含まれていると考えがちな作業です。これらを「別途見積もり」と書いておくだけで、認識のずれによるトラブルを大きく減らせます。

変更の受付期限と手続きを決める

どの工程までなら仕様変更を受け付けるのか、変更を依頼するときはどのような手続きを踏むのかを決めておきます。たとえば、変更の依頼は書面やチャットで残る形で受け、影響範囲と追加費用を見積もってから着手する、という流れにしておくと、口頭での小さな変更が積み重なって費用が膨らむのを防げます。

予備費の考え方を共有する

大きな案件では、見積もり総額とは別に、想定外の対応に使う予備費を発注者と共有しておく方法もあります。予備費の範囲内であれば都度の承認を簡略化できるため、進行が滞りにくくなります。使わなかった分は請求しないという取り決めにしておけば、発注者にとっても安心できる仕組みになります。

受注前にクライアントへ確認したい質問

仕様変更の回数を減らすためには、受注前の段階で発注者の状況をよく聞いておくことが効果的です。次のような質問を用意しておくと、見積もりの精度が上がります。

・このシステムを主に使うのは誰か、その人は要件の確認に参加できるか・現在はどのような方法で業務を行っているか、困っている点は何か・最終的な判断をするのは誰か、承認にどれくらいの期間がかかるか・リリース後に機能を追加する予定はあるか、予算はどの程度見込んでいるか

特に、実際にシステムを使う現場の担当者が要件確認に参加できるかどうかは重要です。決裁者だけで仕様を決めると、リリース直前に現場から要望が出て、大きな仕様変更につながることがあります。

単価を上げていくために積み上げたいもの

相場の中で自分の単価を少しずつ上げていくには、担当できる工程を広げることが近道です。実装だけを担当している段階から、詳細設計、基本設計、要件定義へと上流工程に関われるようになるほど、人月単価は上がりやすくなります。上流工程では、発注者の業務を理解し、仕様変更の起きにくい要件を固める力が求められるため、この記事で扱った仕様変更の管理そのものが評価の対象になります。

もう一つは、納品物の品質を客観的に示せる材料を残すことです。テスト項目の一覧、設計書、リリース後の不具合件数の推移などを、守秘義務に反しない範囲で説明できるようにしておくと、次の案件で単価を提示するときの根拠になります。案件が終わるたびに、担当した工程、規模、仕様変更への対応方法を短くまとめておく習慣をつけると、提案文や面談での説明が格段にしやすくなります。

あわせて、使える技術の幅を少しずつ広げておくことも単価の底上げにつながります。クラウド環境の構築、データベースの設計、外部サービスとの連携など、業務システムで頻繁に求められる周辺技術を扱えると、一つの案件で任される範囲が広がり、結果として受注金額も大きくなります。新しい技術は、まず小さな改修案件や自分用のツール開発で試し、実務で説明できる水準まで経験を積んでから提案に加えるのが安全です。