framework-migration-legacy-modernize

レガシーコードのモダナイゼーションワークフロー

エキスパートエージェントの連携を通じて、ストラングラーフィグパターンを用いた包括的なレガシーシステムのモダナイゼーションを統括します。継続的な業務運用を維持しながら、古くなったコンポーネントを段階的に置き換えます。

[Extended thinking: 熱帯のイチジクの木が宿主を徐々に包み込み、置き換えていく様子にちなんで名付けられたストラングラーフィグパターンは、リスクを管理しながらレガシーシステムをモダナイズするための最良の方法です。このワークフローでは、新機能でレガシーコンポーネントを段階的に置き換え、移行中は両方のシステムを共存させる体系的なアプローチを実施します。評価、テスト、セキュリティ、実装を専門とするエージェントを統括し、各移行フェーズの検証を完了してから次へ進むことで、混乱を最小限に抑えながらモダナイゼーションの速度を最大化します。]

このスキルを使用する場面

• レガシーコードのモダナイゼーションワークフローに関するタスクやワークフローに取り組む場合
• レガシーコードのモダナイゼーションワークフローに関するガイダンス、ベストプラクティス、チェックリストが必要な場合

このスキルを使用しない場面

• タスクがレガシーコードのモダナイゼーションワークフローに関係しない場合
• この範囲外の別のドメインやツールが必要な場合

手順

• 目標、制約、必要な入力を明確にします。
• 関連するベストプラクティスを適用し、結果を検証します。
• 実行可能な手順と検証方法を提示します。

フェーズ 1：レガシーシステムの評価とリスク分析

以下のしきい値、割合、疑似コマンドのオプションは、計画時の例であり、インストール済みの CLI や保証された結果を示すものではありません。実際に利用可能なホストツールを使用し、許可されている場合に限って委任してください。トラフィックの切り替えや二重書き込みの前に、スキーマとデータの両方について、信頼できる唯一の情報源、冪等性、順序、照合、バックフィル、ロールバックを定義してください。二重書き込みは本質的に一貫性が保たれるわけではありません。行カバレッジにかかわらず、重要な動作を特性化してください。また、ウェブトラフィックが観測されなかっただけで廃止するのではなく、スケジュール実行、バッチ、オフラインの利用者と、保持および復旧に関する義務を確認してから廃止してください。本番環境への書き込みや削除、外部への連絡には、対象が明確な権限が必要です。

1. 包括的なレガシーシステム分析

• subagent_type="legacy-modernizer" を指定して Task ツールを使用します
• プロンプト：「$ARGUMENTS のレガシーコードベースを分析してください。次の項目を含む技術的負債の一覧を記録してください：古くなった依存関係、非推奨の API、セキュリティ脆弱性、パフォーマンスのボトルネック、アーキテクチャ上のアンチパターン。コンポーネントの複雑度スコア（1～10）、依存関係マッピング、データベース結合分析を含むモダナイゼーション準備状況レポートを作成してください。すぐに改善できる項目と、複雑なリファクタリングが必要な対象を特定してください。」
• 期待される出力：リスクマトリクスとモダナイゼーションの優先順位を含む詳細な評価レポート

2. 依存関係とインテグレーションのマッピング

• subagent_type="architect-review" を指定して Task ツールを使用します
• プロンプト：「レガシー評価レポートに基づき、次の項目を示す包括的な依存関係グラフを作成してください：内部モジュールの依存関係、外部サービスとの連携、共有データベーススキーマ、システム間のデータフロー。移行中にファサードパターンやアダプターレイヤーが必要となるインテグレーションポイントを特定してください。解消が必要な循環依存と密結合を明らかにしてください。」
• 前のステップからのコンテキスト：レガシー評価レポート、コンポーネントの複雑度スコア
• 期待される出力：依存関係のビジュアルマップとインテグレーションポイントの一覧

3. ビジネスへの影響とリスクの評価

• subagent_type="business-analytics::business-analyst" を指定して Task ツールを使用します
• プロンプト：「特定された各コンポーネントのモダナイゼーションがビジネスに与える影響を評価してください。次の点を考慮したリスク評価マトリクスを作成してください：ビジネス上の重要度（収益への影響）、ユーザートラフィックのパターン、データの機密性、規制要件、フォールバックの複雑さ。加重スコアリング方式を使ってコンポーネントの優先順位を決めてください：（ビジネス価値 × 0.4）+（技術リスク × 0.3）+（すぐに改善できる可能性 × 0.3）。各コンポーネントのロールバック戦略を定義してください。」
• 前のステップからのコンテキスト：コンポーネント一覧、依存関係マッピング
• 期待される出力：リスク軽減策を含む優先順位付き移行ロードマップ

フェーズ 2：テストカバレッジの確立

1. レガシーコードのテストカバレッジ分析

• Task ツールを subagent_type="unit-testing::test-automator" で使用します
• プロンプト：「$ARGUMENTS にあるレガシーコンポーネントの既存のテストカバレッジを分析してください。カバレッジツールを使用して、テストされていないコードパス、不足している統合テスト、および存在しないエンドツーエンドのシナリオを特定してください。カバレッジが 40% 未満のコンポーネントについては、機能を変更せずに現在の動作を記録する特性テストを生成してください。安全なリファクタリングのためのテストハーネスを作成してください。」
• 期待される出力：テストカバレッジレポートと特性テストスイート

2. コントラクトテストの実装

• Task ツールを subagent_type="unit-testing::test-automator" で使用します
• プロンプト：「依存関係マッピングで特定したすべての統合ポイントについて、コントラクトテストを実装してください。API、メッセージキューとのやり取り、およびデータベーススキーマに対するコンシューマー駆動型コントラクトを作成してください。CI/CD パイプラインでコントラクト検証を設定してください。モダナイズされたコンポーネントが SLA を維持していることを検証するため、応答時間とスループットのパフォーマンスベースラインを生成してください。」
• 前のコンテキスト：統合ポイントのカタログ、既存のテストカバレッジ
• 期待される出力：パフォーマンスベースラインを含むコントラクトテストスイート

3. テストデータ管理戦略

• Task ツールを subagent_type="data-engineering::data-engineer" で使用します
• プロンプト：「並行システム運用のためのテストデータ管理戦略を設計してください。エッジケース向けのデータ生成スクリプトを作成し、機密情報のデータマスキングを実装し、テストデータベースの更新手順を確立してください。移行中にレガシーコンポーネントとモダナイズされたコンポーネント間のデータ整合性を監視する仕組みを設定してください。」
• 前のコンテキスト：データベーススキーマ、テスト要件
• 期待される出力：テストデータパイプラインと整合性監視

フェーズ 3：段階的な移行の実装

1. ストラングラーフィグのインフラストラクチャ設定

• Task ツールを subagent_type="backend-development::backend-architect" で使用します
• プロンプト：「トラフィックルーティング用の API ゲートウェイを備えたストラングラーフィグのインフラストラクチャを実装してください。環境変数またはフィーチャー管理サービスを使用して、段階的なロールアウト用のフィーチャーフラグを設定してください。URL パターン、ヘッダー、ユーザーセグメントに基づくリクエストルーティングルールを備えたプロキシレイヤーを設定してください。耐障害性を確保するため、サーキットブレーカーとフォールバックの仕組みを実装してください。デュアルシステム監視用の可観測性ダッシュボードを作成してください。」
• 期待される出力：API ゲートウェイ設定、フィーチャーフラグシステム、監視ダッシュボード

2. コンポーネントのモダナイズ — 第 1 波

• Task ツールを subagent_type="python-development::python-pro" または "golang-pro"（対象スタックに応じて）で使用します
• プロンプト：「評価で特定した第 1 波のコンポーネント（短期間で成果を得られるもの）をモダナイズしてください。各コンポーネントについて、レガシーコードからビジネスロジックを抽出し、モダンなパターン（依存性注入、SOLID 原則）を使用して実装し、アダプターパターンで後方互換性を確保し、イベントソーシングまたはデュアルライトでデータ整合性を維持してください。12-factor app の原則に従ってください。モダナイズするコンポーネント：[優先順位付けされたロードマップのリスト]」
• 前のコンテキスト：特性テスト、コントラクトテスト、インフラストラクチャ設定
• 期待される出力：アダプターを備えたモダナイズ済みコンポーネント

3. セキュリティ強化

• Task ツールを subagent_type="security-scanning::security-auditor" で使用します
• プロンプト：「モダナイズされたコンポーネントのセキュリティ脆弱性を監査してください。OAuth 2.0/JWT 認証、ロールベースのアクセス制御、入力検証とサニタイズ、SQL インジェクション対策、XSS 保護、シークレット管理などのセキュリティ改善を実装してください。OWASP Top 10 への準拠を確認してください。セキュリティヘッダーを設定し、レート制限を実装してください。」
• 前のコンテキスト：モダナイズされたコンポーネントのコード
• 期待される出力：セキュリティ監査レポートとセキュリティ強化済みコンポーネント

フェーズ 4：パフォーマンスの検証と最適化

1. パフォーマンステストと最適化

• subagent_type="application-performance::performance-engineer" を指定して Task ツールを使用します
• プロンプト：「レガシーコンポーネントとモダナイズされたコンポーネントを比較するパフォーマンステストを実施してください。本番環境のトラフィックパターンをシミュレートした負荷テストを実行し、応答時間、スループット、リソース使用率を測定してください。パフォーマンスの低下を特定し、該当する場合は、インデックス作成によるデータベースクエリの最適化、キャッシュ戦略（Redis/Memcached）、コネクションプーリング、非同期処理によって最適化してください。SLA 要件を満たしていることを検証してください。」
• 前の手順からのコンテキスト：パフォーマンスのベースライン、モダナイズされたコンポーネント
• 期待される出力：パフォーマンステストの結果と最適化の推奨事項

2. 段階的なロールアウトとモニタリング

• subagent_type="deployment-strategies::deployment-engineer" を指定して Task ツールを使用します
• プロンプト：「フィーチャーフラグを使用した段階的なロールアウト戦略を実装してください。まず、モダナイズされたコンポーネントにトラフィックの 5% を流し、エラー率、レイテンシ、ビジネスメトリクスをモニタリングしてください。自動ロールバックのトリガーを定義してください：エラー率が 1% を超える、レイテンシがベースラインの 2 倍を超える、またはビジネスメトリクスが低下すること。トラフィックを 5% → 25% → 50% → 100% と切り替える手順と、各段階で 24 時間の観察期間を設けたランブックを作成してください。」
• 前の手順からのコンテキスト：フィーチャーフラグの設定、モニタリングダッシュボード
• 期待される出力：自動化された保護策を含むロールアウト計画

フェーズ 5：移行の完了とドキュメント作成

1. レガシーコンポーネントの廃止

• subagent_type="legacy-modernizer" を指定して Task ツールを使用します
• プロンプト：「置き換えたレガシーコンポーネントを安全に廃止する計画を立ててください。トラフィック分析により、依存関係が残っていないことを確認してください（トラフィックが 0% の状態を最低 30 日間維持）。元の機能を説明するドキュメントを添えて、レガシーコードをアーカイブしてください。CI/CD パイプラインを更新して、レガシーのビルドを削除してください。未使用のデータベーステーブルをクリーンアップし、非推奨の API エンドポイントを削除してください。保持するレガシーコンポーネントがあれば、廃止予定のタイムラインとともに記録してください。」
• 前の手順からのコンテキスト：トラフィックルーティングデータ、モダナイゼーションの状況
• 期待される出力：廃止チェックリストとタイムライン

2. ドキュメント作成とナレッジ移転

• subagent_type="documentation-generation::docs-architect" を指定して Task ツールを使用します
• プロンプト：「包括的なモダナイゼーションドキュメントを作成してください。内容には、アーキテクチャ図（変更前／変更後）、移行ガイド付き API ドキュメント、二重システム運用のランブック、一般的な問題のトラブルシューティングガイド、学んだ教訓のレポートを含めてください。モダナイズされたシステム向けの開発者オンボーディングガイドを作成してください。移行中に行った技術的な判断とトレードオフを記録してください。」
• 前の手順からのコンテキスト：すべての移行成果物と判断
• 期待される出力：モダナイゼーションドキュメント一式

設定オプション

• --parallel-systems：段階的な移行のために、両方のシステムを無期限に稼働させます
• --big-bang：検証後に全面的に切り替えます（リスクは高く、完了は早くなります）
• --by-feature：技術コンポーネントではなく、機能単位で移行します
• --database-first：アプリケーション層より先にデータベースのモダナイゼーションを優先します
• --api-first：レガシーバックエンドを維持したまま API 層をモダナイズします

成功基準

• 優先度の高いすべてのコンポーネントをモダナイズし、テストカバレッジを 80% 超にする
• 移行中に予定外のダウンタイムをゼロにする
• パフォーマンス指標を維持または改善する（P95 レイテンシをベースラインの 110% 以内にする）
• セキュリティ脆弱性を 90% 超削減する
• 技術的負債のスコアを 60% 超改善する
• ロールバックすることなく、移行後 30 日間正常に運用する
• 1 週間未満で新しい開発者のオンボーディングが可能な完全なドキュメントを整備する

対象：$ARGUMENTS

例

ユーザーのリクエスト：

このレガシーシステムについて、サービスの継続性を維持し、測定可能な切り替え段階を定義したストラングラーフィグ移行を計画してください。

制限事項

• タスクが上記の説明の範囲に明確に該当する場合にのみ、このスキルを使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、停止して確認してください。