# 技術設計向けフルディスカバリープロセス

## 目的
技術設計が完全で正確かつ最新の情報に基づいていることを確保するため、包括的な調査と分析を実施する。

## ディスカバリーステップ

### 1. 要件分析
**要件を技術的ニーズにマッピング**
- EARSフォーマットからすべての機能要件を抽出
- 非機能要件を特定（パフォーマンス、セキュリティ、スケーラビリティ）
- 技術的制約と依存関係を決定
- コア技術課題をリスト

### 2. 既存実装分析
**現在のシステムを理解**（修正/拡張する場合）:
- コードベース構造とアーキテクチャパターンを分析
- 再利用可能なコンポーネント、サービス、ユーティリティをマッピング
- ドメイン境界とデータフローを特定
- 統合ポイントと依存関係を文書化
- アプローチを決定: 拡張 vs リファクタ vs ラップ

### 3. 技術調査
**ベストプラクティスとソリューションを調査**:
- **WebSearchを使用**して以下を検索:
  - 類似問題に対する最新のアーキテクチャパターン
  - 技術スタックに対する業界のベストプラクティス
  - 関連技術の最近の更新や変更
  - よくある落とし穴と解決策

- **WebFetchを使用**して以下を分析:
  - フレームワーク/ライブラリの公式ドキュメント
  - APIリファレンスと使用例
  - 移行ガイドと破壊的変更
  - パフォーマンスベンチマークと比較

### 4. 外部依存関係調査
**各外部サービス/ライブラリについて**:
- 公式ドキュメントとGitHubリポジトリを検索
- APIシグネチャと認証方法を検証
- 既存スタックとのバージョン互換性を確認
- レート制限と使用制限を調査
- コミュニティリソースと既知の問題を検索
- セキュリティの考慮事項を文書化
- 実装調査が必要なギャップを記録

### 5. アーキテクチャパターンと境界分析
**アーキテクチャオプションを評価**:
- 関連パターンを比較（MVC、Clean、Hexagonal、Event-driven）
- 既存アーキテクチャとステアリング原則との適合性を評価
- チーム間の競合を回避するために必要なドメイン境界と所有権の継ぎ目を特定
- スケーラビリティへの影響と運用上の懸念を考慮
- 保守性とチームの専門知識を評価
- 推奨パターンと却下した代替案を `research.md` に文書化

### 6. リスク評価
**技術的リスクを特定**:
- パフォーマンスボトルネックとスケーリング限界
- セキュリティ脆弱性と攻撃ベクトル
- 統合の複雑さと結合
- 技術的負債の生成 vs 解消
- 知識ギャップとトレーニングニーズ

## 調査ガイドライン

### 検索するタイミング
**常に検索するもの**:
- 外部APIドキュメントと更新
- 認証/認可のセキュリティベストプラクティス
- 特定されたボトルネックに対するパフォーマンス最適化テクニック
- 依存関係の最新バージョンと移行パス

**不確かな場合に検索するもの**:
- 特定のユースケースに対するアーキテクチャパターン
- データフォーマット/プロトコルの業界標準
- コンプライアンス要件（GDPR、HIPAAなど）
- 予想負荷に対するスケーラビリティアプローチ

### 検索戦略
1. 公式ソース（ドキュメント、GitHub）から開始
2. 最近のブログ記事や記事をチェック（過去6ヶ月）
3. 一般的な問題についてStack Overflowを確認
4. 類似のオープンソース実装を調査

## 出力要件
設計決定に影響するすべての発見を共有テンプレートを使用して `research.md` にキャプチャ:
- アーキテクチャ、技術整合、コントラクトに影響する主要なインサイト
- 調査中に発見された制約
- 推奨アプローチと選択したアーキテクチャパターン（根拠付き）
- 却下した代替案とトレードオフ（設計決定セクションに文書化）
- コンポーネント & インターフェースコントラクトに情報を提供する更新されたドメイン境界
- リスクと軽減戦略
- 実装中にさらなる調査が必要なギャップ