システム刷新の移行計画はどう作る?切替・確認・戻す条件の決め方

システム開発・連携 · 実務ガイド
システム刷新の移行計画はどう作る?切替・確認・戻す条件の決め方
「新システムへ切り替える日に、確認が終わらなければ誰が戻すと決めるのか」。刷新を考える経営者へ、作業の順番と業務確認、続行・復旧の判断を先に決める方法を解説します。
架空の受注管理で、9:00の更新停止から10:30の判断までを整理します。戻す条件と担当、新側へ入力した記録の扱いも残し、関係者へ渡せる切替計画表を作れます。

この記事でできるようになること
- 切替当日の作業と業務確認を、担当と時刻で並べられる
- 続行・保留・復旧を誰が判断するか決められる
- 切替後の更新と戻す場合の照合を別に残せる
01 / システム開発・連携
切り替える日は、どの仕事をいつまで止められる?
業務の締切と代わりの受付方法から、確認と復旧の時間を確保します。

架空の会社が旧受注管理O01から新管理N01へ切り替えます。営業は9:00から入力を止められますが、12:00までに受注を再開したいとします。経営者は切替の作業時間だけでなく、照合、利用者の確認、復旧が必要な場合の時間を含めて計画を読みます。
この教材では、切替中の注文を別の受付台帳へ受け、元の依頼を保管する条件にします。誰が受け、いつどちらのシステムへ登録するかを決めておきます。停止中に営業が勝手に旧側へ入力すると、移したデータと旧記録の間に差ができるためです。
IPAの要件定義資料は、移行や運用の要求も整理する参考です。本稿の時刻と作業は架空の計画で、どの会社でも3時間で切り替えられる保証ではありません。自社の締切、利用量、復旧の実測に合わせ、経営者と業務・技術の担当で条件を決めてください。
営業へ受注を止められる時間と代わりの受付方法を尋ね、計画表の「停止可能時間・受付方法」欄へ記入してください。
この章の根拠:出典1
02 / システム開発・連携
作業を終えたら、どの確認へ進む?
技術側の切替と、業務側の照合・操作確認を別の完了条件にします。

9:00に旧側の更新を止め、技術担当が同じ時点の保存と移行資料を確認する計画です。新側へ移した後、件数と関連資料を照合します。業務担当は架空の注文C088を検索し、数量と納期、担当の役割を確認します。画面が開くことだけでは業務確認は終わりません。
作業表には担当、開始条件、終わったと言える結果を記します。移行作業が終わっても照合が未確認なら、次の利用開始へ進めない条件にします。前の作業を待つ人が、何の回答を受けたら進めるかを読める形にしてください。
最後に業務責任者が、重要な確認の結果と未確認の項目をまとめます。技術担当の「設定は完了」と、営業の「必要な受注が参照できる」は違う判定です。切替の作業者だけに全体判断を任せず、自社の業務を再開する責任者と連絡方法を決めます。
| 段階 | 担当と確認 | 次へ進む条件 |
|---|---|---|
| 9:00/更新停止 | 営業と技術担当/受付台帳へ切替 | 旧側の更新停止を確認 |
| 保存と移行 | 技術担当/同じ時点の保存 | 移行結果を照合へ渡す |
| 照合と操作 | 照合担当・営業・出荷/C088等 | 重要項目の確認結果がそろう |
| 10:30/判断 | 業務責任者/不足と残り時間 | 続行・保留・復旧を記録 |
技術・業務担当へ作業の順番を確認し、「作業順序」欄へ担当・開始条件・完了結果を記入してください。
03 / システム開発・連携
10:30に確認が終わらなければ、誰が決める?
重要な不足と残り時間を見て、業務責任者が判断を記録します。

架空例では、注文の参照、数量の照合、役割の制御を重要な確認とします。10:30時点で重要な項目が未確認なら、未確認を合格へ変えません。業務責任者は技術担当の回答と残り時間を確認し、復旧か、別の受付を続けるかを決めます。
復旧に60分、業務確認に30分が必要だと試行で分かった場合、10:30の判断から12:00まで90分を確保します。これは架空の実測条件です。復旧が可能か、保存資料と担当がそろうかは事前に試します。締切を過ぎてから戻せるだろうと推測しません。
IPAの非機能要求の観点を使い、停止時間と代わりの手順を合意します。続行の判断にも条件を付け、重要項目がそろっていること、通常利用後の確認担当がいることを残します。軽微な不足の扱いも責任者が決め、すべてを同じ「問題あり」表示へまとめないでください。
業務責任者と提供会社へ戻す条件を確認し、「判断」欄へ重要項目・担当・期限・復旧所要時間を記入してください。
この章の根拠:出典2
04 / システム開発・連携
新側で受けた注文は、戻すときどうなる?
切替後の更新を別に保管し、戻す前後で照合する方法を決めます。

初回の判断前は、この例では新側への実注文の入力を始めません。続行を決めた後、新側で6件を受けてから不具合が見つかった場合は別の復旧判断です。9:00の旧記録へ戻すだけでは、新側で受けた6件が欠ける可能性があります。
技術担当は新側の更新範囲を保存し、営業が別の受付台帳と照合する計画を作ります。注文番号、変更時刻、処理状態を確認し、どちらへ何を反映するか責任者が判断します。更新が重複したり、出荷済みの注文を再処理したりしない条件も残してください。
Microsoftの復旧の概念は、戻す時点と停止時間を分ける参考になります。本稿は具体的な復元コマンドを示す教材ではありません。新旧の更新を扱えない場合は、むやみに復元せず、技術担当と業務責任者がデータ保全と再開手順を確認する計画へ戻します。
切替後の注文を記録する担当へ確認し、「更新の保護」欄へ保存先と新旧の照合方法を記入してください。
この章の根拠:出典3
05 / システム開発・連携
本番前に、復旧まで試した計画になっている?
別の試験場所で、作業・確認・担当の連絡を通して測ります。

計画を読むだけでなく、許可された別の試験場所と架空または匿名化された資料で切替を試します。保存、移行、照合、操作確認、復旧の所要時間を担当ごとに残します。切替の成功例だけでなく、照合が合わず戻す場面も試してください。
担当が休みのときの代行、回答が遅れるときの連絡、確認資料の所在も点検します。計画表に担当名があっても、本人が判断条件を読めなければ運用できません。試行で欠けた条件を更新し、同じ版の表を全担当へ渡します。
本番の日時は、関係者の対応、保存と復旧の準備、業務の停止条件を責任者が確認して決めます。試行の結果が自社の期限を超える場合には範囲や手順を見直します。計画表が埋まったことを、本番へ自動的に進む許可と扱わないでください。
技術・業務担当へ復旧までの試行結果を確認し、「試行結果」欄へ時間と不足条件を記入してください。
06 / システム開発・連携
まとめ:切替計画は、順序と戻す判断まで決める
業務の再開時刻から逆算し、担当と更新の扱いを残します。

システム刷新の移行計画は、設定を変える作業だけでは足りません。O01からN01へ移す架空例では、9:00の停止、移行と照合、10:30の判断を分けました。重要な確認が終わらない場合に、誰が復旧や保留を決めるかも計画の一部です。
戻す条件には、所要時間、保存資料、再開前の業務確認を含めます。続行後の新しい注文は、切替前の保存と別に保全して照合します。自社では、業務の期限と技術担当の試行結果を合わせ、記録が欠けない順序を確認してください。
次に、営業へ停止できる時間を、技術担当へ復旧までの試行結果を尋ね、下のメモへ書いてください。業務責任者と重要項目、判断期限、代わりの受付を合意します。未確認があるなら計画を直し、同じ版で関係者が判断できる状態に整えましょう。
営業・技術担当・業務責任者で計画表を照合し、「未確認条件」と「続行・保留・復旧の判断担当」欄を埋めてください。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。


