業務システム開発を外注する費用【2026年版】規模別・機能別の相場と、見積書に載らない連携・移行費

「業務システムを外注したら、結局いくらかかるのか」——販売管理や在庫管理の刷新を検討している方から、こうした相談をよく受けます。3社に声をかけたら180万円・520万円・1,100万円と返ってきて、どれが妥当なのか説明できない。社内では「一番安いところでいいのでは」と言われるが、安い会社を選んで失敗したときの責任は自分に来る。金額の差の理由が分からないまま稟議を書くのは、かなり心細いものです。

結論から言うと、業務システムの外注費用には、公開された一次統計がありません。出回っている相場表は各社が自社の受注実績でまとめたもので、同じ「中規模」でも会社によって金額の幅が大きく違います。そのため本記事では他社の相場表を引用せず、自社の案件がどの規模・どの作り方に当たるかを見分ける方法と、金額を公開している当社の単価を物差しとして示します。そのうえで稟議に書くべきは初期費用ではなく、保守費とクラウド運用費を足した5年総額です。

そして、見積もりが2倍以上違う原因の大半は単価ではなく、既存システムとの連携とデータ移行を含んでいるかどうか、要件定義にどれだけ工数を置いたかの2点です。業務システムには必ず20年物の基幹システムやExcel台帳という前任者がいます。ここを「別途」にした見積もりだけが安く見える、というのが実情です。

本記事では、規模の見分け方と5年総額の考え方、販売管理・在庫・生産管理・勤怠・社内ポータルといった機能別に費用が動く要因、SaaS/ノーコード/パッケージ/スクラッチの選び分け、見積書に載らない費用(連携・移行・クラウド運用費・保守費)、費用を下げる現実的な方法、よくある質問の順に解説します。金額は、原典を確認できない他社の相場表は引用せず、当社が公開している単価と、提供元が自ら公表している価格だけを示します。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社は実務3年目安のエンジニアで月1,500USD(約22.5万円・1USD=150円換算目安)と単価を公開していますが、業務システムの費用は単価ではなく「作る範囲」で決まります。この記事を読み終えるころには、自社の案件がどの規模・どの作り方に当たるかと、各社に何を追加で聞けばよいかが判断できるはずです。

業務システム開発を外注する費用の全体像——規模の見分け方と、初期費用ではなく5年総額で見る理由

業務システムとは、販売管理・受発注、在庫管理、生産管理、顧客管理、勤怠、社内ポータルなど、日々の業務を回すために社内で使うシステムのことです。BtoCのWebサービスやスマートフォンアプリとは費用の構造が違い、既存の基幹システムやExcel台帳との接続が前提になる点が最大の特徴です。まずは規模の見分け方から押さえてください。

規模の見分け方(小規模・中規模・大規模・超大規模)

金額の目安は、公的な統計がないため本記事では示しません。開発会社が公開している相場表は各社の受注実績に基づくもので、同じ「中規模」でも会社によって数倍の開きがあります。どちらかが間違っているのではなく、母集団が違うだけです。自社の案件は「つなぐ既存システムが何本あるか」「使う部門がいくつか」で当てはめるのが、最も外しにくい読み方です。そのうえで各社から見積もりを取り、金額の差の理由を範囲で説明してもらってください。

「平均」で相場を読むと予算を間違える——平均値と中央値がずれる理由

相場を平均値で理解すると、予算は必ず高めに振れます。開発費用の分布は少数の大型案件が平均を押し上げる形になるため、平均値は「よくある金額」から外れた値になりやすいからです。ただし、その分布を示す公的な統計は2026年時点で存在せず、開発会社が公表している平均値・中央値も母数と取得期間が明示されていないため、本記事では具体的な金額を引用しません。

大事なのは、平均値を自社の予算の出発点にしないことです。「基幹システムだから高額になる」と決めつける前に、1業務に絞った小規模の範囲で足りないかを先に検討してください。範囲を絞れば、平均値とは違う帯で成立する余地があります。

同じ要件で見積もりが大きく違う理由——人月単価と、工数の前提のずれ

業務システムの見積もりは、ほぼ例外なく「人月単価×必要工数+付帯費用」で作られます。総額の大半を占めるのは人件費で、なかでも要件定義は、1行もプログラムを書かないまま相応の金額が積まれる工程です。工程ごとの内訳を出してもらわない限り、この部分は総額に埋もれて見えません。

人月単価は発注先で大きく変わります。フリーランス、中小の開発会社、大手システムインテグレーターの順に上がるのが一般的ですが、各社が公開している単価表はいずれも自社実績に基づく目安で、照合できる公的な統計はありません。そのため本記事では他社の単価は示さず、金額を公開している当社の単価(実務3年目安 月1,500USD・約22.5万円、実務5年 2,000USD、ブリッジSE 3,000USD。1USD=150円換算の目安)を物差しとしてお使いください。同じ人数・同じ期間でも、誰が作るかで総額は大きく動きます。人月という単位そのものの読み方は「人月単価」の記事で詳しく整理しています。

もう1つの理由が、工数の前提がそろっていないことです。A社は「既存システムからのデータはCSVで出してもらう前提」、B社は「連携の仕組みまで作る前提」で計算している。この差だけで見積もりは大きく動きます。なお2026年時点では、工数や単価を照合できる公的な統計は存在しません。IPA(情報処理推進機構)の「ソフトウェア開発分析データ集」は2022年版が最後で、IPAの公式ページにも事業終了により今後の発行予定がない旨が記載されています(2026年9月21日確認)。各社の相場表はすべて自社実績に基づく体感値であり、数字が食い違うのは当然だと考えてください。

稟議に書くべきは5年総額——初期費用だけの稟議は差し戻される

業務システムは5年以上使うものです。開発費を払って終わりではなく、保守費が毎年上乗せされます。保守費の比率についても公的な統計はないため、本記事では割合を示しません。契約前に、保守の月額と対応範囲(障害対応・軽微な改修・問い合わせ対応がどこまで含まれるか)を見積書に別記させ、5年分を自社の数字で積み上げてください。ここにクラウド利用料と、AI機能や外部サービスを使う場合の従量課金が加わります。

経理や経営層が知りたいのは、初期費用ではなく5年分の合計です。初期費用だけの稟議は必ず「毎年いくらかかるのか」で差し戻されます。次章では、この全体像を自社の案件に当てはめられるよう、対象業務ごとに費用が動く要因を見ていきます。

機能・システム別に費用が動く要因——販売管理、在庫管理、生産管理、勤怠、社内ポータル

「業務システム」とひとくくりにしても、対象業務によって必要な機能も費用の動き方も違います。同じ予算でも、顧客管理なら十分な範囲が作れる一方、多拠点の在庫管理では足りないということが起こります。ここでは代表的な対象業務ごとに、費用を動かしている要因と標準品の充実度を並べ、自社の案件のどこで金額が膨らむかを見当づけられるようにします。

対象業務別に費用が動く要因の一覧表

金額の帯は、対象業務ごとに公開された一次統計がないため本記事では示しません。代わりに、見積もりを取るときは上の「費用が動く主な要因」を自社の条件に当てはめ、各社に同じ条件で出してもらってください。業界固有の工程や独自の原価計算が絡む生産管理は、同じ対象業務でも金額が上振れしやすい領域です。

販売管理・受発注と在庫管理——拠点数と外部連携の数で大きく動く

この2つは業務システムの中でも金額が動きやすい領域です。在庫管理が単一拠点と多拠点で大きく開くのは、拠点間の在庫移動、ロケーション管理、ハンディターミナルとの連動が加わると、設計・テストの工数が一気に増えるためです。

販売管理も同じで、見積から請求までを1本でつなぐと、会計ソフト・EDI・ECサイトなど外部との接続が必ず発生します。外部サービスとの連携は1本増えるごとに、仕様調査・実装・テスト・エラー時の運用設計がセットで乗ります。見積もりを比べるときは「連携先は何本で、それぞれどこまでが範囲か」を最初に確認してください。ここを曖昧にしたまま金額だけを並べるのが、比較を誤らせる最大の原因です。

勤怠・社内ポータル・生産管理——標準品があるかどうかで判断が分かれる

勤怠・人事は、法改正への追随が必要で、かつ標準品(SaaS)が非常に充実している領域です。自社専用に作れば開発費がかかるうえ、労働法制が変わるたびに改修費が発生します。特殊なシフト体系や複雑な手当計算がないのであれば、作らずにSaaSを選ぶほうが安く、速い。標準機能で足りる業務まで作り込むのは失敗のもとです。

一方、社内ポータルと申請ワークフローは、承認ルートや権限の切り方が会社ごとに違うため、独自要件が出やすい領域です。とはいえ画面と項目の組み立てが中心で処理はシンプルなことが多く、ノーコード・ローコードで十分に成立します。生産管理は逆で、工程管理や原価計算が競争力そのものになっている製造業では、パッケージに業務を合わせられずスクラッチに寄る傾向があります。

当社が手がけてきた開発でいえば、求人プラットフォーム(応募者管理システム)やヘッドレスCMSを使ったWebサイトは、権限管理・ステータス遷移・外部連携という点で業務系システムに近い構造を持っています。こうした案件でも、費用を決めているのは技術の難しさよりも「どこまでを標準に寄せ、どこを自社仕様にするか」の線引きでした。では、その線引きはどう決めればよいのでしょうか。答えは「作り方の選択」にあります。

作り方で費用は大きく変わる——SaaS、ノーコード、パッケージ、スクラッチの選び分け

同じ「在庫管理システムがほしい」という要望でも、既製のSaaSを使うのか、ノーコードで組むのか、パッケージをカスタマイズするのか、ゼロから作るのかで費用は桁違いに変わります。業務システムの外注費用を下げる余地は、単価の交渉よりもこの選択に大きく残っています。

作り方別の費用の出方と向いているケース(表)

金額の目安は、作り方別にも公的な統計がないため本記事では示しません。ただし構造として、スクラッチの下限は下がってきています。AIによるコーディング支援の普及で実装工程の生産性が上がったためで、数年前に予算が合わずに諦めた小規模なシステム化は、いま見積もりを取り直すと通る可能性があります。当社もAIを活用した開発体制を取っていますが、効くのは実装とテストで、設計とレビューは日本人PMが担います。

5年総額で並べ直すと帯が重なる——初期費用だけでは判断できない

初期費用だけで比べると、SaaSやノーコードが圧倒的に安く見えます。しかし業務システムは5年以上使うものなので、5年総額で並べ直す必要があります。

金額を自分で確かめられる例を1つ挙げます。サイボウズが公式サイトで公開しているkintoneの価格は、スタンダードコースが1ユーザーあたり月1,800円(税別、最小10ユーザー。2026年9月21日確認)です。20名で使うなら年43.2万円、5年で216万円になります。提供元が自ら公表している価格なので、この種の数字は自社の利用人数と年数で積み上げれば確かめられます。

この試算で気づいてほしいのは、SaaSの5年総額も無視できない水準になるという点です。「作るのは高い、既製品は安い」とは単純に言い切れません。ユーザー数が多くてSaaSの課金が積み上がる、業務が独自で既製品に合わせられない、既存システムとの連携が必要——この3つが重なるほど、作ったほうが5年総額で有利になります。

判断の順番——まず作らない、次にノーコード、最後にスクラッチ

私が相談を受けたときに最初に確認するのは、「それは本当に作る必要があるか」です。会計・勤怠・経費精算のように標準品が成熟している業務は、作らないのが最も安く、最も速い。SaaSで足りるなら、その旨をはっきりお伝えしています。

次の選択肢がノーコード・ローコードです。項目や画面は自社独自でも、処理そのものが「入力して、一覧で見て、承認する」程度であれば十分に成立します。自社で設定を変えられるため、細かな改修のたびに見積もりを取る必要がなくなるのも利点です。

スクラッチを選ぶべきなのは、独自の業務フローが競争力そのものになっている場合と、既存システムとの複雑な連携が避けられない場合に絞られます。迷ったらノーコードで小さく作り、限界が来た部分だけをスクラッチに置き換える——この順番が、最も損の少ない進め方です。逆に、最初から全社の基幹システムを一気に作り替えようとすると、要件定義だけで予算が消えます。ここは要注意です。

見積書に載らない費用——既存システム連携、データ移行、クラウド運用費、保守費

業務システムの予算で最も見落とされるのが、見積書に金額として現れない費用です。3社の見積もりが2倍以上違うとき、差の正体はたいてい単価ではなく、この部分を含んでいるかどうかにあります。業務システムには必ず既存の基幹システムやExcel台帳という前任者がいる以上、ここを避けて通ることはできません。

見積書に現れにくい7つの費用(表)

保守費の比率を「開発費の年◯%」と示す相場表が複数の開発会社から公開されていますが、いずれも自社実績に基づく目安で、照合できる公的な統計はありません。そのため本記事では比率を示さず、見積書に月額と対応範囲を別記させる方法をお勧めします。7つの費目すべてについて「含む/含まない」を明記させれば、各社の見積もりを同じ土俵で比べられる形になります。

既存システム連携とデータ移行——業務システムで費用が最も動く2つ

新規のWebサービスと業務システムの決定的な違いが、この2つの存在です。

既存システム連携でまず問題になるのは、相手側にデータを外へ出す仕組みがあるかどうかです。API(外部のシステムとデータをやり取りするための窓口)が用意されている会計ソフトやSaaSなら話は早いのですが、20年前に作られた基幹システムが相手だと、そもそもデータを取り出せるかの調査から始まります。この調査だけで数週間かかることがあり、結果として「CSVの手動連携でいく」と方針が変わることもあります。要件定義の段階でここを先に確認しておけば、後から「連携できないので追加費用が必要」という事態を避けられます。

データ移行で工数を食うのは、プログラムではなくデータそのものの整理です。同じ取引先が「株式会社◯◯」「(株)◯◯」「◯◯」と複数の表記で登録されている、廃止したはずのコードが生きている、必須項目が空のまま運用されてきた——こうした状態のまま新システムに流し込むと、自動処理が通りません。名寄せのルールを決め、誰が判断するかを先に決めておく必要があります。ここは発注側でしか判断できない部分が多く、社内工数としても跳ね返ってきます。

見積書に必ず明記させる5項目と、相見積もりの取り方

私は人材業界の出身で、2018年からホーチミンで約100社の開発体制づくりに携わってきました。業務システムの相談で最も多いのが「3社の見積もりが2倍以上違って比較できない」というものです。実際に中身を開いてみると、最も安かった1社はデータ移行と会計ソフト連携を含めておらず、要件定義にも1週間しか置いていませんでした。当初は最安でしたが、含まれていない範囲を足し戻すと、3社の中で最も高くなる提案でした。

こうしたすれ違いは、契約前の確認で大半が防げます。見積書に次の5項目が明記されているかを確認してください。

5番目が最も重要で、そして最も書かれていません。「変更は別途相談」としか書かれていない見積書は、費用が青天井になる余地を残しています。開発中は変更管理票と課題管理一覧表を作り、追加作業のやり取りを議事録として残しておくだけで、後から金額を巡って揉める確率は大きく下がります。

相見積もりを取るときは、必ず同じ要件書を各社に渡し、上記5項目と7つの費目について「含む/含まない」を明記させてください。これをやらずに金額だけを並べた比較は、意味がないどころか判断を誤らせます。工程別の内訳の読み方は「システム開発 見積もり 内訳」の記事で詳しく整理しています。

費用を下げる現実的な方法——標準機能に寄せる、優先順位を絞る、ラボ型で内製と並走

費用を下げると聞くと、まず単価の交渉を思い浮かべる方が多いのですが、業務システムの費用は単価ではなく「作る範囲」で決まります。効果の順に並べると、範囲を絞ることが最も効き、次に体制の単価、補助金は最後です。

費用を下げる4つの方法と、下げてはいけない工程(表)

補助金については、2026年に「IT導入補助金」が「デジタル化・AI導入補助金」へ改称され、生成AIを含むツールも対象として明確化されました。運営する独立行政法人中小企業基盤整備機構の公式サイトによれば、2026年の通常枠は補助率1/2以内(最低賃金近傍の事業者は2/3以内)、補助額は業務プロセスが1〜3つで5万〜150万円、4つ以上で150万〜450万円です(2026年9月21日確認)。枠と公募回で条件が変わり、GビズIDの取得などの事前準備にも時間がかかるため、必ず公式サイトで最新の条件を確認してください。

一方で、下げてはいけない工程があります。要件定義です。工数の面でも軽い工程ではありませんが、ここを削った見積もりは安く見えるだけで、要件定義書に書かれていない機能は後から「当初の仕様に含まれない」と判断され、追加請求の対象になります。要件定義が曖昧なまま進んだ案件は、発注側が構造的に不利になる——これは相談を受けてきた中で例外がありません。

ラボ型で内製と並走する——月額固定で改修が続く業務システムに向く

業務システムは、作って終わりではなく改修が続きます。法改正、組織変更、取引先の増減、現場からの要望。請負契約で一括発注すると、改修のたびに見積もりと稟議が必要になり、小さな改善ほど後回しになります。

そこで選択肢になるのがラボ型開発です。専属チームを月額固定で確保し、優先順位を見直しながら継続的に開発を進める形態で、オフショア開発白書2025年版(オフショア開発.com、2026年9月21日確認)では契約形態の45%と最多になりました。社内のエンジニアをプロダクト側に張り付けたまま、業務システム側を外部の手で並走させたい——こうした体制に向きます。ラボ型の費用構造そのものは「ラボ型開発 費用」の記事、内製化との組み合わせは「システム内製化」の記事で整理しています。

当社の場合の費用感——公開単価と最小構成、向く案件と向かない案件

当社は単価を公開しています。実務3年目安のエンジニアが月1,500USD(約22.5万円)、実務5年で2,000USD(約30万円)、実務10年以上およびブリッジSEで3,000USD(約45万円)です(1USD=150円換算目安)。当社調べで市場相場の約1/2にあたります。協力会社や紹介を経由せず、2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインしているため、仲介マージンが乗りません。

推奨する最小構成は、日本人PMをフロントに置き、エンジニア2〜3人月を組み合わせた月額約80万円〜です。前章の規模で言えば、複数部門で使う中規模の案件を数か月で進める体制に相当します。1名から契約でき、開始は最短2週間、増員は約1週間、縮小・交代は1か月単位で調整できます。流れは打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始で、契約・支払いは日本国内法人・日本法準拠のため海外送金は不要です。

品質は仕組みで担保します。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点です。開発実績には求人プラットフォーム(応募者管理システム)やヘッドレスCMSを使ったWebサイトがあり、介護記録SaaS「CareViewer」では日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、従来の半分以下のコストで継続開発を進めています。ベトナムとの時差は2時間、祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)、テト(旧正月)は2026年が2月14日〜22日です。

正直に書くと、向かない案件もあります。全社基幹システムの一斉刷新のように数十名を同時に立ち上げる案件、CMMIなどの認証準拠が必須の案件、月30万円以下の単発改修は、当社より国内の大手システムインテグレーターや近隣の開発会社のほうが適しています。逆に、改修が続く業務システムを小さく始めて育てたい案件、社内のエンジニアを空けずに並走させたい案件は、当社の構造と噛み合います。自社の案件はどちらでしょうか。

業務システムの外注費用でよくある質問

業務システムの費用について、相談の場で繰り返し聞かれる質問を5つにまとめました。稟議書の想定問答にもお使いください。

Q1. 業務システムの開発は、最低いくらから依頼できますか?

最低価格を示した公的な統計はないため、金額の目安は示せません。当社の場合は、日本人PMをフロントに置いた最小構成の月額約80万円〜(実務3年目安のエンジニアが月1,500USD・約22.5万円。1USD=150円換算の目安)からお受けしています。金額を抑えたいときは、詰まっている作業を1つに絞ってください。対象を全社に広げると、予算が要件定義だけで消えます。

Q2. 保守・運用費の相場はどのくらいですか?

保守費の相場を示した公的な統計はないため、比率での目安は示せません。内容はサーバー費・不具合修正・軽微な機能追加・問い合わせ対応が中心になります。見積もりを取るときは、保守の月額と対応範囲を別記させてください。保守費が極端に安い場合は、不具合修正が別請求になっていないかを契約内容で確認してください。提示された月額を5年分積み上げたうえで稟議を書くのが安全です。

Q3. データ移行は開発費に含まれますか?

含まれないことが多く、「別途」と書かれて素通りされやすい費目です。既存のExcel・紙台帳・旧システムからの移行では、表記ゆれ・重複・欠損の名寄せが最も工数を食います。見積もり依頼の時点で、移行対象のデータ件数と現在の管理方法を伝え、移行費を含めた金額を出してもらってください。

Q4. 20年前に導入した基幹システムと連携できますか?

相手側にデータを外へ出す仕組みがあるかどうかで変わります。窓口がない場合は連携方式の調査だけで数週間かかることがあり、CSVの手動連携に方針を切り替える判断もあり得ます。要件定義の中でこの調査を先に済ませておけば、後から「連携できないので追加費用が必要」という事態を避けられます。

Q5. オフショア開発にすれば費用は本当に半分になりますか?

単価だけを見れば下がります。当社は実務3年目安で月1,500USD(約22.5万円・1USD=150円換算目安)と公開しており、当社調べで市場相場の約1/2です。ただし総額が半分になるかは、日本語での設計・レビューを誰が担うかで決まります。単価の安さだけで選んで手戻りが増えれば、総額はかえって上がる。そのために当社が日本人PMをフロントに置き、月額約80万円〜の最小構成から始められるようにしているのが要点。

まとめ: 規模と機能で当たりをつけ、5年総額で比べ、見積書に載らない費用を先に確認する

業務システムを外注する費用には、公開された一次統計がありません。出回っている相場表は各社が自社の受注実績でまとめたもので、同じ「中規模」でも会社によって金額の幅が大きく違います。自社の案件は、使う部門の広がりと、つなぐ既存システムの本数で規模の当たりをつけてください。対象業務ごとに金額を動かしているのは、外部連携の本数、拠点数、シフト体系や原価計算の独自性です。そして稟議に書くべきは初期費用ではなく、保守費とクラウド運用費を足した5年総額です。

見積もりが会社で2倍以上違う原因は、単価よりも前提のずれにあります。既存システムとの連携とデータ移行を含んでいるか、要件定義にどれだけ工数を置いたか。この2つを「別途」にした見積もりだけが安く見える、というのが実情です。相見積もりを取るときは、同じ要件書を渡したうえで、工程別の内訳・機能と画面数・テストと移行費・保守の月額・要件変更時の単価という5項目を必ず明記させてください。費用を下げる順番は、標準機能に寄せる、優先順位を絞って1業務から始める、体制の単価を下げる、補助金を使う。要件定義だけは削らないことです。

当社は実務3年目安のエンジニアで月1,500USD(約22.5万円・1USD=150円換算目安)と単価を公開しており、当社調べで市場相場の約1/2です。日本人PMをフロントに置いた最小構成なら月額約80万円〜、1名から最短2週間で開始でき、改修が続く業務システムを内製と並走させる形に向きます。一方で、全社基幹の一斉刷新や認証準拠が必須の案件は、国内の大手システムインテグレーターのほうが適しています。見積もりの工程別の内訳はシステム開発の見積もりの内訳、月額固定で継続する体制の費用はラボ型開発の費用相場もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、規模と作り方の判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。