社内システムの外注費用の相場は？
中小企業が社内向けシステムを外注開発する場合、機能規模・開発方式・ベンダー規模によって数十万円から数千万円と幅広く、単純な平均値は参考になりません。この記事では費用レンジの根拠となるデータを示したうえで、見積書の読み方と発注判断の基準を順に解説します。
なお、本記事で引用する費用レンジはすべて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」）。
要注意の記載パターンと交渉ポイント
以下のパターンが見積書に含まれている場合は、内容を確認してから受け入れることをお勧めします。
1. 工程や工数の根拠が書かれていない
「システム開発一式 300万円」のように、工程も人月も記載がない見積は比較・検証ができません。工程ごとの工数と単価を明示した明細への変更を依頼してください。
2. 「要件定義は御社負担」と記載されている
要件定義をベンダー任せにする場合と御社側が主導する場合では、実装工程の手戻りリスクが大きく異なります。要件定義工程がそもそも見積に含まれていないケースでは、後から要件追加が発生したときの追加費用の算出根拠が曖昧になりがちです。
3. 保守・運用費用が含まれていない
初期開発費用だけで比較すると、リリース後の月額保守費用が高いベンダーを選んだ結果、3年間の総コストが他社より高くなるケースがあります。初期費用と保守費用を合算した総保有コスト（TCO）で比較することが重要です。
4. 「概算」「別途協議」が多い
不確定要素が多い状態での発注は、仕様確定後に費用が大幅に増額するリスクがあります。特に外部サービスとの連携や既存データの移行作業は、調査工程を経て金額が決まることが多いため、「調査後に確定見積を提出する」という合意をあらかじめ取っておくことが有効です。
5. 人月単価の水準を確認する
見積書に人月単価が明記されている場合、エンジニアの経験レベルと単価の対応が妥当かを確認します。単価の目安は案件の規模・技術領域・ベンダー規模によって変動が大きいため一概には言えませんが、同じ開発要件で複数のベンダーに見積を依頼し、工数と単価の両方を比較することで相場感を掴めます。
交渉の基本姿勢: 「安くしてほしい」という値引き交渉より、「この工程の工数が他社より多い理由を教えてほしい」という根拠確認の方が、ベンダーとの関係を損なわずに適正価格を確認できます。スコープを絞る（フェーズ分割発注）交渉も有効な手段です。
費用超過のリスクや、発注後に追加費用が発生しやすいパターンについては次のセクションで詳しく説明します。