「そろそろリプレイスしたいが、業務を止められない。そのうえ当時の設計を知っている人がもう社内にいない」。システム刷新の相談を受けるとき、この 2 つはほぼ必ずセットで出てきます。動いてはいるが手を入れるのが怖い、しかし放置するほどリスクが積み上がる。本記事は、この典型的なジレンマを抱える情報システム部門や事業責任者に向けて、現状の棚卸しからカットオーバーまでの進め方を 7 ステップで整理した実務ガイドです。AI 駆動開発のクリエイティブスタジオとして実際の刷新案件で使っている手順と判断基準を、できるだけ一次情報のまま共有します。

結論: 「一括書き直し」より段階移行が安全な理由

先に結論を書きます。システムリプレイスは、全機能を一気に作り直して一日で切り替える「一括書き直し・ビッグバンカットオーバー」よりも、機能とデータを区切って少しずつ新システムへ寄せていく「段階移行」のほうが、ほとんどのケースで安全です。

理由は単純で、一括書き直しはリスクが切り替え当日の一点に集中するからです。切り替えるまで本番で動くものが存在せず、当日になって初めて全機能を本番データで動かすことになります。そこで想定外が出れば、戻す先は古いシステムしかなく、数か月かけた開発が宙に浮きます。古いシステムほど暗黙の業務ルールや例外処理が積み重なっているため、「全部把握できた」と思った時点を過ぎてから抜けが見つかるのが常です。

段階移行は、この一点集中を分散させます。参照系の画面だけ先に切り替える、特定の拠点や商品カテゴリだけ新フローに乗せる、といった形で対象を絞り、問題が起きても影響範囲をその区切りに閉じ込めます。切り替えのたびに小さく検証できるので、想定外を早く・安く発見できます。これは AI を使うかどうか以前の、移行という行為そのものの原則です。本記事の 7 ステップも、この段階移行を前提に組み立てています。

なお、段階移行を取れるかどうかは、移行設計の最初に「機能をどの単位で区切れるか」を決められるかにかかっています。ここを飛ばして実装に入ると、結局すべてが密結合のまま一括切り替えに追い込まれます。後半のステップで具体的な区切り方を扱います。

リプレイスとマイグレーション・モダナイズの違い

進め方の前に、よく混同される 3 つの言葉を整理しておきます。発注側と開発側で言葉の指す範囲がずれていると、見積もりも移行設計も噛み合わなくなるためです。

用語主に変えるもの業務やデータの扱い向く状況
マイグレーション(移行)動く基盤(サーバー・OS・言語バージョン)仕様はほぼそのまま運ぶ老朽化した基盤を新しくしたいが業務は変えたくない
モダナイズ(近代化)内部構造・技術スタック業務はおおむね維持し、保守性を上げる動いているが手を入れづらく、改修コストが高い
リプレイス(刷新)システム全体と業務フローの一部業務の見直しを伴うことが多い老朽化に加え、業務そのものを変えたい

マイグレーションは、業務やデータの中身を極力変えずに「乗せ替える」イメージです。仕様を運ぶだけなので比較的読みやすい一方、古い業務の悪いところもそのまま引き継ぎます。モダナイズは、外から見た業務は変えずに内部を作り直す近代化で、保守できる状態に戻すのが目的です。リプレイスはこの中で最も範囲が広く、システムを刷新すると同時に「この業務フロー、本当に必要か」を問い直すことを含みます。

実務では、これらは排他ではなく組み合わさります。たとえば「基幹システムをリプレイスする」と言いつつ、中身を見ると会計連携の部分はマイグレーション、受発注の部分は業務を見直すリプレイス、という具合に区画ごとに方針が変わるのが普通です。最初に対象を一枚岩で捉えず、区画ごとに「どこまで変えるか」を分けて考えると、見積もりと移行順序が一気に整理できます。

進め方 7 ステップの全体像

段階移行を前提にしたシステムリプレイスは、おおまかに次の 7 ステップで進みます。順番には意味があり、特に前半の棚卸しとドメイン分割を飛ばすと、後半の移行設計が成り立ちません。

  1. 既存資産の棚卸し。何が動いていて、何に依存しているかを洗い出す
  2. ドメイン責務マップの作成。業務の区切りでシステムを分割する
  3. 移行順序の設計。どの区画から、どの順で切り替えるかを決める
  4. テスト先行での再実装。業務ルールをテストに書き起こしてから作る
  5. データ移行のリハーサル。本番相当のデータで移行手順を繰り返す
  6. Feature Flag による段階リリース。対象を絞って新側へ切り替える
  7. 旧システムの停止。並行稼働を終え、安全に旧側を畳む

前半(1〜2)は現状を読み解いて地図を作るフェーズ、中盤(3〜4)は移行のシナリオを設計して作るフェーズ、後半(5〜7)は本番に安全に反映するフェーズ、と捉えるとつかみやすいです。以降で各ステップの勘所を掘り下げます。

ステップ 1-2: 既存資産の読み解きとドメイン責務マップ

最初のステップは、対象システムが「いま何をしていて、何に依存しているか」を洗い出す棚卸しです。設計書がない、仕様を知る人がいない、という状況がここで立ちはだかりますが、出発点を資料ではなく実物に置けば前に進めます。具体的には、動いているコード、データベースのテーブル定義と実データ、そして現場の業務オペレーションの 3 つを一次情報として読み解きます。

棚卸しで把握したいのは次のような点です。どの画面・バッチが、どのテーブルを、どのタイミングで読み書きしているか。外部システムとの連携は何本あり、どんな頻度でどんなデータをやり取りしているか。仕様書には載らない手運用や例外処理がどこに潜んでいるか。これらは現場ヒアリングでしか出てこないことが多いので、コードを読むだけで完了とせず、必ず使っている人に当てます。

この読み解きは AI 駆動開発と特に相性の良い工程です。コードベースを Claude Code などに読み込ませ、各モジュールの責務やデータの流れ、推定される業務ルールを要約させると、人手だけで追うより短期間で全体像をつかめます。ただし AI が出すのはあくまで仮説です。重要な業務ルールは、後続のステップでテストと現場確認によって裏を取ります。AI に依存して裏取りを省くと、誤った仕様を新システムに固定してしまうため注意してください。AI の出力をどう検証に組み込むかは AI 駆動 TDD の考え方が参考になります。

棚卸しが進んだら、結果を「ドメイン責務マップ」にまとめます。これは技術的なモジュール構成ではなく、業務の区切りでシステムを分割した地図です。受注、在庫、請求、顧客管理、といった業務のまとまりごとに、関連する画面・データ・連携を割り当て、まとまり間の依存関係を矢印で描きます。このマップが、段階移行で「どの単位なら区切って切り替えられるか」を判断する土台になります。依存が少なく外から呼ばれるだけの区画は先に切り替えやすく、多くの区画から参照される中核データ(マスタ類)は最後まで残す、といった移行順序がここから見えてきます。

ステップ 3-4: 移行順序の設計とテスト先行での再実装

ドメイン責務マップができたら、移行順序を設計します。原則は「依存の少ない末端から、影響範囲の閉じた区画を先に」です。たとえば、他から参照されるだけで自分は何も呼ばない参照系の画面や帳票は、新システムへ向けても他への波及が小さいため先頭に置きやすい候補です。逆に、多数の区画から読み書きされる顧客マスタや商品マスタのような中核データは、影響が全体に及ぶため後半に回し、新旧で同期を取りながら慎重に切り替えます。

移行順序を決めるときは、業務上のリスクとビジネス価値も天秤にかけます。月末の締め処理に直結する区画は繁忙期を避ける、現場が最も困っている画面を先に新しくして早く効果を体感してもらう、といった調整です。技術的な依存だけで順序を機械的に決めず、業務カレンダーと現場の優先度を重ねて現実的な並びにします。

順序が決まったら、いよいよ再実装ですが、ここで「テスト先行」を徹底します。古いシステムには設計書がないと前述しました。だからこそ、新システム側に業務ルールをテストとして書き起こしていくことが、移行の安全装置になります。「この入力でこの出力になる」という旧システムの振る舞いをテストに固定し、それを満たすように新コードを実装する。こうすれば、AI に実装を任せても振る舞いがテストで縛られ、勝手な仕様の解釈ずれを防げます。書き溜まったテストは、そのまま生きた仕様書として残り、後任への引き継ぎ資料にもなります。

AI 駆動開発を取り入れると、この再実装フェーズの速度が大きく変わります。旧コードの読み解きで得た仮説をテストに落とし込み、AI に実装させ、テストで検証する、というループを高速に回せるためです。従来開発で人手だけで進めると、仕様の読み解きと実装で大きな工数がかかっていた部分を圧縮できます。具体的なテスト先行の進め方は AI 駆動 TDD にまとめています。

ステップ 5-7: データ移行リハーサルと Feature Flag による段階リリース

新システムの実装が進んだら、本番反映の前に「データ移行のリハーサル」を繰り返します。これがリプレイスで最も事故が起きやすく、かつ最も軽視されがちな工程です。本番相当のデータをコピーして移行スクリプトを流し、移行後のデータが正しいかを件数照合や金額の突合で検証します。一度で完璧になることはまずなく、文字コードの差異、桁あふれ、過去データの欠損、想定外のヌル値といった問題が必ず出ます。だからこそ、本番当日にぶっつけで流すのではなく、リハーサルを複数回回して手順とスクリプトを枯らしておきます。

リハーサルでは、移行にかかる実時間も計測します。本番のデータ量で何時間かかるかを把握しておかないと、許容できる停止時間に収まるかが当日まで分かりません。時間が足りなければ、移行を分割する、差分だけ流す、といった設計の見直しがここで必要になります。

データ移行の目処が立ったら、Feature Flag を使って段階リリースに入ります。Feature Flag は、新旧どちらの処理を使うかをコードのデプロイなしに切り替えられる仕組みです。これを使えば、最初は社内の一部ユーザーだけ新システムに向ける、次に特定の拠点だけ、次に全体、という形で対象を絞って広げられます。問題が出たらフラグを戻すだけで即座に旧側へ復帰できるので、切り替えのリスクをかなり抑えられます。新旧を一定期間並行稼働させ、データを同期しながら少しずつ新側へ寄せるこの進め方が、業務を止めないリプレイスの核心です。

最後のステップが旧システムの停止です。新システムへの切り替えがすべての区画で完了し、一定期間の並行稼働で問題が出ないことを確認してから、旧側を畳みます。ここで急がないことが大切です。並行稼働の期間中に締め処理や決算など季節性の業務を一巡させ、月次・年次のイレギュラーな処理まで新システムで通ったことを確認してから停止すると、見落としをほぼ防げます。停止前には、旧システムのデータと監査ログを保全し、必要な保管期間を満たす形でアーカイブしておきます。

費用を左右する要因と相場の調べ方

システムリプレイスの費用と期間は規模で大きく変わります。規模別の具体的な費用・期間レンジは、実案件ベースでまとめた レガシー刷新の費用と期間 に整理しているので、相場感はそちらを参照してください。本記事では、その金額が何で動くのか、見積もりを読むときに押さえておきたい変動要因を整理します。

費用と期間を左右するのは、対象システムの規模そのものよりも、次の変動要因です。

  • 外部連携の数。連携先が多いほど、相手側の都合に合わせた検証と切り替え調整が増えます。
  • データ移行の複雑さ。データの量だけでなく、過去データの汚れや、システムをまたいだ整合性の取り方が工数を押し上げます。
  • 設計情報の残り具合。設計書がなく現状把握から始める案件は、棚卸しの工数がそのまま費用に乗ります。
  • 並行稼働の期間。新旧を同期する仕組みの維持コストは、並行稼働が長引くほど積み上がります。

AI 駆動開発を取り入れると、これらのうち特に現状コードの読み解きと再実装の工数を圧縮できます。実案件の感触では、従来開発に比べて期間がおおむね半分から 3 分の 2 程度に短縮できることが多いです。ただし、データ移行のリハーサルや外部連携の調整、現場ヒアリングといった工程は AI で短縮しにくく、ここを削ると事故に直結します。費用が期間と同じ比率でそのまま下がるわけではない、という点は見積もりを読むときに意識してください。AI 駆動開発の費用構造をどう見極めるかは、AI 開発の発注先を選ぶ視点 も参考になります。

実際に AI 駆動開発でレガシーシステムの刷新コストを抑えた事例は レガシーシステム刷新を半分のコストで実現した事例 にまとめています。

失敗を避けるチェックリストと、AI 駆動開発で期間を半分にする勘所

最後に、ここまでの内容を着手前に確認できるチェックリストとして整理します。リプレイスが頓挫する原因は、ほとんどがこのどれかの抜けに起因します。

  • 移行設計の最初に「機能をどの単位で区切れば部分的に切り替えられるか」を決めているか
  • 棚卸しを資料ではなく、動くコード・実データ・現場ヒアリングの三点から始めているか
  • 旧システムの暗黙の業務ルールや例外処理を、テストとして新システム側に書き起こしているか
  • データ移行を本番相当データでリハーサルし、所要時間まで計測しているか
  • 問題が起きたとき即座に旧側へ戻せる手順(Feature Flag やロールバック)を用意しているか
  • 締め処理や決算など季節性の業務を一巡させてから旧システムを停止する計画になっているか

これらを満たしたうえで、AI 駆動開発が効くのは「現状を読み解く速度」と「再実装の速度」です。設計書のない古いコードを読み解く作業は、従来は一部のベテランしか担えず、ここが工程全体のボトルネックでした。コードベースを AI に読ませて責務とデータの流れを要約させ、推定した業務ルールをテストに固定し、AI に実装させてテストで検証する。このループを速く回せると、最も時間のかかっていた前半工程が圧縮され、全体の期間が大きく縮みます。

一方で、AI に任せてはいけない判断もはっきりしています。どの単位で区切るかという移行設計、本番に反映する順序とタイミング、データ移行の正しさの最終確認、旧システムを止める意思決定。これらは業務とリスクへの理解が要る判断で、人間が握り続ける必要があります。AI に読み解きと実装を任せ、設計と検証の判断を人間が握る。この役割分担が、品質を落とさずに期間を半分にする勘所です。AI と人間の責務分担をどう設計するかは AI 駆動 TDD でも詳しく触れています。

よくある質問

リプレイスの相談で特に多い質問を 2 つ補足します。

1 つ目は「本当に業務を止めずに移行できるのか」です。前述のとおり、機能とデータを区切って段階移行を取れば、多くの場合は全面停止を避けられます。ただし条件があり、移行設計の最初に区切りの単位を決め、新旧データを同期する仕組みと即座に戻せる手順を用意しておくことが前提です。これを後回しにすると、結局は全停止のビッグバンカットオーバーに追い込まれます。

2 つ目は「設計書がなく仕様を知る人もいない場合にどう進めるか」です。これも前述のとおり、出発点を資料ではなく動くコードと実データ、現場の業務オペレーションに置けば進められます。古いシステムでは設計書が現存しない、あっても実態とずれているのが普通なので、これはむしろ標準的な前提だと考えてください。読み解きを AI で加速し、把握した業務ルールをテストとして書き起こしていけば、それがそのまま新しい生きた仕様書になります。

システム刷新・リプレイスのご相談

システムリプレイスは、進め方の前半、特に現状の棚卸しと区切りの設計で勝負が決まります。「止めずに移行したい」「設計が分かる人がいない」という状況こそ、AI 駆動開発で読み解きと再実装を加速できる領域です。FIXIT ではシステム刷新・リプレイスの無料相談を承っています。現状の課題や対象システムの規模が固まっていない段階でも構いません。まずは システム刷新・リプレイスのサービス内容 をご覧いただき、お問い合わせ からお気軽にご相談ください。