リスクを見据えた移行計画設計

1. リスクは“全期間”のテーマ、移行は“集約点”

トラブルの多くは切替日に顕在化しますが、原因は初期の設計や意思決定に埋まっています。
だからこそ、リスクは計画初期から登録・評価し、実行中に更新し、終盤の移行で“設計どおりに安全に発動”させる――この流れが重要です。^1,2

2. 止めないための原則（3つ）

1. 段階移行： Big bangを避け、機能・データ・ユーザーを段階的に切替える。
2. 並行稼働： 一定期間は旧新を併用し、業務影響を緩衝する。
3. 可逆性（ロールバック）： 戻す条件・判断者・手順を先に決める。^2,3

※ 原則はプロジェクト規模や重要度に応じて軽重を調整します（固定ではなく“方針”）。

3. 全期間をつなぐ設計サイクル（計画→検証→移行→学び）

3.1 計画初期：リスクを“前提”として設計する

• リスク登録票を作る（対象：システム／データ／業務／権限／外部連携／人・体制）。
• 確率×影響で優先度を付け、暫定の対応方針（回避／低減／受容／移転）を記す。²
• 移行方針（段階移行・並行期間・暫定運用）を“構想段階”でたたき台化。

3.2 実行中：リスクを“更新”し、対策の現実性を上げる

• テストで得た知見をリスク登録票へ反映（確率・影響・対策の更新）。
• 移行リハーサルの準備（本番同等のデータ量・接続・権限での事前検証）。¹
• 移行Runbookの素案作成（役割、時刻表、連絡網、停止許容、復旧手順）。

3.3 終盤：設計どおり“安全に発動”させる

• 段階移行マップに沿って切替（機能→データ→ユーザーの順など、事前合意の順序）。
• ロールバック判定票で可逆性を担保（中止閾値→YES/NO分岐、決裁者を明記）。
• 並行稼働チェックで照合（照合条件・差異対応・終了条件）。³

3.4 運用：学びを“次回の前提”に戻す

• 事後レビューで“効いた対策／過剰だった対策”を棚卸し、標準へ反映。
• 次回以降の移行テンプレ（Runbook／判定票／チェック表）を更新し再利用。

4. 最少セット（これだけは用意する3枚）

• 移行Runbook： 当日のタイムライン、役割、連絡網、停止許容、復旧手順。
• ロールバック判定票： 中止閾値（性能・品質・業務影響）と決裁者、分岐後の手順。
• 並行稼働チェック表： 照合条件（件数・金額・件別）、差異の対応フロー、終了条件。

規模や重要度に応じて詳細化しますが、「3枚基盤」があるだけで切替はぐっと安定します。

5. DreamOnの役割（伴走支援の範囲）

• リスク登録票の設計・ワークショップ運営（関係者の視点を統合）。
• 段階移行マップ／Runbook／判定票／チェック表テンプレの提供と初期整備。
• 移行リハーサルの設計と当日サポート（判断・記録・改善点の反映）。
• 事後レビューの設計（学びの標準化と次回の前提化）。

参考文献

1. 1. IPA（情報処理推進機構）『ITプロジェクトの実態調査』（2020）— 事前検証不足が移行失敗の主要因に。
2. 2. Project Management Institute (2017) 『PMBOK® Guide – Sixth Edition』— リスク計画・対応を計画段階から統合。
3. 3. 経済産業省『DX白書2023』（2023）— 大規模移行では段階導入・並行稼働・可逆性の確保を推奨。