# SDDギャップ分析規約

要件と既存コードベースのギャップ分析のルール。

## 原則

| 原則 | 基準 |
|------|------|
| 情報提供 | 最終決定ではなく、分析と選択肢を提供する |
| 複数選択肢 | 実行可能な代替案を提示する |
| 明示的なギャップ | 未知事項・制約を明確にフラグする |
| コンテキスト整合 | 既存パターン・アーキテクチャの制約に沿う |

## 分析フレームワーク

### 現状調査

- ドメイン関連のファイル・モジュール・ディレクトリ構成
- 再利用可能なコンポーネント・サービス・ユーティリティ
- アーキテクチャパターン・制約
- 命名・レイヤリング・依存方向の規約
- 統合サーフェス（データモデル、APIクライアント、認証等）

### 実装アプローチ

| アプローチ | 条件 | メリット | デメリット |
|-----------|------|---------|-----------|
| A: 既存拡張 | 既存構造に自然に適合 | 最小限のファイル追加 | 肥大化リスク |
| B: 新規作成 | 明確に異なる責務 | クリーンな分離 | ファイル増加 |
| C: ハイブリッド | 複合的な機能 | バランス型 | 計画の複雑化 |

### 複雑さとリスク

| 工数 | 基準 |
|------|------|
| S (1-3日) | 既存パターン、最小依存、直接的な統合 |
| M (3-7日) | 新パターンあり、中程度の複雑さ |
| L (1-2週) | 大きな機能、複数の統合 |
| XL (2週+) | アーキテクチャ変更、未知の技術 |

| リスク | 基準 |
|--------|------|
| High | 未知技術、複雑な統合、アーキテクチャ変更 |
| Medium | ガイダンスありの新パターン、管理可能な統合 |
| Low | 確立パターンの拡張、既知技術、明確なスコープ |

## スコープ外

- 詳細リサーチは設計フェーズに委ねる
- 未知事項は「要調査」として簡潔に記録のみ
