リプレイスとは？システムリプレイスの進め方と失敗しないポイント

リプレイスとは、既存の仕組みを別の仕組みへ置き換えることです。システムでは、古くなった業務システムやWebサービス、スマホアプリを、移行・再構築・段階的な置換などによって更新する取り組みを指します。ただし、使いにくさや技術の古さだけで全面的な置き換えを決めると、移行中の業務負荷やデータ不整合といったリスクを見落としかねません。

この記事では、リプレイスと近い用語の違い、改修と置き換えの判断基準、方式・切替方法、移行の進め方、ベンダー変更時の確認事項を解説します。読後には、自社に合う実装方針と切替方針を整理し、見積依頼に必要な前提をそろえられるようになります。

リプレイスは、置換対象と残す資産を整理したうえで、実装・切替方式、移行計画、引継ぎ条件まで一連で検討します。

01Sectionリプレイスとは？システム移行・リプレースとの違い

ITにおけるリプレイスは、既存システムの全部または一部を新しい仕組みに置き換えることを指す包括的な表現です。「リプレース」と書かれることもありますが、実務では表記を統一すれば足ります。重要なのは、用語ではなく、何を残し、何を移し、何を作り直すのかを関係者間でそろえることです。

ITにおけるリプレイスの意味

リプレイスには、現行機能をおおむね維持して実行環境やデータを移すケースから、業務フローや画面、連携、設計を見直して作り直すケースまで含まれます。したがって、「リプレイスをする」とだけ決めても、必要な作業範囲や移行リスクは判断できません。

近い用語との違い

営業用語としてのリプレイス

営業活動では、他社製品・サービスから自社製品・サービスへ契約や利用を切り替えることを「リプレイス」と呼ぶ場合があります。この用法では契約先の変更に焦点が置かれます。一方、システムリプレイスでは、業務、データ、連携、運用、切替まで対象になり得るため、同じ言葉でも実行範囲は一致しません。

02Section改修ではなくシステムリプレイスを検討する判断基準

リプレイスの要否は、技術が古いかどうかだけでは決まりません。現行システムが業務や事業の変化に対応できるか、継続運用のリスクを許容できるかを確認します。経済産業省のレガシーシステムモダン化委員会総括レポートも、レガシー課題と事業変化への対応を扱っていますが、個別案件に置き換えを求める基準ではありません。自社の影響と制約に照らして評価することが必要です。

リプレイスを優先評価する兆候

次のような状態が複数の領域にまたがる場合は、限定改修だけでなくリプレイスを候補に入れます。

• サポート終了、脆弱性対応、性能限界への対処が継続的に難しい
• 障害や復旧遅延が、顧客対応・受注・月次処理など複数の業務へ波及する
• 変更のたびに影響範囲の特定や広範なテストが必要になり、改善速度が落ちている
• 特定の担当者や現行ベンダーに知識が集中し、運用・保守の継続性に懸念がある
• 新たな業務、データ活用、外部連携を実現できず、事業計画に追随しにくい

限定改修を優先しやすい状態

課題が一部の画面や機能に閉じており、現行の基盤・性能・セキュリティに当面の制約がなく、設計書やテスト資料を利用できる場合は、限定改修が候補になります。その際も、改修後に残る依存関係や、次の変更で必要になる影響調査の負担を確認します。

判断は、次の4観点を同時に見ます。業務影響は手作業時間、処理遅延、受付停止など、技術リスクは障害、復旧時間、サポート状況など、運用継続性は属人作業や文書更新状況、事業適合性は新規施策や連携追加への対応可否で確認します。

判断前に置くKPI

置き換え後に何を改善するのかを、検討開始時点で仮置きします。たとえば、業務影響なら手作業時間や問い合わせ件数、品質なら重大障害件数や復旧時間、移行品質なら件数照合率や未解決差異数、運用なら定常作業時間を使えます。

指標名だけでは比較できません。「現状値」「目標値または合格基準」「測定時点」「取得元」「未達時の対応」を一組にします。これにより、改修で足りるか、置き換えによる効果が期待できるかを、主観だけでなく検証可能な形で話し合えます。

03Sectionシステムリプレイスの方式と切替方法の選び方

方式名から選ぶのではなく、業務変更、資産利用、データ、停止条件、切戻しの制約から実装方針と切替方針を組み合わせます。

方式選定では、実装方針と切替方針を分けます。実装方針は「何を残し、何を作り直すか」、切替方針は「いつ、どの単位で新旧を入れ替えるか」の判断です。再構築と段階切替、マイグレーションと並行稼働のように、両者を組み合わせることがあります。

実装方針：改修・マイグレーション・再構築・段階的置換

改修は限定課題への対応、マイグレーションは既存資産を活用した移行、再構築は業務や設計の見直し、段階的置換は対象を分割して順に入れ替える考え方です。クラウド移行では、既存構造への変更を抑える移行と再設計を伴う移行を分けて考える方法があります。AWS Prescriptive Guidanceの移行戦略は、その参考になります。ただし、これはクラウド移行の資料であり、一般的なリプレイスの唯一の分類ではありません。

切替方針：一括・段階・並行稼働

一括切替は停止枠の中でまとめて切り替える方法です。段階切替は機能、拠点、顧客群、データ領域などで対象を分けます。並行稼働は新旧を一定期間動かし、処理結果の照合を重視する方法です。どの方法でも、データの正本、同期方法、旧環境の参照・停止条件、切戻しの扱いを先に決めます。

方式を絞る判断順序

方式名から選ぶのではなく、制約条件から候補を絞ります。実装方針と切替方針は、業務・資産、データ・停止条件、期限・切戻しの3点を分けて判断します。

04Sectionシステム移行の進め方：調査から安定化まで

開発完了と本番切替の判断は分け、受入、データ照合、切戻し条件を確認してから切り替えます。

移行プロジェクトでは、開発だけでなく、データ、受入、切替、運用移管を独立した管理対象にします。デジタル庁のデジタル社会推進標準ガイドラインおよび標準ガイドライン解説書は政府情報システム向けの資料です。民間案件では体制や文書をそのまま適用するのではなく、テストの合否基準、業務・システム・データ移行の対象と方式を明確にする確認観点として参照できます。

工程ごとの主担当と承認ゲート

移行・受入・切戻しで確認すること

KPIの置き方

KPIは、切替後に確認するものではなく、要件定義から設定します。業務影響、品質、移行品質、運用負荷のうち、プロジェクト目的に直結するものを選びます。たとえば「手作業時間を減らす」なら、比較対象となる期間と集計方法を切替前に決めます。「データ移行の品質」を見るなら、データ種別ごとの照合基準と未解決差異の扱いを、リハーサル前に定めます。

05Section現行ベンダー以外に依頼するための確認事項

ベンダー変更の可否はソースコードだけで決まりません。資産、アクセス権、データ、運用環境、契約条件を横断して確認します。

現行ベンダー以外へリプレイスを依頼できるかは、ソースコードの有無だけでは決まりません。利用・提供できる資産、管理者権限、データ出力、外部サービスの契約主体、引継ぎ条件を確認し、第三者が調査・実装・移行できる状態かを見ます。ベンダーへの依存が高まる要因と抑え方は、ベンダーロックインとは？原因・リスク・回避策でも確認できます。

引継ぎ前に確認する資産とアクセス

契約・権利・検収で確認すること

経済産業省は、情報システム取引における契約、変更管理、検収などの論点として情報システム・モデル取引・契約書の案内を公開しています。実際の契約条項、著作権・利用権、データ返却、アカウント移管、第三者提供の可否は、既存契約、利用規約、社内規程、契約主体によって異なります。情報システム・モデル取引・契約書は確認観点の参考になりますが、個別案件の可否を一律に決めるものではありません。

保守契約が継続中であれば、契約期間、障害対応、環境アクセス、資料更新、解約・引継ぎ条件も確認します。保守契約とは？システム保守の契約内容・確認ポイントを参照し、切替後の保守開始条件と現行保守の終了条件が重ならないよう整理してください。

依頼資料に明記する範囲

見積依頼では、移行対象データと履歴の範囲、引き継ぐ機能、廃止・再構築する機能、旧環境の参照・停止予定、停止枠、委託範囲を明記します。外注時の依頼から契約・進行管理の考え方は、システム開発の外注ガイド｜依頼から契約・進行管理までも参考になります。

複数社を比較する場合は、前提・対象外・成果物・発注者側の作業・資料不足時の扱いを同じ形式で提出してもらうことが重要です。価格だけでなく、調査、移行、受入、切替、保守移管のどこまでを含むかで比較します。比較軸はシステム開発会社の選び方｜比較項目と発注時の注意点も参照してください。

06Section費用・期間を見積もる前にそろえたい条件

システムリプレイスの費用や期間を、単一の相場で比較することは難しいものです。対象機能、資料の有無、データ品質、連携数、停止条件、教育、支援範囲によって、必要な作業が変わります。公開情報だけでは同じ条件での比較が難しいため、金額や日数を先に当てはめるより、費用構造と依存関係をそろえて見積もるほうが実務的です。

費用を3区分に分けて比較する

調査・要件定義、本開発・移行の一時費用、保守・利用の継続費用を分けて比較します。

初期の調査・要件定義と本開発の費用を分けると、資料不足や要件未確定による不確実性を扱いやすくなります。また、移行・教育・切替を開発費に含めたままにすると、各社で含む範囲が異なり比較しにくくなります。

IPAのソフトウェア開発データ白書FAQでは、開発データの分析対象となる工程範囲に限りがあることが説明されています。要件定義以前、受入、教育、移行、切替、保守、社内工数まで含めたリプレイス全体の総額・期間として、開発工程の公開データを単純に利用することは避けるべきです。

全体期間は依存関係から組み立てる

全体期間は、工程の日数を足し算するだけでは決まりません。要件の承認、外部連携先との調整、データ補正、利用部門の受入参加、繁忙期、停止枠のうち、次工程を開始できない最も遅い条件が全体予定を左右します。

まず、各工程に「開始条件」「完了条件」「依存先」「決定者」「決定期限」を置きます。そのうえで、承認待ち、連携先調整、データ整備、リハーサル、受入、切替枠の連鎖を確認します。この連鎖がクリティカルパスです。期限に収まらない場合は、対象範囲の分割、後続フェーズ化、切替方式の変更、期限の見直しを比較します。

社内で決めることと外部へ依頼すること

社内が保持すべきなのは、目的、業務の優先順位、受入基準、最終的な切替判断、部門調整、契約確認です。技術・資産調査、方式設計、データ移行設計、性能・セキュリティ検証、切替・切戻し計画、実装、運用移管は、必要な知見や体制に応じて外部への依頼を検討する領域です。

見積依頼前には、少なくとも次の5点をそろえます。

• 改善目的、維持する業務、KPI、受入基準
• 対象システム、機能、データ、外部連携、利用部門
• コード、設計書、データ定義、環境情報、権限の有無と閲覧可否
• 停止枠、データ移行回数、並行稼働、旧環境の参照・終了条件
• 調査、要件定義、開発、移行、教育、切替、安定化、保守移管の分担

規模、要因、リスク、前提を整理して見積条件を明確にする考え方は、IPAのCoBRA法に基づく見積り支援ツールも参考になります。金額の単価表として使うのではなく、見積もりの前提をそろえ、追加調査や再見積もりが必要になる条件を明確にするために活用します。

システムリプレイスの依頼先を比較する

対象範囲、現行資産、データ移行、切替条件を整理したうえで、対応可能な開発会社を比較できます。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発の会社を探す