業務システム開発を外注する費用は、小規模で300万〜800万円、中規模で800万〜3,000万円、大規模では3,000万円以上が一般的な目安です。金額は画面数より、業務ルール、外部連携、データ移行、セキュリティ要件で変わります。同じ条件で2〜3社を比較し、総額だけでなく範囲と前提を確認することが重要です。
業務システム開発の費用相場と期間
業務システム開発の予算を考えるときは、システムの名称ではなく、「どの業務を、どこまで、何人で利用するか」を基準にします。同じ顧客管理システムでも、顧客情報を登録するだけの場合と、見積・受注・請求・会計まで連携する場合では、必要な設計とテストの量が異なります。
国内の開発会社へ、要件定義(=作るものと実現条件を決める工程)から公開まで依頼する場合の一般的な目安は次のとおりです。
| 規模・方式 | 初期費用の目安 | 期間の目安 | 想定される内容 |
|---|---|---|---|
| SaaS・ローコードを使った簡易構築 | 100万〜500万円 | 1〜4カ月 | 申請管理、簡易な顧客管理、社内台帳、定型的なワークフロー |
| 小規模な個別開発 | 300万〜800万円 | 3〜6カ月 | 単一部門向けの管理システム、帳票出力、限定的な外部連携 |
| 中規模な個別開発 | 800万〜3,000万円 | 6〜12カ月 | 販売・在庫管理、複数部門で使うシステム、複数の外部連携 |
| 大規模な個別開発 | 3,000万〜1億円以上 | 12〜24カ月以上 | 基幹業務、複数拠点、大量データ、高度な権限・監査要件 |
SaaSとは、インターネット経由で利用する既製の業務サービスです。ローコードとは、プログラムを一から書く量を抑えて、画面や処理を組み立てる開発方法を指します。既製機能に業務を合わせられる場合は費用と期間を抑えやすい一方、独自の処理や複雑な連携を多数追加すると、個別開発に近い費用になることがあります。
上表はあくまで一般的な目安です。通常は要件定義、設計、開発、テスト、公開作業を含みますが、次の費用は別途になる場合があります。
- 現行データの整理、名寄せ、重複削除
- データ移行の設計、変換、リハーサル
- 操作マニュアルの作成や利用者研修
- クラウド環境、外部サービス、ソフトウェアの利用料
- パソコン、タブレット、バーコード端末などの機器代
- 公開後の監視、問い合わせ対応、障害対応、追加改修
- 社内ネットワークや認証基盤の変更
公開後の保守運用費は、月額10万〜100万円以上が一つの目安です。ただし、問い合わせの受付だけを行う契約と、24時間監視、障害復旧、軽微な改修、法改正対応まで含む契約では金額が大きく違います。クラウドや外部サービスの利用料も別に発生するため、初期費用だけでなく3〜5年程度のTCO(=導入後も含めた総保有コスト)で比較してください。
パッケージと個別開発の判断基準
費用を抑えるには、最初に「本当に個別開発が必要か」を判断することも重要です。
| 選択肢 | 向いている状況 | 発注時の注意点 |
|---|---|---|
| SaaS・パッケージ | 一般的な業務で、運用を標準機能に合わせられる | 追加設定、利用人数に応じた料金、解約時のデータ出力条件を確認する |
| 個別開発 | 独自業務が競争力に直結し、既製品では対応しにくい | 初期費用だけでなく、保守や将来の改修費も予算化する |
| 組み合わせ | 標準業務は既製品、独自領域だけを開発したい | データ連携の責任範囲と、障害発生時の切り分け方法を決める |
「現在の業務を一切変えずにパッケージへ合わせる」と、追加開発が増えて導入効果が薄れることがあります。反対に、独自性のない業務まで個別開発すると、不要な費用と保守負担が増えます。業務を標準化する領域と、自社独自の仕組みを残す領域を分けることが判断の出発点です。
費用を左右する要素と見積もりの見方
業務システムの費用を大きく左右するのは、画面のデザインよりも、業務ルール、例外処理、連携、移行、品質条件です。「受注を登録する」という一つの機能でも、値引き条件、承認経路、返品、締め処理、権限による表示制御が加われば、設計とテストの工数が増えます。
開発費は、概ね「必要な工数×担当者の単価」に、クラウドや外部サービスなどの直接費、プロジェクト管理費、不確定要素への対応分を加えて算出されます。人月とは、1人が1カ月稼働する作業量の単位です。国内の開発会社では1人月80万〜150万円程度が一つの目安ですが、担当者の役割、専門性、開発体制によって上下します。
主な費用変動要素
- 業務ルールと例外処理:承認条件、料金計算、返品、取消、締め処理などが多いほど設計が複雑になります
- 利用者と権限:管理者、一般社員、取引先など、利用者の種類と閲覧・更新権限が増えるほど確認項目も増えます
- 外部システム連携:会計、決済、物流、勤怠などとの連携には、接続仕様の調査と双方を含む試験が必要です
- データ移行:データ形式の変換だけでなく、欠損、重複、表記揺れの修正が必要になることがあります
- 非機能要件:非機能要件とは、速度、セキュリティ、停止しにくさ、バックアップなど、機能以外の品質条件です
- 利用規模:同時利用者数、データ件数、拠点数が増えると、性能設計やテスト環境の費用が上がります
- 対応端末:パソコンだけでなく、スマートフォン、タブレット、専用機器へ対応すると確認範囲が広がります
- 文書・教育:操作マニュアル、管理者向け手順書、社内研修を依頼する場合は別途工数が必要です
特に見落とされやすいのがデータ移行です。古いシステムからデータを取り出せるか、文字コードや項目名を変換できるか、過去何年分を移すかによって工数が変わります。見積もり前に匿名化したサンプルデータを提示し、移行対象件数とデータ整備の担当者を決めておくと精度が上がります。
見積書で確認する項目
見積書は総額ではなく、「何を成果物として、どこまで実施する金額か」を確認します。
| 確認項目 | 確認すべき内容 | 注意したい表現 |
|---|---|---|
| 要件定義・設計 | 業務整理、画面、データ、権限、連携をどこまで決めるか | 「設計一式」だけで成果物が不明 |
| 開発 | 対象機能と機能ごとの前提条件 | 機能一覧と見積項目が対応していない |
| テスト | 開発会社と発注者が行うテストの範囲 | 総合テストや性能テストが含まれない |
| データ移行 | 対象データ、件数、試行回数、修正担当 | 本番時の1回だけでリハーサルがない |
| インフラ | 初期構築費と毎月の利用料 | 利用量が増えた場合の料金が不明 |
| 進行管理 | 会議、進捗、課題、品質の管理方法 | 管理費がゼロで担当者が不明 |
| 公開・教育 | 公開手順、操作説明、マニュアル | 公開後の利用定着が対象外 |
| 保守運用 | 受付時間、初動時間、監視、改修の扱い | 「保守あり」だけで対応範囲が不明 |
| 前提・除外事項 | 発注者が行う作業と追加費用の条件 | 重要作業が見積書の欄外に記載されている |
安い見積もりが必ずしも割安とは限りません。例えば、データ移行、利用者受入テスト、操作教育が対象外なら、発注後に社内負担や追加費用が発生します。反対に高い見積もりでも、要件定義やテストの範囲が広いとは限りません。
比較するときは、各社へ同じ資料と回答期限を提示し、条件の差を補正します。実務的な比較方法は、システム開発の相見積もり|取り方と比較方法でも詳しく解説しています。
また、仕様が曖昧な段階の概算と、要件定義後の正式見積もりは分けて考えてください。初回相談時の金額は予算枠を確認するための概算であり、確定額ではないのが通常です。概算から正式見積もりへ移る際に、どの条件で金額が変わるのかを事前に確認しておくことが大切です。
外注前の準備と発注の進め方
外注前に詳細な仕様書を完成させる必要はありません。ただし、導入目的、対象業務、利用者、予算上限、希望時期を整理しておかないと、開発会社ごとの想定がばらつき、比較できない見積もりになります。
1. 導入目的と成功条件を決める
「Excelをなくしたい」「業務をDX化したい」だけでは、必要な機能を判断できません。現状の問題と、導入後に確認したい変化を具体化します。
- 月末の集計に毎月何時間かかっているか
- 二重入力や転記ミスがどこで発生しているか
- 問い合わせへの回答に何日かかっているか
- 誰しか分からない属人的な作業があるか
- システム導入後に、時間、件数、ミス率などの何を確認するか
数値を精密に出せない場合でも、「どの業務を、どの状態にしたいか」は決めてください。目的が明確なら、費用に対して優先すべき機能を判断しやすくなります。
2. 現行業務と例外を整理する
業務を「担当者」「入力情報」「処理」「判断条件」「出力物」の順に可視化します。標準的な流れだけでなく、返品、取消、差し戻し、月末処理などの例外も記載します。
開発のご相談を受ける立場から見ると、通常の業務フローより、例外処理の確認に時間がかかる案件が少なくありません。現場担当者への聞き取りを行い、管理者だけが把握している理想の流れと、実際の運用を分けて整理することが重要です。
3. 必須範囲と将来範囲を分ける
必要な機能を次の3段階に分けます。
- 必須:初回公開時になければ業務を開始できない
- 重要:効果は高いが、一時的に手作業で代替できる
- 将来:利用状況を確認してから追加を判断できる
初回からすべてを作ると、要件の確認量とテスト範囲が増えます。まず特定部門や拠点で利用し、実際の運用を確認してから対象を広げる方法も有効です。ただし、後から追加する機能が分かっている場合は、データ構造や権限設計だけ先に考慮してもらいます。
4. データ、連携、セキュリティ条件を確認する
次の資料を可能な範囲で準備してください。
- 現行システムやExcelの項目一覧と匿名化したサンプル
- 移行したいデータの種類、件数、保存年数
- 連携する会計・決済・物流などのサービス名
- API(=システム同士がデータを受け渡すための接続口)の有無
- 個人情報、機密情報、決済情報を扱うか
- 社外からの利用や接続元の制限が必要か
- 操作履歴、バックアップ、承認記録の保存期間
連携先の仕様が不明な場合は、その点も開発会社へ伝えます。連携先への問い合わせや技術調査を誰が担当するかまで決めると、発注後の停滞を減らせます。
5. RFPを用意して2〜3社へ依頼する
RFP(提案依頼書=開発会社へ同じ条件で提案を求める資料)には、目的、現状、対象範囲、利用者、必須機能、予算、時期、選定基準を記載します。画面や処理の詳細が未確定でも、各社が同じ前提で提案できれば問題ありません。
依頼資料に含めたい項目は次のとおりです。
- 導入の背景、課題、達成したい状態
- 対象業務と対象外の業務
- 利用者の種類、人数、場所、端末
- 必須機能と優先順位
- 外部連携とデータ移行の概要
- セキュリティや性能に関する条件
- 予算の目安と希望公開時期
- 社内の決裁者、業務責任者、窓口担当者
- 提案してほしい内容と選定スケジュール
作成手順や記載例は、RFPの作り方|システム開発の依頼準備も参考にしてください。
6. 要件定義と開発を分けて契約する
不明点が多い案件では、最初から全工程を固定金額で契約するより、要件定義を先行して発注し、その成果物を基に開発費を確定する方法が適しています。小〜中規模案件の要件整理を単独で依頼する場合、100万〜500万円程度、1〜3カ月程度が一つの目安ですが、対象部門や業務の複雑さで変わります。
要件定義は準委任契約(=一定の業務遂行を依頼する契約)、仕様確定後の開発は請負契約(=合意した成果物の完成を依頼する契約)とする方法があります。契約名だけで判断せず、成果物、確認方法、変更時の扱い、責任範囲を確認してください。
要件定義の完了時には、少なくとも次を合意します。
- 対象機能と対象外機能
- 画面、帳票、権限、データの概要
- 外部連携とデータ移行の方法
- 性能、セキュリティ、バックアップの条件
- 発注者と開発会社の役割分担
- 正式な費用、納期、検収条件
- 仕様変更を受け付ける手順
7. 発注者側の体制と確認日程を確保する
開発会社へ任せても、業務上の判断は発注者にしかできません。業務責任者、現場代表、決裁者、窓口担当者を決め、質問への回答期限とレビュー日程を確保してください。
中規模案件なら、準備に2〜6週間、要件定義に1〜3カ月、設計・開発・テストに4〜8カ月、受入・移行・公開に1〜3カ月程度かかることがあります。工程は一部重なりますが、社内確認やデータ整備の遅れも全体日程に影響します。
概算予算の整理、外注範囲の切り分け、要件定義から支援が必要な場合は、開発のご相談はこちらをご利用ください。
開発会社の選び方と失敗の回避策
開発会社は、提示価格や実績件数だけでなく、業務理解、見積もりの透明性、担当体制、品質管理、公開後の支援で比較します。類似実績があっても、今回の業務を理解する担当者がプロジェクトに参加しなければ、実績を十分に生かせないためです。
選定時に確認したい質問
- なぜこの機能と方式を提案したのか
- 不要または後回しにできる機能は何か
- 見積もり時点で未確定の事項は何か
- プロジェクト責任者と主要担当者は誰か
- 開発の一部を再委託する場合、品質をどう管理するか
- 進捗、課題、仕様変更をどの方法で共有するか
- テスト、データ移行、利用者教育を誰が担当するか
- 障害時の連絡先、受付時間、初動の目安はどうなるか
- ソースコード、設計資料、データの権利と引き渡し条件はどうなるか
発注の相談を受ける開発会社の立場では、初回から機能数だけを聞く会社より、「なぜ必要か」「現場では例外時にどう処理するか」「既製サービスで代替できないか」まで質問する会社のほうが、認識差を減らしやすいと考えます。質問が多いこと自体ではなく、質問が提案や見積もりへ反映されているかを見てください。
評価基準は提案を受ける前に決めると、社内で判断しやすくなります。次は配点例です。案件の目的に応じて調整してください。
| 評価項目 | 配点例 | 評価する内容 |
|---|---|---|
| 業務・課題の理解 | 25 | 目的、現行業務、例外を理解しているか |
| 提案の妥当性 | 20 | 方式、優先順位、段階導入の考え方が適切か |
| 見積もりの透明性 | 20 | 範囲、前提、除外事項、追加費用条件が明確か |
| 担当体制 | 15 | 責任者、担当者、再委託先、連絡方法が明確か |
| 品質・セキュリティ | 10 | テスト、レビュー、権限、障害対策が具体的か |
| 保守・将来性 | 10 | 公開後の支援、資料の引き渡し、拡張性があるか |
よくある失敗と回避策
| よくある失敗 | 起きる問題 | 回避策 |
|---|---|---|
| 目的を決めず機能一覧だけを渡す | 必要性の低い機能が増え、投資判断ができない | 課題と導入後の成功条件を先に合意する |
| 経営層だけで仕様を決める | 実際の業務や例外に合わない | 要件定義から現場代表を参加させる |
| データ移行を公開直前に考える | 欠損や重複の修正が集中する | 見積もり前にサンプルを確認し、移行を試行する |
| 曖昧な段階で固定価格を求める | 予備費が上乗せされるか、追加請求が増える | 要件定義を先行し、確定後に正式見積もりを取る |
| 初回から全機能を盛り込む | 期間が延び、現場確認の負担も増える | 必須・重要・将来に分けて段階的に導入する |
| 最安値だけで選ぶ | テスト、移行、管理が不足することがある | 同じ条件で成果物、体制、除外事項を比較する |
| 公開後の運用を決めない | 問い合わせや障害時の担当が曖昧になる | 保守範囲、連絡方法、社内管理者を公開前に決める |
契約前には、仕様変更の判断者、追加費用の算出方法、検収(=納品物が合意内容を満たすか確認すること)の条件も明文化します。「軽微な修正は無料」のような曖昧な表現ではなく、どこからが追加対応なのかを確認してください。
また、将来ほかの開発会社へ保守を移す可能性があるなら、ソースコード、データベース定義、環境構築手順、アカウント、設計資料を引き渡せる契約にしておきます。特定の会社しか変更できない状態を避けることは、継続的な運用コストを管理するうえでも重要です。
まとめ
- 業務システム開発の費用は、小規模で300万〜800万円、中規模で800万〜3,000万円、大規模で3,000万円以上が一般的な目安です
- SaaSやローコードを活用し、標準機能へ業務を合わせられる場合は、100万〜500万円程度から検討できることがあります
- 費用は画面数より、業務ルール、例外処理、外部連携、データ移行、非機能要件の影響を受けます
- 見積書では総額だけでなく、成果物、担当範囲、除外事項、追加費用の条件を確認します
- 外注前に目的、現行業務、必須範囲、データ、予算、希望時期、社内体制を整理します
- 仕様が不明確な場合は、要件定義を先行発注し、その後に開発範囲と正式金額を確定する方法が有効です
- 開発会社は価格だけでなく、業務を理解する質問力、担当体制、品質管理、保守、資料の引き渡し条件で選びます
よくある質問
Q1. 業務システム開発には最低いくら必要ですか?
個別開発では、小規模でも300万〜800万円程度が一般的な目安です。機能が限定的で、SaaSやローコードの標準機能を活用できれば、100万〜500万円程度から実現できる場合もあります。要件定義、データ移行、テスト、保守が別料金ではないかも確認してください。
Q2. 業務システム開発にはどれくらいの期間がかかりますか?
小規模で3〜6カ月、中規模で6〜12カ月、大規模で12〜24カ月以上が目安です。外部連携、データ移行、社内確認、追加要望によって延びるため、開発作業だけでなく発注者側の確認期間も計画へ含めます。
Q3. パッケージ導入と個別開発はどちらを選ぶべきですか?
標準的な業務で、運用をサービス側に合わせられるならパッケージが向いています。独自業務が競争力に直結する場合や、複雑な連携が必要な場合は個別開発を検討します。標準業務はパッケージ、独自領域だけ個別開発とする組み合わせも選択肢です。
Q4. 相見積もりは何社に依頼すべきですか?
比較の負担と選択肢のバランスから、2〜3社が目安です。同じ資料と条件を渡し、総額だけでなく、対象範囲、成果物、担当体制、除外事項、保守内容を比較してください。
Q5. 要件が固まっていなくても開発会社へ相談できますか?
相談できます。導入目的、困っている業務、利用者、予算の上限、希望時期まで整理できていれば、詳細仕様がなくても相談可能です。不確定要素が多い場合は、要件定義を先に契約し、その成果を基に開発費を確定する方法が適しています。