システムリプレイスの進め方｜4つの移行方式と失敗の型

リプレイスは4方式あり、選び方は「止められる業務か」で決まります。方式を決めた後は、現状分析から評価までを8段階で進めます。ただし、計画どおりに作るだけでは十分ではありません。現場には仕様書に書かれていない業務ルールがあり、成否はその暗黙知を移せるかで分かれます。本記事では、方式の選び方からロールバックまでを実務順に解説します。

システムリプレイスとは

システムリプレイスの基本をすでにご存じの方は、4つの移行方式と選び方から読み進められます。

システムリプレイスとは、既存システムを新しい仕組みに置き換える取り組みです。対象には、基盤だけでなく画面やデータ、業務手順も含まれます。単なる製品交換ではなく、「業務をどう引き継ぐか」を設計する活動です。

マイグレーションとの違い

マイグレーションは、データや環境を別の場所へ移す行為を指します。一方、リプレイスはシステム全体の置き換えを意味します。たとえば、既存データを新基盤へ移す作業はマイグレーションです。

新しい画面や処理へ切り替える計画は、リプレイスに当たります。両者は対立する考え方ではありません。多くのリプレイスでは、工程の中にマイグレーションが含まれます。

言葉を分ける理由は、責任範囲を明確にするためです。「データが移った」と「業務が動く」は、異なる完了条件です。

メリットとデメリット

メリットは、セキュリティの向上、動作の安定、事業や制度の変化への追従です。サポートが続く基盤へ移せば脆弱性対応を受けやすくなり、属人的な保守を減らせば障害からの復旧も安定させられます。

そのうえで、API連携や機能変更をしやすい構成にすると、新しい販売方法や法改正にも追従しやすくなります。古い制約が外部連携や販売方法の更新を妨げている場合、置き換えで選択肢が広がります。デメリットは、費用と期間、移行時の業務影響、新環境への習熟負担です。

注意したいのは、メリットが自動的には出ないことです。「新しくしたのに、現場の処理は遅くなった」という結果もあり得ます。現行の業務ルールを引き継げるかが、メリットの成立条件です。

目的とタイミング（攻めと守り・実施周期）

目的は、「守り」と「攻め」に分けると整理しやすくなります。守りの目的は、老朽化や保守困難への対応です。障害対応が属人化した状態も、置き換えを考える合図です。

攻めの目的は、新しい販売方法や業務自動化への対応です。現行の制約が事業の変化を妨げるなら、更新の検討が始まります。実施時期の目安として、まず「5年」がよく挙げられます。

根拠の一つは、国税庁の減価償却上、一般的な「その他のソフトウエア」の法定耐用年数が5年とされていることです。この数字は会計上の耐用年数であり、5年を迎えたら必ず交換するという技術基準ではありません。そのため、一定周期だけで実施時期を決めるのは危険です。

製品の保守期限、改修速度、障害影響を一緒に見ます。さらに、繁忙期と社内変更の時期も重ねて判断します。判断基準は、「古いか」ではなく「事業を支え続けられるか」です。

2025年の崖とレガシーが残る理由

経済産業省のDXレポートは、複雑化・ブラックボックス化した既存システムを残すと、DXを進められず、2025年以降に大きな経済損失が生じ得る問題を「2025年の崖」と示しました。これは期限を過ぎたら一斉に障害が起きる予言ではなく、老朽化への対応を経営課題として扱うための警告です。レガシーが残る理由は、更新コストが大きいこと、現行を理解するIT人材が不足していること、保守や改修を特定ベンダーに依存していることです。

実務では、保守費、障害対応時間、変更に要する日数を記録し、放置コストと更新コストを同じ会議で比較します。

4つの移行方式と選び方

移行方式は、一括・段階・並行・パイロットの4つです。方式ごとに、停止時間と切り戻しやすさが異なります。名称だけで選ばず、業務停止の許容度から絞り込みます。

一括・段階・並行・パイロット

方式	進め方	向く状況	主な注意点
一括移行	全対象を同じ切替機会に移す	業務を止められ、対象の関係が強い	障害時の影響範囲が広い
段階移行	機能や業務の単位で順に移す	境界を分けられ、順次確認したい	新旧間のデータ整合が必要
並行移行	現行と新環境を同時に動かす	停止を避け、結果を照合したい	二重運用の負担が生じる
パイロット移行	限定した部門や範囲で先行する	小さく検証し、知見を広げたい	先行範囲が全体を代表するとは限らない

選び方は「止められる業務か」で決まる

最初の問いは、「切替中に業務を止められるか」です。止められるなら、一括移行も選択肢になります。止められないなら、段階移行か並行移行を軸にします。

限定範囲で学習できるなら、パイロット移行も有効です。次に、「データの二重管理を許容できるか」を確認します。許容できなければ、並行期間を短くする設計が必要です。

また、「業務を分ける境界があるか」も重要です。境界が曖昧なら、段階移行の連携負担が増えます。方式はシステム都合だけで決められません。

停止、二重運用、影響範囲のどれを受け入れるかで決めます。

クラウドへ移すか、同じ形で作り直すか

リプレイスの構想では、「クラウドへ移せば新しくなる」と考えがちです。しかし、クラウドは配置先の選択であり、業務やデータ構造を変えるかどうかとは別の判断です。選択肢は、現行をそのまま移す、クラウド前提で作り直す、SaaSやERPの標準機能に業務を寄せる、の3つに整理できます。

選択肢	減るもの	増えるもの	向く状況
そのまま移す	OSや機器の保守、初期の仕様変更	クラウド運用設計、接続・性能の検証	保守期限が迫り、まず基盤リスクを外したい
作り直す	古い技術への依存、変更しにくい構造	現行調査、再実装、データ変換、受入テスト	事業変更を妨げる構造まで解消したい
標準機能に寄せる	独自コード、将来の個別保守	業務変更、教育、例外の扱いに関する合意	独自性が低い業務を共通化したい

そのまま移す方法は、一般にリホストと呼ばれます。アプリケーションの変更を抑えられるため、短期的には移行範囲を限定できます。一方で、古い構造や複雑な運用は残ります。接続やバックアップ方法をクラウド上で再設計する作業も必要です。保守切れへの緊急対応には有効ですが、その後に改修しなければ、技術的な負債の置き場所を変えただけになります。

作り直す方法は、クラウドのマネージドサービスや自動拡張を前提に構成を変えられます。サーバー管理を減らし、機能変更を小さく出しやすくなるのが利点です。その代わり、画面、権限、バッチ、通知、外部連携を再現する範囲が増えます。データ形式も変換し、「新基盤で動いた」ではなく「同じ入力から同じ業務結果が出た」ことを確かめます。

標準機能に寄せる方法は、SaaSやERPが持つ業務フローを採用します。独自開発を減らせるため、製品更新への追従と保守を軽くできます。ただし、減るのは実装であり、意思決定ではありません。例外処理を廃止するのか、設定で吸収するのか、外部に残すのかを業務部門が決めます。重要な統制や顧客対応を捨てると、稼働後に手作業として復活します。

選定では、機能の一致率だけでなく、移行後に誰の仕事が変わるかを並べます。基盤保守を減らす代わりにクラウド費用の監視が増える、独自機能を減らす代わりに現場教育が増える、といった交換関係を見るためです。保守期限だけが課題ならそのまま移し、変更速度まで改善したいなら作り直し、独自性の低い業務なら標準機能へ寄せる、という順で目的に合わせます。可逆性も重要な判断材料です。先にそのまま移して期限のリスクを外し、安定後に領域ごとに作り直す二段階の計画も取れます。3択を全社で一つに統一せず、業務領域ごとに組み合わせることもできます。

ERP・基幹システムのときに変わること

ERPや基幹システムでは、会計、在庫、受発注が同じデータを別の時点で使います。そのため、画面単位ではなく、受注から出荷、請求、入金、仕訳までの一連の業務で移行範囲を決めます。受注だけ新しくしても、在庫引当や会計連携の時刻が変われば、在庫数や売上計上の結果がずれるためです。

さらに、月次の締め処理、棚卸し、決算期が切替日を制約します。締めの途中で新旧をまたぐと、どちらが正しい残高を持つか説明しにくくなります。移行計画には、未出荷の注文、未消込の入金、計上前の伝票をどちらで完了させるかを記載し、期首残高と移行後残高を照合します。並行稼働をする場合も、どちらを正本とするかを期間ごとに固定します。

標準機能へ寄せる判断にも業務側の参加が欠かせません。経理の統制、倉庫の締め時刻、営業の例外承認は、情報システム部門だけでは変更できないからです。繁忙期と決算期を避け、業務責任者が残高・数量・伝票を承認できる日から逆算して切替を置きます。

商品、取引先、勘定科目などのマスターデータも、移行直前のコピーだけでは足りません。新旧でコード体系を変えるなら、対応表の承認者と、切替後にマスターを更新できる側を決めます。内部統制上の証跡が必要な業務では、承認履歴と操作ログが移ったかも受入条件です。機能テストに加えて残高照合と統制確認を置く点が、単独システムの移行と異なります。

進め方8段階

システムリプレイスの進め方は、現状分析から評価までを順に進む5〜7段階のリニア工程として説明されるのが一般的です。実務では、意思決定を曖昧にしないため、予算確保を独立させた次の8段階で進めます。

1. 現状分析

2. 目的設定

3. 予算確保

4. 要件定義

5. ベンダー選定

6. 移行計画

7. リハーサルと本番移行

8. 移行後評価

各段階には、次工程へ進むための確認条件を置きます。日付だけの計画では、未確認事項が本番へ持ち越されます。

現状分析から要件定義まで

現状分析では、画面や機能の一覧だけを作りません。利用者、入力元、出力先、例外処理まで確認します。具体的には、通常時と繁忙時の操作を現場で観察します。

「誰が何を見て判断するか」まで記録するためです。目的設定では、置き換え後の成功条件を決めます。成功条件は、「新しくする」では測れません。

「現行業務を維持する範囲」と「変える範囲」を分けます。予算確保では、初期開発費だけでなく、現行調査、データ移行、並行稼働、教育、移行後の安定化までを対象にします。稟議では、更新の重要性だけでなく、リプレイスは新規構築より難しく、現行業務の再現と移行に不確実性があることも経営層と共有します。

経営層、情報システム部門、業務部門が「なぜ今行うか」「何を守るか」「どの停止リスクを受け入れるか」に共通認識を持つことが、全社の優先順位をそろえる条件です。要件定義では、機能要件と非機能要件を整理します。権限、性能、監査、バックアップ、運用体制も対象です。

さらに、データの移行条件と受入条件を合意します。重要なのは、要求を一覧にすることだけではありません。要件と業務目的の対応関係を残すことが重要です。

ベンダー選定と移行計画

ベンダー選定では、提案機能の多さだけを比べません。現行調査、移行、検証の進め方を具体的に確認します。候補を広く調べる段階ではRFI（情報提供依頼書）を送り、対応可能な範囲、移行経験、体制の情報を同じ形式で集めます。

候補を絞った後はRFP（提案依頼書）に目的、対象範囲、要件、制約、評価基準を記載し、同じ前提で提案を比較します。RFIは、候補各社が同じ粒度で回答できる欄を用意します。自由記述だけにすると、製品紹介の詳しさと移行能力を混同するためです。たとえば、次のように依頼内容と回答形式を対にします。

RFIの欄	記入する内容	回答してもらう形式
対応範囲	現行調査、設計、データ移行、教育、稼働後支援のうち依頼候補を示す	対応可・協力会社対応・対象外
類似移行	業種名ではなく、連携数、データ種別、停止制約が近い実績を求める	規模、方式、担当範囲、結果
実施体制	必要な役割と発注側に求める参加を尋ねる	役割、人数、参加時期、責任者
制約への対応	停止可能時間、利用環境、監査条件を提示する	対応方法、前提、未対応事項

RFPでは、提案の前提をさらに固定します。「受注業務を刷新する」ではなく、対象画面と連携先、移行するデータ期間、稼働を止められない時間帯を記載します。要件には優先度を付け、必須、代替案を許容、将来対応のいずれかを示します。受入条件には「データが移ること」だけでなく、件数と合計値が一致する、代表的な例外処理を完了できる、権限外の利用者が閲覧できない、といった判定可能な結果を書きます。価格欄も総額だけを求めず、現行調査、再現、変更、データ移行、テスト、教育、安定化支援に分けます。前提外の事象が見つかった場合の見積変更手順も記入対象です。評価基準には、要件適合、移行・検証方法、体制、価格の配点を先に示します。これにより、各社が異なる範囲を含めたまま総額だけを比較する事態を避けられます。「不明な仕様をどう発見するか」を質問すると差が見えます。

また、障害時の責任分界と連絡経路も確認します。AIプロダクト開発では、実装前の検証方法も選定材料になります。重要な連携や性能に不確実性があれば、PoC（概念実証）で小さな実データと操作シナリオを使い、応答時間、再現率、エラー処理を実測します。

PoCの合否基準とデータ条件を先に渡し、説明の巧さではなく測定結果を選定材料にします。発注範囲は、成果物と意思決定の担当まで明文化します。開発の契約形態も、変更の多さに合わせて選びます。

移行計画では、対象、順番、判定者、戻し方を決めます。特に、「誰が切替可能と判断するか」を曖昧にしません。データは、抽出、変換、投入、照合の流れで管理します。

移行前に重複、表記揺れ、欠損、不要データをクレンジングし、新旧の項目・コード・型を対応表にして変換します。本番投入前にはテスト環境へ複数回投入し、件数、合計値、代表レコード、業務処理後の結果を現行と照合します。そして、エラー時の保留方法も計画に含めます。

リハーサル・本番移行・評価

本番前のリハーサルは必須であり、本番と同じ手順で実施します。正常系だけでなく、失敗時の連絡と復旧も試します。たとえば、データ投入が止まった場面を想定します。

担当者は、継続か切り戻しかを手順どおり判断します。本番移行では、作業記録と判定記録を同時に残します。口頭判断だけでは、問題発生時の起点を追えません。

移行後は、技術面と業務面の両方を評価します。エラーがないだけでは、業務が移ったとはいえません。利用者の処理時間や例外対応の変化も確認します。

未完了事項は、保守作業と改善作業に分けて管理します。利用者トレーニングは本番直前の説明会だけで終えず、役割別の操作教材、実データに近い演習、問い合わせ窓口を用意します。稼働後は利用率、処理時間、問い合わせ内容を追い、つまずく操作には追加教育や画面改善を行って定着を支援します。

利用者への教育と、移行後の問い合わせ

教育は、本番切替の14日前を告知の基準日とし、対象者と変更点を知らせ、遅くとも3営業日前までに役割別の教材を渡す流れで設計します。業務の複雑さや勤務形態に応じて前倒しします。日常的に操作する利用者には、変更点を絞ったマニュアルと実データに近い操作会を用意します。承認者には、承認経路と例外時の判断を示します。管理者と問い合わせ担当には、権限設定、障害との切り分け、エスカレーション先まで渡します。

移行直後は問い合わせが集中する前提で、一次受付、業務判断、技術調査の担当を分けます。受付窓口を一つにし、質問、利用者の役割、発生画面、緊急度、回答を記録します。同じ質問が続いたら個別回答だけで終えず、マニュアルの該当箇所、画面表示、操作会の内容のいずれを直すかを決めます。切替後の最初の営業日に窓口担当と開発・運用担当がログを確認できる時間を確保します。

工程別チェックリスト

工程	確認すること	完了の証拠
1. 現状分析	利用者、入力元、出力先、例外処理を洗い出したか	現行の業務フローと機能一覧
2. 目的設定	何をもって成功とするかを一文で決めたか	目的・対象範囲の合意記録
3. 予算確保	調査、移行、教育、安定化を含めたか	稟議承認と予算枠
4. 要件定義	機能、非機能、データ、受入条件を合意したか	要件一覧と承認記録
5. ベンダー選定	RFI/RFPとPoCを同一基準で評価したか	評価表と実測結果
6. 移行計画	連携、データ変換、停止、切り戻しを決めたか	移行・ロールバック手順
7. リハーサル・本番移行	本番同等条件で照合し、判定者を置いたか	リハーサル記録と移行判定
8. 移行後評価	業務結果と利用状況を確認したか	KPI、問い合わせ、改善一覧

失敗の型は3つ

失敗の主因は、要件定義の甘さと現場の不参加だと広く整理されています。「要件定義を丁寧にやれば失敗しない」という考えは妥当です。要件定義が粗ければ、完成条件を共有できないためです。

ただ、丁寧な要件定義でも拾えないものが一つあります。画面と画面のあいだにある、書かれていない業務ルールです。暗黙の判断は、通常の機能一覧に現れません。そのため、文書確認に現場観察を組み合わせる必要があります。

失敗の型	起きること	予防策
目的が曖昧	要求の優先順位が揺れる	成功条件と変えない範囲を合意する
現場の声と書かれていない業務ルールを見落とす	画面間の判断や例外処理が消える	観察と受入確認に利用者を入れる
既存システム間の連携を見落とす	データが届かず後続業務が止まる	連携台帳と疎通・異常系テストを作る

目的が曖昧なまま進む

目的が曖昧だと、すべての要望が同じ重さになります。すると、判断のたびに納期や対象範囲が揺れます。目的は、「保守期限に対応する」だけでは足りません。

業務で守る結果まで、成功条件に含めます。たとえば、「受注後の確認手順を維持する」と定めます。さらに、今回変えない範囲も合意します。

変更対象が明確なら、追加要望を別の改善として扱えます。

現場の声と仕様書に無い業務ルールを見落とす

管理者だけで要件を決めると、画面と画面のあいだにある例外処理が抜けます。現場は、入力欄の表示を見て連絡順を変えるなど、日々の判断でシステムの不足を補っています。「この表示なら先に倉庫へ聞く」といった確認順は現行業務の成立条件ですが、仕様書には画面項目しか残っていない場合があります。新システムが仕様どおりでも、業務結果が変わる原因です。発見するには、利用者へ完成案を見せるだけでなく、画面をまたぐ一連の操作を再現してもらいます。通常処理に加えて取消や保留も追い、「何を操作したか」と「なぜそうしたか」を対で記録します。現場参加は要望収集ではなく、業務条件の発見です。実装工数が縮んでも、この観察は省けません。

既存システム間のデータ連携を見落とす

既存システム間の連携を確認しないと、単体では正常でも後続業務が止まります。画面に見えるAPIだけでなく、夜間バッチ、ファイル転送、メール添付、担当者の手入力も連携として洗い出します。連携台帳には、送信元、送信先、項目、頻度、締め時刻、エラー時の再送担当を記録します。

本番前には正常系の疎通だけでなく、遅延、重複、欠損、送信失敗を起こし、業務が継続または復旧できるか確認します。

費用の構造：見積もりの大半は「同じ動きの再現」

同じ「リプレイス」でも、現行の調査範囲と並行稼働の有無で規模の桁が変わるため、一律の実額レンジは自社の判断材料になりません。ここでは金額そのものではなく、見積もりを動かす変数と、費用が生じる構造を示します。システムリプレイスでは、新機能だけに費用がかかるわけではありません。大きな部分を占めるのは、現行と同じ動きの再現です。

画面、権限、計算、通知、例外処理を作り直すためです。利用者には変化がなくても、内部では再実装が発生します。

何が金額を動かすか

金額を動かす変数は、対象範囲と不確実性です。画面数だけでなく、画面間の分岐が工数に影響します。データ量より、変換ルールの複雑さが効く場合もあります。

外部連携、権限の細かさ、停止可能時間も変数です。さらに、現行仕様の残り方が調査工数を左右します。「画面と挙動が仕様として残るか」が重要です。

この記事の発信元であるARCHECO（自社でECプロダクトを開発・運営している）のリポジトリには、DBスキーマの変更が188回残っています。これはリプレイス案件の件数ではありませんが、動く仕様を確定し、同じ結果を保証するために何が起きるかを変更履歴から確認できます。

一つ目は料金表の設計です。12地帯×12地帯×8サイズ、1,152セルの料金表を作り、空港料金だけを独自テーブルへ切り出しました。その後、実データ1,416セルを照合すると、空港料金はすべて「地上料金＋固定額」で導出でき、例外は0件でした。最初の変更から74分後、独自テーブルという設計判断ごと削除し、料金を計算で求める構造へ戻しています。必要だったのは、1,416セルで同じ結果になると確かめ、不要な構造を捨てる判断でした。

二つ目は、注文完了通知です。同じ機能を2人が別々に実装した結果、通知を送るデータベーストリガーが2系統できました。両方が適用されると、顧客は1注文につき通知を2回受け取ります。重複した変更ファイルを消すだけでは、すでに適用済みのデータベースからトリガーは消えません。そのため、既存のトリガーを明示的に削除する変更を追加し、通知経路を一つへ収束させました。

三つ目は、料金データの洗い替えです。新しい料金へ置き換えた後も旧世代が66行残り、同じ経路・同じサイズに二つの料金が存在していました。検索結果の先頭を使う実装では、どちらが返るか決まりません。重複を削除したうえで、経路とサイズの同じ組み合わせを二度登録できない一意制約を追加し、再発を止めました。

3件に共通するのは、新機能ではなく、計算結果、通知回数、料金検索という期待される動きを一つに定め、既存状態との差分を解消し、再発防止の制約を置いたことです。リプレイスでも費用が集まりやすいのは、この「同じ結果になることを調べ、移し、保証する」部分です。見積時には、再現、変更、調査を分けて確認します。

Fit to Standardでも再現コストはゼロにならない

Fit to Standardは、製品の標準機能を優先し、個別の作り込みを最小化する考え方です。標準へ業務を合わせられる範囲では、独自機能の再実装と将来の保守費を減らせます。一方、法令、契約、顧客対応、競争優位に直結する業務まで標準へ合わせると、業務結果を損なう場合があります。

そこで現行の動きを「標準へ合わせる」「設定で再現する」「追加開発する」「廃止する」の4層に分け、理由と承認者を残します。作り込みを減らしても、データ移行、外部連携、権限、例外処理の確認は残るため、再現コストは層ごとに見積もります。

AIで再現実装の工数が縮み始めた

AIが得意なのは、参照できる正解がある実装です。現行の画面と挙動が残っていれば、再現条件になります。AI受託開発では、人手で数か月の画面作り直しが、検証込みで週単位まで縮み始めています。

ただし、AIが正解を決めるわけではありません。現行と同じかを、人が業務結果まで検証します。実装が安くなるほど、調査と受入確認の比重は上がります。

特に、書かれていない業務ルールの言語化は縮みません。ここが、リプレイスにおける見積もりの新しい本体です。AIでの再現実装の中身はこちらで確認できます。

プロジェクトチームをどう立ち上げるか

責任者は、予算と優先順位を決められる業務側の役職者に置きます。情報システム部門は技術、データ、既存連携を管理し、業務部門は業務要件と受入判定を担います。ベンダーは設計・実装・移行の実行責任を持ちますが、業務上の最終判断は発注側に残します。

立ち上げ時に、各成果物の作成者、承認者、相談先、報告先を一枚にします。兼任してもよい一方、「全員で決める」は避け、範囲・費用・本番可否ごとに一人の決定者を置きます。

運営ルール（役割分担・承認の期限・週次レビュー・エスカレーション）

役割表だけでは案件は動きません。承認依頼への回答期限、週次で確認する指標、期限超過時の上位相談経路を決めます。課題は担当者、期限、次の行動を必須項目にし、口頭の宿題を残しません。

週次レビューでは進捗率より、未決事項と本番日への影響を先に確認します。期限内に決められない論点は、選択肢と影響を整理して責任者へ上げます。

進捗管理と課題管理

進捗は作業の完了、課題は完了を妨げる事象として分けます。「対応中」だけでは遅延を発見できないため、成果物の完了条件と証拠を定めます。課題台帳には発生日、影響工程、責任者、期限、暫定策、恒久策を記録します。

実務では、予定との差だけでなく、未決課題がクリティカルパスへ入った日を見ます。赤信号になってから報告するのではなく、期限までに決定者が不在なら自動的に上位へ相談します。

スケジュールに余裕を持たせる

余裕は全工程へ均等に足すのではなく、不確実性が高い箇所へ置きます。現行仕様の調査、データ変換、外部連携、本番判定には手戻りが起きやすいため、再試験できる日を確保します。

予備日を通常作業で先に使い切らないよう、利用条件を責任者が管理します。締め日や繁忙期から逆算し、本番延期を判断できる最終期限も計画へ入れます。

移行計画書に何を書くか

移行計画書には、少なくとも次を記載します。

1. 移行の目的と対象範囲

2. 対象データ・機能・利用者

3. 新旧システムの正本を切り替える時点

4. 抽出・変換・投入・照合の手順

5. 作業日程と停止時間

6. 担当者・承認者・連絡網

7. テストと受入条件

8. リハーサルの回数と合否基準

9. 障害時の切り戻し条件と手順

10. 利用者への告知・教育・問い合わせ窓口

11. 稼働直後の支援と保守への引き継ぎ

各項目には文書名だけでなく、判定者と完了の証拠を添えます。本番当日に判断を増やさないことが計画書の役割です。

テストの種類（単体・結合・システム・受入）

単体テストは一つの機能や部品が仕様どおり動くか、結合テストは部品や外部システム間の受け渡しが正しいかを確認します。システムテストは全体として性能、権限、障害時の動作を含めて確認し、受入テストは業務部門が実際の業務結果を満たすかを判定します。

同じ操作を四回繰り返すのではありません。各段階で検出したい不具合と合格証拠を変え、受入テストには通常処理だけでなく取消、保留、締め処理を含めます。

非機能要件（可用性・RTO／RPO・監視）

非機能要件は、機能以外の「どの状態で使えるべきか」を定めます。可用性は必要な時間に使える度合いです。RTOは障害から業務を復旧させるまでの目標時間、RPOはどの時点までのデータを復元できればよいかという目標です。監視では異常を何で検知し、誰へ通知するかを決めます。

「止まらないこと」ではなく、業務ごとに許容停止時間と許容できるデータ損失を業務側が答えます。復旧手順は資料確認だけで終えず、リハーサルで所要時間を測ります。

品質保証の方針と業務継続性

品質保証では、誰がどの基準で成果物を検査し、不合格をどう戻すかを決めます。業務継続性では、停止時に代替手段で続ける業務、止める業務、復旧を優先する順番を定めます。

不具合件数だけで品質を測らず、残高一致、権限制御、締め処理など業務上失えない結果を重要品質項目にします。障害訓練では、連絡網と手作業の代替手順も実際に通します。

契約形態（準委任と請負）

準委任は、専門家が一定の注意をもって業務を遂行する契約で、調査や要件整理など途中で内容が変わりやすい工程に向きます。請負は、合意した成果物を完成させる責任を負う契約で、範囲と受入条件を明確にできる工程に向きます。

契約名だけでリスクは決まりません。成果物、変更手続き、検収条件、発注側が担う判断を工程ごとに明記し、調査は準委任、確定範囲の実装は請負のように分ける選択も検討します。

相見積もりで相場を掴む

相見積もりは、候補を三社程度に絞り、同じRFP、データ量、連携範囲、停止条件、保守範囲を渡して比較します。社数を増やして前提が違う提案を集めても相場は見えません。

総額だけでなく、現行調査、設計、再現、変更、移行、テスト、教育、稼働後支援の内訳と除外事項を揃えます。差が大きい項目は安い方へ合わせず、想定作業が抜けていないか質問します。

工程ごとの費用配分

費用配分は案件固有ですが、初期の比較表では総額を100%として、現行調査・要件定義、設計、実装、データ移行、テスト、教育・安定化の六工程へ配分します。たとえば仮置きとして15%、15%、25%、15%、20%、10%と置き、各社の見積差を可視化します。これは相場ではなく、抜けを発見するための比較基準です。

「同じ動きの再現」は実装欄だけに現れません。調査、変換、照合、受入にも分散するため、再現に関係する作業へ印を付けて合計します。比率が変わった理由を説明できることが重要です。

保守運用費——動き出した後に毎月かかるもの

稼働後には、利用料、クラウド資源、監視、問い合わせ対応、障害対応、更新、バックアップ、セキュリティ対応が継続します。費用を動かすのは利用者数、処理量、保存量、連携数、監視時間、求める復旧水準、個別改修の多さです。

初期見積と同じ範囲で、定常保守と改善開発を分けます。月次レビューでは金額だけでなく、問い合わせ件数、障害、容量増加、未適用更新を確認し、翌期の費用要因を早めに捉えます。

TCO（総所有コスト）を評価軸に入れる

TCOは総所有コスト、つまり導入から廃止までに組織が負担する費用の合計です。初期開発費だけでなく、利用料、運用、教育、連携改修、障害対応、契約終了時のデータ取り出しまで含めます。

比較期間と対象費目を揃え、新旧システムの両方を同じ表へ載せます。安価な初期提案でも、手作業や個別連携が残るなら社内工数を含めて評価します。

費用対効果をどう見るか

効果は削減時間だけではありません。停止リスクの低下、処理の短縮、誤りの減少、監査証跡、変更の速さに分けます。費用側には初期費用、継続費、移行中の二重運用、現場参加の工数を含めます。

稟議では、効果ごとに測定方法、基準値、確認時期、責任者を決めます。金額換算しにくいリスク低減は無理に一つの額へ変えず、発生可能性と影響、代替策で比較します。

止める時間を事前に知らせる

停止告知には、開始・終了予定、影響する業務、利用できない機能、停止前に終える作業、代替手段、再開確認の方法、問い合わせ先を書きます。全社一斉メールだけでなく、夜勤、拠点、取引先など影響を受ける相手ごとに届けます。

一度知らせて終わらず、事前告知、直前確認、開始通知、再開通知の順に行います。終了が遅れる場合の次回連絡時刻も先に決めます。

ハイパーケア（稼働直後の張り付き）と定期保守

ハイパーケアは、稼働直後に業務・情報システム・ベンダーが通常より厚い体制で監視と問い合わせ対応を行う期間です。一次受付、業務判断、技術修正を同じ時間帯にそろえ、重大度別の応答目標を決めます。

終了条件は日付だけでなく、重大障害がない期間、問い合わせの減少、未解決課題の引き継ぎ完了で判断します。その後は定期保守へ移し、更新、容量、障害傾向、改善候補を月次または四半期で確認します。

稼働後の改善を回し続ける

本番稼働は完了ではなく、実利用から改善を始める地点です。問い合わせ、操作ログ、処理時間、例外処理を集め、不具合、教育不足、業務設計、追加要望に分類します。

改善候補には効果、影響範囲、緊急度、責任者を付け、定期レビューで着手順を決めます。緊急修正と機能改善を同じ列で扱わず、保守契約と改善予算のどちらで行うかも明確にします。

失敗した案件で何が起きたか

一般的な失敗は、一つの大事故ではなく小さな未決事項の連鎖です。業務責任者が不在のまま要件が確定し、移行対象の例外データが遅れて見つかり、受入テストが短縮され、本番後に手作業が増えます。個々の工程が「ほぼ完了」でも、判断の先送りが本番へ集まります。

他社の実案件を自社の経験として転載せず、原因を構造で捉えます。振り返りでは「誰が悪かったか」ではなく、未決事項を検知した時点、決定者、止める条件が機能したかを確認します。

リプレイスの実務論点

計画、契約、品質、費用、稼働後の運用は、方式を決める段階でまとめて確認します。

この記事では、戻せる単位の設計を語ります

ここまでがシステムリプレイスの教科書です。この記事では、工程の一般論ではなく、段階移行を戻せる単位で設計する実務を語ります。

段階移行とロールバックの実務

段階移行は、影響範囲を分けて確認しながら進められる有効な方式です。業務を一度に切り替えられない案件では、特に大きな意味があります。

段階移行は、単に少しずつ公開する方法ではありません。確認できる範囲と、戻せる範囲を一致させる設計です。新旧の境界を決め、業務結果を照合しながら進めます。

188回のスキーマ変更で学んだ移行の順番

同じ開発記録の対象は、1年運営したEC事業です。開発記録には、DBスキーマ変更が188回残っています。実務で確立した順番は、画面・業務の単位から始まります。

まず、現行の入力と出力を再現できる範囲を切り出します。次に、その範囲を作り直し、現行と並行稼働させます。そして、データと業務結果が一致するかを確認します。

確認が取れた範囲だけを、新システムへ切り替えます。データ構造を先に大きく変えると、戻す範囲も広がります。そのため、変更は業務境界に沿って小さく保ちます。

スキーマ変更の回数は、迷走の回数ではありません。戻せる変更単位を維持し、学習を反映した記録です。

ロールバック設計と並行稼働

ロールバックの原則は、「戻せる単位でしか進めない」です。切替前に、戻す対象と判断条件を定めます。コードだけ戻しても、更新済みデータは残ります。

そこで、データを戻すか、再処理するかも決めます。並行稼働では、同じ入力に対する結果を照合します。差分が出たら、不具合か業務ルールかを切り分けます。

「差があるから新側が誤り」とは限りません。現行側の手作業が、差を生んでいる場合もあります。切替判定には、技術担当と業務担当の両方が参加します。

障害の有無と、業務を完了できるかを別々に見ます。ロールバックは保険ではなく、移行範囲を決める設計条件です。

まとめ：止められる業務かという問いへ戻る

冒頭の移行方式は、システムの規模ではなく、業務をどこまで止められるかで選びます。現行の例外を言語化し、確認できる範囲と戻せる範囲を一致させることが、移行方式、費用、テストを一つにつなぐ判断軸です。

この先：実装より受入判断の比重が上がる

再現実装の工数が縮むほど、現行業務の調査と受入判断の比重は上がります。移行は一度の切替ではなく、業務単位で照合しながら更新する運用へ近づきます。発注側には、何を残し、何を標準へ合わせるかを決める責任がより強く求められます。

よくある質問

システムリプレイスとは何ですか？

既存システムを新しい仕組みに置き換える取り組みです。対象は基盤だけでなく、画面やデータ、業務手順まで含みます。単なる製品交換ではなく、業務をどう引き継ぐかを設計する活動です。判断基準は古いかどうかではなく、事業を支え続けられるかどうかです。

マイグレーションとの違いは何ですか？

マイグレーションはデータや環境を移す行為で、リプレイスはシステム全体の置き換えです。多くのリプレイスは工程内にマイグレーションを含みますが、データが移ったことと業務が動くことは異なる完了条件です。

進め方の手順を教えてください。

現状分析、目的設定、予算確保、要件定義、ベンダー選定、移行計画、リハーサルと本番移行、移行後評価の8段階です。各段階には次工程へ進む確認条件を置きます。

移行方式はどう選びますか？

一括、段階、並行、パイロットの4方式があります。業務を止められるなら一括、止められないなら段階か並行を軸にし、二重管理の許容度と業務を分ける境界も確認します。

費用相場はどのくらいですか？

一律の実額ではなく、再現・変更の範囲、調査の不確実性、外部連携、データ変換、停止条件で考えます。並行稼働、教育、稼働後支援の範囲も金額を動かします。

期間はどのくらいかかりますか？

期間を動かすのは、意思決定の速さ、連携先の数、データ品質、受入テストに参加できる利用者、停止可能な時期です。現行仕様が残っていても、暗黙の業務ルールには観察と合意が必要です。

失敗する原因は何ですか？

目的が曖昧なまま進むこと、現場の声と仕様書に無い業務ルールを見落とすこと、既存システム間の連携を見落とすことの3つが型です。最大の地雷は、画面と画面のあいだにある書かれていない判断です。文書確認だけでなく、取消や保留を含む一連の操作を現場で観察します。

実施のタイミングは5年ごとですか？

5年という目安の根拠の一つは、国税庁の減価償却上、一般的なソフトウエアの法定耐用年数が5年とされていることです。ただし会計上の年数であり、5年で必ず交換するという技術基準ではありません。製品の保守期限、改修速度、障害影響に加え、繁忙期と社内変更の時期も重ねて判断します。

ベンダーに任せてよいですか？

実装と移行作業は任せられますが、業務判断は委ねられません。現場だけが知る例外処理の発見には、発注側の参加が必要です。ベンダーには観察方法と確認手順を提案してもらい、発注側は成功条件と切替可否を判断します。役割分担を明確にすれば、専門性を活用しやすくなります。

費用の大半は何に使われるのですか？

新機能ではなく、現行と同じ動きの再現に使われます。画面、権限、計算、通知、例外処理を作り直すだけでなく、移行後も同じ結果になることを照合するためです。ARCHECOの自社ECの変更履歴でも、料金計算、通知回数、料金データの一意性を保証するため、設計の撤回、適用済みトリガーの削除、一意制約の追加が必要でした。見積時には、再現、変更、調査を分けて確認します。

マイグレーションとリプレイスはどちらを先に進めますか？

先にリプレイス後の業務とデータ要件を決め、その要件に沿ってマイグレーションを設計します。データを先に移すと不要な項目まで引き継ぎやすいため、「何を残すか」と「どう移すか」を分けて判断します。ただし、移行可能性の調査は要件定義と並行して進められます。現行の動きを崩さずに作り直すところから、ARCHECOは請けています。AI受託開発（バイブコーディング）の詳細を確認し、お問い合わせからご相談ください。