カットオーバーとは？稼働判定・並行稼働・移行リハーサルの進め方

基幹システム・ERPの本番稼働では、システムを本番環境へ反映するだけでは不十分です。データ移行、外部連携の切替、業務開始、問い合わせ対応、障害時の判断までをつなげて準備しなければ、当日の判断が属人的になりやすくなります。

カットオーバーを「本番リリースの日」とだけ捉えず、業務切替を管理する範囲として定めることが重要です。この記事では、切替方式、リハーサル、稼働可否、切り戻し、責任分担を会議で合意するための判断材料を、実務で使いやすい形で整理します。

カットオーバーは本番環境への反映だけでなく、切替方式、リハーサル、稼働判定、初動支援までをつなげて管理する活動として整理します。

01Sectionカットオーバーとは？近接用語との違いを対象範囲で整理する

カットオーバーは、旧環境から新環境へ業務を移すための一連の活動を指すことが多い言葉です。ただし、対象範囲は組織や契約によって異なります。データ凍結から移行・照合・連携切替までを指す場合もあれば、重要業務の開始確認や初動支援まで含める場合もあります。

そのため、用語を厳密に統一するよりも、「何を対象にするか」「いつ始まり、どこで完了とするか」「誰が判断するか」を計画書で合意するほうが実務的です。復旧手順、代替処理、優先順位、未完了時のエスカレーションを事前に定める考え方は、NISTのコンティンジェンシープランニングガイドも参考になります。これはERPに一律で適用する手順ではなく、切替範囲と業務継続を整理する際の一般原則として捉えてください。

近接用語は「対象作業・時系列・責任分界」で分ける

リリースは、プログラムや設定を本番環境に反映し、利用可能な状態にする技術作業を指すことがあります。ローンチは、利用者や顧客への提供開始を指すことが一般的です。本番稼働は、新環境で実業務の処理を始める状態、データ移行は旧データの抽出・変換・投入・照合の作業、切り戻しは問題発生時に旧環境または代替業務へ戻す対応として整理できます。

ただし、これらの呼び方と範囲は案件ごとに変わります。たとえば、リリースが完了していても、業務部門が重要業務を開始できなければ本番稼働とは言えません。反対に、本番稼働を開始した後も、初動支援や残課題の解消をカットオーバー範囲に含めるかは、あらかじめ決める必要があります。

02Section本番日から逆算するカットオーバー計画の作り方

カットオーバー計画は、本番直前に作業表を作ることではありません。要件定義、設計、テストが進む段階から、移行対象、停止可能時間、外部連携、旧環境の維持条件、切り戻し方針を具体化し、本番日に向けて依存関係を積み上げます。導入全体で確認すべき工程はERP導入の進め方も参照してください。

予定日を先に固定して作業を押し込むと、リハーサルで発見された課題や再検証が日程から漏れやすくなります。本番希望日からの計画は、切替設計、データ準備、リハーサル、課題修正、再検証、判定資料の確認、最終判定、当日切替、初動支援を別々の工程として扱うことがポイントです。ERP導入のスケジュールと照らし、導入全体の日程と矛盾がないかも確認します。

移行データ量、データ形式、変換対象、変換ルールの複雑性は、移行計画の実行可能性を左右します。IPAのデータ連携ガイドライン付録Cは、こうした移行性の検討観点を示しています。準備期間やリハーサル回数は一律に決めず、これらの条件と実績で見積もります。

03Section一斉切替・段階切替・並行稼働をどう選ぶか

切替方式は停止時間だけでなく、業務・連携の分割可否、正データの扱い、照合体制、旧環境の維持条件を踏まえて選定します。

切替方式は「停止時間を短くしたいか」だけで決められません。業務・連携・データを安全に分けられるか、旧環境を維持できるか、二重運用を担う要員がいるか、どちらを正データにするかまで確認する必要があります。

Microsoft Learnの移行計画ガイドはクラウド移行向けの資料ですが、ERPの方式選定でも比較すべき観点を補う参考資料になります。

方式は次の順で絞り込みます。業務・連携・データを安全に分割できるなら段階切替を候補にし、段階間の連携と正データを確認します。分割が難しい場合は、停止可能時間内に移行・照合・重要業務の開始確認まで完了できる見込みを、リハーサルで示せるかを確認します。

並行稼働は、正データ・照合・要員・終了条件を確保できる場合にだけ候補となります。確保できない場合は、段階切替の再設計、対象範囲の縮小、リハーサルや初動支援の強化、本番日の再検討へ進みます。

04Section移行リハーサルで本番計画の実行可能性を確かめる

リハーサルで見つかった課題は、手順修正にとどめず、必要な再検証と稼働判定資料の更新まで反映して本番計画に活用します。

移行リハーサルは、単に移行プログラムが動くかを確かめるテストではありません。停止可能時間内に、データ凍結、抽出・変換・投入、照合、連携切替、権限確認、重要業務の開始準備、問い合わせ・障害連絡まで実行できるかを検証する場です。

NIST SP 800-34 Rev. 1では、テスト計画で目的、成功基準、対象範囲、シナリオ、参加者、時間枠を定め、可能な限り実運用に近い条件で検証する考え方が示されています。ERP導入においても、本番データを必ず利用するという意味ではなく、利用条件や情報管理ルールに沿って、本番に近い条件をどこまで再現するかを決める際の参考になります。

合格条件は、時間・データ・業務・運用に分けて案件固有に設定します。時間は停止可能時間内に移行、照合、業務開始判定まで完了できること、データは対象ごとの照合条件を満たすこと、業務は優先業務と例外処理を必要な権限で実行できること、運用は問い合わせ・監視・障害連絡・承認経路が機能することが確認の軸になります。

リハーサルの課題は、手順を修正しただけでは完了ではありません。改訂内容が反映され、必要な再検証が終わり、稼働判定資料のどこに反映したかを確認できて初めて、本番判断に利用できる状態になります。

05SectionGo／No-Goを根拠と承認記録で判定する

稼働判定では、必須条件、未解決課題の影響、回避策と責任分担の記録を確認し、判断理由を追える状態にします。

Go／No-Goは、テストが終わったかどうかだけで決めるものではありません。業務受入、データ、連携、当日運用・初動支援、切り戻しの各領域について、業務継続や統制上の懸念を受容できるかを確認します。共通の数値基準を置くのではなく、業務影響、契約、社内規程、連携先との条件に合わせて合格条件を定めます。

以下のシートでは、根拠資料、未解決課題、回避策、責任者、期限、判定、承認者を同じ行で管理します。会議用に別々の資料を読むのではなく、どの課題がどの判定に影響するかを追える状態にすることが目的です。

Goは必須条件を満たし、残課題が業務継続や統制に重大な影響を与えない場合の判断です。No-Goは、重要業務を開始できない、受容できないデータ不整合がある、統制上の不備が残る、復旧や切り戻しの見通しが立たない場合に検討します。

条件付きGoは、回避策、実施責任者、完了確認者、期限、期限超過時の再判定先がすべてそろう場合に限る判断です。これらが未確定であれば、課題を後回しにするための判断にはできません。資料が不足している、重要課題への対応が決まっていない、承認権限者または委任権限者が確認できない場合は、判定延期として扱います。

会議前には、切替計画、リハーサル実績、データ照合結果、未解決課題一覧、切り戻し計画、当日連絡網、初動支援計画を提出し、業務・情報システム・導入ベンダーの各責任者が事前確認するゲートを設けます。条件付きGoの後に期限超過、回避策の不履行、影響の拡大が発生したときは、プロジェクト責任者から定めた承認者へ再判定をエスカレーションします。

06Section切り戻しと初動支援を業務継続の計画として備える

切り戻しは、アプリケーションの版を戻す技術作業だけではありません。新環境で取引入力、マスタ更新、外部連携の送信が始まると、旧環境に戻す前に新旧のデータ差分をどう扱うかという業務上の問題が発生します。重要業務の開始、外部連携の送信、新旧双方での更新開始などのイベントを境に、切り戻しの実行可能性は変わります。

そのため、切り戻し可能期限は時刻だけで決めず、どの業務イベントの前までなら旧環境へ戻れるかとして定めます。期限後は、切り戻しではなく、新環境の復旧、データ修復、代替業務、関係者への連絡へ方針を切り替える条件も必要です。

GOV.UKのデプロイ運用ガイドは、デプロイ後の確認が失敗した場合に取消・ロールバックをあらかじめ計画する考え方を示しています。ERPのデータ切り戻しが容易になることを意味するものではありませんが、失敗時の判断と対応を事前設計する参考になります。

07Sectionベンダー任せにしない：発注側の確認事項と責任分担

発注側が技術作業をすべて代替する必要はありません。一方で、業務を開始できるか、事業影響を受容できるか、残課題を条件付きGoとして管理できるか、本番稼働を承認するかといった判断への関与範囲は、契約、社内規程、委任権限、運用体制によって異なります。導入ベンダーには技術的な実施、技術評価、根拠資料の作成を求め、定められた権限者がその資料をもとに業務・事業面の判断を行えるようにします。

IPAの共通フレーム2013に基づく調達管理ガイドは、調達、供給者選定、受入れ、移行、運用・保守を関連する工程として整理し、取得者側が受入れを確認する活動を位置付けています。これは個別契約における検収ルールを定めるものではありませんが、受入確認と本番判断の根拠を整理する参考になります。

RACIでは、Rを実行責任、Aを最終承認、Cを相談・レビュー、Iを情報共有として扱います。役職名は案件に合わせて置き換え、同じ作業にAを複数置かないようにします。切り戻しは、技術的に実行できるかの評価・実行案作成と、事業として実施するかの最終決定を分けて記録します。

以下は役割分担を整理する記載例です。最終的な責任者・承認者は、契約書、社内規程、委任権限、運用体制に合わせて定めてください。

08Section本番前の会議で確認したいカットオーバーの要点

本番前の会議では、資料を集めること自体ではなく、関係者が同じ根拠で判断できる状態をつくることが目的です。少なくとも、切替方式の選定根拠、リハーサル結果と改訂計画、Go／No-Go判定シート、切り戻し・初動支援体制を一続きで確認します。

会議で条件がそろわない場合は、無理に本番へ進めるのではなく、次の選択肢を比較します。

• 対象業務や連携範囲を縮小して、切替条件を満たせる範囲から進める
• 一斉切替、段階切替、並行稼働の方式を再設計する
• リハーサルで未達だった工程を修正し、必要な範囲を再検証する
• 残課題を条件付きGoとして扱えるかを再確認し、満たせなければ日程を再判定する

社内レビューの前に、停止可能時間、対象データ、変換ルール、連携先、旧環境条件、未解決課題、承認権限を整理しておくと、方式・日程・稼働可否の議論が進めやすくなります。

ERP導入の切替計画や稼働判定を整理したい場合

切替方式、移行リハーサル、Go／No-Go判定、切り戻しの体制を自社だけで整理しにくい場合は、ERP導入の支援範囲や体制を比較できます。

ERP導入564社掲載

ERP導入の支援会社を探す