LASSIC Media らしくメディア

LASSIC IT事業部｜プライムベンダーとしてシステム保守・運用を受託

業務システム開発費用相場とは：規模・工程・体制で決まる総額

業務システム開発の費用相場とは、要件定義・設計・実装・テスト・移行・保守までの全工程にかかる費用の市場目安を指す。費用は規模（機能数・画面数・帳票数）・工程配分・体制構成の3要素で決定される。費用相場は単一の数字で示されるものではなく、システム規模ごとのレンジとして把握する必要がある。なお本記事では、案件ごとの業務複雑度・既存資産活用度・パッケージ適用有無によって金額が大きく変動するため、具体的な金額レンジを断定せず、見積もり妥当性を評価するための判断軸の提供を設計方針としている。IPA「ソフトウェア開発分析データ集2022」は、2004年から蓄積した5,546件の開発データのうち直近6年間の1,479件を対象に、工数・工期・生産性・信頼性のベンチマークを公表しており^*1、見積もり妥当性を判断する基礎情報として利用できる。

費用相場を「規模・工程・体制」で分解する理由

費用相場を単一の総額で語ると、自社案件との適合性が判断できない。規模で総工数が決まり、工程配分で各フェーズのコスト構造が決まり、体制構成で人月単価と稼働期間が決まる。3要素に分解することで、自社案件の見積もりが妥当か検証できる。

「相場感」と「実際の見積もり」の差を埋める情報源

業界の費用相場は民間メディアでも公開されているが、定義と算出根拠がメディアごとに異なる。公的データ（IPA・JUAS）と発注経験値を組み合わせて、自社案件のレンジを把握する手順が、見積もり評価の基礎となる。

費用相場の規模別レンジ：小規模・中規模・大規模の目安

業務システム開発の費用は、システム規模で大きく異なる。小規模・中規模・大規模の区分と、各区分で扱う案件像、想定されるシステム要素を整理する。具体の金額レンジは案件条件（業種・既存資産の活用度・パッケージ活用の有無）で変動するため、ここでは金額の範囲を断定せず、規模感の整理に留める。

小規模システム：単一部門向け・機能数が限定的

小規模システムは、単一部門・単一業務を支援する範囲のシステムを指す。例として、特定部門向けの作業管理・タスク管理・営業日報・小規模在庫管理がある。画面数は十数画面以内、帳票も限定的で、開発期間は短期に収まる傾向がある。要件確定が比較的容易で、フェーズ分割せず一括開発できる場合が多い。

中規模システム：複数部門連携・標準業務領域

中規模システムは、複数部門にまたがる業務連携を扱う範囲で、販売管理・購買管理・在庫管理・原価管理など、標準業務領域の複数モジュールを含む。画面数は数十〜100程度、外部システムとの連携要件が発生する。要件定義工程の重みが増し、業務分析のコンサルティングが必要になる場合がある。

大規模システム：全社基幹・100名以上の開発体制

大規模システムは、全社基幹業務を扱い、開発体制の規模が大きい案件である。IPAの定量データ分析では、100名以上のメンバーが携わる規模のシステムが大規模の分析対象区分の目安として言及されており^*1、開発期間は長期にわたり、複数フェーズに分けたリリース計画が一般的だ。要件定義・設計工程の品質が、全体コストを大きく左右する。

金額レンジを「断定しない」理由

業務システム開発の金額レンジは、案件ごとの業務複雑度・既存資産の活用度・パッケージ活用の有無・カスタマイズ範囲・移行データ規模などで大きく変動する。民間メディアが提示する「○万円〜」「○千万円〜」の数字は参考値として扱い、実際の案件は複数社からの見積もりで比較することが標準である。

見積もり総額の構成要素：人件費比率・工程別配分・諸経費

業務システム開発の見積もり総額は、人件費・諸経費・パッケージ/ライセンス費・リスクバッファの構造で構成される。実務的には人件費が大半を占め、工程配分と人月単価で総額が決まる。内訳構造を理解することで、見積もりの妥当性を検証できる。

人件費：見積もりの大半を占める主要費目

業務システム開発の見積もりにおいて、人件費は総額の主要部分を占める。人件費は「人月単価×投入人月数」で計算される。人月単価は技術者のスキル区分（PM・SE・PG）と契約形態（請負・準委任・SES）で異なる。投入人月数は工程ごとの工数積算で算出される。

工程別配分：要件定義・設計・実装・テストの比率

業務システム開発の工程は、要件定義・基本設計・詳細設計・実装・単体テスト・結合テスト・総合テスト・移行・受入支援に分かれる。実装工程の比率が最も大きく、テスト工程と上流工程（要件定義・基本設計）もそれぞれ一定割合を占める。テスト工程の比率が他社比で極端に低い見積もりは、品質リスクの観点で精査が必要だ。

諸経費・ライセンス費：基盤関連の費用

人件費以外には、データベース・ミドルウェア・開発ツールのライセンス費、クラウドインフラ費用、外部サービス利用料、移行作業の諸経費が含まれる。SaaS・PaaSを活用する案件では、ランニングコストとして毎月発生する利用料の累積見積もりが欠かせない。

リスクバッファ：要件確定度に応じた予備工数

見積もりには、要件変更・仕様調整・テスト不具合修正に備えたリスクバッファが含まれる場合がある。要件確定度が低い案件ほどバッファ比率が高くなる。バッファの内訳が明示されない見積もりは、追加見積もりが発生する確率が上昇する。

公的データから見るベンチマーク：IPAソフトウェア開発分析データ集

業務システム開発の費用相場を客観的に評価する基礎データとして、IPA「ソフトウェア開発分析データ集2022」が利用できる。同データ集は、業界各社から提供された定量データを集計・分析した公的なベンチマークである。2004年から累積した5,546件の開発データのうち、直近6年間の1,479件を対象に、工数・工期・生産性・信頼性の分析結果が掲載されている^*1。

工数・工期のベンチマーク：規模との関係性

IPAデータ集では、システム規模（FP値またはSLOC）と工数・工期の関係が公表されている。自社案件の規模と比較することで、見積もり工数の妥当性を相対評価できる。FP（ファンクションポイント。機能規模を計測する手法）・SLOC（Source Lines Of Code、ソースコード行数）の両方の指標で分析されている。

業種別データの活用：金融・製造・情報通信

IPAデータ集には、業種別編（金融・保険業編、製造業編、情報通信業編）も用意されている。業種特性によって生産性・信頼性が異なるため、自社の業種に近いデータと比較することで、より精度の高いベンチマークが得られる。

JUAS調査の活用：IT予算と投資動向

JUAS（一般社団法人日本情報システム・ユーザー協会）「企業IT動向調査2025」は、企業のIT予算・投資動向のベンチマークとして広く参照される^*2。同調査では2025年度にIT予算を増やす企業の比率や、増加理由のトップが整理されており、業界全体の投資水準と比較した自社判断の材料になる。

見積もり妥当性の判断軸：工数積算・人月単価・工程比率

外部パートナーから提示された見積もりが妥当かどうかを判断する軸は、工数積算の根拠・人月単価の妥当性・工程比率の3点である。

工数積算の根拠：機能数・画面数・帳票数からの算出

見積もりの工数は、機能数・画面数・帳票数・データ移行件数などの規模指標から算出される。算出根拠を提示できない見積もりは、ブラックボックス化しており妥当性検証が困難だ。提案時に工数算出の前提となる機能一覧・画面一覧・帳票一覧を要求することで、複数社見積もりの比較が可能になる。

人月単価の妥当性：技術スキル区分との対応

人月単価は、PM・SE・PGなどの技術スキル区分ごとに設定される。シニアSEとジュニアSEで単価が異なる体系が一般的だ。提案体制の役職構成と単価が整合しているか確認する。極端に低い単価は再委託・若手中心の体制を示唆する場合があり、品質リスクの観点で精査が必要だ。

工程比率の妥当性：上流・実装・テストのバランス

見積もりの工程比率は、上流（要件定義・基本設計）・実装（詳細設計・実装）・テスト（単体テスト・結合テスト・総合テスト）・移行運用支援の4区分で評価する。実装工程に偏重した見積もりは、要件定義不足やテスト不足のリスクを示唆する。

追加見積もり発生の前提を確認する

初期見積もりが安価でも、追加見積もりの発生条件が曖昧な契約では、最終的な総額が膨らむ確率が高い。要件変更時の追加見積もりルール、テスト不具合修正の責任範囲、移行作業の追加費用を契約段階で確認することが、総額管理の実務上の基本だ。

費用が膨らむ落とし穴：安価見積もりが運用で反転する事例

業務システム開発で「安価な見積もり」を選択した結果、運用フェーズで追加コストが発生する事象は実務上見られる。代表的な失敗パターンを整理し、発注時に避けるべき判断を示す。

仕様凍結が甘い案件：追加要件で見積もりが膨張

要件定義が完了する前に発注した案件では、開発進行中に追加要件が発生する。追加要件は契約外として別途見積もりが発生するため、初期見積もりの優位性が打ち消される。仕様凍結の手順を契約に組み込む発注運用が、追加コスト抑制につながる。

テスト工程削減：稼働後のバグ修正で追加コスト

テスト工程の見積もりを削減すると、稼働後にバグが顕在化し、修正費用が発生する。基幹業務に近いシステムほど、バグの業務影響コストが大きい。テスト工程は品質保証の要であり、削減対象としては優先度が低い。

保守費が別契約：稼働後の固定費を見落とす

開発見積もりに保守運用フェーズが含まれていない案件は、稼働後に別契約での保守費が発生する。保守費は開発費に対する一定比率が業界で目安として用いられるが、案件規模・SLA水準により変動する。開発と保守を一体で見積もる発注方式が、5年TCO最適化に寄与する。

再委託多重化：管理コストとリスクの上昇

外部パートナーが再委託を多重化している案件は、コミュニケーションコストと品質リスクが上昇する。元請（プライムベンダー）として一貫した責任を負う体制を持つパートナーは、品質管理と契約責任の所在が明確である。再委託の有無と階層は、発注前に確認すべき項目となる。

外部パートナー選定で確認する5項目：見積根拠・体制・保守実績

業務システム開発の発注では、外部パートナーの選定が費用相場の現実化を左右する。確認すべき項目は、見積根拠の透明性・開発体制の自社比率・保守実績・業務知識・契約形態の5点である。

見積根拠：工程別工数の積算が示されているか

見積総額のみではなく、工程別の工数積算が明示されているかを確認する。要件定義・基本設計・詳細設計・実装・テスト・移行・運用支援の各工程について、人月数・人月単価・期間が明示されていることが、妥当性検証の出発点だ。

開発体制：自社要員比率と再委託状況

提案体制が自社要員中心か、再委託（下請け）が多重化しているかを確認する。自社要員比率が高い元請会社は、品質管理・要員育成・契約責任の一貫性を保ちやすい。再委託の階層が深い案件は、コミュニケーションコストが上昇する。

保守実績：長期稼働システムの保守経験

業務システムは長期稼働が前提のため、外部パートナーが長期稼働システムの保守経験を持つかを確認する。受託している保守案件の業種・期間・規模を確認すると、保守力の判断材料になる。新規開発のみの実績では、保守フェーズで発生する課題への対応力が見えない。

業務知識：自社業界の業務経験

業務システムは業界固有の業務知識が要件定義の質を決める。発注側の業界での開発実績を持つパートナーは、要件のヒアリング精度が高く、手戻りを抑えられる。業務知識のある人材を提案チームに含めているかを確認する。

契約形態：請負・準委任・SESの使い分け

契約形態は、請負・準委任・SES（システムエンジニアリングサービス）の3区分から選択する。請負は成果物責任、準委任は業務遂行責任、SESは時間単位の人員提供という違いがある。工程ごとに適切な契約形態を組み合わせる発注設計が、責任所在の明確化に寄与する。

内製化を選ぶ場合のリスク：要員確保コストの増大

業務システム開発を完全内製で進める判断は、要員確保・育成コストの上昇を招く。経済産業省が2019年4月に公表した「IT人材需給に関する調査」では、IT人材不足が2030年に高位シナリオで最大約79万人に拡大すると試算している^*3。内製偏重の選択は、要員確保が中長期の経営課題になることを踏まえて判断する。要件定義は業務知識を持つ内製チーム、設計・実装は外部パートナーという役割分担が、コストと業務適合のバランスを取りやすい。

まとめ：業務システム開発費用相場の3つの判断軸

業務システム開発の費用相場は、規模・工程配分・体制構成の3要素で決定されるため、自社案件の規模区分を見極めたうえでレンジを把握することが出発点だ。IPA「ソフトウェア開発分析データ集」やJUAS「企業IT動向調査」などの公的データを、見積もり妥当性検証のベンチマークとして活用することで、案件固有の相場感が形成できる。見積もりの内訳（工数積算・人月単価・工程比率）を分解して評価し、安価な総額に飛びつかず、運用フェーズまで含めた5年TCOで判断することが、発注後の手戻りを防ぐ。外部パートナー選定では、見積根拠の透明性・体制の自社比率・保守実績の3点を確認することが、費用相場と実態の整合性を担保する。具体的な金額レンジは案件ごとの業務複雑度・既存資産・パッケージ活用の有無で大きく変動するため、複数社の見積もり比較が相場感の形成において最も有効な手段だ。

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：独立行政法人情報処理推進機構「ソフトウェア開発分析データ集2022」（2022年）
2. *2　出典：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査2025」（2025年）
3. *3　出典：経済産業省「IT人材需給に関する調査（概要）」（2019年）

Tweet