6.2移行方式と移行計画

新システムへの移行は、機能開発と同じくらい移行そのものの設計が重要です。システムアーキテクトは、業務が許容できる停止時間・リスク許容度・予算という制約から移行方式（一斉/段階/並行）を選び、失敗時に安全に戻れる切り戻し手順まで含めて移行計画を立てることが求められます。移行方式の選定を誤ると、本番切替の失敗が事業に直接的な損害を与えることになります。

6.2.1一斉移行・段階移行・並行移行

• 一斉移行（big-bang）＝ある期日に旧システムを停止し、新システムへ一気に切り替える方式。移行期間が短く済み、旧新を同時に維持するコスト・複雑さがない利点があるが、切替直後に問題が発覚すると業務全体が影響を受け、切り戻しの難度も高いハイリスク・ハイリターンな方式。
• 段階移行＝対象（拠点・部門・機能単位等）を分割し、一部ずつ新システムへ切り替えていく方式。問題が起きても影響範囲を限定でき、初期の段階で得た教訓を後続の移行に反映できるためリスクは低いが、旧新両システムが混在する期間が長く、両者を接続する暫定的な連携（データ同期等）の構築・保守コストがかかる。
• 並行移行＝旧新システムを一定期間、同時に本稼働させ、両者の出力を突き合わせて新システムの正しさを検証してから旧システムを停止する方式。最も安全でリスクが低いが、同じ処理を二重に運用するコスト（人手・インフラ）が最大になる。金融・会計など誤りが許容できない基幹系でよく採られる。

6.2.2データ移行・リハーサル・切り戻し・Go/No-go

• データ移行は抽出→変換（旧新のデータ形式・コード体系の差異を吸収）→新システムへの投入→件数/整合性の検証という手順で進める。特に変換ロジックの誤りは移行後に業務データの不整合として顕在化しやすいため、本番データに近いテストデータでの事前検証が欠かせない。
• リハーサル＝本番切替と同じ手順・同じ規模のデータで事前に移行作業そのものを試行し、所要時間の見積りや手順の不備を洗い出す活動。切り戻し（ロールバック）＝移行後に致命的な問題が発覚した場合に旧システムへ安全に戻す手順で、切り戻し可能な時間的猶予（判断のタイムリミット）をあらかじめ決めておくことが重要（新システムでのデータ更新が進みすぎると切り戻しが困難になるため）。
• Go/No-go判断＝リハーサル結果・データ検証結果・関係部門の準備状況等を踏まえ、予定通り本番切替を実施するか延期するかを移行直前に最終判断する活動。判断基準（何が満たされればGoか）を事前に明文化しておくことで、当日の場当たり的な判断を避けられる。

あるシステムアーキテクトが、24時間365日稼働が必須の決済基幹システムを新システムへ移行する計画を立てるとします。まず移行方式を検討する段階で、一斉移行は切替直後に問題が発覚した場合、決済という事業の生命線が全面停止するリスクが大きすぎるため候補から外します。段階移行も、決済処理は一部の取引だけ新システムに切り替えるという分割が業務上困難（取引の整合性を保つには全体を同じシステムで処理する必要がある）なため不適切と判断します。最終的に、旧新両システムを一定期間同時稼働させ、同一の取引を両方に流して結果を突き合わせる並行移行を選択します——二重運用のコストは大きいものの、決済という誤りが許容できない領域では最も安全な選択だからです。次に移行計画として、本番切替の1か月前に本番相当のデータ量でリハーサルを実施し、データ変換に想定より時間がかかることが判明したため、変換処理をバッチ分割し並列実行する改善を加えます。切替当日については、新システムへのデータ投入から2時間以内に検証が完了しなければ切り戻すという判断基準（切り戻しのタイムリミット）を事前に定め、経営層・業務部門・開発チームの代表者が参加するGo/No-go判断会議を切替直前に設定し、リハーサル結果とデータ検証結果を基準に最終決定を行う体制を整えます。このように、業務が許容できるリスクと停止時間から移行方式を選び、リハーサルと切り戻し基準、Go/No-go判断まで一体で計画するのが実務です。

6.2.3この節のまとめ

• 一斉移行＝短期間だがハイリスク、段階移行＝影響限定だが混在コスト増、並行移行＝最安全だが二重運用コスト最大
• データ移行は抽出→変換→投入→検証、本番相当データでのリハーサルで手順・所要時間を事前検証
• 切り戻しの判断タイムリミットを事前に決め、Go/No-go判断の基準を明文化して当日の場当たり的判断を避ける