572 lines
16 KiB
Markdown
572 lines
16 KiB
Markdown
## 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 を先に検討してください
|