## Role Debate

異なる専門性を持つロールが議論し、トレードオフを検討して最適解を導出するコマンド。

### 使い方

```bash
/role-debate <ロール 1>,<ロール 2> [議題]
/role-debate <ロール 1>,<ロール 2>,<ロール 3> [議題]
```

### 基本例

```bash
# セキュリティ vs パフォーマンスのトレードオフ
/role-debate security,performance
「JWT トークンの有効期限設定について」

# ユーザビリティ vs セキュリティのバランス
/role-debate frontend,security
「2 段階認証の UX 最適化について」

# 技術選定の議論
/role-debate architect,mobile
「クロスプラットフォーム vs ネイティブ開発の選択について」

# 3 者議論
/role-debate architect,security,performance
「マイクロサービス化の是非について」
```

### 議論の基本原則

#### 建設的議論の心得

- **相互尊重**: 他ロールの専門性と視点を尊重する
- **事実ベース**: 感情的反論ではなく、データ・根拠に基づく議論
- **解決志向**: 批判のための批判ではなく、より良い解決策を目指す
- **実装重視**: 理想論ではなく実現可能性を考慮した提案

#### 論拠の質的要件

- **公式文書**: 標準・ガイドライン・公式ドキュメントへの言及
- **実証事例**: 成功事例・失敗事例の具体的引用
- **定量評価**: 可能な限り数値・指標での比較
- **時系列考慮**: 短期・中期・長期での影響評価

#### 議論倫理

- **誠実性**: 自身の専門分野の限界も認める
- **開放性**: 新しい情報・視点に対する柔軟性
- **透明性**: 判断根拠・前提条件の明示
- **責任性**: 提案の実装リスクも含めて言及

### 議論プロセス

### Phase 1: 初期立場表明

各ロールが専門視点から独立して意見表明

- 推奨案の提示
- 根拠となる標準・文書の明示
- 想定されるリスク・課題の説明
- 成功指標の定義

### Phase 2: 相互議論・反駁

ロール間でのクロス議論

- 他ロール提案への建設的反論
- 見落とされた視点の指摘
- トレードオフの明確化
- 代替案の提示

### Phase 3: 妥協点探索

実装可能な解決策の模索

- 各視点の重要度評価
- Win-Win 解決策の検討
- 段階的実装アプローチ
- リスク軽減策の検討

### Phase 4: 統合結論

最終的な推奨事項の決定

- 合意された解決策
- 実装ロードマップ
- 成功指標・測定方法
- 将来の見直しポイント

### 出力フォーマット例

### 2 ロール議論の場合

```text
ロール議論: Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

議題: JWT トークンの有効期限設定

Security ロールの主張:
「15 分の短期有効期限を推奨します」

根拠:
- OWASP JWT Security Cheat Sheet 準拠
- トークン漏洩時の被害時間窓を最小化
- 攻撃者の利用可能時間を制限

懸念事項:
- 長期有効期限は攻撃リスクが指数関数的に増大
- コンプライアンス要件 (金融系) では短期が必須

成功指標:
- セキュリティインシデント発生率 < 0.1%
- 平均攻撃検出時間 < 5 分

Performance ロールの反論:
「2 時間の有効期限を推奨します」

根拠:
- Google OAuth 2.0 Best Practices 参考
- 頻繁な再認証によるサーバー負荷増大を回避
- ユーザー体験 (作業中断) の最小化

懸念事項:
- 15 分間隔の再認証は API 負荷 8 倍増
- モバイル環境での接続断が頻発

成功指標:
- API レスポンス時間 < 200ms 維持
- サーバー CPU 使用率 < 60%

相互議論:
Security → Performance:
「サーバー負荷よりもセキュリティ侵害のビジネス損失の方が甚大。
例: Equifax 事件では 7 億ドルの損失」

Performance → Security:
「リフレッシュトークン機構で両立可能。
バックグラウンド更新により UX を損なわずセキュリティ確保」

Security → Performance:
「リフレッシュトークンも攻撃対象。適切な実装が前提」

Performance → Security:
「段階的アプローチを提案。通常操作 30 分、機密操作 15 分」

妥協点探索:
共通理解:
- ユーザー体験とセキュリティの両立が必要
- リスクレベルに応じた柔軟な対応
- 実装・運用コストの現実的考慮

Win-Win 要素:
- リフレッシュトークン機構の活用
- リスクベース認証の段階的導入
- 自動ログアウト機能による補完

統合結論:
「30 分有効期限 + リフレッシュトークン + リスクベース認証」

実装詳細:
1. アクセストークン: 30 分有効期限
2. リフレッシュトークン: 7 日有効期限
3. 高リスク操作: 15 分で強制再認証
4. 無操作 30 分で自動ログアウト

段階的実装:
週 1-2: 基本的な 30 分トークン実装
週 3-4: リフレッシュトークン機構追加
月 2: リスクベース認証の導入

成功指標:
- セキュリティ: インシデント発生率 < 0.1%
- パフォーマンス: API 負荷増加率 < 20%
- UX: ユーザー満足度 > 85%

将来の見直し:
- 3 ヶ月後: 実際の攻撃パターン・負荷状況を評価
- 6 ヶ月後: より洗練されたリスクベース認証への移行検討
```

### 3 ロール議論の場合

```text
ロール議論: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

議題: マイクロサービス化の是非

Architect ロールの主張:
「段階的マイクロサービス化を推奨」
根拠: ドメイン境界の明確化、独立したデプロイ、技術選択の自由度

Security ロールの懸念:
「サービス間通信のセキュリティ複雑化」
根拠: API Gateway、mTLS、分散認証の管理コスト

Performance ロールの懸念:
「ネットワーク通信によるレイテンシ増加」
根拠: 内部 API 呼び出しによる N+1 問題、分散トランザクション

3 者議論:
Architect → Security: 「API Gateway で集中管理により統制可能」
Security → Architect: 「単一障害点となるリスク」
Performance → Architect: 「サービス分割の粒度が重要」
...(議論継続)

統合結論:
「ドメイン駆動設計による段階的分割 + セキュリティファースト設計」
```

### 効果的な議論パターン

### 技術選定

```bash
/role-debate architect,performance
「データベース選択: PostgreSQL vs MongoDB」

/role-debate frontend,mobile
「UI フレームワーク: React vs Vue」

/role-debate security,architect
「認証方式: JWT vs Session Cookie」
```

### 設計判断

```bash
/role-debate security,frontend
「ユーザー認証の UX 設計」

/role-debate performance,mobile
「データ同期戦略の最適化」

/role-debate architect,qa
「テスト戦略とアーキテクチャ設計」
```

### トレードオフ問題

```bash
/role-debate security,performance
「暗号化レベル vs 処理速度」

/role-debate frontend,performance
「リッチ UI vs ページ読み込み速度」

/role-debate mobile,security
「利便性 vs データ保護レベル」
```

### ロール別議論特性

#### 🔒 Security ロール

```yaml
議論スタンス:
  - 保守的アプローチ (リスク最小化)
  - 規則準拠重視 (標準からの逸脱に慎重)
  - 最悪ケース想定 (攻撃者視点)
  - 長期的影響重視 (技術的負債としてのセキュリティ)

典型的論点:
  - "セキュリティ vs 利便性" のトレードオフ
  - "コンプライアンス要件の必達"
  - "攻撃コスト vs 防御コストの比較"
  - "プライバシー保護の徹底"

論拠ソース:
  - OWASP ガイドライン
  - NIST フレームワーク
  - 業界標準 (ISO 27001, SOC 2)
  - 実際の攻撃事例・統計

議論での強み:
  - リスク評価の精度
  - 規制要件の知識
  - 攻撃手法への理解

注意すべき偏見:
  - 過度な保守性 (イノベーション阻害)
  - UX への配慮不足
  - 実装コストの軽視
```

#### ⚡ Performance ロール

```yaml
議論スタンス:
  - データ駆動判断 (測定ベース)
  - 効率性重視 (コスト対効果の最適化)
  - ユーザー体験優先 (体感速度重視)
  - 継続的改善 (段階的最適化)

典型的論点:
  - "パフォーマンス vs セキュリティ"
  - "最適化コスト vs 効果の投資対効果"
  - "現在 vs 将来のスケーラビリティ"
  - "ユーザー体験 vs システム効率"

論拠ソース:
  - Core Web Vitals メトリクス
  - ベンチマーク結果・統計
  - ユーザー行動への影響データ
  - 業界パフォーマンス標準

議論での強み:
  - 定量的評価能力
  - ボトルネック特定
  - 最適化手法の知識

注意すべき偏見:
  - セキュリティの軽視
  - 保守性への配慮不足
  - プレマチュアオプティマイゼーション
```

#### 🏗️ Architect ロール

```yaml
議論スタンス:
  - 長期視点重視 (システム進化への配慮)
  - バランス追求 (全体最適)
  - 段階的変更 (リスク管理)
  - 標準準拠 (実証済みパターン優先)

典型的論点:
  - "短期効率 vs 長期保守性"
  - "技術的負債 vs 開発速度"
  - "マイクロサービス vs モノリス"
  - "新技術採用 vs 安定性"

論拠ソース:
  - アーキテクチャパターン集
  - 設計原則 (SOLID, DDD)
  - 大規模システム事例
  - 技術進化のトレンド

議論での強み:
  - 全体俯瞰能力
  - 設計パターンの知識
  - 長期影響の予測

注意すべき偏見:
  - 過度な一般化
  - 新技術への保守性
  - 実装詳細への理解不足
```

#### 🎨 Frontend ロール

```yaml
議論スタンス:
  - ユーザー中心設計 (UX 最優先)
  - 包摂的アプローチ (多様性配慮)
  - 直感性重視 (学習コスト最小化)
  - アクセシビリティ標準 (WCAG 準拠)

典型的論点:
  - "ユーザビリティ vs セキュリティ"
  - "デザイン統一 vs プラットフォーム最適化"
  - "機能性 vs シンプルさ"
  - "パフォーマンス vs リッチな体験"

論拠ソース:
  - UX 研究・ユーザビリティテスト結果
  - アクセシビリティガイドライン
  - デザインシステム標準
  - ユーザー行動データ

議論での強み:
  - ユーザー視点の代弁
  - デザイン原則の知識
  - アクセシビリティ要件

注意すべき偏見:
  - 技術制約への理解不足
  - セキュリティ要件の軽視
  - パフォーマンス影響の過小評価
```

#### 📱 Mobile ロール

```yaml
議論スタンス:
  - プラットフォーム特化 (iOS/Android 差異考慮)
  - コンテキスト適応 (移動中・片手操作)
  - リソース制約 (バッテリー・メモリ・通信)
  - ストア準拠 (審査ガイドライン)

典型的論点:
  - "ネイティブ vs クロスプラットフォーム"
  - "オフライン対応 vs リアルタイム同期"
  - "バッテリー効率 vs 機能性"
  - "プラットフォーム統一 vs 最適化"

論拠ソース:
  - iOS HIG / Android Material Design
  - App Store / Google Play ガイドライン
  - モバイル UX 研究
  - デバイス性能統計

議論での強み:
  - モバイル特有制約の理解
  - プラットフォーム差異の知識
  - タッチインターフェース設計

注意すべき偏見:
  - Web プラットフォームへの理解不足
  - サーバーサイド制約の軽視
  - デスクトップ環境への配慮不足
```

#### 🔍 Analyzer ロール

```yaml
議論スタンス:
  - 証拠重視 (データファースト)
  - 仮説検証 (科学的アプローチ)
  - 構造的思考 (システム思考)
  - バイアス除去 (客観性追求)

典型的論点:
  - "相関関係 vs 因果関係"
  - "症状対症療法 vs 根本解決"
  - "仮説 vs 事実の区別"
  - "短期症状 vs 構造的問題"

論拠ソース:
  - 実測データ・ログ分析
  - 統計的手法・分析結果
  - システム思考理論
  - 認知バイアス研究

議論での強み:
  - 論理的分析能力
  - 証拠評価の客観性
  - 構造的問題の発見

注意すべき偏見:
  - 分析麻痺 (行動力不足)
  - 完璧主義 (実用性軽視)
  - データ万能主義
```

### 議論進行テンプレート

#### Phase 1: 立場表明テンプレート

```text
【ロール名】の推奨案:
「[具体的な提案]」

根拠:
- [公式文書・標準への言及]
- [実証事例・データ]
- [専門分野の原則]

想定効果:
- [短期的効果]
- [中長期的効果]

懸念・リスク:
- [実装リスク]
- [運用リスク]
- [他分野への影響]

成功指標:
- [測定可能な指標 1]
- [測定可能な指標 2]
```

#### Phase 2: 反駁テンプレート

```text
[対象ロール] への反論:
「[対象提案への具体的反論]」

反論根拠:
- [見落とされた視点]
- [対立する証拠・事例]
- [専門分野からの懸念]

代替案:
「[改良された提案]」

妥協可能ポイント:
- [受け入れ可能な条件]
- [段階的実装の可能性]
```

#### Phase 3: 統合解決テンプレート

```text
統合解決案:
「[各ロールの懸念を考慮した最終提案]」

各ロールへの配慮:
- [Security]: [セキュリティ要件の満足方法]
- [Performance]: [パフォーマンス要件の満足方法]
- [その他]: [その他要件の満足方法]

実装ロードマップ:
- フェーズ 1 (即座): [緊急対応事項]
- フェーズ 2 (短期): [基本実装]
- フェーズ 3 (中期): [完全実装]

成功指標・測定方法:
- [統合的な成功指標]
- [測定方法・頻度]
- [見直しタイミング]
```

### 議論品質チェックリスト

#### 論拠の質

- [ ] 公式文書・標準への言及がある
- [ ] 具体的な事例・データが提示されている
- [ ] 推測と事実が明確に区別されている
- [ ] 情報源が明示されている

#### 議論の建設性

- [ ] 相手の提案を正確に理解している
- [ ] 感情的でなく論理的な反論
- [ ] 代替案も提示している
- [ ] Win-Win の可能性を探っている

#### 実装可能性

- [ ] 技術的実現可能性を考慮
- [ ] 実装コスト・期間を見積もり
- [ ] 段階的実装の可能性を検討
- [ ] リスク軽減策を提示

#### 統合性

- [ ] 他分野への影響を考慮
- [ ] 全体最適を追求
- [ ] 長期的視点を含む
- [ ] 測定可能な成功指標を設定

### Claude との連携

```bash
# 設計文書を元にした議論
cat system-design.md
/role-debate architect,security
「この設計のセキュリティ面での課題を議論して」

# 問題を元にした解決策議論
cat performance-issues.md
/role-debate performance,architect
「パフォーマンス問題の根本的解決策を議論して」

# 要件を元にした技術選定議論
/role-debate mobile,frontend
「iOS ・Android ・Web の統一 UI 戦略について議論して」
```

### 注意事項

- 議論は時間がかかる場合があります (複雑なトピックほど長時間)
- 3 つ以上のロールでは議論が発散する可能性があります
- 最終判断は議論結果を参考にユーザーが行ってください
- 緊急性の高い問題では single role や multi-role を先に検討してください