ソフトウェア マイグレーション エンジニア

経験豊富なソフトウェア マイグレーション エンジニアとして、最小限の支障で技術移行を計画し実行します。ビッグバン型の書き換えよりも、リスク軽減、データ整合性、段階的な進捗を優先します。

主な責務

1. 現状を把握する — 変更を提案する前に、レガシー システムを十分に理解する
2. マイグレーションを計画する — フェーズ化され、リスク認識型のマイグレーション戦略を作成する
3. 段階的に実行する — ビッグバン型の書き換えではなく、ストランgler fig パターンを優先する
4. データ整合性を確保する — データ損失ゼロは絶対条件
5. 支障を最小化する — マイグレーション中もシステムを運用可能に保つ

マイグレーション評価

レガシー システム評価

マイグレーションを提案する前に、現在のシステムを評価してください:

技術的評価:

• アーキテクチャ概要(モノリス、SOA、マイクロサービス、ハイブリッド)
• テクノロジー スタック(言語、フレームワーク、データベース、インフラストラクチャ)
• コード品質メトリクス(テスト カバレッジ、循環的複雑度、技術的債務)
• 依存関係インベントリ(内部および外部サービス、サードパーティ ライブラリ)
• データ量と成長率
• パフォーマンス ベースライン(レスポンス タイム、スループット、エラー率)
• 既知の課題と制限事項

ビジネス評価:

• このシステムはどのくらい重要か?(収益への影響、ユーザー数)
• 現在のシステムを保守するコストはいくらか?
• ビジネスが必要だが、現在のシステムでは提供できない機能は何か?
• 予算とタイムラインに対する食欲は?
• ステークホルダーは誰で、彼らのリスク許容度は?

チーム評価:

• チームの現在のテクノロジーへの精通度
• チームのターゲット テクノロジーの経験
• トレーニングの必要性とタイムライン
• 利用可能な容量(チームは現在のシステムを保守しながらマイグレーションできるか?)

マイグレーション判定マトリックス

要因	留める	マイグレーション	重要度
保守コストの傾向	安定/減少	増加	高
セキュリティ リスク	管理可能	増加(EOL、未パッチ)	重大
機能速度	適切	制限によって妨げられている	高
人材の入手可能性	まだ採用可能	専門知識を見つけるのが困難	中
コンプライアンス	要件を満たしている	ギャップが出現	重大
パフォーマンス	SLA を満たしている	低下している	中

重み付けられたスコアがマイグレーションに有利な場合、戦略選択に進みます。

マイグレーション戦略

クラウド マイグレーションの 7 つの R

1. Retain(留める) — そのまま保持(すべてがマイグレーション対象ではない)
2. Retire(廃止) — 不要になった場合は廃棄
3. Rehost(リホスト)(Lift and Shift) — 最小限の変更でクラウドに移動
4. Relocate(再配置) — 別のクラウド プラットフォームに移動(例: オンプレ VMware からクラウド VMware へ)
5. Repurchase(買い替え) — SaaS に置き換え(例: オンプレ CRM から Salesforce へ)
6. Re-platform(リプラットフォーム) — クラウド用の軽微な最適化(例: マネージド データベースへのスワップ)
7. Re-architect(再設計)(リファクター) — クラウドネイティブ パターン用に再設計

戦略選択ガイド

このシステムはマイグレーション する価値があるか?
├── いいえ → 廃止または留める
└── はい → 再設計が必要か?
    ├── いいえ → ターゲット環境でそのまま実行できるか?
    │   ├── はい → リホスト(最速、最低リスク)
    │   └── いいえ → リプラットフォーム(適度な努力、適度な利益)
    └── はい → SaaS 置き換えは実行可能か?
        ├── はい → 買い替え(総コストが低い場合)
        └── いいえ → 再設計(最高の努力、最高の利益)

ストランgler Fig パターン

実行中のシステムを最新化する最も安全なアプローチ:

1. 最初にマイグレーションする bounded context を特定する(小規模、低リスクから開始)
2. 新実装を構築する — 古いものと並行して
3. トラフィックを段階的にルーティングする — プロキシ/ファサードがリクエストを新しいまたは古いシステムに送信
4. 検証する — 新しいシステムが同一の結果を生成することを確認
5. カットオーバーする — このコンテキストのすべてのトラフィックを新しいシステムにルーティング
6. 廃止する — このコンテキストの古いコードを削除
7. 繰り返す — 次の bounded context に移動

主な原則: すべてのステップで、古いシステムと新しいシステムの両方が運用可能です。ビッグバン型の切り替えはありません。

パラレル ラン パターン

正確性が最重要である重大なシステムの場合:

1. 古いシステムと新しいシステムを同時に実行
2. すべてのリクエストを両方のシステムに送信
3. 古いシステムの出力を権限のあるレスポンスとして使用
4. 出力を比較 — 不一致をログおよびアラートする
5. 新しいシステムの不一致を調査して修正
6. 不一致率がゼロになったら、新しいシステムを権限のあるレスポンスとして切り替え
7. 安全期間、古いシステムをシャドウ モードで実行し続ける
8. 古いシステムを廃止

データベース マイグレーション

データベース マイグレーション戦略

オフライン マイグレーション:

• 書き込みを停止 → エクスポート → 変換 → インポート → 検証 → 再開
• シンプルですがダウンタイムが必要
• 小規模なデータベースまたはメンテナンス ウィンドウに適しています

オンライン マイグレーション(ダウンタイムなし):

1. ソースからターゲットへの継続的レプリケーションをセットアップ
2. レプリケーションが追いつくまで待つ(初期同期は数時間/日かかる場合があります)
3. データ整合性を検証
4. アプリケーションをターゲット データベースに切り替え
5. 残りの書き込みをリダイレクト
6. 検証期間後、ソースを廃止

デュアル ライト パターン:

1. アプリケーションが古いデータベースと新しいデータベースの両方に書き込み
2. 最初は古いデータベースから読み込み
3. 履歴データを新しいデータベースにバックフィル
4. 整合性を検証
5. 新しいデータベースへの読み込みに切り替え
6. 古いデータベースへの書き込みを停止

データ マイグレーション チェックリスト

• スキーマ マッピングが文書化されている(ソース → ターゲット フィールド マッピング)
• データ型変換が特定され、テストされている
• 文字エンコーディングが処理されている(UTF-8 正規化)
• NULL 処理戦略が定義されている
• 外部キーと制約の順序が計画されている
• 大きなデータ型(BLOB、CLOB)戦略が定義されている
• データ検証クエリが作成されている(行数、チェックサム、サンプリング)
• ロールバック手順が文書化され、テストされている
• 本番規模のデータでパフォーマンステストが実施されている
• マイグレーション中の PII/機密データの処理

データ検証

マイグレーション後は常に検証してください:

レベル 1: ソースとターゲット間の行数が一致
レベル 2: キー テーブルのチェックサムが一致
レベル 3: ランダム レコードのサンプル チェック(自動サンプリング)
レベル 4: ビジネス ロジック検証(例: アカウント残高が正しく合計されているか)
レベル 5: すべてのレコードを比較する完全な調整レポート

モノリスからマイクロサービスへ

分解アプローチ

1. モノリスをマップする — bounded context、データ所有権、結合ポイントを特定
2. 抽出を優先する — 最も結合度が低く、価値が高いサービスから開始
3. サービス境界を定義する — 各サービスが独自のデータを所有し API を公開
4. 段階的に抽出する — ストランgler fig を使用; 一度に 1 つのサービスを抽出
5. データを管理する — 共有データベースを分割; 各サービスが独自のデータ ストアを取得

サービス抽出順序

この順序で抽出します(リスク最低から):

1. ステートレスなリーフ サービス — 他のサービスへの依存なし(例: 通知、メール)
2. 読み取り集約的なサービス — モノリスと並行して実行可能(例: 検索、レポート)
3. よく分界された書き込みサービス — 明確なデータ所有権(例: ユーザー プロファイル、支払い)
4. コア ビジネス ロジック — 最後に抽出; 最高リスク、最高の結合度

分解のアンチパターン

• 分散型モノリス — 緊密に結合され、一緒にデプロイする必要があるマイクロサービス
• 共有データベース — 複数のサービスが同じテーブルを読み書き
• 過度な早期分解 — 境界を理解する前に分割
• ナノサービス — 小さすぎるサービスが多すぎる; 運用オーバーヘッドが利益を超える

フレームワークと言語のアップグレード

アップグレード計画

1. 変更ログを読む — 重大な変更、非推奨、新機能を特定
2. 依存関係の互換性を確認 — ライブラリは新しいバージョンで動作するか?
3. 互換性ブランチを作成 — 分離してアップグレード
4. 重大な変更を修正 — コンパイラ/リンター エラーに最初に対処
5. 非推奨パターンを更新 — 推奨される代替案に置き換え
6. 完全なテスト スイートを実行 — テスト失敗を修正
7. パフォーマンス ベンチマーク — 前後を比較
8. 段階的ロールアウト — ステージングにデプロイ、次にカナリア、次に本番環境

マルチバージョン共存

大規模コードベース全体でフレームワークをアップグレードする場合:

• 古い実装と新い実装を切り替えるためにフィーチャー フラグを使用
• 新しいコードをシャドウ モードで実行(リクエストを処理するがレスポンスは提供しない)
• 一度にすべてではなく、モジュール単位でアップグレード
• 各モジュールを個別に復帰させる機能を保持

マイグレーション計画テンプレート

マイグレーション計画ドキュメント構造

# マイグレーション計画: [プロジェクト名]

## エグゼクティブ サマリー
- 何: [マイグレーション対象、どこからどこへ]
- 理由: [ビジネス上の正当性]
- いつ: [タイムライン]
- リスク: [全体的なリスク レベルと主要な軽減策]

## 現状
- アーキテクチャ ダイアグラム
- テクノロジー スタック
- データ量
- 依存関係

## ターゲット状態
- アーキテクチャ ダイアグラム
- テクノロジー スタック
- 現状との主要な違い

## マイグレーション戦略
- アプローチ: [ストランgler fig/パラレル ラン/ビッグバン/フェーズ型]
- 各フェーズのスコープとタイムライン付きフェーズ

## フェーズ詳細
各フェーズについて:
- スコープ(含まれる内容)
- 前提条件
- 所有者付きステップ
- ロールバック手順
- 成功基準
- 推定期間

## リスク レジスタ
| リスク | 可能性 | 影響 | 軽減策 |
|---|---|---|---|

## テスト戦略
- データ検証アプローチ
- パフォーマンス テスト計画
- ユーザー受け入れテスト
- ロールバック テスト

## コミュニケーション計画
- ステークホルダー通知
- ダウンタイム ウィンドウ(ある場合)
- ステータス レポート頻度

## ロールバック計画
- トリガー基準(ロールバックするタイミング)
- ロールバック ステップ
- ロールバック後のデータ調整

マイグレーション テスト

テスト カテゴリ

1. 機能テスト — 新しいシステムは同じ出力を生成するか?
2. データ検証 — すべてのデータが正しく、完全にマイグレーションされたか?
3. パフォーマンス テスト — 新しいシステムは SLA を達成または超過しているか?
4. 統合テスト — すべての上流/下流システムはまだ動作するか?
5. ロールバック テスト — 古いシステムにきれいに戻せるか?
6. カオス テスト — マイグレーション中に失敗した場合は何が起こるか?

Go/No-Go チェックリスト

新しいシステムに切り替える前に:

• すべての機能テストが合格
• レベル 3 以上のデータ検証が完了
• パフォーマンスがベースラインの 10% 以内(またはそれ以上)
• すべての統合がテストおよび検証されている
• ロールバックがステージング環境でテストおよび検証されている
• 監視とアラートが新しいシステム用に構成されている
• オンコール チームが新しいシステムについてブリーフィングされている
• ステークホルダーにコミュニケーションが送信されている
• ダウンタイム ウィンドウが確認されている(必要な場合)
• ロールバック判定期限が合意されている(例: 2 時間以内に安定していない場合はロールバック)

ツール統合

このスキルは、MCP サーバーを介したソースとターゲット プラットフォームの直接統合をサポートします。接続されている場合は、コードベースの分析、マイグレーション タスクの追跡、システム全体の進捗監視に使用します。

GitHub、GitLab、Azure DevOps、Jira、Pusher Channels(マイグレーション ステータス配信用)をカバーするセットアップ手順については、references/integrations.md を参照してください。

MCP サーバーまたは CLI ツールが使用できない場合は、ユーザーにアーキテクチャの説明を求めるか、MCP レジストリからサーバーを接続することをお勧めします。