「レガシーシステムのリプレイスに、いったいいくらかかるのか」——この疑問は、IT担当者や経営層が最初にぶつかる最大の壁のひとつです。現行システムの老朽化やサポート切れを前に、刷新の必要性を感じながらも、費用の見通しが立たずプロジェクトが前に進まないケースは非常に多く見られます。経済産業省のDXレポートが指摘するように、多くの企業でIT予算の8割以上がレガシーシステムの維持管理に費やされており、新しい価値を生み出すための投資に回す余力がなくなっているのが実情です。
本記事では、レガシーシステムリプレイスにかかる費用の全体像を、規模別の相場・工程別の内訳・人月単価の目安から、コストが膨らむ要因と対策、ROI（投資対効果）の算出方法、そして財務・会計処理のポイントまで、体系的に解説します。単なる費用の羅列ではなく、「なぜそのコストが発生するのか」「どこを抑えればよいのか」という実務的な観点で整理していますので、稟議資料の作成やベンダー見積もりの精査にもそのまま活用していただけます。
▼全体ガイドの記事
・レガシーシステムリプレイスの完全ガイド
レガシーシステムリプレイスの費用相場一覧
レガシーシステムのリプレイス費用は、企業の規模・システムの複雑性・移行方式によって大きく異なります。まずは全体の費用感をつかんでから、詳細の内訳を把握していくことが、見積もり精査の第一歩です。
規模別の費用目安（中小企業 vs 中堅・大企業）
レガシーシステムリプレイスの費用は、対象企業の規模によって大きく3つのレンジに分かれます。従業員50名以下の小規模企業では100万〜500万円程度が目安となります。スクラッチ開発ではなくクラウドSaaSへの移行や、限定的な業務領域のみのリプレイスであれば、この範囲に収まるケースが多いです。
従業員51〜300名規模の中小・中堅企業では500万〜3,000万円程度が相場です。複数の業務システムを統合したり、既存のオンプレミス環境をクラウドに移行したりする場合はこのレンジが中心となります。従業員300名を超える大企業・グループ企業では、3,000万円〜1億円以上の投資が必要になるケースが多く、SAP等の大規模ERPを導入する場合は数億円規模になることも珍しくありません。
ただし、これらはあくまでも目安であり、同じ規模の企業でもシステムのカスタマイズ度合い・データ移行の複雑さ・連携する外部システムの数によって費用は大きく変動します。「中小企業だから安い」という単純な判断は禁物で、後述するコスト膨張の要因を正しく理解したうえで見積もりに臨むことが重要です。
開発工程別の費用内訳（要件定義・設計・開発・テスト・保守）
見積書を受け取った際に最初に確認すべきなのが、工程別の費用内訳です。適切な費用配分の目安として、要件定義が全体の10〜15%、設計が10〜25%、開発・実装が50〜60%、テストが5〜10%、運用保守が15〜20%というのが業界の標準的な比率です。
注意が必要なのは「開発費」に何が含まれているかという点です。要件定義と設計を一括りにして「上流工程費」として提示するベンダーもいれば、プロジェクトマネジメント費用を別途請求するケースもあります。また、データ移行費・ユーザー教育費・ドキュメント作成費が見積もりに含まれているかどうかは必ず確認してください。これらが「別途」となっていると、後から数百万円単位の追加費用が発生することがあります。
要件定義フェーズへの費用配分が極端に低い（全体の5%以下）見積もりは要警戒です。要件定義が薄いプロジェクトほど、後工程での手戻りや追加要件による費用膨張が起きやすく、結果的に総費用が当初見積もりを大幅に超えるリスクがあります。
エンジニアの人月単価目安（新人〜上級）
システム開発費用の大部分はエンジニアの人件費で構成されます。人月単価（1名のエンジニアが1ヶ月稼働した場合の費用）は、スキルレベルによって大きく異なります。新人・ジュニアクラスで月額80万円以下、一般的なエンジニアで80〜140万円、上級・アーキテクトクラスで140〜250万円が目安となります。
「見積もりが高いからといって人月単価の低い会社を選ぶ」という判断には落とし穴があります。人月単価が低いということは、経験値の低いエンジニアが多く、習熟に時間がかかる分、全体の工数（人月数）が増加するリスクがあります。仮に単価50万円のエンジニアが10人月かかる場合と、単価120万円のエンジニアが4人月で終わる場合、後者の方が総額は同等か安くなることすらあります。重要なのは単価ではなく、「単価×人月数=総額」で比較することです。
また、コンサルタント・PMクラスになると月額200〜350万円を超えることもあります。レガシーシステムのリプレイスでは、上流工程（要件定義・設計）の質がプロジェクト成否を大きく左右するため、上流工程に経験豊富なエンジニアを配置することへの費用は、むしろ積極的に確保すべき投資です。
費用の見積もり手法を理解する
ベンダーから提示される見積もりを正しく評価するには、見積もりがどのような手法で算出されているかを理解しておく必要があります。見積もり手法によって精度・信頼性が大きく異なるため、発注側もある程度の知識を持って臨むことが重要です。
5つの見積もり手法（類推法・係数法・FP法・ボトムアップ法・三点見積もり法）
システム開発の見積もりには、主に5つの手法が使われています。第一に「類推法」は、過去の類似プロジェクトの実績をベースに費用を類推する方法です。初期段階のラフ見積もりによく使われますが、精度は低く、±50%程度の誤差が生じることもあります。第二に「係数法（COCOMO法など）」は、コードの規模やシステムの複雑性に係数をかけて算出する手法で、比較的早く見積もりを出せます。
第三に「FP法（ファンクションポイント法）」は、システムが持つ機能の数と複雑さをポイントに換算して見積もる手法です。要件定義が進んだ段階で精度の高い見積もりが出せるため、大規模プロジェクトでよく使われます。第四に「ボトムアップ法」は、タスクを詳細に分解して積み上げる方法で、最も精度が高い反面、見積もり作成に時間がかかります。第五に「三点見積もり法」は、楽観値・最頻値・悲観値の3点から期待値を算出する手法で、不確実性の高いプロジェクトに有効です。
発注初期段階でベンダーが提示する「超概算見積もり」は類推法や係数法ベースのことが多く、要件が固まっていない状態での数字である点を理解しておく必要があります。詳細設計が完了した時点の「確定見積もり」と比べると、数倍の差が生じることも珍しくありません。
見積もりは「構造的に変動する」——超概算・概算・確定の違い
「最初の見積もりから大幅に金額が上がった」という話はシステムリプレイスプロジェクトで頻繁に聞かれますが、これは必ずしもベンダーの不誠実さを意味しません。見積もりの変動は「構造的に起こりうる」ものであり、発注側がこの特性を正しく理解しておくことが重要です。
見積もりは大きく3段階に分けて考えるとよいでしょう。まず「超概算」は、要件が固まっていない検討初期段階のもので、誤差±50%以上は当然です。次に「概算（中間見積もり）」は、要件定義が完了した段階のもので、誤差±20〜30%程度が目安です。最後に「確定見積もり」は、基本設計まで完了した段階で算出するもので、誤差は±10%以内を目指します。
プロジェクトが進むにつれて要件が明確になり、当初は想定されなかった非機能要件（パフォーマンス・セキュリティ・可用性）の実装コストや、既存システムとの連携における複雑性が判明することで見積もりが変動します。これは「契約後に吹っかけられた」のではなく、前提条件が変化した結果です。発注側は、プロジェクトのどの段階の見積もりを比較しているのかを常に意識したうえで、ベンダーとの価格交渉に臨む必要があります。
コストが膨らむ5つの要因と対策
レガシーシステムのリプレイスプロジェクトで予算超過が起きる原因は、多くの場合、プロジェクト開始前から内在しています。以下に挙げる5つの要因は、実際のプロジェクト現場で繰り返し確認されているものです。事前に把握しておくことで、コスト膨張のリスクを大幅に低減できます。
カスタマイズの代償——製造業D社「70%カスタマイズで費用2.5倍」の実例
パッケージソフトやERP製品を導入する際、最もコストが膨張しやすいのがカスタマイズです。ある製造業D社の事例は、この問題を端的に示しています。D社は標準パッケージを導入する際、自社の業務フローに合わせて70%に相当する機能をカスタマイズしました。結果として、費用は当初予算の2.5倍に膨張しました。ただし、この投資によって自社業務への完全適合が実現し、生産性は30%向上しています。
問題の本質は「カスタマイズすること自体が悪い」のではなく、「カスタマイズのコストと効果を事前に正確に見積もれていなかった」点にあります。パッケージ製品を選定する際は、「標準機能のままで業務を変える（Fit to Standard）」か「業務に合わせてカスタマイズする」かのトレードオフを明確にし、カスタマイズ率が30%を超えてくる場合は費用が倍以上になる可能性を前提として予算計画を立てることが重要です。カスタマイズが多いほど、将来のバージョンアップ対応コストも増大するという点も見落とせません。
データ移行の隠れコスト——商社E社「クレンジングだけで4ヶ月」の教訓
見積もりの段階で最も見落とされやすいのが、データ移行・データクレンジングにかかるコストです。従業員200名規模の商社E社では、20年分の顧客データが3つの異なるシステムに分散して管理されていました。リプレイスに際してデータを統合しようとしたところ、名寄せ・表記正規化・重複排除・欠損値補完といったデータクレンジング作業だけで4ヶ月を要しました。
この4ヶ月は直接的なシステム開発コストには計上されていなかった「隠れコスト」です。人員のアサインコストと機会損失を合算すると、数百万円規模の追加コストになり得ます。データ移行の工数は、データの品質・量・システム間の形式差異によって指数関数的に増加します。特に以下のケースでは、移行工数が大幅に増える傾向があります。複数システムにデータが分散している場合、長年にわたって入力ルールが守られていない場合、表記が統一されていない（「株式会社」と「（株）」が混在する等）場合、そして外字・特殊文字が含まれる場合です。プロジェクト計画の段階でデータの品質調査を実施し、クレンジングコストを別途見積もりとして計上することを強くお勧めします。
非機能要件の後出しによるコスト増
非機能要件（性能・セキュリティ・可用性・拡張性）の定義が曖昧なまま開発が進み、後工程で追加要件として発覚するケースは頻繁に起きます。例えば、「月次バッチ処理は3時間以内に完了すること」「同時接続ユーザー数500名に対応すること」「システム停止時間は年間4時間以内にすること」といった要件が要件定義の段階で明示されていないと、開発完了後に「実は夜間バッチが12時間かかっている」という問題が発覚し、大幅な追加改修コストが発生します。
非機能要件はシステムの「機能」ではないため、業務担当者は見落としがちです。しかし、インフラ構成・アーキテクチャ選定・セキュリティ対策の方針はすべて非機能要件に基づいて決定されるため、これが後から変わると設計レベルからの手戻りが発生します。要件定義の段階でIPA（情報処理推進機構）が公開する「非機能要求グレード」などのフレームワークを活用し、網羅的に非機能要件を定義しておくことが、コスト膨張防止の重要な対策です。
ベンダーの追加費用請求への対処法
プロジェクト進行中に「これは仕様外の対応になりますので追加費用が発生します」とベンダーから告げられるケースは少なくありません。追加費用請求への対処は、発注側が最も苦労する局面のひとつです。まず重要なのが、「何が契約スコープに含まれているか」を契約書・仕様書・議事録で確認することです。曖昧な記述があれば、それは双方の解釈の余地があり、交渉の余地があります。
対処法として有効なのは、「なぜ仕様外なのか」の根拠を書面で示してもらうことです。口頭での「仕様外です」という主張だけでは不十分で、当初の要件定義書や基本設計書のどの記述に基づいてスコープ外と判断したのかを明示させることで、交渉の基盤が整います。また、追加費用を認める場合でも、変更管理プロセス（Change Request：CR）として正式に起票・承認のフローを経ることを求めてください。口頭や非公式のやりとりで追加対応を進めると、後から費用が積み上がっても承認の記録がないという事態になりかねません。
レガシーシステムの維持コストという「もうひとつの費用」
リプレイス費用の議論では、新システムの導入コストばかりに目が行きがちですが、「リプレイスしない場合のコスト」も正しく計上する必要があります。経済産業省のDXレポートが指摘するように、多くの企業でIT予算の8割がシステムの維持管理費に費やされています。レガシーシステムは、老朽化するほど維持コストが増大する構造を持っているためです。
具体的には、COBOL・AS/400等の旧技術に対応できるエンジニアの確保コストが年々上昇しています。市場に人材が少なく、夜間・休日対応の体制を維持するためのコストは高騰の一途を辿っています。さらに、オンプレミス環境ではサーバーの物理的な老朽化に伴うハードウェア交換費用、空調・電力・ラック賃料といった固定コストも継続的に発生します。セキュリティパッチの適用やOSサポート延長契約のために年間数百万円が必要になるケースも珍しくありません。「現状維持のコスト」を5〜10年スパンで積算した数字と、リプレイス投資額を比較した場合、多くのケースで刷新の方が総コストを抑えられます。
ROI（投資対効果）の算出方法
レガシーシステムリプレイスの投資判断には、定性的な効果（業務の利便性向上・リスク低減）だけでなく、ROI（投資利益率）の定量的な算出が不可欠です。特に経営層への稟議や取締役会での承認を得るためには、「何年で投資を回収できるか」を数字で示せるかどうかが、プロジェクト承認の分水嶺となります。
人件費削減は「基本給の2倍」で計算する
業務効率化によって削減できる人件費をROIに算入する際、多くの企業が犯しがちなミスが「基本給だけで計算する」ことです。実際の人件費コストには、基本給に加えて社会保険料（健康保険・厚生年金・雇用保険・労災保険）、通勤交通費、福利厚生費、賞与・退職金引当、オフィスコスト（一人当たりの光熱費・スペース賃料）が含まれます。これらを合算すると、一般的に「基本給の約2倍」が実際の雇用コストになります。
具体的な計算例を示します。月次決算作業に3名が各2日（合計6人日）かかっていたとします。リプレイス後に1日（1人日）に短縮できた場合、年間削減工数は(6-1)人日×12ヶ月=60人日です。1人日コストを月給40万円のスタッフ（実コスト80万円/月、1日あたり約3.5万円）で計算すると、年間削減額は60人日×3.5万円=210万円となります。この計算をシステムの耐用年数5年で積算すると、1,050万円の人件費削減効果を示せることになります。この「基本給の2倍」という計算ロジックは、経理部門や経営層からの信頼を得やすい合理的な根拠として機能します。
経営層を説得するROI説明の型
ROIを経営層に説明する際の基本的な型は「投資額・年間削減効果・回収期間」の3点セットです。ROIの計算式は「（年間削減効果 − 年間維持費） ÷ 初期投資額 × 100%」で表されます。例えば、初期投資3,000万円・年間維持費300万円・年間削減効果（人件費+運用コスト削減）800万円の場合、純年間効果は500万円で回収期間は6年（3,000万円÷500万円）となります。
経営層への説明では、定量効果だけでなく「リプレイスしない場合のリスクコスト」も合わせて提示することが説得力を高めます。レガシーシステムが障害を起こした際の業務停止コスト（1時間あたりの売上損失×復旧時間）や、セキュリティインシデントが発生した場合の対応コスト・信用損失、そして老朽システムを維持するためのエンジニア人件費の上昇トレンドを数字で示すことで、「今すぐリプレイスしなければ損をする」という論理的な説明が組み立てられます。なお、従業員100名規模の製造業A社では、リプレイス後に月次決算作業が3週間から1週間に短縮された事例があります。これを人件費換算すると年間数百万円規模の削減効果であり、稟議資料の根拠として十分な数値です。
財務・会計処理のポイント
システムリプレイスの費用をどのように会計処理するかは、稟議の通りやすさや税務上の取り扱いに直結します。多くのIT担当者が苦手意識を持つ領域ですが、経理部門と連携するうえで基本的な知識を持っておくことが重要です。競合記事では触れられていない、現場で実際に問われるポイントを解説します。
ソフトウェア資産計上と減価償却（耐用年数5年）
自社利用目的でシステムを開発・購入した場合、そのコストはソフトウェアとして無形固定資産に計上されます（国税庁基準）。法定耐用年数は5年で、定額法による減価償却が適用されます。例えば3,000万円のシステム開発費を資産計上した場合、毎年600万円（3,000万円÷5年）が減価償却費として損益計算書に計上されます。
ただし、すべてのシステム開発費用が資産計上の対象になるわけではありません。研究開発的な要素が強い費用（市場調査・プロトタイプ開発）や、既存システムの機能追加ではなく単なる維持・保守の費用は、費用として損益計算書に計上されます。データ移行費用や従業員向け教育訓練費も、一般的には費用処理（損金算入）となります。この「資産か費用か」の判断は、プロジェクト開始前に経理部門・税理士と方針を確認しておくことが重要です。資産計上すれば初年度の費用負担を分散できますが、毎年の減価償却費計上が必要になります。
SaaS移行によるCAPEX→OPEX化の財務諸表への影響
オンプレミスのレガシーシステムをクラウドSaaSに移行すると、コスト構造が根本的に変化します。オンプレミスのシステム開発費はCAPEX（設備投資）として資産計上され、減価償却費として複数年にわたって費用化されます。一方、SaaSの月額・年額利用料はOPEX（運営費）として毎年の費用として計上されます。
このCAPEX→OPEX化は財務諸表に次のような影響をもたらします。貸借対照表（B/S）上の固定資産が減少し、資産効率が改善します。損益計算書（P/L）では、大きな初期投資の代わりに毎年の定額費用（SaaS利用料）が計上されます。これは初期の資金流出を抑え、キャッシュフローを安定させる効果があります。ただし、SaaS移行後はシステムが「資産」でなく「費用」として扱われるため、M&Aや事業売却の際にシステムが自社資産として計上されなくなる点は留意が必要です。
稟議の際には「SaaS移行により年間XXX万円の投資が不要になる」という観点だけでなく、「財務諸表上の固定資産が減少し、自己資本比率が改善する」という財務効果も加えることで、CFO・財務部門からの承認を得やすくなります。
見積もりを取る際のポイント
適切な見積もりを取得するためには、発注側の準備が欠かせません。ベンダーに精度の高い見積もりを提示してもらうには、発注側から正確な情報を提供することが前提となります。
要件明確化と仕様書の準備
見積もりの精度を高めるために最も効果的なのが、発注前の要件明確化です。現行システムの機能一覧・業務フロー・画面一覧・帳票一覧を整理し、「新システムでどの機能を引き継ぐか」「廃止する機能はどれか」「新たに追加する機能は何か」を整理したRFP（提案依頼書）を作成することで、ベンダーが正確な見積もりを出せる環境が整います。
RFPに必ず記載すべき項目は、プロジェクトの背景と目的、現行システムの概要（規模・機能・データ量）、新システムへの要件（機能要件・非機能要件）、スケジュールと予算の概算、評価基準と選定プロセス、そして提案形式（費用内訳の明示・工程別内訳の要求）の6点です。特に「費用内訳を工程別に明示すること」を要件として明記することで、後から比較しにくい一括提示を防ぐことができます。
複数社比較と発注先の選び方
見積もりは最低でも3社から取得することが基本です。金額の差が大きい場合（例えばA社500万円、B社1,500万円、C社1,200万円）は、「安い方が得」という単純な判断ではなく、なぜ差が生じているのかを確認することが重要です。スコープの定義が異なる（A社は教育・データ移行費を含んでいない等）、人月単価と工数の前提が異なる、あるいは品質・サポート体制に差がある、といった理由を確認することで、真に有利な発注先が判明します。
レガシーシステムのリプレイスでは、同業種・同規模の支援実績があるベンダーを優先することをお勧めします。業界特有の業務フロー・データ構造・規制対応（製造業であれば品質管理規格、金融業であれば金融庁規制等）への理解度が、プロジェクトの円滑な進行に直結するためです。提案書に具体的な事例（できれば匿名でも業種・規模・課題・効果が記載されたもの）が含まれているかどうかが、実績確認の際の重要なチェックポイントです。
注意すべきリスクと予算確保の考え方
ガートナーの調査によれば、ERP導入プロジェクトの75%が何らかの失敗を経験しているとされています。予算超過・スケジュール遅延・品質問題のリスクを想定したコンティンジェンシー（予備費）を、当初予算の15〜20%程度確保しておくことが現実的なリスク管理です。「予算通りに終わるに決まっている」という楽観的な前提でプロジェクトを始めると、問題が顕在化した際に追加予算の承認に時間がかかり、プロジェクトが停滞する要因になります。
また、リプレイス後の「安定稼働フェーズ（Go-Live後3〜6ヶ月）」にもコストが発生します。本番稼働直後は想定外の不具合対応・ユーザーからの問い合わせ対応・運用手順の微調整が集中するため、ベンダーによる手厚いサポート体制の確保とその費用を契約に含めておくことが重要です。このポストGo-Liveサポートの費用を見積もりから省略するベンダーも多いため、契約交渉の際に必ず確認してください。
まとめ
本記事では、レガシーシステムリプレイスの費用に関わる全体像を解説しました。要点を整理します。費用相場は企業規模によって100万〜1億円超と幅広く、工程別では開発・実装フェーズが50〜60%を占めます。エンジニア人月単価は新人〜80万円・一般80〜140万円・上級140〜250万円が目安です。
コスト膨張の主な要因は、カスタマイズの過多（製造業D社の事例：70%カスタマイズで2.5倍に膨張）・データ移行の隠れコスト（商社E社：クレンジングだけで4ヶ月）・非機能要件の後出し・追加費用請求への対処不足、そして現行レガシーシステムの維持コストという5点です。ROI算出では人件費削減額を「基本給の2倍」で計算することが合理的であり、SaaS移行によるCAPEX→OPEX化は財務諸表改善の観点でも経営層への説明力を持ちます。
「費用が高そうだからリプレイスを先送りする」という判断は、IT予算の8割をレガシー維持に費やし続けるコストを積み上げていくことを意味します。今の時点で正確な費用の全体像を把握し、ROIと維持コストを比較したうえで意思決定することが、長期的に見て最も合理的な選択です。riplaでは、レガシーシステムリプレイスのコンサルティングから開発まで、費用の透明化・ROI試算・ベンダー選定支援を含めて一気通貫でサポートしています。まずはお気軽にご相談ください。
▼全体ガイドの記事
・レガシーシステムリプレイスの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。