# 設計レビュープロセス

## 目的
技術設計ドキュメントのインタラクティブな品質レビューを実施し、許容可能なリスクで実装に進むのに十分堅牢であることを確認する。

## レビュー哲学
- **品質保証であり、完璧の追求ではない**
- **クリティカルフォーカス**: 最も重要な懸念事項を3つに限定
- **インタラクティブな対話**: 一方的な評価ではなく、設計者との対話
- **バランスの取れた評価**: 長所と短所の両方を認識
- **明確な決定**: 根拠付きの明確なGO/NO-GO

## スコープ & 非目標

- スコープ: プロジェクトコンテキストと標準に対して設計ドキュメントの品質を評価し、GO/NO-GOを決定
- 非目標: 実装レベルの設計、深い技術調査、技術選択の最終決定は行わない。そのような項目は設計フェーズのイテレーションに延期

## コアレビュー基準

### 1. 既存アーキテクチャとの整合（クリティカル）
- 既存システム境界とレイヤーとの統合
- 確立されたアーキテクチャパターンとの一貫性
- 適切な依存方向と結合管理
- 現在のモジュール構成との整合

### 2. 設計の一貫性と標準
- プロジェクトの命名規則とコード標準への準拠
- 一貫したエラーハンドリングとロギング戦略
- 統一された設定と依存関係管理
- 確立されたデータモデリングパターンとの整合

### 3. 拡張性と保守性
- 将来の要件に対する設計の柔軟性
- 関心の明確な分離と単一責任
- テスタビリティとデバッグの考慮
- 要件に対する適切な複雑さ

### 4. 型安全とインターフェース設計
- 適切な型定義とインターフェースコントラクト
- 安全でないパターンの回避（例: TypeScriptでの `any`）
- 明確なAPI境界とデータ構造
- 入力バリデーションとエラーハンドリングのカバレッジ

## レビュープロセス

### ステップ1: 分析
すべてのレビュー基準に対して設計を分析し、統合、保守性、複雑さ、要件充足に影響するクリティカルな問題に焦点を当てる。

### ステップ2: クリティカルな問題を特定（≤3）
各問題について:
```
🔴 **クリティカルな問題 [1-3]**: [簡潔なタイトル]
**懸念**: [具体的な問題]
**影響**: [なぜ重要か]
**提案**: [具体的な改善案]
**トレーサビリティ**: [requirements.mdの要件ID/セクション]
**根拠**: [設計ドキュメントのセクション/見出し]
```

### ステップ3: 長所を認識
バランスの取れたフィードバックを維持するため、1〜2つの強い側面を認める。

### ステップ4: GO/NO-GOの決定
- **GO**: クリティカルなアーキテクチャ不整合なし、要件対応済み、明確な実装パス、許容可能なリスク
- **NO-GO**: 根本的な競合、クリティカルなギャップ、高い失敗リスク、不釣り合いな複雑さ

## トレーサビリティと根拠

- 各クリティカルな問題を `requirements.md` の関連要件（IDまたはセクション）にリンク
- 評価を裏付ける設計ドキュメント内の根拠箇所（セクション/見出し、図、成果物）を引用
- 該当する場合、問題を正当化するためにステアリングコンテキストからの制約を参照

## 出力フォーマット

### 設計レビューサマリー
全体的な品質と準備状況について2〜3文。

### クリティカルな問題（≤3）
各項目: 問題、影響、推奨事項、トレーサビリティ（例: 1.1, 1.2）、根拠（design.mdセクション）。

### 設計の長所
1〜2つのポジティブな側面。

### 最終評価
決定（GO/NO-GO）、根拠（1〜2文）、次のステップ。

### インタラクティブディスカッション
設計者の視点、代替案、明確化、必要な変更について対話。

## 長さとフォーカス

- サマリー: 2〜3文
- 各クリティカルな問題: 合計5〜7行（問題/影響/推奨事項/トレーサビリティ/根拠を含む）
- 全体のレビュー: 簡潔に（目安約400語）

## レビューガイドライン

1. **クリティカルフォーカス**: 成功に大きく影響する問題のみをフラグ
2. **建設的なトーン**: 批判だけでなく解決策を提供
3. **インタラクティブなアプローチ**: 一方的な評価ではなく対話を行う
4. **バランスの取れた評価**: 長所と短所の両方を認識
5. **明確な決定**: 明確なGO/NO-GO推奨を行う
6. **アクション可能なフィードバック**: すべての提案が実装可能であることを確認

## 最終チェックリスト

- **クリティカルな問題 ≤ 3** かつ各問題に影響と推奨事項を含む
- **トレーサビリティ**: 各問題が要件ID/セクションを参照
- **根拠**: 各問題が設計ドキュメントの場所を引用
- **決定**: 明確な根拠と次のステップを伴うGO/NO-GO