migration-readiness

移行準備状況の評価

ステップ 1：コンテキストの収集

ユーザーに次の内容を尋ねます。

どのワークロードの移行を計画していますか？次の情報を共有してください。

• ワークロード名と分析対象のコードパッケージ／ディレクトリ
• 現在の環境（オンプレミス、他のクラウド、コロケーション）
• ビジネス上の推進要因（コスト、俊敏性、コンプライアンス、ハードウェアのサポート終了など）
• タイムラインの制約（任意）

コンテキストがすでに提供されている場合、またはコードベース内にいる場合は、そのまま次に進みます。

ステップ 2：アプリケーションスタックの検出

コードベースを分析し、現在のアプリケーションスタックを把握します。

必ず次の項目を調査します。

• プログラミング言語とランタイム（バージョン、AWS サービスとの互換性）
• フレームワークとライブラリ（Web フレームワーク、ORM、メッセージング）
• データベース技術（リレーショナル、NoSQL、検索、キャッシュ）
• ミドルウェアとメッセージブローカー
• 外部サービスへの依存関係（API、SaaS 統合）
• 構成管理（構成ファイル、環境変数、シークレット）
• OS への依存関係とシステムレベルの要件
• ビルドおよびパッケージングシステム（Maven、npm、pip、Docker）

各コンポーネントについて、次の内容を記録します。

• ファイルパスと行番号
• テクノロジーとバージョン
• AWS の同等サービスまたは移行パス
• 移行の複雑さ（単純なリホスト、変更が必要、書き換えが必要）
• 他のコンポーネントへの依存関係

次の項目は必ずブロッカーとしてフラグを付けます。

• クラウドに同等のものがない OS 固有の依存関係
• ライセンス上の制約があるプロプライエタリソフトウェア（Oracle、特定の Windows 機能）
• ハードウェア固有の依存関係（FPGA、特定の CPU 命令、USB ドングル）
• アプリケーションコードにハードコードされた IP アドレスまたはホスト名
• ローカルファイルシステムへの依存関係（共有ネットワークドライブ、ローカルストレージ）

ステップ 3：インフラストラクチャの検出

既存のインフラストラクチャ構成を分析します。

必ず次の項目を調査します。

• サーバー構成（CPU、メモリ、ストレージ要件）
• ネットワークトポロジー（VLAN、ファイアウォール、ロードバランサー、DNS）
• ストレージシステム（SAN、NAS、ローカルディスク、ファイル共有）
• データベース構成（エンジン、バージョン、サイズ、レプリケーション）
• モニタリングおよびアラートシステム
• バックアップおよび DR 構成
• セキュリティ制御（ファイアウォール、IDS/IPS、WAF、証明書）
• 既存の IaC（Terraform、Ansible、Chef、Puppet）があれば、その内容

各インフラストラクチャコンポーネントについて、次の内容を記録します。

• 現在の構成
• AWS の同等サービス
• 移行アプローチ（リホスト、リプラットフォーム、リファクタリング）
• データ量と転送に関する考慮事項

ステップ 4：依存関係のマッピング

すべての内部および外部依存関係をマッピングします。

必ず以下を調査してください。

• サービス間通信（プロトコル、ポート、パターン）
• データベース接続（接続文字列、コネクションプーリング、複数の利用者）
• 共有データベースまたはデータストア（複数のサービスによる書き込み／読み取り）
• 外部 API 統合（サードパーティサービス、パートナー API）
• ネットワーク依存関係（レイテンシの影響を受けやすい接続、VPN トンネル）
• バッチジョブの依存関係（スケジュール、実行順序）
• 認証／認可の依存関係（LDAP、AD、SSO）

以下を示す依存関係図を必ず作成してください。

• すべてのサービスとその接続
• データフローとプロトコル
• 外部依存関係
• 移行ウェーブのグループ分け（同時に移行する必要があるもの）

以下は必ず高リスクとして示してください。

• 同時に移行する必要があるコンポーネント間の密結合（影響範囲が拡大します）
• 複数のサービスからアクセスされる共有データベース（移行順序の制約）
• 移行中にハイブリッド環境をまたぐことになる、レイテンシの影響を受けやすい統合
• 移行できないオンプレミスシステムへの強い依存関係（ハイブリッド接続が必要）

---STOP--- チェックポイント：検出と依存関係のマッピングが完了しました。移行戦略を決定する準備ができています。

アプリケーションスタック（{X} 個のコンポーネント）、インフラストラクチャ構成、依存関係をマッピングしました。{Y} 個のブロッカー、{Z} 件の高リスク依存関係（共有データベース、レイテンシの影響を受けやすい統合）、および移行ウェーブのグループ分けを特定しました。

各コンポーネントの移行戦略（7 Rs）の決定と、柱ごとの準備状況の評価に進めてもよろしいですか？

ユーザーが明示的に確認するまで、この時点から先に進まないでください。

ステップ 5：移行戦略（7 Rs）の決定

各コンポーネントについて、コードの証拠に基づいて適切な戦略を評価します。

戦略	使用する状況	コードの指標
Rehost	迅速な移行、変更を最小限に抑える	標準的な OS、コンテナ化可能、OS 固有の依存関係がない
Replatform	移行時に小規模な最適化を行う	セルフマネージド DB → RDS、セルフマネージドキャッシュ → ElastiCache
Refactor	クラウドネイティブのメリットが必要	分解すべきモノリス、ステートフル → ステートレス
Repurchase	SaaS に置き換える	AWS／SaaS 相当の製品がある商用ソフトウェア
Retire	もはや必要ない	未使用のコード、非推奨のサービス
Retain	移行の準備ができていない	強い依存関係、コンプライアンス上のブロッカー
Relocate	VMware ワークロード	VMware 固有の構成

各推奨事項はコードの証拠に基づいて必ず正当化してください。

ステップ 6：柱ごとの準備状況の評価

各柱について、準備状況（準備完了／条件付きで準備完了／未準備）、証拠（ファイル：行）、ギャップ、必要な対応を提示してください。

オペレーショナルエクセレンスの準備状況

• IaC がありますか？（CloudFormation、Terraform、CDK、Ansible）
• CI/CD パイプラインは整備されていますか？AWS を対象にできますか？
• モニタリングは移植可能ですか、それとも特定のツールに依存していますか？
• 運用手順は文書化されていますか？

セキュリティの準備状況

• リージョンやサービスの選択に影響するコンプライアンス要件はありますか？
• シークレットはどのように管理されていますか？（ハードコード、ボールト、構成ファイル）
• 代替手段が必要なネットワークセキュリティ上の依存関係はありますか？
• ID 管理は AWS IAM／Identity Center と互換性がありますか？

信頼性の準備状況

• 現在の可用性はどの程度ですか？目標は何ですか？
• 複製すべき HA の仕組みはありますか？
• 移行中に許容できるダウンタイムはどの程度ですか？
• バックアップ／復旧手順はテスト済みですか？

パフォーマンス効率の準備状況

• レイテンシの影響を受けやすい統合はありますか？
• ハードウェア固有の依存関係はありますか？
• 現在のパフォーマンスベースラインはどのようになっていますか？
• 切り替え中に維持すべき SLA はありますか？

コスト最適化の準備状況

• 現在の TCO はどのくらいですか？（ハードウェア、ライセンス、運用、設備）
• ライセンスへの影響はありますか？（BYOL、ライセンス込み、再購入）
• 既存の契約または前払いのコミットメントはありますか？

サステナビリティへの対応状況

• 移行によってリソースの使用量を削減できますか？
• Graviton／サーバーレスを活用できる余地はありますか？
• マネージドサービスでセルフマネージドのインフラストラクチャを置き換えられますか？

ステップ 7：リスク評価

各リスクを、影響度 × 発生可能性で評価します。

影響度：軽微（スケジュールの遅れ、軽微な手戻り）｜中程度（大幅な手戻り、ハイブリッド環境の長期化）｜重大（移行の失敗、データ損失、長期にわたる停止）

発生可能性：低（適切に計画すれば可能性は低い）｜中（具体的な緩和策がなければ起こり得る）｜高（現在の状況を踏まえると起こる可能性が高い）

影響度	発生可能性	リスクレベル
重大	高	クリティカル
重大	中	高
重大	低	高
中程度	高	高
中程度	中	中
中程度	低	中
軽微	高	中
軽微	中	低
軽微	低	低

---STOP--- チェックポイント：リスク評価が完了しました — 最終的な移行評価を作成できます

移行に関する {N} 件のリスクを評価しました。リスクの内訳：クリティカル {X} 件、高 {Y} 件、中 {Z} 件、低 {W} 件。全体的な準備状況：{Ready / Conditionally Ready / Not Ready}。重大な阻害要因と緩和策を特定しました。

移行計画とコスト比較を含む、移行準備状況の完全な評価を作成しますか？

ユーザーが明示的に確認するまで、この先に進まないでください。

ステップ 8：評価を作成する

# Migration Readiness Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Recommended Strategy**: {primary strategy}
- **Overall Readiness**: {Ready / Conditionally Ready / Not Ready}
- **Estimated Effort**: {T-shirt size with justification}
- **Key Risks**: {top 3}
- **Critical Blockers**: {count and brief description}

## Application Stack Summary
| Component | Technology | Version | AWS Equivalent | Strategy | Complexity |
|-----------|-----------|---------|---------------|----------|------------|
| {name} | {tech} | {ver} | {aws service} | {7R} | {Low/Med/High} |

## Dependency Map
{PlantUML diagram showing service dependencies, data flows, and migration wave groupings}

## Readiness Scorecard
| Pillar | Readiness | Score (1-5) | Key Blocker | Action Needed |
|--------|-----------|-------------|-------------|---------------|
| Operational Excellence | {status} | {score} | {blocker} | {action} |
| Security | {status} | {score} | {blocker} | {action} |
| Reliability | {status} | {score} | {blocker} | {action} |
| Performance Efficiency | {status} | {score} | {blocker} | {action} |
| Cost Optimization | {status} | {score} | {blocker} | {action} |
| Sustainability | {status} | {score} | {blocker} | {action} |

## Critical Blockers
{For each: ID, description, evidence (file:line), impact on migration, resolution approach, effort}

## Risks and Mitigations
| Risk | Evidence | Risk Level | Migration Impact | Mitigation | AWS Service |
|------|----------|------------|-----------------|------------|-------------|
| {risk} | {file:line} | {level} | {impact} | {mitigation} | {service} |

## Pre-Migration Checklist
{Ordered by priority — what must be done before migration starts}
- [ ] {action with evidence of why it's needed}

## Migration Plan

### Phase 1: Mobilize (Weeks 1-2)
| Task | Dependencies | AWS Service | Evidence |
|------|-------------|-------------|----------|
{Landing zone, connectivity, tooling setup}

### Phase 2: Migrate (Weeks 3-6)
| Wave | Components | Strategy | Data Volume | Downtime Window |
|------|-----------|----------|-------------|-----------------|
{Component migration waves based on dependency analysis}

### Phase 3: Optimize (Weeks 7-8)
| Optimization | Component | Expected Benefit | AWS Service |
|-------------|-----------|-----------------|-------------|
{Right-sizing, managed services, serverless, Graviton}

## AWS Services for Migration
| Category | Service | Purpose | Relevant Components |
|----------|---------|---------|-------------------|
| Server | AWS MGN | Rehost EC2 | {components} |
| Database | AWS DMS | Replicate with minimal downtime | {components} |
| Data | DataSync / Snowball | Large-scale transfer | {components} |
| Schema | AWS SCT | Schema conversion | {components} |
| Network | Direct Connect / VPN | Hybrid connectivity | {components} |
| Governance | Control Tower | Multi-account | All |

## Cost Comparison
| Category | Current (monthly est.) | AWS Estimated | Delta | Notes |
|----------|----------------------|---------------|-------|-------|
| Compute | {estimate} | {estimate} | {delta} | {basis} |
| Storage | {estimate} | {estimate} | {delta} | {basis} |
| Networking | {estimate} | {estimate} | {delta} | {basis} |
| Licensing | {estimate} | {estimate} | {delta} | {basis} |
| Operations | {estimate} | {estimate} | {delta} | {basis} |

## Next Steps
{Top 5 concrete actions the team should take this week to prepare}

ステップ 9：次の対応を提案する

評価を提示した後、次の項目を提案します。

次の対応を行いましょうか？

• AWS ランディングゾーンのアーキテクチャを設計する
• 特定のデータベース向けに詳細なデータ移行計画を作成する
• 特定のコンポーネントの AWS コストを詳細に見積もる
• 移行前のテスト戦略を策定する
• ハイブリッド接続アーキテクチャを設計する
• 移行先の AWS アーキテクチャ向けに IaC を作成する

評価の指針

• すでにコンテナ化され、CI/CD と IaC が導入されているワークロードは、準備が「おおむね整っています」— AWS 固有の最適化とデータ移行計画に注力してください
• すべての阻害要因とリスクには、必ずコード上の根拠が必要です — 実際の依存関係を確認せずに「ライセンスリスク」を指摘しないでください
• 移行戦略の推奨事項は、コード分析に基づいて正当化する必要があります（推測に基づいてはいけません）
• 「判断できません」は、コードから確認できない実行時の特性（例：実際のデータ量、ネットワーク遅延の要件）に対して有効です
• 共有データベースについては、必ず移行順序の制約を指摘してください — これが移行の複雑さを招く最大の原因です
• 静的分析に基づくコスト見積もりは概算です — 不確実性を明示し、正確な見積もりには AWS Pricing Calculator の利用を推奨してください
• 移行準備が整っている点（コンテナ化、ステートレス、IaC がすでに存在すること）を明確に示してください