LESSON 30分

ストーリー

田
田中VPoE
新規プロジェクトはテンプレートで標準に準拠させられる。だが既存のサービスはどうする？
あなた
既存サービスを標準に移行するのは大変ですよね。稼働中のシステムをいじるわけですから
あ
田
田中VPoE
だからこそ「マイグレーション支援」が重要だ。移行は「やれ」と言うだけでは進まない。計画、ツール、サポート体制を整えて初めて動き出す。標準を策定した側に移行を支援する責任がある

マイグレーション戦略

3つのアプローチ

アプローチ特徴適用場面リスク
Big Bang一気に全面移行小規模サービス、停止可能な場合高い
Strangler Fig段階的に新旧を共存させながら移行大規模サービス、停止不可の場合低〜中
Branch by Abstraction抽象化レイヤーを挟んで段階的に移行ライブラリ・フレームワークの変更低い

Strangler Fig パターンの詳細

Strangler Fig（絞め殺しパターン）:

Phase 1: 共存準備
  旧サービス ← 全トラフィック
  新サービス（準備中）

Phase 2: 並行稼動
  旧サービス ← 90% のトラフィック
  新サービス ← 10% のトラフィック（カナリア）

Phase 3: 段階的移行
  旧サービス ← 20% のトラフィック
  新サービス ← 80% のトラフィック

Phase 4: 完全移行
  旧サービス（廃止）
  新サービス ← 100% のトラフィック

マイグレーション計画書

計画書テンプレート

セクション内容
対象移行するサービス・コンポーネント
移行元/移行先現在の技術と移行後の技術
移行アプローチBig Bang / Strangler Fig / Branch by Abstraction
スケジュールフェーズごとの期間とマイルストーン
リスク想定されるリスクと緩和策
ロールバック計画問題が発生した場合の切り戻し手順
テスト計画移行後の動作確認手順
完了基準移行が「完了」と判断する条件

移行チェックリスト

フェーズチェック項目
移行前バックアップの取得、ロールバック手順の確認、関係者への通知
移行中モニタリングの強化、エラー率の監視、パフォーマンスの確認
移行後動作確認テストの実施、旧環境のクリーンアップ、ドキュメント更新

移行支援体制

移行支援チームの役割

役割担当責務
移行アーキテクト技術標準委員会メンバー移行方針の策定、技術的な支援
移行パートナー先行チームの経験者移行実施チームへのペアリング・サポート
QAサポートQAチームテスト計画の支援、テスト実施の補助

移行のプリンシプル

原則説明
ビジネスを止めない移行は通常のサービス運用を妨げない方法で行う
段階的に進める一度にすべてを変えず、小さなステップで進む
ロールバック可能いつでも元の状態に戻せる状態を維持する
テストで担保移行の正しさは手動確認ではなく自動テストで担保する
移行に専用の時間を確保「ついでに移行」ではなく、専用のスプリントを設ける

移行の定量管理

進捗トラッキング

指標測定方法報告頻度
移行完了サービス数標準準拠チェック月次
移行進捗率完了 / 対象全体月次
移行による障害件数インシデントレポート都度
移行コスト（実績）工数トラッキング月次

「移行支援なき標準は”絵に描いた餅”だ。標準を作った側が、移行を支援する責任を持つ。これが標準策定者の義務だ」 — 田中VPoE

まとめ

ポイント内容
3つのアプローチBig Bang、Strangler Fig、Branch by Abstraction
計画書対象、アプローチ、スケジュール、リスク、ロールバック計画
支援体制移行アーキテクト、移行パートナー、QAサポートの3役割
原則ビジネスを止めない、段階的、ロールバック可能、テストで担保

チェックリスト

  • 3つの移行アプローチの使い分けを理解した
  • マイグレーション計画書の構成を理解した
  • 移行支援体制の役割を理解した
  • 移行の原則（ビジネス継続、段階的、ロールバック可能）を理解した

次のステップへ

次は演習「標準普及計画を策定しよう」に進みます。Step 4で学んだ採用促進、ツーリング、教育、マイグレーション支援を統合した実践演習です。

推定読了時間: 30分