「保守契約が切れているのに誰も手を付けられない」「担当者が退職したらシステムの仕様が誰にもわからなくなった」「毎年保守費用が上がるのに業務の効率は一向に改善しない」――こうした悩みを抱えながら、古いシステムを使い続けている企業は少なくありません。経済産業省は2018年に「DXレポート」を公表し、レガシーシステムの放置が2025年から2030年にかけて年間最大12兆円の経済損失をもたらすと警鐘を鳴らしました。この「2025年の崖」という言葉が示すように、老朽化したシステムを抱えたまま現代のデジタル競争を戦うことは、もはや困難な時代に突入しています。

本記事では、レガシーシステムのリプレイスを検討している情報システム担当者・DX推進責任者・経営層の方に向けて、進め方の全体像から具体的な7ステップ、移行方式の選び方、失敗しないためのポイント、そして実際の事例まで体系的に解説します。「何から手をつけるべきかわからない」という段階の方でも、この記事を読めば自社のリプレイスプロジェクトを主体的に動かせる知識が身につきます。

▼全体ガイドの記事
・レガシーシステムリプレイスの完全ガイド

レガシーシステムリプレイスの全体像

レガシーシステムとは、古い技術・アーキテクチャで構築され、現代のビジネス要件や技術トレンドに対応しにくくなったシステムの総称です。メインフレームや独自言語で書かれた基幹システム、導入から20年以上が経過した業務パッケージなどが代表例として挙げられます。「リプレイス」とは、そうしたシステムを新しいシステムやパッケージに置き換えることを指し、既存システムを別のサーバー環境に移す「マイグレーション（リホスト）」とは区別されます。リプレイスでは業務プロセスの見直しも伴うことが多く、単なるシステム移行よりも大きなインパクトをビジネスにもたらします。

レガシーシステムのリプレイスには、大きく分けて「守りの投資」と「攻めの投資」という2つの目的があります。守りの投資とは、老朽化によるリスクを取り除くための対応です。具体例としては、サポート終了したOSやミドルウェアのセキュリティリスクへの対処、保守費用の増大抑制、属人化・ブラックボックス化の解消などが挙げられます。一方、攻めの投資とは、新システムの導入をきっかけにDXを推進し、競争優位を獲得することを目指すものです。クラウド活用によるスケーラビリティの確保、AIや分析ツールとのデータ連携、業務プロセスの抜本的な効率化などがその代表です。プロジェクトの目的をこの2軸でどのバランスで設定するかによって、スコープ・予算・期間の方向性が大きく変わります。

自社のシステムがリプレイスのタイミングを迎えているかどうかは、以下の5つのサインで判断できます。①ベンダーやOSのサポートが終了している、または間近に迫っている。②システムの仕様書がなく、改修・変更を加えられる担当者が社内に1〜2名しかいない（属人化）。③保守・運用費用が年々増加しており、新機能の追加が非常に困難になっている。④業務の変化に対してシステムが追いつかず、ExcelやAccessでの「つなぎ運用」が常態化している。⑤セキュリティの脆弱性が放置されており、コンプライアンスリスクが顕在化している。こうしたサインが1つでも当てはまる場合、リプレイスの検討を先送りにするコストは毎年確実に積み上がっています。特に「担当者が退職したら誰も触れない」というブラックボックス化の状態は、企業にとって最も危険なリスクのひとつです。

レガシーシステムリプレイスの進め方 7ステップ

レガシーシステムのリプレイスは、通常1〜3年にわたる長期プロジェクトです。大きな失敗の多くは「いきなり要件定義に入ってしまった」「ゴールの定義が曖昧なままベンダーを決めた」という上流工程の手抜きから生まれます。以下の7ステップを順守することで、プロジェクトの成功確率を大幅に高めることができます。

リプレイスプロジェクトの出発点は「現行システムの棚卸し」です。現在動いているシステムが何を処理しているのか、どのシステムと連携しているのか、誰が保守しているのかを文書化します。レガシーシステムの場合、この棚卸し作業自体が非常に難しいことがあります。「仕様書がない」「開発会社がすでに存在しない」「担当者しか知らないロジックがある」という状況は珍しくありません。この段階での重要なアウトプットは、①システムマップ（全体の構成図・連携図）、②業務フローとシステムの対応表、③技術的負債のリスト（サポート切れOS、属人化している処理、ドキュメントのない仕様）の3点です。特にレガシーシステムでは、この棚卸しに2〜3ヶ月かかることも珍しくありません。一人情シスや兼任担当者しかいない中小企業では、この作業を外部コンサルタントに依頼することも現実的な選択肢のひとつです。

現状分析を踏まえ、「このリプレイスで何を達成するのか」を明文化します。ここでの注意点は、ゴールを「システムを新しくすること」ではなく「業務成果」で定義することです。「月次決算を現在の3週間から1週間に短縮する」「保守費用を年間500万円削減する」「担当者不在でも保守が継続できる体制を整える」といった具体的な指標を設定してください。ROI（投資対効果）の算出も、この段階で行っておくと経営層への稟議がスムーズになります。ROI計算で人件費削減効果を試算する際は、表面上の給与だけでなく、社会保険料などの管理コストを含めた「基本給の約2倍」を人的コストとして計算するのが現場での実態に即した方法です。たとえば月給40万円のスタッフが毎月20時間の手作業から解放される場合、月40万円×2倍÷160時間×20時間＝10万円/月の削減効果として計上できます。

ゴールと現状分析が揃ったら、RFP（提案依頼書）を作成してベンダーへの提案を依頼します。RFPには「プロジェクトの背景と目的」「現行システムの構成」「実現したい機能・非機能要件」「スケジュール」「予算感」「評価基準」を盛り込みます。レガシーシステムのリプレイスでは、特に「現行機能の現状踏襲をどこまで求めるか」を明確にすることが重要です。「現行と同じことができればよい」という指示だけでは、ベンダーが機能を過剰に盛り込んで見積もりが膨らむ原因になります。複数のベンダーから提案を受ける際は、3〜5社程度に絞り込んだ上で同一条件で比較できるよう、評価シートを事前に準備しておくと判断が容易になります。

ベンダーを選定したら、いよいよ要件定義フェーズに入ります。レガシーシステムのリプレイスで最も陥りやすい罠が「現行踏襲」です。「今やっていることを全部新システムでもできるようにしてほしい」という要求は、一見合理的に聞こえます。しかし、現行システムに蓄積された業務ロジックの中には、「誰も理由を知らないが変えると怖いから残している処理」や「本来はExcelで管理すべきだが誰かがシステムに組み込んだ例外処理」が含まれていることが多く、それを全て新システムに移し替えようとするとカスタマイズが膨らみ、コストと工期が大幅に超過します。推奨されるアプローチは「Fit to Standard（業務をシステムの標準機能に合わせる）」の考え方です。パッケージの標準機能で業務を再設計し、カスタマイズはどうしても必要なものだけに絞る。この判断を現場担当者だけに任せると「いや、うちはこの処理がないと困る」という反論が続出するため、プロジェクトオーナー（経営層・CIO）が「カスタマイズの承認ゲート」を設けることが不可欠です。

要件定義が承認されたら、設計・開発フェーズに進みます。この段階でのポイントは、「発注側が受け身にならないこと」です。設計書のレビューに現場キーマンを参加させ、「ベンダーが作ったものを承認するだけ」という体制では、後になって「こんな動きになるとは思わなかった」という認識齟齬が生まれます。また、追加要件や仕様変更が発生した場合は、必ず変更管理台帳に記録し、工数・コスト・スケジュールへの影響をその都度確認することが重要です。「追加費用はかかりません」という口頭合意は後でトラブルになるため、軽微な変更であっても書面・メールで残す習慣をつけてください。開発工程別の費用配分は、一般的に開発・実装が全体の50〜60%を占め、要件定義が10〜15%、設計が10〜25%、テストが5〜10%程度です。

レガシーシステムのリプレイスで最も工数がかかり、かつプロジェクト成否を左右するのが「データ移行」です。長年使われてきたシステムのデータには、表記の揺れ（同一顧客が「山田商事」「山田商事株式会社」「ヤマダ商事」などと複数存在する）、未使用・重複データ、システム間での不整合など、大量の「汚れ」が蓄積しています。移行前のデータクレンジング作業は、商社E社（従業員200名規模）の事例では20年分の顧客データが3システムに分散していた結果、データ統合・クレンジングだけで4ヶ月を要しました。この隠れコストを見落とすと、プロジェクト全体の予算が大幅に圧迫されます。

テストは3段階で行うことが推奨されます。まず「サンプル移行テスト」で代表的なデータパターンを使った動作確認を行います。次に「全件移行テスト」で実データ全量を移行して件数・金額・処理結果を突合します。最後に「移行リハーサル」で本番と同じ手順・同じ時間帯でカットオーバー作業を一通り演習します。会計データの突合では、売掛金・買掛金などの残高について「1円の差異も許容しない」姿勢で検証することが求められます。150円の差異が発生した場合でも、端数処理ミスなのかデータ移行不備なのかを明細レベルで追跡し、1円単位で原因を特定する必要があります。これは将来の監査対応を見据えた現場の実態でもあります。

いよいよ本番カットオーバーです。カットオーバー前に必ず「切り戻し基準」を明文化しておくことが重要です。「カットオーバー後にどのような問題が発生したら旧システムに戻すか」という判断基準を、発注側とベンダー双方で合意しておかなければなりません。ある食品メーカーの事例では、この切り戻し基準の合意がないまま本番稼働に突入した結果、新旧データの在庫数量に不整合が発生し、受発注・出荷・製造が長期停止するという深刻な事態に陥りました。この失敗の本質は、「何があれば切り戻すか」という意思決定プロセスを省略したことにあります。本番稼働後の定着化支援も重要なフェーズです。操作マニュアルの整備と全社員向けのトレーニングを実施し、新システムへの移行後も一定期間はサポート窓口を設けることで、現場の混乱を最小化できます。

移行方式の比較と選び方

レガシーシステムのリプレイスでは、どのように新旧システムを切り替えるかという「移行方式」の選択が、リスクとコストに大きな影響を与えます。主な移行方式は以下の4つです。

「一括移行（ビッグバン）」は、特定の日付に旧システムを停止し、新システムに一気に切り替える方式です。移行期間が短くコストを抑えられる反面、問題発生時の影響が全社に及ぶため、リスクは4方式の中で最大です。十分なテストとリハーサルを経ていないと、前述した食品メーカーのような深刻な事態を招く可能性があります。「段階移行」は、機能モジュールや部門・拠点ごとに順番に新システムへ移行していく方式です。問題が発生しても影響を限定できるため安全性が高く、レガシーシステムのリプレイスで最もよく採用されます。「並行稼働」は、一定期間、新旧システムを同時に稼働させてデータを突合・比較しながら移行する方式です。安全性は最も高いですが、二重運用によるコストと現場の負担が増大します。「パイロット移行」は、特定の部門や拠点を先行して移行し、そこで得た知見を本格展開に活かす方式で、大規模組織のリプレイスで有効です。

移行方式の選択は「リスク許容度」と「コスト」のトレードオフです。24時間365日稼働が求められる製造・物流・金融系のシステムでは、一括移行のリスクは非常に高く、段階移行や並行稼働が原則となります。一方、比較的業務の切れ目が作りやすい年度替わりや期末・期首タイミングがある業種では、一括移行を選ぶケースもあります。中小企業や一人情シス体制の場合は、二重運用の負担が大きい並行稼働よりも、リスクを小さなモジュール単位に分割した段階移行が現実的です。重要なのは、移行方式を「ベンダーに任せる」のではなく、「発注側がリスク感度を持って選択する」ことです。

失敗しないための5つのポイント

ガートナーの調査によると、ITプロジェクトの75%が進行中に何らかの失敗を経験しているとされています。レガシーシステムのリプレイスは特に規模が大きく、失敗の影響も甚大です。以下の5つのポイントを押さえることで、プロジェクトの成功確率を大きく高めることができます。

レガシーシステムのリプレイスにおける最大の障壁のひとつが、現場の「変化への抵抗」です。「新しいシステムには慣れていないから今のままの方がいい」「Excelの方が使いやすい」「自分の仕事が奪われるのでは」という心理的抵抗は、特に長年同じシステムを使い続けてきた組織で顕著に現れます。この抵抗に対して「会社が決めたことだから使え」という強制アプローチは逆効果になりがちです。有効な対策は以下の3点です。まず「なぜリプレイスが必要か」を全員に丁寧に伝える説明会を開催し、現場の不安を受け止める場を設けること。次に、現場の意見をシステムに反映する「現場キーマンをプロジェクトメンバーに巻き込む」体制を作ること。そして、反対派の中でも発言力のある人物を「アーリーアダプター」として取り込み、その人が「実際に使ってみたら便利だった」と発言できる状況を意図的に作ることです。システムの定着化は、カットオーバー後に終わるものではなく、稼働後3〜6ヶ月の継続的なサポートと改善が必要です。

ベンダーを選んだ後、発注側が「後はお任せします」とプロジェクトから離れてしまうことが、多くの失敗プロジェクトに共通するパターンです。週次の定例会議を設け、「今週の進捗」「課題・リスク」「次週のアクション」を必ず議題に入れることで、遅延の早期発見と対処が可能になります。特に注意が必要なのが「仕様外です（追加費用が発生します）」という主張への対応です。レガシーシステムのリプレイスでは、仕様の曖昧さから「これは仕様の範囲内か、追加か」という議論が頻繁に発生します。こうしたトラブルを防ぐためには、要件定義時点での仕様書の精度を高めることと、「仕様外と言われた際の合意プロセス」を契約書やプロジェクト計画書に明記しておくことが有効です。フェーズの移行判断にも明確な基準を設けることを推奨します。たとえばILUO評価フレームワークを活用し、検証担当者が「U（理解・実行可能）」レベルに到達していることをフェーズ移行の条件とすることで、「テスト完了とはいえ現場が使えていない」という問題を未然に防げます。

システム開発の契約形態には「請負契約」と「準委任契約」の2種類があります。請負契約はベンダーが成果物の完成を約束し、要件通りのシステムが納品されなければ契約不適合責任（瑕疵担保責任）が問われます。一方、準委任契約は作業の遂行を約束するものであり、成果物の保証はありません。レガシーシステムのリプレイスのように仕様が複雑で変化しやすいプロジェクトでは、要件定義フェーズを準委任、開発フェーズを請負という「ハイブリッド契約」を採用するケースが増えています。また、発注規模によっては下請法（下請代金支払遅延等防止法）が適用され、代金を受領後60日以内に支払う義務が生じる場合があります。ベンダーへの支払いサイクルを社内の通常フローで設定してしまうと法令違反になるリスクがあるため、契約締結前に確認が必要です。

カットオーバー前に「切り戻し判断基準」を文書化することは、リプレイスプロジェクトにおける必須の安全弁です。切り戻し基準には「どのような障害が発生したら旧システムへ戻すか」「判断はいつ・誰が行うか」「旧システムへの切り戻し手順と所要時間」を明記します。前述の食品メーカーAの事例はまさにこの基準がなかったために発生した事故でした。新旧データの照合観点（件数・金額・計算ロジック・締め処理）の定義が不足したまま本番稼働に踏み切り、受発注・在庫不整合が連鎖して出荷・製造が長期停止するという重大インシデントへと発展しています。会計データの突合においては、「1円の差異も許容しない」姿勢で臨むことが求められます。わずかな差異でも放置すると、数ヶ月後の監査で発覚し、差異の追跡に膨大な工数を要します。差異が発生した際は、端数処理ミスなのかデータ移行不備なのかを明細レベルで特定する習慣を徹底してください。

「最初の見積もりから大幅に費用が増えた」というトラブルはレガシーシステムのリプレイスで頻繁に発生します。しかしこれは必ずしもベンダーの悪意や怠慢ではなく、「構造的な変動」が起きているケースがほとんどです。プロジェクトの初期段階では、要件が固まっておらず、ベンダーは「超概算」で費用を提示するしかありません。要件定義が進むにつれて非機能要件（処理速度・セキュリティ・可用性）や外部連携の詳細が明らかになるたびに、見積もりは「概算」→「確定見積もり」へと精度が上がり、金額も変化します。発注側はこの「見積もり変動の構造」を理解した上で、「確定見積もりはいつ出るか」「どの時点で追加費用が確定するか」をプロジェクト計画書に明記しておくことが重要です。一方、レガシーシステムのリプレイスで特に費用が膨らみやすい要因として「カスタマイズの積み重ね」があります。ある製造業では標準パッケージに70%ものカスタマイズを施した結果、費用が当初予算の2.5倍にまで膨張しました。カスタマイズの承認ゲートを設けることの重要性は、こうした事例からも明らかです。

成功事例・失敗事例から学ぶ

理論や手順よりも、実際のプロジェクトの成功・失敗事例から学ぶことが、最も実践的な知識を得る方法です。以下の事例は、抽象的なリスクをリアルな教訓として理解するための参考になります。

食品メーカーAの事例は、並行稼働設計の不備が引き起こした失敗の典型例です。新旧データの照合観点（件数・金額・計算ロジック・締め処理）の定義が不足したまま、また切り戻し基準が発注側とベンダー間で合意されないままカットオーバーを迎えた結果、受発注・在庫不整合が連鎖し、出荷・製造が長期停止するという事態に陥りました。この事例で特に教訓となるのは、「問題が起きてから基準を決めようとした」という意思決定の遅れです。危機的状況では冷静な判断が難しく、「もう少し待てば直るかもしれない」という期待から旧システムへの切り戻しタイミングを逃してしまいます。別の失敗事例として、建築業B社では大容量データや連携バッチの性能見積もりが甘く、本番稼働後に深刻なレスポンス問題が発生しました。設計段階での机上比較に偏りPoC（概念実証）が不足していたことが原因で、工期延伸と大幅な予算超過を招いています。性能要件は「それほど速くなくて良い」という曖昧な定義のまま開発を進めてはならず、処理件数・応答時間・ピーク時の負荷を数値で定義することが不可欠です。

製造業A社（従業員100名規模）では、レガシーな会計・販売管理システムのリプレイスを段階移行で実施した結果、月次決算の所要日数が3週間から1週間に短縮されました。このプロジェクトが成功した要因は、「月次決算3週間→1週間」という具体的なKPIをプロジェクト開始時に設定し、全ての意思決定をそのゴールに照らして行ったことです。「現行踏襲か標準機能か」という議論が発生するたびに「このカスタマイズは決算短縮に寄与するか」という問いに立ち返ることで、不要なカスタマイズの抑制に成功しました。別の成功事例として、ゼネラルリンクでは複数システムに分散していた情報の手作業集計をリプレイスによって廃止し、月次決算を約3営業日短縮することに成功しています。大企業の事例では、鹿島建設がERPによる文書管理の一元化で年間100万枚以上の紙書類を削減し、現場と本社のリアルタイム情報共有を実現しました。これらの成功事例に共通するのは、「具体的な数値目標の設定」「段階的なアプローチ」「現場の巻き込み」という3点です。

まとめ

レガシーシステムのリプレイスは、属人化・ブラックボックス化・保守費用増大・2025年の崖という4つの固有課題に直面している企業にとって、避けては通れない経営課題です。本記事で解説した進め方を振り返ると、成功の鍵は「現状分析→ゴール設定→RFP作成→要件定義→設計開発→データ移行・テスト→カットオーバー」という7ステップを丁寧に踏むことにあります。特に重要なのは、上流工程（現状分析・ゴール設定）への投資と、切り戻し基準の明文化です。食品メーカーAの失敗事例が示すように、「後で決めれば良い」という先送りがプロジェクトを致命的な危機に追い込みます。

また、チェンジマネジメントに代表される「人」への対応、ベンダーとの契約・コントロールの実務知識、データ移行における「1円の差異も許容しない」検証姿勢など、技術面だけでは解決できない課題が多く存在することも本記事で強調しました。一人情シスや兼任担当者しかいない中小企業であっても、「現状分析→ゴール設定→段階移行」という基本の骨格さえ守れば、大企業と同じ原則で安全なリプレイスを実行できます。リソースが限られている場合は、外部コンサルタントを上流工程の支援に活用し、自社の意思決定の質を高めることが、コスト以上の価値をもたらします。

▼全体ガイドの記事
・レガシーシステムリプレイスの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。