社内システムの外注費用の相場は？
中小企業が社内向けシステムを外注開発する場合、機能規模・開発方式・ベンダー規模によって数十万円から数千万円と幅広く、単純な平均値は参考になりません。この記事では費用レンジの根拠となるデータを示したうえで、見積書の読み方と発注判断の基準を順に解説します。
なお、本記事で引用する費用レンジはすべて2026年7月時点の公開情報にもとづきます。
システム種別ごとの費用レンジ一覧
発注ラウンジ・システム幹事など複数の民間調査を参照すると、比較的シンプルな業務システムの受託開発費用は概ね100万円〜500万円程度、基幹系や複数業務を統合するシステムでは500万円〜2,000万円以上になるケースが多いとされています。下表はその目安をシステム種別に整理したものです。
| システム種別 | 主な機能の例 | 費用レンジの目安 |
|---|---|---|
| 勤怠管理システム | 打刻、休暇申請、集計レポート | 100万円〜300万円 |
| 在庫管理システム | 入出庫管理、在庫アラート、CSV連携 | 150万円〜400万円 |
| 顧客管理（CRM）システム | 顧客情報、商談履歴、メール連携 | 200万円〜600万円 |
| 受発注管理システム | 注文受付、請求書発行、ステータス管理 | 300万円〜800万円 |
| 基幹・複数業務統合型 | 上記機能の複合＋会計連携など | 500万円〜2,000万円以上 |
上記はあくまで目安であり、要件の複雑さや連携先の数によって大きく変動します。費用を決める要因については次のセクションで詳しく解説します。
費用レンジの根拠を補強するデータとして、IPA（情報処理推進機構）「ソフトウェア開発分析データ集2022」が参考になります。同データ集は国内5,546件の実プロジェクトを集計したもので、国内ソフトウェア開発の生産性中央値は9.1FP（ファンクションポイント）/人月と報告されています（出典: IPA「ソフトウェア開発分析データ集2022」）。ファンクションポイントとは、システムの機能量を入出力・データ保持・連携の数で定量化する単位です。この数値を使うと、「見積書に示された人月数が機能量に対して多すぎないか」を検証する際の基準として活用できます。
また、IPAの「ソフトウェア開発データ白書2018-2019 情報通信業編」によると、小規模プロジェクト（開発規模100FP未満）の平均工期は3.9か月、平均工数は6.2人月とされています。中小企業が発注する比較的小さな業務システムの工期・工数感を掴む参考値として位置づけてください。
費用を左右する3つの開発方式（スクラッチ・パッケージ・ノーコード）
開発方式の選択は、初期費用と運用コストのバランスに直接影響します。主な3方式の特徴を下表で比較します。
| 開発方式 | 概要 | 初期費用の傾向 | カスタマイズ自由度 | 向いているケース |
|---|---|---|---|---|
| スクラッチ開発 | 要件にあわせてゼロから開発 | 高い | 高い | 独自業務フローが多い場合 |
| パッケージ導入 | 既製品ソフトを導入・設定 | 中程度 | 中程度 | 標準的な業務フローに近い場合 |
| ノーコード・ローコード | GUI操作で構築、コード不要または最小限 | 低い | 低〜中 | シンプルな帳票・フォーム管理など |
選択の判断軸は「御社の業務フローが市場の標準からどれだけ外れているか」です。業務フローが一般的なものに近いほどパッケージやノーコードで対応でき、初期費用を抑えられます。
開発方式を選ぶ際に無視できない背景として、クラウドサービスの普及があります。総務省「令和6年通信利用動向調査報告書（企業編）」によると、2024年時点で国内企業全体のクラウドサービス利用率は77.0%に達しています。従業者数300人未満の中小規模企業でも、令和5年調査時点で72.4%がクラウドサービスを利用しており（出典: 総務省「令和5年通信利用動向調査（企業編）」）、スクラッチ開発よりもクラウドサービスを組み合わせる選択肢が現実的なコスト水準で検討できるようになっています。ただし、同調査ではクラウド活用の目的はメールやグループウェアなど汎用ツールが中心で、基幹業務への適用は限定的とも指摘されています。御社の基幹業務をクラウドで代替できるかどうかは、要件定義の段階で慎重に見極める必要があります。
費用を大きく左右する要因は？
開発費用の大部分は「要件の複雑さ」「既存システムとの連携数」「ベンダーの人月単価」の3要素で決まります。この3点を整理しないまま見積依頼すると、ベンダーごとに前提条件が異なり、金額の比較自体が意味をなさなくなります。
要件定義の精度が見積ブレを左右する
要件定義とは、「このシステムで何ができるべきか」を文書化する工程です。この精度が低いほど、ベンダー側は不確実性を費用に上乗せします。
開発規模を測る指標のひとつにFP（ファンクションポイント）があります。FPとは、システムが持つ機能の数と複雑さを定量化した単位です。IPA「ソフトウェア開発分析データ集2022」（5,546プロジェクトを集計）によると、国内ソフトウェア開発プロジェクトの生産性中央値は9.1FP/人月と報告されています。
この数値は、見積もりの妥当性を検証するための基準として活用できます。たとえば、ベンダーから提示された工数が「このシステムの規模で本当に妥当か」を判断する際の参考値になります。
同じIPAの「ソフトウェア開発データ白書2018-2019 情報通信業編」（238件）では、開発規模が100FP未満の小規模プロジェクトの平均工期は3.9か月、平均工数は6.2人月と集計されています。中小企業が発注する比較的シンプルな業務システムは、この規模感に近いケースが多いと言えます。
要件定義の精度が見積ブレに与える影響を整理すると、以下の通りです。
| 要件定義の状態 | 見積への影響 |
|---|---|
| 業務フローが文書化されており、画面数・データ項目が明確 | ベンダーが詳細見積を出しやすく、ブレが小さい |
| 「こういうことがしたい」という方向性のみ | ベンダーが不確実性を上乗せし、金額が高めになりやすい |
| 要件が口頭のみで未文書化 | 複数社の見積金額が2〜3倍以上乖離するケースがある |
見積依頼前に最低限整理しておくべき項目は次の4点です。
- 対象業務のフロー（現状と理想の両方）
- 想定する利用者数とアクセス頻度
- 必須機能と「あれば望ましい」機能の区別
- 連携が必要な既存ツール・システムの一覧
既存システム・外部サービス連携の工数
連携先が増えるほど、開発工数は非線形に増加します。連携とは、たとえば新しく作る受発注システムを既存の会計ソフトや在庫管理ツールと自動的にデータ連携させる作業を指します。
連携工数が膨らむ主な理由は3つあります。
- API仕様の調査コスト: 連携先ごとに仕様書を読み込み、接続方法を設計する必要があります。
- データ変換処理: 既存システムと新システムでデータの形式が異なる場合、変換ロジックの実装が必要になります。
- テスト工数の増加: 連携が1件増えるごとに、組み合わせのテストケースが指数的に増えます。
連携先別の工数増加の目安を示します（目安であり、案件の複雑さにより変動します）。
| 連携先の種類 | 工数増加の目安 |
|---|---|
| クラウドサービス（REST API公開済み） | 0.5〜2人月程度 |
| 既存の社内パッケージソフト（API非公開） | 2〜5人月程度 |
| 古い基幹システム（レガシー・ファイル連携） | 5人月以上になるケースあり |
なお、総務省「令和6年通信利用動向調査報告書（企業編）」によると、国内企業全体のクラウドサービス利用率は2024年時点で**77.0%に達しています。同調査の令和5年版では従業者数300人未満の中小企業に絞っても利用率は72.4%**に達しており、クラウドサービスを組み合わせた構成は中小企業にとっても現実的な選択肢になっています。
すでに複数のクラウドサービスを導入済みの場合、それらとの連携工数が見積に含まれているか確認することが重要です。連携箇所の見落としは、後工程での追加費用につながります。詳しくは後述の「費用超過のパターン」のセクションで取り上げます。
見積書の読み方と確認すべき項目は？
見積書は「工程×工数×単価」の積み上げ構造になっており、各工程の人月数と単価の妥当性を個別に確認することがコスト適正化の第一歩です。全体の合計金額だけを見ていては、どの工程にコストが集中しているかが把握できません。
工程別の標準的な工数配分
社内システムの受託開発では、一般的に以下の5工程に分けて見積が積み上げられます。IPA「ソフトウェア開発データ白書2018-2019 情報通信業編」（238件集計）によると、情報通信業における100FP未満の小規模プロジェクトの平均工数は6.2人月、平均工期は3.9か月です。この数値を基準に、工程ごとの配分比率を確認すると妥当性の判断がしやすくなります。
| 工程 | 内容 | 工数配分の目安 |
|---|---|---|
| 要件定義 | 業務フローの整理、機能要件・非機能要件の文書化 | 全体の10〜20% |
| 基本設計 | 画面・データ構造・連携仕様の設計 | 全体の15〜25% |
| 詳細設計・実装 | 実際のコーディング作業 | 全体の30〜40% |
| テスト | 単体テスト・結合テスト・受入テスト | 全体の20〜30% |
| 導入・移行支援 | データ移行、マニュアル作成、初期トレーニング | 全体の5〜10% |
配分比率はプロジェクトの特性によって変動しますが、「実装工程のみが突出して高い」または「テスト工程がほぼゼロ」といった偏りがある場合は、品質リスクや後工程での追加費用の発生を疑う根拠になります。
また、単価の妥当性を検証する際はIPA「ソフトウェア開発分析データ集2022」（5,546プロジェクト集計）が参考になります。同データ集では国内ソフトウェア開発の生産性中央値が9.1FP/人月と報告されており、提示された工数と機能規模の比率が大きく乖離していないかを確認する基準として活用できます（出典: IPA「ソフトウェア開発分析データ集2022」https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。
要注意の記載パターンと交渉ポイント
以下のパターンが見積書に含まれている場合は、内容を確認してから受け入れることをお勧めします。
1. 工程や工数の根拠が書かれていない
「システム開発一式 300万円」のように、工程も人月も記載がない見積は比較・検証ができません。工程ごとの工数と単価を明示した明細への変更を依頼してください。
2. 「要件定義は御社負担」と記載されている
要件定義をベンダー任せにする場合と御社側が主導する場合では、実装工程の手戻りリスクが大きく異なります。要件定義工程がそもそも見積に含まれていないケースでは、後から要件追加が発生したときの追加費用の算出根拠が曖昧になりがちです。
3. 保守・運用費用が含まれていない
初期開発費用だけで比較すると、リリース後の月額保守費用が高いベンダーを選んだ結果、3年間の総コストが他社より高くなるケースがあります。初期費用と保守費用を合算した総保有コスト（TCO）で比較することが重要です。
4. 「概算」「別途協議」が多い
不確定要素が多い状態での発注は、仕様確定後に費用が大幅に増額するリスクがあります。特に外部サービスとの連携や既存データの移行作業は、調査工程を経て金額が決まることが多いため、「調査後に確定見積を提出する」という合意をあらかじめ取っておくことが有効です。
5. 人月単価の水準を確認する
見積書に人月単価が明記されている場合、エンジニアの経験レベルと単価の対応が妥当かを確認します。単価の目安は案件の規模・技術領域・ベンダー規模によって変動が大きいため一概には言えませんが、同じ開発要件で複数のベンダーに見積を依頼し、工数と単価の両方を比較することで相場感を掴めます。
交渉の基本姿勢: 「安くしてほしい」という値引き交渉より、「この工程の工数が他社より多い理由を教えてほしい」という根拠確認の方が、ベンダーとの関係を損なわずに適正価格を確認できます。スコープを絞る（フェーズ分割発注）交渉も有効な手段です。
費用超過のリスクや、発注後に追加費用が発生しやすいパターンについては次のセクションで詳しく説明します。
中小企業が陥りやすい費用超過のパターンは？
要件の後追い追加（仕様変更）と、運用・保守費用の見落としが、最終的な総コストを当初見積の1.5〜2倍に押し上げる主な原因です。どちらも発注前の段階で対策できるリスクです。
「要件変更」が追加費用になるメカニズム
仕様変更が費用超過につながるのは、開発が「積み上げ型の作業工程」で進むためです。前工程の成果物を前提に次工程が始まるため、後から要件を変えると手戻りが複数工程にわたります。
開発現場では、この手戻りをリスクとして認識したベンダーが、不確実性の高い要件に対して工数を多めに見積もる傾向があります。要件が曖昧なほど、バッファとして上乗せされる費用は大きくなります。セクション2で触れたとおり、要件定義の精度が見積金額に直接影響する理由はここにあります。
仕様変更が発生しやすい場面には、以下のようなパターンがあります。
- 画面確認後の機能追加: プロトタイプを見て「やはりこの項目も入力できるようにしたい」と気づくケース
- 関係者間の認識齟齬: 発注側の担当者と経営者で要件の解釈が異なり、後から修正指示が出るケース
- 業務フローの変更: 開発期間中に社内の運用ルールが変わり、システム仕様に反映が必要になるケース
- 外部連携の仕様変更: 連携先のAPIやデータ形式が変わり、対応工数が追加発生するケース
追加費用の発生を防ぐために、発注前に実施できる対策を以下に整理します。
| 対策 | 内容 |
|---|---|
| 関係者の事前合意 | 経営者・現場担当者・IT担当者が要件定義の内容を確認し、書面で合意する |
| 画面モックの活用 | ワイヤフレーム（画面の骨格図）を先に作成し、認識齟齬を工数が少ない段階で解消する |
| 変更管理ルールの明文化 | 契約時に「仕様変更の都度、追加見積を作成し承認後に着手する」と取り決める |
| 優先度づけによる段階開発 | 全機能を一括で作らず、必須機能を優先してリリースし、追加は第2フェーズに回す |
特に「変更管理ルールの明文化」は契約書レベルで確認すべき項目です。ベンダー側の標準契約ではなく、変更手続きと追加費用の上限承認プロセスが明記されているかを必ず確認してください。
初期開発後に発生するランニングコスト
初期開発費用だけで予算を組むと、運用フェーズで予期しない支出が発生します。システムは完成後も継続的なコストが伴うことを、発注前から計画に織り込む必要があります。
ランニングコストの主な内訳は以下のとおりです。
| コスト項目 | 概要 | 発生タイミング |
|---|---|---|
| 保守・サポート費用 | バグ修正、問い合わせ対応、軽微な仕様変更 | 毎月または年間契約 |
| インフラ費用 | サーバ、データベース、ストレージの利用料 | 毎月（クラウドは従量課金が多い） |
| ライセンス費用 | 利用するSaaS・ミドルウェアのライセンス | 毎月または毎年 |
| セキュリティ対応 | SSL証明書更新、脆弱性対応、パッチ適用 | 年1回以上 |
| 機能追加・改修 | 業務変化や法改正に伴うシステム改修 | 都度（スポット発注） |
特に見落とされやすいのが「保守費用の未計上」です。初期開発の見積書に保守費用の記載がない場合、リリース後の対応はすべてスポット費用になります。その場合、軽微な修正でも都度工数見積と発注手続きが発生し、対応コストと時間が割高になる傾向があります。
発注前に確認すべき保守関連の項目を以下に示します。
- リリース後のバグ対応はどの範囲まで無償か（保証期間と範囲）
- 月次保守契約の有無と月額費用の目安
- インフラ費用の実費請求範囲（どのサービスを使うか）
- 法改正（例: 消費税率変更、電子帳簿保存法対応）による改修は保守契約内か別途見積か
初期費用と3年間のランニングコストを合算した「3年総コスト」で比較することを推奨します。初期費用が安く見えても保守費用が高いケースや、逆に初期費用を高めに設定することで保守を包括しているケースがあり、単純な初期費用比較では実態が見えません。
ベンダーへの見積依頼時に「初期開発費用に加えて、リリース後3年間のランニングコストの目安も提示してください」と明記することで、比較の精度が上がります。見積書の確認ポイントについてはセクション3で詳しく解説していますので、あわせて参照してください。
自社に合ったベンダーの選び方は？
ベンダー選定では「価格の安さ」より「同業種・同規模の開発実績」と「要件定義への関与姿勢」を優先することが、トラブル回避につながります。安価な見積が結果的に費用超過や品質問題を招くケースは少なくありません。
発注先の規模別メリット・デメリット比較
ベンダーは大きく「大手SIer」「中堅開発会社」「小規模・フリーランス」の3区分に分かれ、それぞれ適した案件の規模と性質が異なります。
| 区分 | 目安の人月単価 | 主なメリット | 主なデメリット | 向いている案件 |
|---|---|---|---|---|
| 大手SIer | 100万〜200万円/人月 | 体制・品質管理が安定。法対応や監査への耐性が高い | 費用が高め。担当者が頻繁に交代する場合がある | 基幹系・大規模・上場企業向け |
| 中堅開発会社 | 60万〜120万円/人月 | 業種特化の実績を持つ場合がある。コストと品質のバランスが取れやすい | 会社による品質のばらつきが大きい | 中小企業の業務システム全般 |
| 小規模・フリーランス | 40万〜80万円/人月 | 費用が低い。担当者と直接やりとりできる | 体制変更リスク。長期保守に不安が残る場合がある | 機能を絞ったMVP開発やプロトタイプ |
人月単価はベンダーの規模だけでなく、担当エンジニアのスキルや案件の難易度によっても変動します。単価の高低だけで判断せず、その単価で何の工程を何人が担当するかを確認してください。
相見積もりで確認すべき5つのポイント
複数社から見積を取ることは必須ですが、金額を横並びに比較するだけでは不十分です。以下の5点を各社に問い、回答の内容と姿勢を評価することが適切なベンダー選定につながります。
同業種・同規模の開発実績があるか 業種特有の業務ルールや商習慣への理解度は、開発品質に直結します。「○○業界での導入実績がある」と主張するベンダーには、具体的な規模と課題内容を確認してください。
要件定義の工程を一緒に担ってくれるか 要件定義をベンダーに投げ渡すだけでなく、ヒアリング・整理・文書化を共同で進める姿勢があるかを確認します。「仕様書をいただければ進められます」という対応のみのベンダーは、要件の抜け漏れリスクが高まります。
見積の工程と工数の根拠を説明できるか 見積書の数値に対して「なぜこの工数か」を説明できるベンダーは、見積精度が高い傾向があります。「一式」「概算」としか書かれていない項目が多い場合は根拠を求めてください。見積書の読み方は前セクションで詳述しています。
追加費用が発生する条件が明文化されているか 要件変更時の単価・手順・承認フローが契約書または見積書に記載されているかを確認します。曖昧な場合は書面で明確にするよう依頼してください。費用超過のメカニズムは前セクションで整理しています。
開発完了後の保守・サポート体制はどうなっているか 初期開発が完了しても、バグ対応・法改正対応・機能追加のニーズは継続的に発生します。保守契約の有無、対応範囲、月額費用を発注前に確認してください。
複数社の回答を上記5点で比較すると、価格の差異がどの部分から来ているかが明確になります。最安値のベンダーが要件定義を含まない工数で見積を出している場合、実質的な費用は高くなることがあります。相見積もりは「条件をそろえた上での比較」が前提です。
ベンダー候補の絞り込みが難しい場合や、見積書の内容を第三者視点で確認したい場合は、当社の無料診断をお気軽にご活用ください。開発の規模感や発注先の選定基準について、実装者の立場からフラットにお伝えします。
ノーティックラボに外注した場合の進め方は？
当社では要件定義から実装・運用まで一貫して対応し、AIチャットボット構築は100,000円から、DXコンサルおよびシステム開発は500,000円から提供しています。
ここまでの各セクションで、費用相場・見積の読み方・ベンダー選定のポイントを整理してきました。このセクションでは、当社に依頼した場合の具体的な進め方をご説明します。
当社サービスの料金体系
| サービス区分 | 開始価格 | 主な対象 |
|---|---|---|
| AIチャットボット構築 | 100,000円から | 社内FAQ自動化、問い合わせ一次対応 |
| Webサイト制作 | 300,000円から | コーポレートサイト、採用・LP |
| DXコンサル・システム開発 | 500,000円から | 業務システム、機械学習導入、基幹連携 |
いずれも案件の規模と要件により変動します。詳細は無料診断でヒアリングのうえ、個別にお見積もりします。
当社が選ばれる理由
代表はUC Berkeley Data Science在学のAIエンジニアです。RAG（検索拡張生成）、Fine-tuning（モデルの追加学習）、Computer Vision（画像認識）を自ら実装しており、コンサルやライターではなく「実装者が直接担当する」体制が最大の特徴です。
提案書や見積書の根拠を技術レベルで説明できるため、「なぜこの工数なのか」を御社が理解できるかたちで丁寧に示します。第5セクションで述べた「見積根拠の透明性」を当社自身が体現することを重視しています。
発注から納品までの標準的な流れ
- 無料診断（オンライン・30〜60分）: 現状の業務課題と希望する機能を整理します。この時点で予算の方向感もお伝えします
- 要件定義: 業務フロー・利用者数・既存システムの連携要件を整理し、機能の優先度を御社と共同で確定します
- 見積提示: 工程・工数・単価を明示した見積書を提出します。概算ではなく根拠のある数値を提示します
- 開発・実装: 定期的な進捗報告を行い、仕様変更が生じた場合は追加費用の発生前に必ず合意を取ります
- 納品・運用支援: 本番環境への展開後も、初期運用期間のサポートを含めて対応します
補助金の活用についてはご相談を受け付けています。詳細は補助金活用ページをご覧ください。
御社の課題が「どこから手をつければよいかわからない」という段階であっても、無料診断では投資対効果の試算や優先順位の整理からお手伝いします。まずはお気軽にご相談ください。