[テンプレ]移行リハーサル計画書

関連テンプレ構成
テンプレート
# 移行リハーサル

## リハーサルの目的

本番移行作業の成功確率を高めるため、以下を目的として移行リハーサルを実施する。

- 本番移行作業の手順・役割・所要時間の妥当性を確認する
- データ移行・環境切替・アプリケーション起動などの本番手順を事前に検証する
- 問題発生時の対応(切り戻し手順を含む)の実効性を確認する
- 関係者間の連携や役割分担が適切に機能することを確認する

**期待される効果**:
- 本番移行時の作業ミスの削減
- 想定外の問題の早期発見と対策
- 関係者の不安解消と習熟度向上

---

## リハーサルの範囲

**実施対象となる移行作業**:

| 作業項目 | 実施方法 | 理由 |
|---------|---------|------|
| データ移行 | 本番同等 | 所要時間とデータ品質の検証が必須 |
| 設定反映 | 本番同等 | 設定ミスが致命的な影響を与える |
| アプリケーション起動 | 本番同等 | 起動順序と依存関係の確認が重要 |
| 動作確認 | 簡略化 | 主要機能のみ確認(詳細は別途テスト実施済み) |
| 外部連携確認 | モック使用 | 本番環境の外部システムを使用できないため |
| バックアップ取得 | 簡略化 | 手順確認のみ(全量バックアップは時間的制約) |
| 監視設定 | 手順確認のみ | 本番環境でのみ実施可能 |

**リハーサル範囲外とする作業**:

| 作業項目 | 理由 |
|---------|------|
| 本番データの実バックアップ | セキュリティ上の制約により本番環境へのアクセスが制限されるため |
| 外部システムへの本番連携 | 外部システム側の協力が得られない、またはテスト環境が存在しないため |
| DNSの本番切替 | 本番環境でのみ実施可能、かつ影響範囲が大きいため |

---

## 前提条件・準備事項

**使用する環境**:
- **データ移行元**: ステージング環境(本番データの匿名化コピー)
- **データ移行先**: 検証環境(本番同等の構成)
- **ネットワーク**: 本番と同等の帯域を確保

**必要なテストデータ**:

```mermaid
graph LR
    A[本番データ] --> B[匿名化処理]
    B --> C[ステージング環境]
    C --> D[リハーサル用データ<br/>・顧客マスタ: 10万件<br/>・受注データ: 50万件<br/>・商品マスタ: 5千件]
```

| データ種別 | データ量 | 備考 |
|-----------|---------|------|
| 顧客マスタ | 10万件 | 本番の約20%、個人情報は匿名化済み |
| 受注データ | 50万件 | 直近1年分、本番の約30% |
| 商品マスタ | 5千件 | 本番の全件 |
| 在庫データ | 5千件 | 商品マスタに対応 |

**必要なアカウント・権限**:

| 担当 | 必要な権限 | 対象システム |
|-----|----------|------------|
| インフラチーム | 管理者権限 | ステージング環境、検証環境 |
| データチーム | データ操作権限 | データベース、ETLツール |
| 開発チーム | 読み取り権限 | 全環境(動作確認用) |
| 業務部門 | 業務機能権限 | 検証環境(受入確認用) |

**事前に準備すべきリソース**:

- **ツール・スクリプト**
  - データ抽出スクリプト
  - データ変換スクリプト
  - データロードスクリプト
  - 動作確認自動テストスクリプト
- **ドキュメント**
  - 作業手順書(詳細版)
  - チェックシート
  - 緊急連絡先リスト
  - 切り戻し手順書

---

## リハーサルの実施方法

**手順の流れ**:

```mermaid
gantt
    title 移行リハーサル作業フロー
    dateFormat HH:mm
    axisFormat %H:%M
    
    section 準備
    環境準備確認 :13:00, 30m
    データ整合性確認 :13:30, 30m
    
    section データ移行
    データ抽出 :14:00, 1h
    データ変換 :15:00, 30m
    データロード :15:30, 1h30m
    
    section 起動確認
    アプリケーション起動 :17:00, 30m
    初期動作確認 :17:30, 1h
    
    section 検証
    業務側確認 :18:30, 1h
    結果レビュー :19:30, 30m
```

**作業単位ごとの担当者**:

| 作業フェーズ | 作業内容 | 担当者 | 所要時間(予定) |
|------------|---------|--------|---------------|
| 準備 | 環境準備確認 | インフラチーム | 30|
| 準備 | データ整合性確認 | データチーム | 30|
| データ移行 | データ抽出 | データチーム | 1時間 |
| データ移行 | データ変換 | データチーム | 30|
| データ移行 | データロード | データチーム | 1.5時間 |
| 起動確認 | アプリケーション起動 | インフラチーム | 30|
| 起動確認 | 初期動作確認 | 開発チーム | 1時間 |
| 検証 | 業務側確認 | 業務部門 | 1時間 |
| 検証 | 結果レビュー | 全員 | 30|

**所要時間の測定方法**:
- 各作業の開始時刻・終了時刻を記録シートに記入
- 自動化されている作業はログから時刻を抽出
- 待機時間と実作業時間を分けて記録

**ログの取得・記録方法**:
- システムログ: 自動収集(syslog、アプリケーションログ)
- 作業ログ: 作業記録シートに手動記入
- スクリーンショット: 主要な確認画面を記録
- 問題発生時: 別途インシデント記録シートに詳細を記録

---

## 確認項目(成功判定基準)

**作業手順の妥当性**:

| 確認項目 | 判定基準 | 確認方法 |
|---------|---------|---------|
| 手順書の完全性 | 手順書のみで作業が完遂できる | 作業者へのヒアリング |
| 手順の明確性 | 曖昧な表現や不明点がない | 作業者へのヒアリング |
| 役割分担 | 各担当者が自分の作業を理解している | 作業記録の確認 |

**所要時間の妥当性**:

| 作業 | 目標時間 | 判定基準 |
|-----|---------|---------|
| データ抽出 | 1時間 | ±10%以内 |
| データ変換 | 30| ±15%以内 |
| データロード | 1.5時間 | ±10%以内 |
| 全体 | 6時間 | 本番スケジュール内に収まる |

**データ移行の正確性**:

```mermaid
graph TD
    A[データ件数チェック] --> B{一致?}
    B -->|Yes| C[データ内容チェック]
    B -->|No| D[エラー対応]
    C --> E{整合性OK?}
    E -->|Yes| F[合格]
    E -->|No| D
    D --> G[原因分析]
```

| 確認項目 | 判定基準 |
|---------|---------|
| データ件数 | 移行元と移行先で100%一致 |
| データ内容 | サンプル抽出で100件中エラー0|
| 参照整合性 | 外部キー制約違反が0|
| 必須項目 | NULL値が想定外に存在しない |

**システム動作の正常性**:

| 確認項目 | 判定基準 |
|---------|---------|
| アプリケーション起動 | 全サービスが正常起動 |
| ログイン機能 | テストユーザーでログイン可能 |
| 主要業務機能 | 受注登録・照会が正常動作 |
| バッチ処理 | テスト実行で正常終了 |
| 外部連携 | モック連携で正常動作 |

---

## 切り戻しの検証

**切り戻しの実施方針**:
- リハーサルでは切り戻し手順を実際に試す
- 切り戻し所要時間を測定し、本番での判断材料とする

**切り戻し実施タイミング**:

```mermaid
graph TD
    A[移行作業完了] --> B{動作確認}
    B -->|問題あり| C{切り戻し判断}
    B -->|正常| D[リハーサル完了]
    C -->|切り戻し実施| E[旧環境復旧開始]
    C -->|問題対応継続| F[問題解析]
    E --> G[切り戻し動作確認]
    G --> H[切り戻し完了]
```

**切り戻しに必要な環境・データの準備**:

| 準備項目 | 内容 |
|---------|------|
| バックアップデータ | 移行前の状態のデータベースバックアップ |
| 設定ファイル | 旧システムの全設定ファイル |
| 旧環境 | すぐに起動できる状態で待機 |
| ネットワーク設定 | 旧環境に切り替え可能な状態 |

**切り戻しにかかる時間の測定**:

| 作業 | 目標時間 | 測定結果記入欄 |
|-----|---------|-------------|
| データベースリストア | 30|   |
| アプリケーション切替 | 15|   |
| 動作確認 | 30|   |
| **合計** | **1.5時間以内** |   |

**切り戻し後の動作確認項目**:

- ログイン機能が正常に動作する
- 直近のトランザクションデータが存在する
- バッチ処理が実行可能である
- 外部システムとの連携が正常である

---

## リハーサル回数と計画

**実施スケジュール**:

| 回数 | 実施時期 | 目的 | 参加者 |
|-----|---------|------|--------|
| 1回目 | 結合テスト完了後(5月中旬) | 手順確認、問題の早期発見 | ベンダー全員 |
| 2回目 | 総合テスト期間中(6月上旬) | 本番想定、時間測定 | ベンダー全員 + 業務部門代表 |
| 3回目(必要時) | 本番1週間前 | 最終確認 | 全員 |

**各回の目的と重点項目**:

```mermaid
graph LR
    A[1回目リハーサル] -->|手順改善| B[2回目リハーサル]
    B -->|問題なし| C[本番移行]
    B -->|問題あり| D[3回目リハーサル]
    D --> C
```

- **1回目**: 手順書の妥当性確認、大きな問題の洗い出し
- **2回目**: 本番同等の実施、所要時間の精密測定、切り戻し訓練
- **3回目**: 最終確認(必要に応じて)

---

## リハーサル結果の扱い

**問題・改善点の整理方法**:

| 項目 | 記録内容 |
|-----|---------|
| 問題ID | 一意の識別番号 |
| 発生フェーズ | どの作業で発生したか |
| 問題内容 | 具体的な事象 |
| 影響度 |//|
| 原因 | 根本原因の分析結果 |
| 対策 | 具体的な改善策 |
| 担当者 | 対策実施責任者 |
| 期限 | 対策完了予定日 |

**本番移行手順へのフィードバック方法**:

1. リハーサル終了後24時間以内に振り返りMTGを実施
2. 問題管理表を更新し、対策を明確化
3. 手順書を改訂し、バージョン番号を更新
4. 関係者全員に改訂版を共有

**追加リハーサルの要否判断基準**:

| 判断基準 | 内容 |
|---------|------|
| 重大な問題発生 | システム起動不可、データ破損など |
| 手順の大幅変更 | 作業フローの30%以上が変更された |
| 所要時間の大幅超過 | 予定時間の150%以上かかった |
| 切り戻しの失敗 | 切り戻し手順が正常に機能しなかった |

---

## 関係者体制

**リハーサル当日の体制**:

```mermaid
graph TD
    A[リハーサル責任者<br/>プロジェクトマネージャー] --> B[作業指揮者<br/>インフラリーダー]
    B --> C[インフラチーム<br/>2名]
    B --> D[データチーム<br/>3名]
    B --> E[開発チーム<br/>2名]
    A --> F[業務部門立会者<br/>1名]
    A --> G[承認者<br/>事業責任者]
```

| 役割 | 担当者 | 責任範囲 |
|-----|--------|---------|
| リハーサル責任者 | PM(山田) | 全体統括、Go/No Go判断 |
| 作業指揮者 | インフラリーダー(佐藤) | 作業進行管理、時間管理 |
| インフラ担当 | 鈴木、田中 | 環境準備、システム起動 |
| データ担当 | 高橋、伊藤、渡辺 | データ移行作業 |
| 開発担当 | 中村、小林 | 動作確認 |
| 業務立会者 | 業務部門(山本) | 業務観点での確認 |
| 最終承認者 | 事業責任者(斎藤) | 成否判定 |

**緊急対応フロー**:

```mermaid
graph TD
    A[問題発生] --> B[作業担当者が検知]
    B --> C[作業指揮者に報告]
    C --> D{影響度判定}
    D -->|小| E[担当者レベルで対応]
    D -->|中| F[リハーサル責任者判断]
    D -->|大| G[作業中断・切り戻し検討]
    F --> H[対応方針決定]
    G --> I[最終承認者へエスカレーション]
    I --> J[Go/No Go判断]
```

**連絡体制**:

| 担当者 | 役割 | 電話番号 | メール |
|--------|------|---------|--------|
| 山田 | PM | 090-XXXX-XXXX | yamada@example.com |
| 佐藤 | インフラリーダー | 090-YYYY-YYYY | sato@example.com |
| 山本 | 業務部門 | 080-ZZZZ-ZZZZ | yamamoto@example.com |
| 斎藤 | 事業責任者 | 090-AAAA-AAAA | saito@example.com |

※本番移行時も同様の体制で実施する予定

---
プレビュー

移行リハーサル

リハーサルの目的

本番移行作業の成功確率を高めるため、以下を目的として移行リハーサルを実施する。

  • 本番移行作業の手順・役割・所要時間の妥当性を確認する
  • データ移行・環境切替・アプリケーション起動などの本番手順を事前に検証する
  • 問題発生時の対応(切り戻し手順を含む)の実効性を確認する
  • 関係者間の連携や役割分担が適切に機能することを確認する

期待される効果:

  • 本番移行時の作業ミスの削減
  • 想定外の問題の早期発見と対策
  • 関係者の不安解消と習熟度向上

リハーサルの範囲

実施対象となる移行作業:

作業項目 実施方法 理由
データ移行 本番同等 所要時間とデータ品質の検証が必須
設定反映 本番同等 設定ミスが致命的な影響を与える
アプリケーション起動 本番同等 起動順序と依存関係の確認が重要
動作確認 簡略化 主要機能のみ確認(詳細は別途テスト実施済み)
外部連携確認 モック使用 本番環境の外部システムを使用できないため
バックアップ取得 簡略化 手順確認のみ(全量バックアップは時間的制約)
監視設定 手順確認のみ 本番環境でのみ実施可能

リハーサル範囲外とする作業:

作業項目 理由
本番データの実バックアップ セキュリティ上の制約により本番環境へのアクセスが制限されるため
外部システムへの本番連携 外部システム側の協力が得られない、またはテスト環境が存在しないため
DNSの本番切替 本番環境でのみ実施可能、かつ影響範囲が大きいため

前提条件・準備事項

使用する環境:

  • データ移行元: ステージング環境(本番データの匿名化コピー)
  • データ移行先: 検証環境(本番同等の構成)
  • ネットワーク: 本番と同等の帯域を確保

必要なテストデータ:

graph LR
    A[本番データ] --> B[匿名化処理]
    B --> C[ステージング環境]
    C --> D[リハーサル用データ<br/>・顧客マスタ: 10万件<br/>・受注データ: 50万件<br/>・商品マスタ: 5千件]
データ種別 データ量 備考
顧客マスタ 10万件 本番の約20%、個人情報は匿名化済み
受注データ 50万件 直近1年分、本番の約30%
商品マスタ 5千件 本番の全件
在庫データ 5千件 商品マスタに対応

必要なアカウント・権限:

担当 必要な権限 対象システム
インフラチーム 管理者権限 ステージング環境、検証環境
データチーム データ操作権限 データベース、ETLツール
開発チーム 読み取り権限 全環境(動作確認用)
業務部門 業務機能権限 検証環境(受入確認用)

事前に準備すべきリソース:

  • ツール・スクリプト
    • データ抽出スクリプト
    • データ変換スクリプト
    • データロードスクリプト
    • 動作確認自動テストスクリプト
  • ドキュメント
    • 作業手順書(詳細版)
    • チェックシート
    • 緊急連絡先リスト
    • 切り戻し手順書

リハーサルの実施方法

手順の流れ:

gantt
    title 移行リハーサル作業フロー
    dateFormat HH:mm
    axisFormat %H:%M

    section 準備
    環境準備確認 :13:00, 30m
    データ整合性確認 :13:30, 30m

    section データ移行
    データ抽出 :14:00, 1h
    データ変換 :15:00, 30m
    データロード :15:30, 1h30m

    section 起動確認
    アプリケーション起動 :17:00, 30m
    初期動作確認 :17:30, 1h

    section 検証
    業務側確認 :18:30, 1h
    結果レビュー :19:30, 30m

作業単位ごとの担当者:

作業フェーズ 作業内容 担当者 所要時間(予定)
準備 環境準備確認 インフラチーム 30分
準備 データ整合性確認 データチーム 30分
データ移行 データ抽出 データチーム 1時間
データ移行 データ変換 データチーム 30分
データ移行 データロード データチーム 1.5時間
起動確認 アプリケーション起動 インフラチーム 30分
起動確認 初期動作確認 開発チーム 1時間
検証 業務側確認 業務部門 1時間
検証 結果レビュー 全員 30分

所要時間の測定方法:

  • 各作業の開始時刻・終了時刻を記録シートに記入
  • 自動化されている作業はログから時刻を抽出
  • 待機時間と実作業時間を分けて記録

ログの取得・記録方法:

  • システムログ: 自動収集(syslog、アプリケーションログ)
  • 作業ログ: 作業記録シートに手動記入
  • スクリーンショット: 主要な確認画面を記録
  • 問題発生時: 別途インシデント記録シートに詳細を記録

確認項目(成功判定基準)

作業手順の妥当性:

確認項目 判定基準 確認方法
手順書の完全性 手順書のみで作業が完遂できる 作業者へのヒアリング
手順の明確性 曖昧な表現や不明点がない 作業者へのヒアリング
役割分担 各担当者が自分の作業を理解している 作業記録の確認

所要時間の妥当性:

作業 目標時間 判定基準
データ抽出 1時間 ±10%以内
データ変換 30分 ±15%以内
データロード 1.5時間 ±10%以内
全体 6時間 本番スケジュール内に収まる

データ移行の正確性:

graph TD
    A[データ件数チェック] --> B{一致?}
    B -->|Yes| C[データ内容チェック]
    B -->|No| D[エラー対応]
    C --> E{整合性OK?}
    E -->|Yes| F[合格]
    E -->|No| D
    D --> G[原因分析]
確認項目 判定基準
データ件数 移行元と移行先で100%一致
データ内容 サンプル抽出で100件中エラー0件
参照整合性 外部キー制約違反が0件
必須項目 NULL値が想定外に存在しない

システム動作の正常性:

確認項目 判定基準
アプリケーション起動 全サービスが正常起動
ログイン機能 テストユーザーでログイン可能
主要業務機能 受注登録・照会が正常動作
バッチ処理 テスト実行で正常終了
外部連携 モック連携で正常動作

切り戻しの検証

切り戻しの実施方針:

  • リハーサルでは切り戻し手順を実際に試す
  • 切り戻し所要時間を測定し、本番での判断材料とする

切り戻し実施タイミング:

graph TD
    A[移行作業完了] --> B{動作確認}
    B -->|問題あり| C{切り戻し判断}
    B -->|正常| D[リハーサル完了]
    C -->|切り戻し実施| E[旧環境復旧開始]
    C -->|問題対応継続| F[問題解析]
    E --> G[切り戻し動作確認]
    G --> H[切り戻し完了]

切り戻しに必要な環境・データの準備:

準備項目 内容
バックアップデータ 移行前の状態のデータベースバックアップ
設定ファイル 旧システムの全設定ファイル
旧環境 すぐに起動できる状態で待機
ネットワーク設定 旧環境に切り替え可能な状態

切り戻しにかかる時間の測定:

作業 目標時間 測定結果記入欄
データベースリストア 30分
アプリケーション切替 15分
動作確認 30分
合計 1.5時間以内

切り戻し後の動作確認項目:

  • ログイン機能が正常に動作する
  • 直近のトランザクションデータが存在する
  • バッチ処理が実行可能である
  • 外部システムとの連携が正常である

リハーサル回数と計画

実施スケジュール:

回数 実施時期 目的 参加者
1回目 結合テスト完了後(5月中旬) 手順確認、問題の早期発見 ベンダー全員
2回目 総合テスト期間中(6月上旬) 本番想定、時間測定 ベンダー全員 + 業務部門代表
3回目(必要時) 本番1週間前 最終確認 全員

各回の目的と重点項目:

graph LR
    A[1回目リハーサル] -->|手順改善| B[2回目リハーサル]
    B -->|問題なし| C[本番移行]
    B -->|問題あり| D[3回目リハーサル]
    D --> C
  • 1回目: 手順書の妥当性確認、大きな問題の洗い出し
  • 2回目: 本番同等の実施、所要時間の精密測定、切り戻し訓練
  • 3回目: 最終確認(必要に応じて)

リハーサル結果の扱い

問題・改善点の整理方法:

項目 記録内容
問題ID 一意の識別番号
発生フェーズ どの作業で発生したか
問題内容 具体的な事象
影響度 高/中/低
原因 根本原因の分析結果
対策 具体的な改善策
担当者 対策実施責任者
期限 対策完了予定日

本番移行手順へのフィードバック方法:

  1. リハーサル終了後24時間以内に振り返りMTGを実施
  2. 問題管理表を更新し、対策を明確化
  3. 手順書を改訂し、バージョン番号を更新
  4. 関係者全員に改訂版を共有

追加リハーサルの要否判断基準:

判断基準 内容
重大な問題発生 システム起動不可、データ破損など
手順の大幅変更 作業フローの30%以上が変更された
所要時間の大幅超過 予定時間の150%以上かかった
切り戻しの失敗 切り戻し手順が正常に機能しなかった

関係者体制

リハーサル当日の体制:

graph TD
    A[リハーサル責任者<br/>プロジェクトマネージャー] --> B[作業指揮者<br/>インフラリーダー]
    B --> C[インフラチーム<br/>2名]
    B --> D[データチーム<br/>3名]
    B --> E[開発チーム<br/>2名]
    A --> F[業務部門立会者<br/>1名]
    A --> G[承認者<br/>事業責任者]
役割 担当者 責任範囲
リハーサル責任者 PM(山田) 全体統括、Go/No Go判断
作業指揮者 インフラリーダー(佐藤) 作業進行管理、時間管理
インフラ担当 鈴木、田中 環境準備、システム起動
データ担当 高橋、伊藤、渡辺 データ移行作業
開発担当 中村、小林 動作確認
業務立会者 業務部門(山本) 業務観点での確認
最終承認者 事業責任者(斎藤) 成否判定

緊急対応フロー:

graph TD
    A[問題発生] --> B[作業担当者が検知]
    B --> C[作業指揮者に報告]
    C --> D{影響度判定}
    D -->|小| E[担当者レベルで対応]
    D -->|中| F[リハーサル責任者判断]
    D -->|大| G[作業中断・切り戻し検討]
    F --> H[対応方針決定]
    G --> I[最終承認者へエスカレーション]
    I --> J[Go/No Go判断]

連絡体制:

担当者 役割 電話番号 メール
山田 PM 090-XXXX-XXXX yamada@example.com
佐藤 インフラリーダー 090-YYYY-YYYY sato@example.com
山本 業務部門 080-ZZZZ-ZZZZ yamamoto@example.com
斎藤 事業責任者 090-AAAA-AAAA saito@example.com

※本番移行時も同様の体制で実施する予定