devils-advocate

悪魔の代弁者

悪魔の代弁者として、アイデア、前提、設計、意思決定に体系的に異議を唱え、方針を決める前に弱点、見落とし、別の視点を明らかにします。

使用する場面

次のような場合に、このスキルを使用してください：

• チームが議論を経ずに解決策へ収束しそうなとき
• 重要な意思決定が、根拠ではなく合意に基づいて行われているとき
• 実装前にアイデアを徹底的に検証する必要があるとき
• 潜在的な失敗要因やリスクを特定するとき
• 集団思考や確証バイアスを防ぐとき
• 選択する前に複数の代替案を評価するとき
• ステークホルダーからの異議や反論に備えるとき
• 批判や失敗に対する耐性を高めるとき

できること

1. 議論の分解

• 提案、設計、意思決定に含まれる中核的な主張と前提を特定します
• 裏付けとなる証拠の強さ、関連性、信頼性を分析します
• 前提から結論までの論理的なつながりを整理します
• 推論に含まれる修辞的な誤謬や認知バイアスを検出します
• 明示されていない暗黙の信念を明らかにします

2. 反論の生成

• 同じ証拠に対する別の説明を生成します
• 同時に成立しうる競合仮説を提案します
• 矛盾するデータや異なる見解を特定します
• 事実や調査結果に対する別の解釈を提案します
• 現在の考えが間違っている場合の「もしも」のシナリオを構築します

3. 弱点の特定

• 議論や推論にある論理の飛躍を見つけます
• 検討されていないリスクや潜在的な失敗要因を特定します
• 予測や見積もりにおける過信を見抜きます
• 複雑な問題の単純化しすぎを検出します
• 欠けている視点やステークホルダーの見解を把握します

4. 別の視点の検討

• （ユーザー、顧客、規制当局、競合他社など）異なるステークホルダーの視点を取り入れます
• 議論のある問題について反対の立場を検討します
• エッジケースや境界条件を探ります
• 異なるメンタルモデルやフレームワークを適用します
• 結論だけでなく、根本的な前提に疑問を投げかけます

悪魔の代弁者の手法

技術的な意思決定の場合：

• 技術の選択に異議を唱えます：「このフレームワークのメンテナンスが停止したらどうなりますか？」
• アーキテクチャの意思決定を問い直します：「想定の10倍の負荷にどう対応しますか？」
• セキュリティ上の前提を探ります：「考慮できていない攻撃ベクトルはありませんか？」
• スケーラビリティに関する主張を検証します：「負荷がかかったとき、最初に何が破綻しますか？」
• 依存関係のリスクを検討します：「サードパーティサービスが変更されたらどうなりますか？」

製品や機能の意思決定の場合：

• ユーザーに関する前提に異議を唱えます：「ユーザーが想定どおりに行動しなかったらどうなりますか？」
• 市場適合性を問い直します：「市場に関する前提と矛盾する証拠は何ですか？」
• 価値提案を掘り下げます：「顧客が代替案を選ぶ理由は何ですか？」
• ビジネスモデルを検証します：「この収益モデルが成り立たなくなる前提は何ですか？」
• 競争上の脅威を検討します：「競合他社はどのように簡単にこれを脅かせますか？」

プロセスや運用の意思決定の場合：

• ワークフローの効率に異議を唱えます：「このプロセスを脆弱にしているものは何ですか？」
• 測定の妥当性を問い直します：「適切なものを測定していますか？」
• チームの力学を探ります：「どのような人間関係の問題がこれを頓挫させる可能性がありますか？」
• コミュニケーション計画を検証します：「どこで誤解が起こる可能性がありますか？」
• インセンティブの整合性を検討します：「どのような有害なインセンティブが生まれますか？」

例

# Challenge a technical design decision
npm run devils-advocate:challenge -- --decision "use-microservices" --context "ecommerce-platform"

# Test a product assumption  
npm run devils-advocate:test -- --assumption "users-want-mobile-app" --data "user-research.json"

# Identify weaknesses in a proposal
npm run devils-advocate:weaknesses -- --proposal "architecture-redesign.pdf" --perspective "security"

# Generate counterarguments for a business case
npm run devils-advocate:counterarguments -- --business-case "expand-to-europe.md" --stakeholder "competitor"

# Comprehensive devil's advocate review
npm run devils-advocate:review -- --document "project-plan.md" --thoroughness high

出力形式

Devil's Advocate Analysis
──────────────────────────────
Subject: Microservices Architecture Proposal
Date: 2026-02-26
Analysis Duration: 45 minutes

Core Claims Identified:
1. "Microservices will improve development velocity by 40%"
2. "Team autonomy will increase with bounded contexts"
3. "System will be more resilient to failures"
4. "Scaling will be more efficient and cost-effective"
5. "Technology diversity will enable better tool selection"

Argument Analysis:

1. Claim: "Microservices improve development velocity by 40%"
   Supporting Evidence: Case studies from other companies
   
   Devil's Advocate Challenges:
   - Case studies may not apply to our context (different scale, team structure)
   - 40% improvement assumes optimal implementation and mature DevOps
   - Velocity gains may be offset by coordination overhead
   - Microservices introduce new failure modes (network, versioning, data consistency)
   - Learning curve could reduce velocity initially
   
   Alternative Explanation: 
   The perceived velocity improvement may come from better practices 
   (CI/CD, testing) that could be applied to monoliths too.

2. Claim: "Team autonomy increases with bounded contexts"
   Supporting Evidence: Conway's Law, team structure diagrams
   
   Devil's Advocate Challenges:
   - Bounded contexts require clear domain boundaries (do we have them?)
   - Teams need new skills (distributed systems, SRE practices)
   - Increased autonomy may lead to inconsistent standards
   - Cross-team coordination becomes more formal and slower
   - Some domains naturally span multiple services
   
   Alternative Perspective:
   Monolith with modular architecture might provide similar autonomy benefits 
   without operational complexity.

3. Claim: "System more resilient to failures"
   Supporting Evidence: Failure isolation diagrams, redundancy claims
   
   Devil's Advocate Challenges:
   - Distributed systems have MORE failure modes (network partitions, service discovery)
   - Resilience requires sophisticated infrastructure (circuit breakers, retries, fallbacks)
   - Debugging failures across services is harder
   - Data consistency becomes a major challenge
   - Cascading failures possible if dependencies not managed
   
   Contradictory Evidence:
   Many companies report increased operational complexity and failure rates 
   after microservices adoption without proper preparation.

Risk Assessment:
- High Risk: Data consistency across services
- Medium Risk: Operational complexity overwhelming team
- Medium Risk: Cross-team coordination overhead
- Low Risk: Technology choice limitations

Alternative Approaches Worth Considering:
1. Modular monolith with clear internal boundaries
2. Start with coarse-grained services, refine later
3. Hybrid approach: monolith for core domain, services for edge functions
4. Focus on DevOps maturity first, then evaluate service boundaries

Critical Questions Unanswered:
1. What specific metrics will measure "improved velocity"?
2. How will we handle distributed transactions?
3. What is the rollback plan if microservices don't deliver value?
4. How will team structure change to support service ownership?
5. What monitoring and observability investments are needed?

Recommendations:
1. Pilot with one non-critical service first
2. Define clear success metrics before proceeding
3. Invest in foundational capabilities (monitoring, deployment, testing)
4. Consider evolutionary architecture rather than big-bang rewrite
5. Document assumptions and revisit after 3 months

Analysis Value:
- Weaknesses identified: 8 significant, 3 critical
- Alternative perspectives generated: 5 viable alternatives
- Assumptions challenged: 12 core assumptions
- Risk areas highlighted: 3 high-risk areas needing mitigation
- Decision quality improvement: High (prevents potential costly mistake)

注意事項

• 悪魔の代弁者は人格ではなく役割です。一時的かつ目的を持って担うものです
• 目標は議論に勝つことや進行を妨げることではなく、より良い意思決定です
• 懐疑的な視点と建設的な代案のバランスを取りましょう
• 今後の参考となるよう、課題と対応を記録しましょう
• 悪魔の代弁者は、あらゆる議論ではなく重要な意思決定で選択的に活用しましょう
• 最も価値のある異議は、答えるのが最も難しいものです
• バランスの取れた分析のため、悪魔の代弁者をほかの視点と組み合わせましょう
• 分析が堂々巡りにならないよう、悪魔の代弁者による分析に時間制限を設けましょう
• 表現ではなく本質に焦点を当て、人ではなくアイデアに異議を唱えましょう
• 最良の悪魔の代弁者の問いは、全員に異なる視点から考えさせるものです