カットオーバーとは、新しく開発したシステムを本番環境に切り替え、実際の業務データを使って稼働させることです。日本語では「本番移行」「本稼働」とも呼ばれ、システム開発プロジェクトの最終フェーズを指します。
この記事は、カットオーバーの計画を任された発注者側のPM・IT担当者に向けたものです。「何をいつまでに準備すればよいか」「当日は何を確認すればよいか」を、そのまま社内共有・印刷して使えるチェックリストの形でまとめました。まず定義と方式の違いを整理し、後半で当日直前に見るべきチェックリストと、よくある失敗の回避策を解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
カットオーバーとは？リリース・本番移行との違い
カットオーバーは、これまでテスト環境で動かしていたシステムを本番環境に切り替え、実際の業務データで運用を開始するタイミングを指します。旧システムを使っていた場合は、旧システムから新システムへの切り替えそのものを指すこともあります。
似た言葉との違いを整理すると、以下のようになります。
用語 | 意味 | 使われる場面 |
|---|---|---|
カットオーバー | 新システムへの本番切り替え全体 | 社内システム・業務システムの移行 |
リリース | 新しい機能やソフトウェアを世に出すこと | Webサービス・アプリの公開 |
ローンチ | 新商品・サービスのお披露目 | マーケティング文脈での公開 |
本番移行 | カットオーバーとほぼ同義 | ITプロジェクト内部の用語 |
開発会社（ベンダー）にとってカットオーバーはプロジェクトの完了を意味しますが、発注者（ユーザー）にとっては「運用の開始地点」です。カットオーバーを境にシステムの主導権は開発会社から発注者に移るため、当日に向けた準備と意思決定体制の整備は発注者自身の責任になります。
カットオーバーの種類（一括移行・段階移行・並行稼働）
カットオーバーには大きく3つの方式があり、リスクと期間、当日の負荷が異なります。どの方式を選ぶかは発注者も含めた判断事項です。
方式 | 概要 | メリット | デメリット | 向いているケース |
|---|---|---|---|---|
一括移行 | 特定の日時に旧システムを停止し、新システムに完全に切り替える | 移行期間が短くコストを抑えられる／二重管理が不要で業務の混乱が少ない | 問題発生時の影響範囲が全体に及ぶ／ロールバックが難しい場合がある／当日の作業負荷が高い | 移行対象が小規模、または停止できる時間帯が確保できる場合 |
段階移行 | 機能・部門・地域などの単位で段階的に新システムへ移行する | 問題発生時の影響範囲を限定できる／移行の習熟度を高めながら進められる | 移行完了までの期間が長い／新旧システムの並行管理が必要になる期間が生じる | 規模の大きい移行、業務影響を最小限に抑えたい場合 |
並行稼働 | 一定期間、旧システムと新システムを同時に稼働させながら移行する | 動作を確認しながら移行できる／旧システムへの切り戻しがしやすい | 二重入力が必要になる場合がある／運用負荷・コストが最も高い | 初めてのシステム移行、データの正確性を慎重に検証したい場合 |
初めてシステム移行を行う組織には、段階移行か並行稼働をお勧めします。一括移行はシンプルですが、経験のない組織にとってはトラブル時のリスクが相対的に高くなるためです。判断軸としては「業務停止が許容できる時間」「トラブル時のリスク許容度」「移行にかけられるコストと期間」「旧データの正確な移行がどれほど重要か」の4点を、開発会社と一緒に確認してください。
カットオーバー計画の立て方・タイムライン
カットオーバーの成功は、当日までの準備でほぼ決まります。発注者側がいつ・何をすべきかを時系列で整理しました。
タイミング | やること |
|---|---|
2〜3ヶ月前 | 移行判定基準（カットオーバークライテリア）に開発会社と合意します。システムテストの完了率、UAT合格基準、データ移行検証、業務マニュアル整備、運用体制、ロールバック計画の確認項目を事前に定めます |
1〜2ヶ月前 | 業務マニュアルの整備とユーザートレーニングを開始します。各部門のキーユーザーを先行トレーニングし、キーユーザーが同僚をサポートする体制を作ります |
2〜4週間前 | 緊急時対応体制と連絡ルートを確定します。エスカレーション先・対応タイムライン・業務継続の手動フローを図にして関係者全員に共有します |
1〜2週間前 | ロールバック条件に合意します。ロールバックの対象範囲・判断権者・タイムリミットを事前に決めておきます |
前日〜当日 | 次章の「直前チェックリスト」で最終確認します |
移行判定基準（カットオーバークライテリア）は「発注者が主導して確認する」ことが重要です。業務面の状況を総合的に判断できるのは発注者のみだからです。開発会社から「技術的には問題ない」と言われても、業務準備が整っていなければ延期を判断する権限と責任は発注者にあります。
カットオーバー直前チェックリスト（コピペ用）
そのままコピーして社内チャットや紙で共有できるチェックリストです。「前日」「当日開始前」「切り替え実行中・直後」「完了直後」の4段階に分けています。
前日までに確認すること
□ 移行判定基準（カットオーバークライテリア）の全項目クリアを最終確認
□ ロールバックの判断権者・対象範囲・タイムリミットを関係者全員で再確認
□ エスカレーション連絡網（誰に・何分以内に・どの経路で報告するか）をチャットまたは紙で掲示
□ 「最終承認者」「業務確認責任者」「システム連絡窓口」の当日の配置と連絡先を確認
□ システムが使えない場合の業務継続手順（手動対応フロー）を現場に再周知
当日開始前に確認すること
□ 開発会社からカットオーバークライテリアの達成状況について最終報告を受領
□ 発注者側の最終承認者によるGO/NG判断の実施と、判断内容の記録
□ 現場スタッフへの切り替え開始時刻と問い合わせ窓口の再周知
切り替え実行中・直後に確認すること
□ 重要マスタデータ（顧客・在庫・取引先など）の整合性を業務部門が確認
□ 主要業務フロー（受注・出荷・請求など）を実データで一通り動作確認
□ 他システムとのデータ連携が正しく機能しているかを確認
□ 軽微なトラブル発生時の対応フロー（現場→業務確認責任者→システム連絡窓口→開発会社）が機能することを確認
□ 重大なトラブル発生時、最終承認者によるタイムリミット内でのロールバック要否の判断
完了直後（安定化開始前）に確認すること
□ 現場からの問い合わせ窓口が稼働していることの周知
□ エラーログ・パフォーマンスの監視体制を開発会社と確認
□ 発生した問題を記録するフォーマットと共有先の確認
よくある失敗パターンと回避策
失敗パターン | 原因 | 回避策 |
|---|---|---|
ロールバック判断が遅れて被害が拡大する | 「誰が」「いつまでに」判断するかが曖昧なまま当日を迎えてしまいます | 判断権者とタイムリミットを事前合意し、判断フローを紙やチャットで共有しておきます |
緊急連絡網が機能せず対応が後手に回る | 連絡先リストは作成したものの、実際に連絡が届くか試したことがありません | 前日までに簡易リハーサルを行い、連絡が実際に届くか確認します |
現場が新システムの操作でパニックになる | トレーニングが1回きりで、現場での横展開がありません | キーユーザーを先行トレーニングし、当日はキーユーザーが同僚をサポートする体制にします |
データ移行後の不整合発見が遅れる | 確認が「システムが動くか」に偏り、業務データの中身まで見ていません | 重要マスタデータの正確性確認を切り替え直後の必須タスクとしてチェックリストに組み込みます |
発注者側に意思決定できる人がいない | 「技術的な話だから」と当日の体制作りを開発会社に委ねてしまいます | 最終承認者・業務確認責任者・システム連絡窓口の3役を発注者側で必ず配置します |
カットオーバー後の確認事項
カットオーバーが完了しても、システムが「本当に安定している」と言えるまでには一定の期間が必要です。この期間を「安定化期間」と呼び、目安は1〜3ヶ月程度です。
- システムの監視強化: エラーログの確認、パフォーマンスの監視
- ユーザーサポートの継続: 操作に不慣れなスタッフへの継続的な支援
- 問題の記録と報告: 発生した問題を記録し、開発会社と共有する
安定化期間中は、データ形式の違いによる不整合や、操作に不慣れなことによる誤操作、連携システムとの不具合が起きやすくなります。重要なマスタデータの正確性確認、重要データ操作の上長確認、連携先担当者との事前すり合わせを行っておくと被害を抑えられます。
以下の状態がそろえば「安定稼働」と判断し、開発会社との保守サポート契約の内容を見直すフェーズに移ることができます。
- 1〜2ヶ月間、業務に影響する重大な問題が発生していない
- 日常的に発生する軽微な問題に運用チームが対応できる状態になっている
- 現場スタッフが日常業務を支障なく行えるようになっている
まとめ
カットオーバーとは、新システムを本番環境に切り替え、実際の業務で稼働させることです。方式選びと事前の計画に加えて、当日「何を」「いつ」確認するかが決まっているかどうかが、トラブルを防げるかの分かれ目になります。
本記事の直前チェックリストをそのままコピーして社内で共有し、当日は迷わず確認作業を進めてください。なお、カットオーバーとシステム検収は別物です。検収はプロジェクトとしての完了、カットオーバーは運用の開始点として区別しておくと、経営層への説明もしやすくなります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- カットオーバーの準備は何ヶ月前から始めればよいですか？
規模にもよりますが、移行判定基準の合意とユーザートレーニング計画は本番の2〜3ヶ月前から着手するのが目安です。特に現場スタッフのトレーニングと業務マニュアル整備は時間がかかるため、開発会社のスケジュールを待たず発注者側で早めに段取りを始めてください。
- IT専任者がいない会社でも、発注者がカットオーバーを主導できますか？
できます。発注者に求められるのは技術判断ではなく「業務が回るか」の判断です。移行判定基準の合意・現場トレーニング・緊急時の連絡ルート整備など業務面の準備に集中し、技術的な切り分けは開発会社に任せる役割分担を明確にすれば対応できます。
- ロールバックを判断するのは開発会社ですか、それとも発注者ですか？
実施判断の最終権限は発注者にあります。ロールバック計画の作成や技術的助言は開発会社が担いますが、業務を止めて旧システムに戻すかどうかは業務影響を負う発注者が決める事項です。当日までに「誰が決断するか」を一人に定めておいてください。
- 業務準備が間に合わないとき、カットオーバーを延期してもよいですか？
延期は発注者の正当な権限です。開発会社が「技術的に問題ない」と言っても、トレーニング未完了や緊急対応体制が整っていなければ延期を判断してかまいません。延期の可否は移行判定基準に照らして判断し、再設定日を開発会社と早期に調整してください。
- 初めてのシステム移行では、どの移行方式を選べばよいですか？
経験のない組織には段階移行か並行稼働をお勧めします。一括移行はシンプルでコストも低い反面、トラブル時の影響が全体に及び切り戻しも難しいためです。システム停止が許容できる時間とリスク許容度を基準に、開発会社と相談して選定してください。
