システムリプレイスは、「新しいシステムを作る」作業である以前に、「いまのシステムが何をしているかを正確に知り、そのうち何を引き継ぎ、何を捨て、何を変えるかを決める」作業です。進め方の骨格は、現行調査、新旧の差分整理、要件と移行方針の決定、開発、データ移行のリハーサル、並行稼働や段階切り替え、本番切り替え、切り替え後の安定化という流れになります。この順番を飛ばさずに進めるだけで、リプレイスでよく起きる「動いていた機能が消えた」「データが合わない」「切り替え当日に戻せない」といった事故の多くは防げます。
リプレイスが新規開発より難しいのは、現行システムという「正解の一部」がすでに存在し、業務がそれに合わせて動いているからです。利用者は画面の細かな動きや帳票の並び順まで前提にしており、それが少し変わるだけで業務が止まることがあります。一方で、現行の動きをすべて再現しようとすると、古い業務の無駄まで新システムに持ち込むことになり、作り直す意味が薄れます。
この記事は、社内の基幹システムや業務システム、自社サービスの裏側の仕組みなどを作り直そうとしている事業責任者や情報システム担当者に向けて書いています。現行調査から切り替えまでの手順、工程ごとの判断基準、発注側が準備すべきもの、よくある失敗と避け方を順に整理します。
システムリプレイスの全体像と進め方の原則
リプレイスの進め方には、新規開発にはない原則がいくつかあります。最初に押さえておくと、各工程での判断がぶれにくくなります。
一つ目は、「現行と同じ」を要件にしないことです。「今と同じ機能で、新しい技術に置き換えてほしい」という依頼はよくありますが、現行の仕様が文書化されていない限り、「同じ」の中身は誰にも分かりません。開発会社は現行システムを解析して推測するしかなく、見積もりも品質も不安定になります。引き継ぐ機能は一覧にして、一つずつ「そのまま」「変える」「やめる」を決めるのが原則です。
二つ目は、データ移行と切り替えを開発と同じ重さで計画することです。リプレイスの失敗は、新システムの機能不足よりも、データ移行の不備や切り替え手順の甘さから起きることが多くあります。開発が終わってから移行を考え始めると、日程の終盤に問題が集中します。
三つ目は、戻れる状態を最後まで残すことです。切り替えた後に重大な問題が見つかったとき、旧システムに戻す手順と判断基準があるかどうかで、被害の大きさが変わります。切り戻しの準備は「使わないかもしれない保険」ですが、省くと取り返しがつかなくなります。
発注側で用意する体制と役割分担
手順に入る前に、発注側の体制を決めておきます。リプレイスは開発会社に任せきりにできる工程が少なく、現行業務を知る人の時間を確保できるかどうかで進み方が大きく変わります。
最低限必要なのは、全体の判断を下す責任者、業務の詳細を説明できる各部署の窓口、現行システムの運用を知る担当者の三者です。責任者は「やめる機能」や「切り替え日」の最終判断を担い、部署の窓口は聞き取りと受入テストに協力し、運用担当者はデータの取り出しや旧システムの停止作業を担います。兼務で構いませんが、誰がどの判断をするかを最初に明文化しておくと、議論が堂々巡りになるのを防げます。
システムリプレイスの手順：現行調査から切り替えまで
ここからは工程を六つに分けて、それぞれで何を決め、何を成果物として残すかを説明します。
手順1：現行システムの調査と機能の棚卸し
最初の工程は、現行システムが「何を、誰のために、どのように」処理しているかを把握することです。ここが曖昧なまま進むと、後工程で必ず手戻りが起きます。調査は次の順で進めると漏れが少なくなります。
- 利用者と利用場面を洗い出す。部署、役割、利用頻度、繁忙期を一覧にする。
- 画面・帳票・バッチ処理・外部連携を一覧にする。メニュー構成、出力されるファイル、夜間に動く処理、他システムとのデータのやり取りを拾う。
- データの構造を把握する。主要なテーブル、件数、保存期間、マスタと取引データの関係を整理する。
- 業務ルールを拾う。計算式、締め処理、承認の条件、例外の扱いなど、画面からは見えない処理を確認する。
- 運用作業を拾う。手作業でのデータ修正、定期的な再起動、障害時の対応など、システムの外側で人が補っている作業を書き出す。
- 利用者に「困っていること」と「絶対に変えてほしくないこと」を聞く。
仕様書が残っていない、作った人がいないといった状況では、ソースコードやデータベース、操作ログから仕様を復元する必要があります。具体的な方法は仕様書がないブラックボックス化したシステムの現状把握の方法で詳しく解説しています。
調査の成果物は、機能一覧（画面・帳票・処理・連携ごとの行）と、データ一覧、運用作業一覧の三つにまとめておくと、次の差分整理にそのまま使えます。
手順2：新旧の差分整理と「引き継ぐ・変える・やめる」の判断
棚卸しした機能一覧の各行に、新システムでの扱いを決めていきます。判断の観点は次の表のとおりです。
| 判断 | 選ぶ条件 | 注意点 |
|---|---|---|
| そのまま引き継ぐ | 業務に必須で、現行の動きに不満がない | 「同じ」の定義（入力項目、計算結果、出力形式）を具体的に書く |
| 変えて引き継ぐ | 必須だが、手間やミスが多い・業務が変わった | 変更後の業務フローを先に決め、利用者と合意する |
| 既製サービスに任せる | 会計、勤怠、メール配信など汎用的な処理 | 連携方法とデータの持ち方を確認する |
| やめる | 使われていない、目的が失われている | 本当に誰も使っていないかをログや聞き取りで確かめる |
| 後回しにする | 必須ではないが、いずれ必要 | 初回リリースから外すことを関係者に明示する |
この工程で重要なのは、「使われていない機能」を見極めることです。長く運用されたシステムには、一度だけ使われた帳票や、担当者が辞めて誰も触らなくなった画面が残っています。アクセスログや出力履歴を確認し、利用実績がない機能は思い切って対象から外すと、開発範囲と費用を大きく絞り込めます。
逆に、利用者が「この機能は使っていない」と言っても、月末や年度末にだけ使う処理が隠れていることがあります。年に一度の処理、監査対応、法定帳票などは、繁忙期の担当者に個別に確認してください。
手順3：要件と移行方針を決める
差分整理が終わったら、新システムの要件と、どのように移行するかの方針を決めます。ここでは機能要件だけでなく、性能、可用性、セキュリティ、保守のしやすさといった非機能要件も現行と比較して決めておきます。現行システムで許容されていた応答の遅さや停止時間が、新システムでも許容されるとは限りません。
移行方針として決めておくべきことは次のとおりです。
- 一度に全機能を切り替えるか、機能や拠点ごとに段階的に切り替えるか
- 旧システムと新システムを並行稼働させるか、させる場合の期間と比較方法
- 移行するデータの範囲（全期間か、直近分だけか、マスタだけか）
- 切り替えのタイミング（繁忙期を避ける、月初や期初に合わせるなど）
- 切り戻しを判断する基準と、判断する人
一括で切り替えるか段階的に移すかは、業務停止をどこまで許容できるか、他システムとの連携がどれだけ密かによって変わります。判断の観点はシステム移行は段階的か一括か：ビッグバン移行との違いと選び方にまとめています。
手順4：開発とテスト（現行との比較テストを含める）
開発工程そのものは新規開発と大きく変わりませんが、テストには現行システムとの比較という独自の観点が加わります。同じ入力データを新旧両方のシステムに通し、計算結果や帳票の出力が一致するかを確かめる「比較テスト」は、リプレイスで最も効果の高い品質確認の方法です。
比較テストを行うには、次の準備が必要です。
- 実際の業務データから、典型的なケースと例外的なケースを含むテストデータを選ぶ。
- 現行システムでの処理結果（帳票、集計値、出力ファイル）を保存しておく。
- 新システムで同じデータを処理し、結果を突き合わせる。
- 差異が出たら、新システムの不具合か、意図した仕様変更か、現行システムの不具合かを判定する。
最後の判定で「現行システムのほうが間違っていた」と分かることも珍しくありません。その場合は、新システムで正しく直すのか、業務への影響を避けるために現行の動きに合わせるのかを、業務部門と相談して決めます。
また、開発の途中で機能を追加・修正するたびに、すでに確認した機能が壊れていないかを確かめる必要があります。回帰テストを自動化しておくと、リプレイス後の改修でも同じ仕組みを使い続けられます。
手順5：データ移行のリハーサル
データ移行は、本番の切り替え前に少なくとも一度、できれば複数回リハーサルを行います。リハーサルでは、本番と同じ手順で、本番に近い量のデータを移し、次の点を確認します。
- 移行にかかる時間（業務停止の時間内に収まるか）
- 件数と金額の合計が新旧で一致するか
- 文字化け、桁あふれ、日付の形式違いなどの変換エラーがないか
- 移行後のデータで、新システムの主要な業務が問題なく動くか
- 手順書どおりに作業して、担当者が迷わないか
リハーサルで見つかった問題を直して、もう一度リハーサルする。この繰り返しで、本番当日の不確実性を減らしていきます。移行対象の選び方や変換ルールの決め方、切り戻しの準備についてはリプレイス時のデータ移行計画：移行リハーサルと切り戻しの準備で詳しく扱っています。
手順6：並行稼働と本番切り替え、切り替え後の安定化
切り替えの直前には、並行稼働を行うかどうかを判断します。並行稼働とは、一定期間、旧システムと新システムの両方で同じ業務を処理し、結果を比較する方法です。安心感は高い一方で、利用者は二重入力の負担を負うため、期間と対象業務を絞るのが現実的です。
本番切り替えは、次のような段取りで進めます。
- 切り替え日時と業務停止の時間を、利用者と取引先に事前に周知する。
- 旧システムへの入力を止め、最終データを確定させる。
- 旧システムのバックアップを取得する。
- データ移行を実施し、件数・合計値を検証する。
- 主要業務の動作確認を行い、切り替えの可否を判断する。
- 問題がなければ利用を開始し、問題があれば切り戻し手順を実行する。
切り替え後の数週間は、問い合わせや不具合が集中する期間です。問い合わせ窓口を一本化し、日次で不具合と要望を整理して、優先度の高いものから対応します。この期間に開発会社の体制を手厚くしておく契約にしておくと安心です。初回の月次締めや請求処理など、切り替え後に初めて動く処理は特に注意して見守ってください。
安定化期間の終わりには、振り返りの場を設けます。切り替え後に出た不具合や要望を「移行の不備」「仕様の誤解」「新たな改善要望」に分けて整理すると、次の改善計画と、今後の保守の範囲を決める材料になります。リプレイスは切り替えで終わりではなく、新しいシステムを業務に合わせて育てていく始まりだと考えておくと、初回リリースの範囲を欲張らずに済みます。
具体的な場面の例：受発注管理システムのリプレイス
ここでは架空の一般例として、ある卸売業の会社が十数年使ってきた受発注管理システムをリプレイスする場面を考えます。
現行システムは社内サーバーで動いており、作った担当者はすでに退職しています。機能の棚卸しをしたところ、画面と帳票を合わせて数十の機能が見つかりましたが、アクセスログを確認すると、そのうち三分の一ほどは直近一年間で一度も使われていませんでした。また、受注データを会計ソフトに取り込むために、毎日担当者がCSVを出力して手で加工している作業が見つかりました。
この会社は、使われていない機能を対象から外し、CSVの手作業は会計ソフトとのAPI連携に置き換えると決めました。移行方針は、まず商品マスタと取引先マスタを新システムに移して整備し、次に受注機能、最後に発注と在庫の機能という順で段階的に切り替える形を選びました。各段階で旧システムとの比較テストを行い、月末の締め処理を新旧両方で並行して確認したうえで旧システムを停止しています。
この例のポイントは、「現行と同じものを作る」のではなく、棚卸しを通じて業務の無駄を削り、移行の順番を業務の区切りに合わせて設計したことです。
システムリプレイスでよくある失敗と避け方
リプレイスで繰り返し見られる失敗と、その避け方を整理します。
現行機能の漏れが本番後に見つかる。 画面にない処理、年に一度の処理、担当者が手で補っていた作業が漏れやすい部分です。運用作業の一覧と、繁忙期担当者への聞き取りで防ぎます。
「現行と同じ」で発注して見積もりがぶれる。 機能一覧に「そのまま」「変える」「やめる」を書き込んだ資料を渡せば、開発会社は同じ前提で見積もれます。
データ移行を後回しにする。 開発の終盤で旧データの汚れや形式の違いが見つかり、日程が崩れます。調査の段階でデータの品質を確認し、移行の作業を計画に含めてください。
切り戻し手順を用意していない。 切り替え後に致命的な問題が出たとき、戻れなければ業務が止まります。判断基準、判断者、手順、所要時間を事前に決めておきます。
利用者への説明と教育が不足する。 機能が正しくても、使い方が変われば現場は混乱します。操作説明会、簡単なマニュアル、切り替え直後の問い合わせ窓口を用意します。
旧システムの停止時期を決めていない。 旧システムを「念のため」動かし続けると、二重管理と保守費用が続きます。参照用にデータを残す方法を決め、停止日を計画に入れておきます。
リプレイス準備のチェックリスト
開発会社に相談する前、または社内で計画を固める前に、次の項目を確認してください。
- 現行システムの利用者、利用場面、繁忙期が一覧になっている
- 画面・帳票・バッチ処理・外部連携の機能一覧がある
- 各機能に「そのまま」「変える」「やめる」「後回し」の判断が書かれている
- 主要データの件数、保存期間、品質の問題点が把握できている
- システムの外で人が補っている運用作業が洗い出されている
- 非機能要件（性能、停止許容時間、セキュリティ）が現行と比較して決まっている
- 一括切り替えか段階切り替えかの方針がある
- 比較テストに使うテストデータと現行の処理結果を用意できる
- データ移行のリハーサル回数と日程が計画に入っている
- 切り戻しの判断基準、判断者、手順が決まっている
- 利用者への周知と教育の計画がある
- 旧システムの停止日と、旧データの保管方法が決まっている
よくある質問
Q. リプレイスと改修のどちらがよいか判断がつきません。
改修の費用と期間が年々増えている、使っている技術のサポートが終わる、業務と仕組みのずれが大きくなっている、といった兆候が重なっているならリプレイスを検討する時期です。判断基準はシステムを作り直すべきタイミングで整理しています。
Q. 現行システムの開発会社に頼むべきですか、別の会社に頼むべきですか？
現行の仕組みを熟知している点では現行の会社に利点があります。一方で、技術や構成を大きく変えたい場合や、現行の会社の体制に不安がある場合は、別の会社に提案を求める価値があります。どちらの場合も、現行調査の成果物を発注側が持っておくと、比較や乗り換えがしやすくなります。
Q. リプレイスの期間はどのくらい見込めばよいですか？
機能の数、データの量と品質、連携の数、段階移行か一括移行かによって大きく変わります。一般的には、開発期間だけでなく、現行調査、移行リハーサル、並行稼働、切り替え後の安定化の期間を含めて計画する必要があります。調査を先に小さく実施し、その結果をもとに全体の期間を見積もると精度が上がります。
Q. 業務を止めずにリプレイスすることはできますか？
段階的な切り替えや、データを差分で同期する仕組みを組み合わせれば、業務停止の時間を短くすることは可能です。ただし、仕組みが複雑になるぶん費用と期間は増えます。どこまで停止を許容できるかを業務部門と先に決めておくことが大切です。
Otsumuに相談できること
対象のシステムが小さく、現行の仕様が文書で残っていて、社内に業務とシステムの両方が分かる担当者がいる場合は、この記事の手順で棚卸しと差分整理を進め、その資料をもとに複数社から見積もりを取るだけで、十分に進められることがあります。既製のクラウドサービスに置き換えられる業務であれば、開発そのものが不要な場合もあります。
一方で、仕様書がなく現行の動きを誰も説明できない、データの品質に不安がある、業務を止められる時間が短い、他システムとの連携が多い、といった条件が重なる場合は、調査と移行計画の段階から外部の力を借りたほうが、結果として手戻りが少なくなります。リプレイスは開発よりも「何を引き継ぐかの判断」と「移行の段取り」で成否が分かれるからです。
Otsumuは、構想から開発・運用・改善までを一気通貫で支援する立場から、現行システムの調査、機能の棚卸しと優先順位付け、移行方針の設計、AIを活用した少人数・短期間の開発、切り替え後の安定化までを伴走します。システムリプレイスのページで進め方を紹介しています。費用は対象範囲に応じて個別にお見積もりします。
現行調査をどこから始めればよいか、作り直すべきかどうか迷っている段階でもご相談いただけます。30分の無料相談で、いまのシステムと業務の状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01