段階移行の単位と順序を決める
一括での全面切り替えはリスクが高いため、多くの刷新では業務やデータの塊を単位として、リスクの低い順に段階移行します。たとえば参照系から先に移す、影響範囲の小さい周辺業務を先行させる、繁忙期を避けて切り替える、といった設計が基本です。単位の切り方は現行システムの依存関係に左右されるため、現行調査で把握した連携構造をもとに、安全に分割できる境界を見極めます。順序を誤ると後戻りが効かなくなるため、要件定義での慎重な設計が重要です。
基幹刷新・レガシー脱却 / 工程5 要件定義・進め方整理
業務を止めずに移すための段階移行計画をつくりたい
刷新の方針が固まったら、次は「どの順序で・どうデータを移し・どう切り替えるか」を具体化する要件定義です。基幹システムは業務の根幹を担うため、移行で一日でも止まれば現場に大きな影響が出ます。だからこそ、段階移行の単位、データ移行の手順、新旧並行稼働の期間と方法を丁寧に設計する必要があります。このページでは、業務を止めずに移すための移行計画の組み立て方を整理します。
段階移行計画の要件定義を相談するデータ移行とクレンジング
刷新で最も事故が起きやすいのがデータ移行です。長年の運用で蓄積したデータには、重複・表記ゆれ・欠損・もう使われていない項目が混在していることが多く、そのまま移すと新システムで不整合を起こします。要件定義では、移行対象データの範囲、クレンジングの方針、変換ルール、移行後の検証方法を定義します。どこまで過去データを移すか、移行できないデータをどう扱うかも、業務側と合意して決めておく必要があります。
並行稼働と切り替えの設計
新システムへ一気に切り替えるのが不安な場合、一定期間は新旧を並行稼働させ、結果を突き合わせて検証する進め方があります。並行稼働は安全性を高める一方、二重運用の負荷がかかるため、期間と範囲を絞ることが大切です。要件定義では、切り替えの方式（一斉切替か段階切替か）、並行稼働の期間、問題発生時の切り戻し手順まで設計します。GXOでは、業務を止めないことを最優先に、移行単位・データ移行・並行稼働を一体で要件定義し、現実的な移行計画に落とし込みます。
FAQ
よくある質問
Q. 新旧の並行稼働は必ず必要ですか？
A. 必須ではありません。業務の重要度や移行リスクによって判断します。止まると影響が極めて大きい中核業務では、一定期間の並行稼働で結果を突き合わせて安全性を確かめる価値がありますが、影響の小さい業務では一斉切替で済ませることもあります。並行稼働には二重運用の負荷が伴うため、必要な範囲に絞って設計するのが現実的です。
Q. 過去データはすべて新システムに移すべきですか？
A. すべてを移す必要はないことが多いです。法令や業務上の保管義務、参照頻度をふまえ、移行する範囲を決めます。古いデータはアーカイブとして別に保管し、新システムには直近の必要なデータだけ移す、といった切り分けが現実的です。どこまで移すかは業務側と合意のうえ、要件定義で明確にします。
Q. データのクレンジングはどのくらい時間がかかりますか？
A. データの量と汚れ具合によって変動するため、一概には言えません。重複や表記ゆれが多いほど手間がかかります。要件定義の段階で移行対象データの状態を調査し、クレンジングの方針と工数の見立てを示します。早めに着手するほど、移行直前の手戻りを減らせます。