---
name: implementation-approach
description: 実装戦略（垂直スライス、水平、ハイブリッド）をリスク評価で選択。機能の実装計画時に使用。
---

# 実装戦略選択フレームワーク（メタ認知的アプローチ）

## メタ認知的戦略選択プロセス

### Phase 1: 現状の包括的分析

**核心質問**: 「既存の実装はどうなっているのか？」

#### 分析フレームワーク
```yaml
アーキテクチャ分析: 責務分離、データフロー、依存関係、技術的負債
実装品質評価: コード品質、テストカバレッジ、パフォーマンス、セキュリティ
歴史的文脈理解: 現在の形の理由、過去判断の妥当性、制約の変化、要求の進化
```

#### メタ認知質問リスト
- この実装の真の責務は何か？
- どの部分がビジネス本質で、どの部分が技術的制約由来か？
- コードから明確でない依存関係や暗黙の前提条件は何か？
- 現在の設計がもたらしている利点と制約は？

### Phase 2: 戦略探索と創造

**核心質問**: 「before → after を判断する時に、参考にすべき実装パターンや戦略は何なのか？」

#### 戦略発見プロセス
```yaml
調査・探索: 技術スタック事例（WebSearch活用）、同種プロジェクト、OSS実装、文献・ブログ
創造的思考: 戦略組み合わせ、制約前提設計、フェーズ分け、拡張ポイント設計
```

#### 参考戦略パターン（創造的組み合わせを推奨）

**レガシー対応戦略**:
- ストラングラーパターン: 段階的置換による漸進的移行
- ファサードパターン: 統一インターフェースによる複雑性の隠蔽
- アダプターパターン: 既存システムとの橋渡し

**新規開発戦略**:
- 機能駆動開発: ユーザー価値重視の縦断実装
- 基盤駆動開発: 安定性重視の基盤優先構築
- リスク駆動開発: 最大リスク要素から優先的に対処

**統合・移行戦略**:
- プロキシパターン: 透過的な機能拡張
- デコレーターパターン: 既存機能の段階的強化
- ブリッジパターン: 抽象化による柔軟性確保

**重要**: 最適解は各プロジェクトの文脈に応じた創造的思考により発見される。

### Phase 3: リスク評価とコントロール

**核心質問**: 「既存の実装にそれを当てはめた時にどういうリスクが発生し、それをどうコントロールするのが最良なのか？」

#### リスク分析マトリクス
```yaml
技術的リスク: 既存システム影響、データ整合性、パフォーマンス劣化、統合複雑性
運用リスク: サービス可用性、デプロイダウンタイム、運用プロセス変更、切り戻し手順
プロジェクトリスク: スケジュール遅延、技術習得コスト、品質達成度、チーム連携
```

#### リスクコントロール戦略
```yaml
予防的対策: 段階的移行、並行動作検証、統合・回帰テスト追加、監視設定
発生時対応: 切り戻し手順、ログ・メトリクス準備、連絡体制定義、サービス継続手順
```

### Phase 4: 制約適合性検証

**核心質問**: 「このプロジェクトの制約は何か？」

#### 制約チェックリスト
```yaml
技術的制約: ライブラリ互換性、リソース容量、義務要件、数値目標
時間的制約: 期限・優先度、依存関係、マイルストーン、学習期間
リソース制約: チーム・スキル、作業時間・体制、予算、外部契約
ビジネス制約: 市場投入時期、顧客影響、法規制・標準
```

### Phase 5: 実装アプローチ決定

基本的な実装アプローチから最適解を選択（創造的組み合わせも推奨）：

#### 垂直スライス（機能駆動）
**特徴**: 機能単位で全層を縦断実装
**適用条件**: 機能間の依存が少ない、ユーザーが利用可能な形で出力、アーキテクチャ全層への変更が必要
**確認方法**: 各機能完成時のエンドユーザー価値提供

#### 水平スライス（基盤駆動）
**特徴**: アーキテクチャ層別の段階的構築
**適用条件**: 基盤システムの安定性が重要、複数機能が共通基盤に依存、層別の段階的確認が有効
**確認方法**: 全基盤層完成時の統合動作確認

#### ハイブリッド（創造的組み合わせ）
**特徴**: プロジェクト特性に応じた柔軟な組み合わせ
**適用条件**: 要件が明確でない、フェーズごとにアプローチ変更が必要、プロトタイピングから本格実装への移行
**確認方法**: 各フェーズの目標に応じてL1/L2/L3の適切なレベルで確認

### Phase 6: 判断根拠の文書化

**Design Docでの記載**：実装戦略の選択理由と根拠を明記する。

## 確認レベル定義

各タスクの完了確認における優先順位：

- **L1: 機能動作確認** - エンドユーザー機能として動作（例：検索実行可能）
- **L2: テスト動作確認** - 新規テストが追加されパス（例：型定義テスト）
- **L3: ビルド成功確認** - コンパイルエラーなし（例：インターフェース定義）

**優先順位**: L1 > L2 > L3 の順で確認可能性を重視

## 統合ポイントの定義

選択した戦略に応じて統合ポイントを定義：
- **ストラングラー系**: 各機能の新旧システム切り替え時
- **機能駆動**: ユーザーが実際に機能を利用可能になった時
- **基盤駆動**: 全アーキテクチャ層が揃いE2Eテストが通った時
- **ハイブリッド**: 各フェーズで定義した個別目標達成時

## アンチパターン

- **パターン固執**: リスト内の戦略のみで選択し、独自の組み合わせを検討しない
- **分析不足**: Phase 1の分析フレームワークを飛ばして戦略選択
- **リスク軽視**: Phase 3のリスク分析マトリクスを省略して実装着手
- **制約無視**: Phase 4の制約チェックリストを確認せず戦略決定
- **根拠省略**: Phase 6の文書化テンプレートを使用せず戦略選択

## メタ認知的実行のための指針

1. **既知パターンの活用**: 出発点として参考し、創造的組み合わせを探索
2. **WebSearch積極活用**: 同種技術スタックの実装事例を調査
3. **5 Whys適用**: 根本理由を追求し本質を把握
4. **複数観点評価**: Phase 1-4の各観点から網羅的に評価
5. **創造的思考**: 複数戦略の順序適用やプロジェクト固有の制約を活かした設計を検討
6. **判断根拠明示**: 設計ドキュメントでの戦略選択根拠を明示化