constructive-dissent

建設的な異論

構造化された異論のプロトコルを通じて提案に体系的に異議を唱え、弱点を明らかにし、前提を検証し、より優れた代替案を生み出します。

このスキルを使用するタイミング

• 重要な決定やアーキテクチャの選択を最終決定する前
• 提案に潜む弱点や見落としを検証するとき
• まだ検討されていない代替案を生み出すとき
• 明示的、暗黙的、構造的な前提を監査するとき
• ステークホルダーの視点から競合する解決策を評価するとき
• 定常的なコードレビューには使用しないでください。代わりに requesting-code-review を使用してください

ワークフロー

ステップ 1：異論の強度を選択する

決定の重要度に応じて、適切な異議申し立てのレベルを選びます。

レベル	目的	使用するタイミング
穏やか	中核となるアプローチには異議を唱えずに改善する	重要度の低い改善、初期段階の草案
体系的	意図を尊重しながら手法に異議を唱える	中程度に重要な決定、手法のレビュー
厳格	根本的な前提を厳しく検討する	重要度の高いアーキテクチャ、大幅な方向転換
パラダイム的	世界観を問い直し、抜本的な代替案を提案する	戦略的な方向性、イノベーションの追求

ステップ 2：前提を監査する

レビュー対象の提案について、次の項目を体系的に特定します。

1. 明示的な前提 — 何が所与のものとして述べられていますか？
2. 暗黙的な前提 — 述べられていないものの、機能している前提は何ですか？
3. 構造的な前提 — どのようなフレームワーク上の偏りが存在しますか？
4. 時間的な前提 — どの時間的制約が人為的なものですか？

| Assumption | Type | Validity | Risk if Wrong |
|------------|------|----------|---------------|
| Users prefer speed over accuracy | Implicit | Medium | Product misalignment |
| API rate limits won't change | Temporal | Low | System failure at scale |

ステップ 3：エッジケースを洗い出す

次の観点から提案に負荷をかけ、耐性を検証します。

• 規模の極端なケース：量が 10 倍または 0.1 倍になった場合、どうなりますか？
• パフォーマンスの限界：どこでこのアプローチが破綻しますか？
• ユーザー行動の極端なケース：最良および最悪の使用パターンはどのようなものですか？
• リソースの制約：予算、時間、またはチームの規模が半分になったらどうなりますか？

ステップ 4：異議申し立ての手法を適用する

代替案生成フレームワーク：

1. 目標の抽象化 — 具体的な実装から中核となる目標を抽出する
2. 制約の緩和 — 可能性を探るため、一時的に制約を取り除く
3. 手法の反転 — 正反対のアプローチを検討する
4. 異分野からの着想 — 他分野の解決策を応用する

ステークホルダーの立場からの提言 — それぞれの視点から主張します。

• エンドユーザー、メンテナー、セキュリティ、アクセシビリティ、将来のステークホルダー

ステップ 5：統合して推奨する

構造化された分析を作成します。

## Constructive Dissent Analysis: [Proposal Title]

### Intensity Level: [Selected Level]

### Executive Summary
[2-3 sentence summary of key challenges and recommendations]

### Challenges Raised
#### Challenge 1: [Title]
**Type**: Methodology / Premise / Evidence / Stakeholder
**Core Argument**: [What's being challenged and why]
**Evidence**: [Data or reasoning supporting the challenge]
**Alternative Approach**: [What to do instead]

### Generated Alternatives
#### Alternative 1: [Title]
**Approach**: [High-level description]
**Advantages**: [Why this might be better]
**Trade-offs**: [What you give up]

### Synthesis
- Strengthen current proposal: [specific improvements]
- Consider alternative if: [conditions that favor switching]
- Unresolved questions: [items needing more information]

ベストプラクティス

• 重要度に強度を合わせる — CSS の微調整にパラダイム的な異論を唱えるのは、全員の時間を無駄にします
• 建設的な姿勢を保つ — 人ではなく、アイデアに異議を唱えます
• 必ず代替案を提案する — 代替案のない批判は、単なる批判にすぎません
• 前提を明示的に記録する — 隠れた前提は、最もリスクの高い項目です
• ステークホルダーの立場から提言する — 藁人形論法ではなく、それぞれの視点から誠実に主張します