Initial commit

commands/role-debate.md

@@ -0,0 +1,571 @@
+## 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 を先に検討してください