---
name: shinpr/implementation-approach
source: https://app.decimal.ai/s/shinpr-implementation-approach@4/SKILL.md
source_sha256: 615c3d306dc3
---

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

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

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

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

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

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

**完了証跡**: 確認したパス、観測したアーキテクチャ・データフローの事実、既知の制約、推測と明記した歴史的背景、不明点のうち戦略選択を変え得るもの。

**移行条件**: 戦略に関係するすべての主張が、観測済み、根拠付きの推測、または不明として明記されている場合に次へ進む。

### Phase 2: Design Convergence

**核心質問**: 「現行の必要な成果を届ける最小の設計は何か。そこから先の追加は、どの根拠が要求しているのか？」

実装戦略の探索に入る前に、以下を順に完了させる：

1. **Direct MVP**: 既存のシステム機能を使って現行の必要な成果を届ける、最も単純なエンドツーエンドの設計を記述する。明示されたユーザー要件と確定済みの判断は拘束力を持つ。提案や選択肢として示された技術手段は、必須と確定されるまでは候補にとどまる。
2. **失敗チェック**: Direct MVP を、現行要件、検証済みの制約、確定済みスコープまたは成果に必要な依存の範囲内で観測された問題、根拠のある重大リスクに照らして検証する。満たせない項目だけを根拠とともに `Failed Items` として記録し、すべて満たす場合は `None` と記録する。その範囲外の問題は、スコープ判断のために別途報告する。
3. **的を絞った拡張**: `Failed Items` ごとに、まず既存の設計サーフェス内での解決を検証する — 再利用、既存データからの導出、オンデマンド計算、現在の呼び出し側または境界での責務保持。これらで解決できない場合に、十分な最小の追加を選択する。`Adopted Additions` として、追加 → 対応する Failed Item → より小さいサーフェスでの解決が成立しない根拠、の形で記録する。追加には対応する Failed Item が必要である。
4. **減算チェック**: `Adopted Additions` を1つずつ一時的に取り除き、対応する Failed Item を再検証する。項目が再び満たせなくなる場合にその追加を残す。ステップ3で検討したが採用しなかった選択肢を、簡潔な理由とともに `Rejected Additions` として記録する。ステップ3で不採用の候補がなかった場合は `None` と記録する。

**フェーズの出力**: `Direct MVP`、`Failed Items`、`Adopted Additions`、`Rejected Additions`。Design Docの作成者は4つすべてを記録する。実装エージェントは、設計成果物の作成責務を設計フェーズに残したまま、追加された仕組みを検証するためにこれらを使用する。

**完了証跡**: 4つの出力すべてが記録されていること。`Failed Items` ごとに根拠があり、`Adopted Additions` ごとに対応する Failed Item、より小さいサーフェスでは不十分である理由、減算チェックの結果が示されていること。

**移行条件**: 裏付けとなるすべての主張が、観測済み、根拠付きの推測、または不明として明記されている場合に次へ進む。不明点がステップの続行を妨げる場合は、そのステップで止まり、必要な根拠またはユーザー判断を具体的に示す。

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

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

#### 戦略発見プロセス
```yaml
調査・探索: リポジトリ内のパターンを最初に確認し、次に特定した依存バージョンの公式ドキュメント、保守されているOSS実装の順に調査する。文献・ブログは代替案を補足する場合にのみ使用し、非公式な情報源と明記する
創造的思考: 戦略組み合わせ、制約前提設計、フェーズ分け、拡張ポイント設計
```

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

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

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

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

**完了証跡**: 判断が自明でない場合は、実行可能な候補を2つ以上示し、それぞれが満たす観測済みの制約と未解決の制約を対応づける。

**移行条件**: 同じ制約集合に対して候補を比較できる場合に次へ進む。

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

**核心質問**: 「既存の実装に適用するとどのようなリスクが発生し、検証可能性と切り戻し可能性を保ちながら、その発生確率または影響を計測可能な形で下げられる制御は何か？」

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

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

**完了証跡**: 重要なリスクごとに、発生確率・影響の根拠、予防または封じ込めの制御、検証点を1つずつ示す。

**移行条件**: 影響が大きいすべてのリスクに制御または作業を止めるエスカレーションが設定されている場合に次へ進む。

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

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

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

**完了証跡**: 各制約を観測済み、推測、不明のいずれかに分類する。候補を無効にし得る不明点ごとに、必要な根拠またはユーザー判断を示す。

**移行条件**: 残る不明点によって有効な候補集合が変わらない場合、またはユーザーが解決した場合に次へ進む。

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

すべての必須制約と現行要件を満たし、移行リスクが最も低く、検証までの遅延が最も小さいアプローチを選択する。要件の充足、互換性、リスク制御が同等の場合にのみ、ライフサイクルコストと実装工数をタイブレーカーとして使用する。

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

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

#### ハイブリッド（創造的組み合わせ）
**特徴**: プロジェクト特性に応じた柔軟な組み合わせ
**適用条件**: 要件が明確でない、フェーズごとにアプローチ変更が必要、プロトタイピングから本格実装への移行
**確認方法**: エンドユーザーが操作可能な振る舞いを生むPhaseにはL1、テスト可能な内部の振る舞いまたは契約を生むPhaseにはL2、実行可能な振る舞いをまだ持たないビルド時の構造だけを生むPhaseにはL3を割り当てる

ハイブリッドでは、すべてのPhaseにL1/L2/L3のいずれか1つと、観測可能な完了結果を明示する。

**完了証跡**: 選択したアプローチ1つ、そのPhase境界、統合点、各Phaseの検証結果。

**移行条件**: 選択したアプローチがすべての必須制約を満たし、リスクに制御が設定されている場合は文書化へ進む。それ以外は候補探索（Phase 3）へ戻る。Phase 4〜5の結果が `Direct MVP`、`Failed Items`、`Adopted Additions` のいずれかを変える場合は Design Convergence（Phase 2）へ戻る。

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

Design Docまたは計画のハンドオフに、以下の構造で記載する：

```yaml
implementationApproachDecision:
  observedConstraints: [<制約 + 根拠>]
  inferredConstraints: [<制約 + 根拠と推測>]
  unknowns: [<不明点 + 必要な根拠または判断>]
  candidates: [<アプローチ + 満たす要件 + リスク + 検証までの遅延>]
  selectedApproach: <vertical | horizontal | hybridの説明>
  selectionRationale: <必須制約の充足、互換性、リスク制御、その後にタイブレーカー>
  rejectedApproaches: [<アプローチ + 未充足要件またはより大きい重要リスク>]
  phaseVerification: [<Phase + L1/L2/L3 + 観測可能な完了証跡>]
```

**完了証跡**: 採用・不採用のすべての判断が、観測済みの制約、受け入れた推測、または解決済みのユーザー判断まで追跡できること。

## 検証レベル定義

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

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

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

## 統合ポイントの定義

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

## 判断ゲートのチェックリスト

- [ ] 戦略選択前にPhase 1の証跡がある
- [ ] Phase 2にDesign Convergenceの4つの出力が記録され、`Failed Items` と `Adopted Additions` ごとに根拠がある
- [ ] 一覧の戦略だけでは必須制約を満たせない場合、候補生成で組み合わせを検討している
- [ ] 重要なリスクごとに制御と検証点がある
- [ ] すべての必須制約が選択したアプローチに対応づけられている
- [ ] Phase 7の出力に採用・不採用の根拠が記録されている

チェック項目に必要な根拠が不明な場合は、そのPhaseで止まり、継続に必要なリポジトリ内の根拠またはユーザー判断を具体的に報告する。

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

1. **既知パターンの活用**: 出発点として参考にし、創造的組み合わせを探索
2. **根拠の優先順に従う調査**: リポジトリ内の根拠、対象バージョンに一致する公式ドキュメント、保守されているOSS実装、補足的な二次情報の順に使用
3. **5 Whys適用**: 根本理由を追求し本質を把握
4. **複数観点評価**: Phase 1〜5の証跡と移行条件を満たす
5. **戦略の組み合わせ**: 1つの戦略ではすべての必須制約を満たせない場合に組み合わせる
6. **判断のトレーサビリティ**: すべての選択理由をPhase 7の出力にある根拠へ対応づける