システム開発プロジェクトの終盤、開発会社から「カットオーバー計画書」が届いたとき、多くの発注者は困惑を感じます。「カットオーバーとは何か、だいたいはわかる。でも、実際に何を準備すればよいのか、当日に何をすべきなのか、トラブルが起きたら誰が判断するのか」という疑問が浮かんでくるからです。
特にIT専任者がいない環境では、この局面を経験した人が社内にいないことも多く、「なんとなく開発会社に任せておけばいい」という認識のまま当日を迎えがちです。しかし、カットオーバーは発注者にとっても重要な意思決定の連続であり、受け身でいるとトラブル時に対応が後手に回るリスクがあります。
本記事では、カットオーバーの基本的な意味と方式の違いから、発注者側が事前に準備すべきこと、当日の役割と意思決定ポイント、切り替え後の安定化期間の過ごし方まで、発注者の視点で体系的に解説します。経営層に「こういう体制で臨みます」と説明できる状態を作ることを目標に、読み進めてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
カットオーバーとは？リリース・本番移行との違い
カットオーバーとは「新システム本稼働の瞬間」
カットオーバーとは、開発したシステムを本番環境で実際に稼働させる切り替えのことです。日本語では「本番移行」「本稼働」とも呼ばれ、システム開発プロジェクトにおける最終フェーズを指します。
具体的には、これまでテスト環境で動かしていたシステムを本番環境に切り替え、実際の業務データを使って運用を開始するタイミングがカットオーバーです。旧システムを使っていた場合は、旧システムから新システムへの切り替えタイミングを指すこともあります。
リリース・ローンチ・本番移行との違い
似た言葉が多いため、整理します。
用語 | 意味 | 使われる場面 |
|---|---|---|
カットオーバー | 新システムへの本番切り替え全体 | 社内システム・業務システムの移行 |
リリース | 新しい機能やソフトウェアを世に出すこと | Webサービス・アプリの公開 |
ローンチ | 新商品・サービスのお披露目 | マーケティング文脈での公開 |
本番移行 | カットオーバーとほぼ同義 | ITプロジェクト内部の用語 |
リリースは「開発者が成果物を外部に出す」ニュアンスが強く、カットオーバーは「旧環境から新環境への切り替え作業の全体」を指す言葉として使われることが一般的です。
発注者（ユーザー）にとってカットオーバーが意味すること
開発会社（ベンダー）にとってカットオーバーはプロジェクトの完了を意味します。一方、発注者（ユーザー）にとってカットオーバーは「運用の開始地点」です。
カットオーバーを境に、システムの主導権は開発会社から発注者に移ります。それだけに、カットオーバー当日に向けた準備と、当日の意思決定体制の整備は、発注者自身の責任として取り組む必要があります。
カットオーバーの主な方式と発注者への影響
カットオーバーには大きく3つの方式があり、それぞれリスクと期間が異なります。どの方式を選ぶかは発注者も含めた判断事項です。
一括移行（ビッグバン方式）のメリット・デメリット
一括移行とは、特定の日時に旧システムを停止し、新システムに完全に切り替える方式です。
メリット:
- 移行期間が短く、コストを抑えられる
- 二重管理（新旧並行運用）が不要で、業務の混乱が少ない
- 切り替えのタイミングが明確
デメリット:
- 問題発生時の影響範囲が全体に及ぶ
- ロールバック（旧システムへの切り戻し）が難しい場合がある
- 当日の作業負荷・プレッシャーが高い
一括移行は「シンプルさ」を重視する場合に選ばれますが、万が一の際のリスクが大きいため、事前のリハーサルと緊急対応計画が不可欠です。
段階移行（フェーズ方式）のメリット・デメリット
段階移行とは、機能や部門、地域などを単位として、段階的に新システムへ移行していく方式です。
メリット:
- 問題発生時の影響範囲を限定できる
- 移行の習熟度を高めながら進められる
- 一部を旧システムで継続できるため、業務リスクが低い
デメリット:
- 移行完了までの期間が長くなる
- 新旧システムの並行管理が必要な期間が生じる
- 全体完了まで両システムの維持コストがかかる
規模の大きいシステム移行や、業務影響を最小限に抑えたい場合に適した方式です。
並行稼働のメリット・デメリット
並行稼働とは、一定期間、旧システムと新システムの両方を同時に動かしながら、段階的に新システムへ移行していく方式です。
メリット:
- 新システムの動作を確認しながら移行できる
- 旧システムへの切り戻しがしやすい
- データの正確性を比較検証しながら進められる
デメリット:
- 両システムへの二重入力が必要になる場合がある
- 運用負荷・コストが最も高い
- データ不整合が生じやすい
並行稼働は安全性が高い反面、業務現場への負担が最も大きい方式です。
どの方式を選ぶか：発注者が押さえるべき判断軸
方式の選択は、以下の観点で判断します。
- 業務の継続性: システム停止が許容できる時間はどれだけか
- リスク許容度: 万が一のトラブル時に、どこまで影響を許容できるか
- コスト: 移行にかけられる期間とコストの上限はどこか
- データの重要性: 旧データの正確な移行がどれほど重要か
一般的に、初めてシステム移行を行う組織では、段階移行か並行稼働を検討することをお勧めします。一括移行はシンプルですが、経験のない組織にとってトラブル時のリスクが高くなります。
カットオーバー前に発注者が準備すること
カットオーバーの成功は、当日までの準備で9割が決まります。発注者側が取り組むべき準備を整理します。
移行判定基準（カットオーバークライテリア）に合意する
カットオーバーに進むかどうかを判断する基準を、事前に開発会社と合意しておくことが重要です。この基準を「カットオーバークライテリア（移行判定基準）」と呼びます。
具体的には以下の項目を事前に定めます。
- システムテストの完了率（例: バグ対応率95%以上）
- ユーザー受入試験（UAT）の合格基準
- データ移行の検証完了
- 業務マニュアルの整備状況
- 運用体制の構築完了
- ロールバック計画の確認
カットオーバー判定は「発注者が主導して行うべき」です。なぜなら、業務面の状況を総合的に判断できるのは発注者のみだからです。開発会社から「技術的には問題ない」と言われても、業務準備が整っていなければカットオーバーを延期する権限と責任は発注者にあります。
業務マニュアルとユーザートレーニングの準備
新システムを使う現場スタッフのトレーニングと、業務マニュアルの整備は発注者側の責任範囲です。
- 操作マニュアルの作成: 開発会社が提供する操作マニュアルをベースに、自社業務に合わせた補足を加える
- トレーニングの実施: カットオーバー前に全ユーザーが最低1回はシステムを操作する機会を設ける
- 問い合わせ窓口の設置: 切り替え後の現場からの問い合わせを受ける担当者を事前に決めておく
特にシステムの変化が大きい場合は、現場のキーユーザー（各部門のリーダー格）を先行してトレーニングし、キーユーザーが同僚をサポートする体制を作ると効果的です。
緊急時対応体制と連絡ルートの確立
カットオーバー当日にトラブルが発生した場合に、誰に連絡し、誰が判断するかを事前に決めておきます。
- エスカレーション先: 問題の深刻度に応じた連絡先（開発会社の担当・リーダー・経営層）
- 対応タイムライン: 問題発生から何分以内に誰に報告するか
- 業務継続手順: システムが使えない場合の手動対応手順（バックアップ業務フロー）
連絡ルートは「図に起こして関係者全員で共有する」ことで、当日の混乱を大幅に減らすことができます。
ロールバック（切り戻し）条件の事前合意
ロールバックとは、問題が発生した場合に新システムへの切り替えを中止し、旧システムに戻すことです。ロールバックの実施判断は「どのような状況になったら戻すか」を事前に合意しておくことで、当日の判断が明確になります。
- ロールバックの対象範囲: 全システムを戻すのか、一部機能のみか
- ロールバックの判断権者: 誰がロールバックを決断するか
- ロールバックのタイムリミット: どの時刻までに判断するか（期限を超えると旧システムへの切り戻しが困難になる場合がある）
ロールバック計画は開発会社が作成しますが、実施判断の最終権限は発注者にあります。
カットオーバー当日の発注者の役割と意思決定ポイント
発注者側の当日体制：役割分担の整理
カットオーバー当日は、発注者側も明確な役割分担を持って臨む必要があります。
役割 | 担当者 | 主な責務 |
|---|---|---|
最終承認者 | 経営層・責任者 | カットオーバーGO/NG判断、ロールバック決断 |
業務確認責任者 | 部門リーダー | 各業務の動作確認、現場からの問い合わせ対応 |
システム連絡窓口 | IT担当・情シス | 開発会社との技術的なやり取り、問題の一次切り分け |
現場オペレーター | 各部門担当者 | 実際の業務操作、動作確認のデータ入力 |
「開発会社に任せておけばいい」という認識のまま当日を迎えると、発注者側に意思決定できる人が不在になるリスクがあります。少なくとも「最終承認者」「業務確認責任者」「システム連絡窓口」の3役は、当日会場（または即応可能な状態）に配置することをお勧めします。
カットオーバーGO/NGの判断：誰が最終承認するか
カットオーバーに進むかどうかの最終判断（GO/NG判断）は、発注者側の責任者が行います。
開発会社がカットオーバークライテリアの確認結果を報告し、発注者がそれを踏まえて最終承認する、というフローが一般的です。
GO判断のチェックポイント:
- 移行判定基準をすべて満たしているか
- 現場スタッフのトレーニングが完了しているか
- 緊急対応体制が整っているか
- ロールバック計画が確認されているか
いずれか一つでも未達の場合、カットオーバーの延期を検討する権限が発注者にあります。
トラブル発生時の意思決定フロー
カットオーバー当日にトラブルが発生した場合の判断フローを事前に整備しておきます。
軽微なトラブル（業務継続可能）:
- 現場から業務確認責任者へ報告
- 業務確認責任者がシステム連絡窓口へ連絡
- 開発会社が対応・修正
- 修正後に動作確認して業務再開
重大なトラブル（業務停止が発生する可能性）:
- システム連絡窓口が即座に最終承認者へ連絡
- 最終承認者が業務停止の範囲・期間の許容度を判断
- 開発会社と協議してロールバックの要否を決定
- ロールバック判断の場合：旧システムへ切り戻して業務継続
重要なのは「誰が何を決めるか」の権限を明確にしておくことです。トラブル発生時にその場で権限者を探すと判断が遅れ、被害が拡大します。
ロールバック（切り戻し）を決断するタイミング
ロールバックを決断する主なタイミングは以下の通りです。
- 重大な機能不全: 業務に不可欠な機能が動作しない
- データの不整合: 移行したデータに重大な誤りが見つかった
- パフォーマンス問題: システムの応答速度が業務継続に支障をきたすレベルで低下している
- タイムリミット到達: ロールバックを行うことができる時刻の上限に近づいた
ロールバックの決断は「失敗」ではありません。むしろ、事前にロールバック計画を整備し、適切なタイミングで実行できることが、リスク管理のうえで重要です。
切り替え後の安定化期間の過ごし方とよくあるトラブル対応
安定化期間とは何か・なぜ重要か
カットオーバーが完了しても、システムが「本当に安定している」と言えるまでには一定の期間が必要です。この期間を「安定化期間」と呼びます。
一般的な安定化期間の目安は1〜3ヶ月程度です。この期間中は、予期しない問題が発生しやすく、開発会社のサポートを受けながら問題対応を続けることが一般的です。
安定化期間中は以下の点に注意が必要です。
- システムの監視強化: エラーログの確認、パフォーマンスの監視
- ユーザーサポートの継続: 操作に不慣れなスタッフへの継続的な支援
- 問題の記録と報告: 発生した問題を記録し、開発会社と共有する
よくあるトラブルと発注者ができる対応
安定化期間中に発生しやすいトラブルを把握しておきましょう。
データの不整合: 旧システムから新システムへのデータ移行時に、データのフォーマットの違いや変換ミスによって不整合が生じることがあります。発注者側の対応としては、重要なマスタデータを中心に、カットオーバー直後に業務部門でデータの正確性を確認する作業を計画に組み込むことが有効です。
操作ミス（誤操作）: 新しいシステムの操作に不慣れな時期は、誤操作によるデータの誤入力やシステムの誤動作が起きやすくなります。発注者側の対応としては、重要なデータ操作については上長確認を必須にするなど、人的なチェック体制を一時的に強化することが効果的です。
連携システムとの不具合: 他のシステムとデータ連携している場合、カットオーバー後に連携が正しく機能しないケースがあります。連携先システムの担当者とも事前に確認ポイントを合わせておくことが重要です。
「安定稼働」と判断するための基準
安定化期間の終了（安定稼働の判断）は、以下の観点で行います。
- 重大障害がゼロの状態が一定期間継続している: 1〜2ヶ月間、業務に影響する重大な問題が発生していない
- 軽微な問題への対応体制が整っている: 日常的に発生する軽微な問題は、運用チームが対応できる状態になっている
- ユーザーの操作習熟度が上がっている: 現場スタッフが日常業務を支障なく行えるようになっている
これらの条件が満たされた時点で、開発会社との保守サポート契約の内容を見直すフェーズに移ることができます。
システム検収とカットオーバーの関係
カットオーバーとシステム検収は、混同されやすい概念です。整理すると以下の関係にあります。
- システム検収: 開発会社が納品したシステムが要件を満たしているかを発注者が確認・承認する作業
- カットオーバー: システムを本番環境で実際に稼働させる切り替え
一般的には、ユーザー受入試験（UAT）を経てシステム検収が完了した後に、カットオーバーへ進みます。ただし、カットオーバー後の安定化期間中に残存する課題が明確になり、追加の検収項目が生じることもあります。
検収の完了をもってプロジェクト上の「完了」となりますが、カットオーバー後の安定化をしっかり管理することが、実務上の成功につながります。
カットオーバーは、システム開発プロジェクトの中でも発注者にとって最も重要な局面の一つです。「開発会社に任せれば大丈夫」という考えは、当日のトラブル対応で大きなリスクになります。
本記事で解説した通り、移行判定基準の事前合意・緊急対応体制の整備・ロールバック条件の明確化を事前に行い、当日は発注者側も明確な役割を持って臨むことが、カットオーバーを成功させる鍵です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
