「古いシステムを使い続けているが、いつ止まるか不安で仕方ない」「ベンダーに依存しすぎていて、何を変えようにも言い値になってしまう」——レガシーシステムを抱える企業の担当者が口にする悩みは、今や特定の業界や規模を問わず広がっています。経済産業省が警告した「2025年の崖」は既に現実となりつつあり、古い基幹システムを放置するリスクはかつてないほど高まっています。

このページでは、レガシーシステム更改の全体像から進め方・費用・開発会社の選び方・発注方法まで、一枚の地図として俯瞰できるよう整理しました。各テーマの詳細は専門の子記事で詳しく解説していますので、気になるトピックは下記のリンクからご確認ください。更改プロジェクトをこれから立ち上げる方も、すでに動き始めている方も、判断の拠り所となる情報をまとめています。

関連記事一覧

・レガシーシステム更改の進め方｜現状分析からリリースまでの全工程を解説
・レガシーシステム更改におすすめの開発会社比較
・レガシーシステム更改の費用相場｜規模別の目安と内訳
・レガシーシステム更改の発注・外注方法｜RFP作成から契約まで

レガシーシステム更改の全体像

レガシーシステムを更改するプロジェクトは、単なるシステム移行ではありません。組織の業務プロセス・データ・人材・ベンダー関係といった複合的な課題を同時に解決しなければならない、経営課題そのものです。まずは「レガシーシステムとは何か」「なぜ今更改が急務なのか」「関連用語の違い」を整理することで、プロジェクト全体の見通しを立てやすくなります。

レガシーシステムとは、一般的に「技術的に陳腐化したにもかかわらず業務上の代替が困難なシステム」を指します。単に古いだけでなく、内部構造がブラックボックス化していたり、保守できる技術者が社内外に存在しなくなっていたりすることが問題の本質です。メインフレームやCOBOL、独自フレームワークで構築されたシステムが典型例ですが、2000年代以降に構築されたシステムでも、ドキュメントが整備されずベンダー依存度が高ければ「実質的なレガシー」と見なされます。

経済産業省が2018年に発表した「DXレポート」では、2025年までに既存システムの刷新を進めなければ、2025年以降に年間最大12兆円の経済損失が生じる可能性があると指摘しました。これが「2025年の崖」と呼ばれる問題です。2025年時点でこの崖を完全に乗り越えた企業は多くなく、今まさに更改プロジェクトに着手している企業、あるいは着手を検討している企業が大多数を占めています。放置すれば、システム障害によるサービス停止・セキュリティリスクの拡大・保守費用の高騰という三重苦が待っています。

「レガシーシステム更改」に関連する用語は多く、プロジェクト関係者の間で認識がずれることが少なくありません。「更改」とは既存システムを新しいシステムに置き換えること全般を指し、再構築・移行・刷新などを包括した広い概念です。「マイグレーション」は、データやアプリケーションを別の環境（例：オンプレミスからクラウド）に移行する作業を指します。「モダナイゼーション」は、アーキテクチャやコード構造を現代的な設計に変換することで、リプラットフォームやリファクタリング、リライトなど複数の手法が含まれます。

Gartnerが提唱する「6つのR」（Retain・Retire・Rehost・Replatform・Refactor・Replace）はモダナイゼーション戦略の整理に広く使われており、自社のシステム特性に応じてどのアプローチを選ぶかがプロジェクト計画の出発点となります。「全部作り直す」という選択肢が最適でないケースも多く、既存資産を部分的に活かしながら段階的に移行するアプローチが主流になっています。

▶ 詳細はこちら：レガシーシステム更改の進め方｜現状分析からリリースまでの全工程を解説

レガシーシステム更改の進め方

レガシーシステム更改は「現状把握なき計画は失敗する」と言われるほど、初期フェーズの質がプロジェクト全体の成否を左右します。長年にわたる改修の積み重ねでコードとドキュメントが乖離し、「誰も全体像を把握していない」という状態が珍しくありません。そのため、進め方は現状分析から始まり、移行計画・開発・テスト・リリース後の運用安定化まで、複数のフェーズに分けて着実に進めることが求められます。

企画フェーズで最初に行うべきことは、現行システムの「棚卸し」です。どの業務がどのシステムに依存しているかを一覧化し、データフロー・インターフェース・バッチ処理・帳票出力などの全体像を可視化します。特にブラックボックス化が進んでいる場合、静的解析ツールやリバースエンジニアリング手法を使ってコード構造を把握することが求められます。この作業を怠ると、後工程で「こんな機能があったのか」という発見が続き、スケジュールと予算が大幅に膨らみます。

現状分析が完了したら、更改の優先順位と段階的移行計画を策定します。全機能を一度に移行する「ビッグバン移行」はリスクが非常に高く、多くのプロジェクトで失敗の原因となってきました。代わりに、業務領域ごとに段階的に移行する「ストラングラーパターン」や、新旧システムを並行稼働させながら切り替える「ブルーグリーン方式」が採用されるケースが増えています。投資対効果（ROI）の算定もこのフェーズで行い、経営層の承認を得ることが重要です。

開発フェーズでは、現状分析で得た業務要件をもとに新システムの設計・実装を進めます。レガシー更改特有の難所は「仕様書がない業務ロジックをどう移植するか」です。コードリーディングと業務担当者へのヒアリングを組み合わせ、暗黙知を文書化しながら実装するプロセスが不可欠です。特にデータ移行については、旧システムのデータ品質が低いケースが多く、名寄せ・クレンジング・変換ルールの策定に想定外の工数がかかることを見込んでおく必要があります。

テストフェーズでは、単体テスト・結合テストに加え、旧システムとの「突き合わせテスト」が重要です。同じ入力に対して新旧システムが同じ出力を返すかどうかを検証することで、移行漏れや仕様差異を早期に発見できます。リリース時は、切り戻し手順を事前に確立した上で本番移行を行うことが鉄則です。リリース後の運用安定化期間（通常1〜3か月）には、想定外の不具合対応や業務担当者のオペレーション習熟支援が続くため、ベンダーとの保守体制を事前に合意しておくことが求められます。

▶ 詳細はこちら：レガシーシステム更改の進め方｜現状分析からリリースまでの全工程を解説

開発会社の選び方

レガシーシステム更改の成否は、開発会社（ベンダー）の選定に大きく依存します。更改プロジェクトは通常の新規開発よりも難易度が高く、旧技術への理解・移行設計力・プロジェクト管理力の三拍子が揃ったパートナーを選ぶことが不可欠です。また、更改後もベンダーへの依存が深まる「新たなベンダーロックイン」を防ぐ体制を最初から設計することが、長期的なシステム健全性を守ることにつながります。

開発会社を選ぶ際に最初に確認すべきは、レガシーシステム更改の具体的な実績です。「DX支援」「モダナイゼーション」という言葉を掲げている会社は多いですが、実際に旧COBOLシステムやメインフレームからの移行を手がけた経験があるか、段階的移行を成功させた実績があるかを具体的な事例で確認することが重要です。特に自社と同規模・同業種での実績があれば、類似課題への対処ノウハウが期待できます。

技術力の面では、旧技術（COBOL・VB6・Access・Oracle Forms など）の読解力と、新技術（クラウドネイティブ・マイクロサービス・API設計）の両方に精通しているかを確認します。さらに、データ移行・静的解析・リファクタリングの専門知識を持つエンジニアがプロジェクトにアサインされるかどうかも、提案段階で確認することをおすすめします。「何でもできます」という回答ではなく、具体的なツールや手法を提示できるベンダーが信頼に値します。

レガシーシステム更改の大きな落とし穴の一つが、更改後に「新たなベンダーロックイン」に陥ることです。旧ベンダーへの依存を断ち切ったはずが、新ベンダーに同様に依存してしまうケースは珍しくありません。これを防ぐには、契約段階からソースコードの著作権と納品物の所有権を発注者側に帰属させること、ドキュメントの整備義務をSLAに明記すること、そして特定の独自フレームワークへの過度な依存を避けた設計を求めることが効果的です。

また、開発会社を評価する際は「この会社が撤退したときに困らないか」という観点で判断することをおすすめします。設計書・API仕様書・テスト仕様書などのドキュメント類が成果物として納品されるか、別ベンダーが引き継ぎやすいアーキテクチャを採用しているかを、提案書の段階で確認することが重要です。優れたベンダーは、こうした質問に対して明確かつ前向きな回答を提示できます。

▶ 詳細はこちら：レガシーシステム更改におすすめの開発会社比較

費用相場

レガシーシステム更改の費用は、通常の新規開発よりも見積もりが難しく、プロジェクトが進むにつれて追加費用が発生しやすい傾向があります。その主な理由は、旧システムのブラックボックス化により、着手するまで作業量の全貌が把握できないからです。予算計画を立てる際は、「判明していないリスク」を含むバッファをあらかじめ確保しておくことが現実的です。

レガシーシステム更改には、通常のシステム開発費用に加えて「レガシー特有のコスト」が発生します。代表的なものは、旧システムのコード解析・仕様書の逆生成（リバースエンジニアリング）・データクレンジングの3つです。特に長年稼働してきたシステムでは、数十年分のデータに重複・欠損・フォーマット不整合が蓄積しており、新システムへのデータ移行前に多大な浄化作業が必要となるケースがあります。

また、旧システムを稼働させながら並行開発を進める場合、旧システムの保守費用と新システムの開発費用が同時にかかる「二重投資」の期間が生じます。移行プロジェクトの期間が長引くほどこの二重コストは膨らむため、移行期間の短縮もコスト管理の重要な視点です。さらに、現場ユーザーへのトレーニング費用・変更管理コスト・外部コンサルタント費用も見落とされやすい費用項目として注意が必要です。

費用の目安は対象システムの規模・複雑度・移行方式によって大きく異なりますが、一般的な参考値として以下のような水準が示されることが多いです。中小規模システム（ユーザー数50〜200名程度）の場合、1,000万〜5,000万円程度。中規模システム（ユーザー数200〜1,000名、複数業務領域）の場合、5,000万〜2億円程度。大規模基幹システム（グループ全社・複数拠点にわたる）の場合、2億円〜10億円以上になることもあります。

これらはあくまで概算の目安であり、実際の見積もりは現状調査（フィジビリティスタディ）を経て算出されます。「安すぎる見積もり」には、現状分析が不十分なまま固定費を提示しているリスクが隠れていることが多いため、見積もりの前提条件と想定外リスクの扱いを必ず確認することが重要です。また、ベンダーに現状調査フェーズだけを依頼し、その結果をもとに本工程の見積もりを取り直すアプローチも有効です。

▶ 詳細はこちら：レガシーシステム更改の費用相場｜規模別の目安と内訳

発注・外注方法

レガシーシステム更改を外部に委託する際は、「何を委託するか」を明確にした上で発注先を選ぶことが重要です。コンサルティング（企画・調査・設計）と開発（実装・移行・テスト）を同一ベンダーに委託するケースと、それぞれ別の会社に分離発注するケースがあり、自社のIT部門の体制や予算規模に応じて判断します。いずれの場合も、発注前の準備が不十分だと、ベンダーとの認識齟齬が後に大きなトラブルとなります。

発注前に最低限整備すべきドキュメントは、業務フロー図・データ一覧・システム間連携図・現行の課題リストの4点です。これらが揃っていると、ベンダーが現状を正確に理解した上で提案・見積もりを行えるため、見積もり精度が大幅に向上します。逆に「ドキュメントが何もない」という状態でベンダーに相談すると、現状調査から別途費用が発生し、適正な見積もりが出るまでに数ヶ月を要するケースもあります。

「ドキュメントを作るノウハウがない」という場合は、まずITコンサルタントや専門家に現状整理を依頼することも選択肢の一つです。特に中小企業では、社内にIT専門人材がいないケースが多く、外部の支援を受けながら発注準備を進めることが合理的です。この準備段階への投資は、後工程での手戻りを防ぐという意味で非常に費用対効果が高いと言えます。

RFP（提案依頼書）は、複数のベンダーから比較可能な提案を引き出すための重要な文書です。レガシーシステム更改のRFPに盛り込むべき主な内容は、現行システムの概要・更改の目的と範囲・求める機能要件と非機能要件・スケジュールの制約・予算の上限・評価基準の明示です。特に「評価基準を明示する」ことは、ベンダーが何を重視して提案すればよいかを理解するために欠かせません。