移行計画とフェーズ設計 - L0 カリキュラム

ストーリー

佐

佐藤CTO

設計図は完成した。だが、“一夜にして完成形に置き換える”なんてことはしない

佐

佐藤CTO

NexPayは新規開発だが、実際のプロジェクトでは既存システムからの移行が必ずある。レガシーシステムからの段階的な移行を前提に、フェーズを設計する力が必要だ

佐

佐藤CTO

どの順番で作り、どうやって安全にリリースするか — 移行計画こそがアーキテクトの腕の見せどころだ

移行パターン

Strangler Fig パターン

段階的移行の定番パターンです。新しいサービスを既存システムの隣に構築し、トラフィックを段階的に切り替えます。

Strangler Fig パターンの適用:

Phase 1: 共存期間
┌──────────────────────────────────────────┐
│                API Gateway                │
│         (ルーティング制御)                  │
└────┬─────────────────────────┬───────────┘
     │ /api/v2/payments        │ /api/v1/*（その他）
     ▼                        ▼
┌──────────┐            ┌──────────┐
│ 新: Payment│            │ 旧: モノリス│
│ Service   │            │          │
│ (Kotlin)  │            │ (Legacy) │
└──────────┘            └──────────┘

Phase 2: 移行拡大
  → 送金、投資も新サービスに移行
  → モノリスの担当範囲が縮小

Phase 3: 完了
  → モノリスを完全に廃止
  → API Gatewayのルーティングを簡素化

Big Bang vs 段階的移行

観点	Big Bang	段階的移行
リスク	極めて高い	各フェーズで制御可能
ビジネス停止	長期間の機能凍結	並行してリリース継続
ロールバック	困難（全体を戻す）	フェーズ単位で可能
完了までの期間	短い（理論上）	長い
適用ケース	小規模システム	大規模本番システム

「フィンテックでBig Bang移行を選ぶのは自殺行為だ。決済を1秒たりとも止められないNexPayでは、段階的移行が唯一の現実解だ」 — 佐藤CTO

NexPayの移行フェーズ

全体タイムライン

NexPay 構築・移行タイムライン（18ヶ月）:

Month  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18
       ├──────────┤
       Phase 0: 基盤構築
       │EKS, CI/CD, 監視基盤│

                  ├──────────────┤
                  Phase 1: 決済基盤
                  │Payment, Account Service│
                  │内部テスト→パイロット加盟店│

                                 ├──────────────┤
                                 Phase 2: 拡張
                                 │Transfer, KYC, Investment│
                                 │パイロット→一般公開│

                                                ├──────────────┤
                                                Phase 3: 最適化
                                                │AI不正検知、分析基盤│
                                                │スケーリング検証│

                                                               ├────┤
                                                               Phase 4
                                                               │レガシー廃止│

Phase 0: 基盤構築（Month 1-3）

■ Phase 0: 基盤構築

目標: 開発チームが自律的にサービスを開発・デプロイできる基盤を整備

成果物:
  - EKSクラスター（東京 + 大阪）
  - CI/CDパイプライン（GitHub Actions + Argo CD）
  - 可観測性基盤（Grafana Stack + OpenTelemetry）
  - IaCリポジトリ（Terraform + Terragrunt）
  - 開発環境テンプレート（サービス雛形）
  - セキュリティ基盤（Istio + Vault + OPA）

完了基準:
  - サービス雛形からのデプロイが30分以内に完了
  - CI/CDパイプラインが全ステージパス
  - 監視ダッシュボードが稼働
  - チーム全員がローカル開発環境を構築済み

リスク:
  - EKSクラスターの構成に想定以上の時間
  対策: マネージドサービスを最大活用。カスタマイズは最小限

Phase 1: 決済基盤（Month 4-7）

■ Phase 1: 決済基盤

目標: 決済と残高管理の中核サービスを構築し、パイロット運用を開始

構築順序:
  1. Account Service（残高管理）
  2. Payment Service（決済処理）
  3. Tokenization Service（カード情報のトークン化）
  4. API Gateway + BFF

マイルストーン:
  Month 4: Account ServiceのMVP完成。単体テスト完了
  Month 5: Payment Serviceの実装。インテグレーションテスト
  Month 6: E2Eテスト、セキュリティ監査、PCI DSS準備
  Month 7: パイロット加盟店（5社）での限定リリース

パイロット基準:
  - 取引量: 1日100件以下（段階的に増加）
  - 対象: 低リスクの加盟店（小額決済中心）
  - 監視: 全取引をリアルタイムでSREが監視
  - ロールバック: 即座にレガシーシステムに切り戻し可能

Go/No-Go判定基準:
  ✅ 決済成功率 > 99.9%
  ✅ レイテンシ p99 < 800ms
  ✅ セキュリティ監査パス
  ✅ PCI DSS Self-Assessment完了
  ❌ 1つでも未達ならPhase 2に進まない

Phase 2: 拡張（Month 8-12）

■ Phase 2: サービス拡張

目標: 送金・KYC・投資サービスを追加し、一般公開へ

構築順序:
  1. KYC Service（本人確認 -- 送金の前提条件）
  2. Transfer Service（銀行送金）
  3. Investment Service（投資機能）
  4. Notification Service（通知基盤）

段階的リリース:
  Month 8-9: KYC + Transfer Service構築
  Month 10: 送金機能のパイロットリリース（招待制）
  Month 11: 投資機能のパイロットリリース
  Month 12: 全機能の一般公開

データ移行:
  - レガシーDBからの移行はETLパイプラインで実施
  - 二重書き込み期間を設け、データ整合性を検証
  - 差分検証ツールで旧DB/新DBの不一致を検出

Phase 3-4: 最適化とレガシー廃止（Month 13-18）

■ Phase 3: 最適化（Month 13-16）

  - AI不正検知エンジンの導入
  - 分析基盤（データレイク + BI）の構築
  - パフォーマンスチューニング（負荷テスト結果に基づく）
  - マルチリージョンDR構成の完全稼働

■ Phase 4: レガシー廃止（Month 17-18）

  - 残存トラフィックの新システムへの完全切り替え
  - レガシーシステムの段階的シャットダウン
  - データアーカイブ（法定保存期間を考慮）
  - 廃止後の運用ドキュメント更新

移行リスクと対策

リスクマトリクス

リスク	影響度	発生確率	対策
データ移行時の不整合	致命的	中	二重書き込み + 差分検証 + ロールバック手順
パフォーマンス劣化	高	中	各フェーズで負荷テスト。Canaryデプロイで段階的移行
チームのスキル不足	中	高	Phase 0で研修。ペアプログラミング。外部アーキテクト支援
スケジュール遅延	中	高	各フェーズにバッファ20%。スコープ調整可能な設計
外部API連携の障害	高	中	サンドボックスでの十分なテスト。Circuit Breaker

フェーズゲート

フェーズゲート（次のフェーズに進む判断基準）:

  Phase 0 → Phase 1:
    ✅ EKSクラスターが本番Ready
    ✅ CI/CDパイプラインが動作
    ✅ チーム全員がKotlin研修完了
    審査: エンジニアリングリード

  Phase 1 → Phase 2:
    ✅ 決済成功率 > 99.9%（パイロット期間）
    ✅ PCI DSS Self-Assessment完了
    ✅ セキュリティ監査指摘事項の対応完了
    審査: CTO + CISO

  Phase 2 → Phase 3:
    ✅ 全サービスの一般公開完了
    ✅ SLO達成率 > 99%（30日間）
    ✅ インシデント0件（重大障害）
    審査: 経営会議

  Phase 3 → Phase 4:
    ✅ レガシーシステムへのトラフィック0%
    ✅ データ移行の完全性検証完了
    ✅ 廃止影響の最終確認
    審査: CTO

まとめ

ポイント	内容
移行パターン	Strangler Figで段階的に移行。Big Bangは回避
フェーズ設計	基盤→決済→拡張→最適化→廃止の5フェーズ
パイロット	少数の加盟店で限定リリースし、本番データで検証
フェーズゲート	各フェーズの完了基準を明確に定義し、Go/No-Go判定
リスク管理	データ不整合、パフォーマンス劣化、スキル不足への対策

チェックリスト

Strangler Figパターンによる段階的移行を理解した
18ヶ月のフェーズ設計とマイルストーンを策定できた
パイロットリリースのGo/No-Go基準を定義できた
フェーズゲートの判定基準と審査者を設定できた
移行リスクと対策を特定できた

次のステップへ

次は「コスト見積もりとROI」に進みます。設計したアーキテクチャの構築・運用コストを見積もり、投資対効果を経営層に説明できるようにしましょう。

推定読了時間: 40分