dissent

/dissent

意思決定を強化する、構造化された異論です。後戻りできない選択をする前に、欠陥を見つけます。

異論は攻撃ではありません。自分が間違っている可能性を示す理由を、積極的に探すことです。

使用するタイミング

次のような場合に /dissent を実行します。後戻りできない選択（アーキテクチャ、公開 API、大規模な採用など）を確定する直前、自信は高いもののリスクがさらに大きい場合、周囲があまりに早く同意に傾いている場合、自分の立場を擁護している場合、または前に進む道が明白に思える場合です。

使用しない場合： 初期の選択肢を集めている段階や、ブレインストーミングの最中。異論は意思決定を検証するものであり、選択肢を生み出すものではありません。

異論の視点

このファイルに記載された中核的な異論プロセスをデフォルトで使用します。より専門分野に踏み込んだ検証が必要な場合は、該当する補足リファレンスを読み込んでください。

• アーキテクチャ、公開 API、技術的な方向性、または変更が難しい実装上の選択：references/architecture.md
• ナラティブ、ポジショニング、ドキュメント戦略、または概念的な枠組み：references/writing-framing.md
• 教育、オンボーディング、カリキュラム、または説明の戦略：references/learning.md
• プロダクト、運用、ワークフロー、優先順位付け、またはプロセスに関する意思決定：references/product-process.md

これらは視点として使い、ワークフローの置き換えには使いません。最終的な異論プロセスでは、現在のアプローチを最も強い形で示し、反証となる証拠を探し、プレモーテムを行い、隠れた前提を明らかにして、結論を出します。

異論プロセス

ステップ 1：現在のアプローチを最も強い形で示す

異議を唱える前に、その立場を明確にします。

「現在のアプローチは［アプローチ］です。その根拠は［理由］です。期待される結果は［結果］です。この立場を最も強く表現すると、こうなります。」

好意的に説明できないなら、異議を唱えるのに十分な理解ができていません。

ステップ 2：反証となる証拠を探す

• どのようなデータがあれば、このアプローチが間違っていると証明できますか？
• 誰が反対していますか？その主張は何ですか？
• 他の場所で、似たアプローチが失敗した例はありますか？なぜですか？
• 不都合だからという理由で、何を無視していますか？

「このアプローチが間違っているとしたら、どのような兆候が見られるはずですか？実際にその兆候はありますか？」

ステップ 3：プレモーテム

6 か月後に、この意思決定が失敗したと想像し、原因をさかのぼって考えます。

「これは［理由］で失敗しました。無視した警告サインは［兆候］でした。破綻した前提は［前提］でした。」

少なくとも、次のような失敗シナリオを 3 つ考えます。

1. 機能上の失敗 — 期待どおりに動作しない
2. 導入の失敗 — 動作はするが、誰も使わない／何も変わらない
3. 機会費用 — 動作はするが、別のことをするべきだった

ステップ 4：隠れた前提を明らかにする

すべての意思決定には、明示されていない前提があります。それらを見つけます。

• ユーザー／顧客について、何を前提にしていますか？
• システム／コードベースについて、何を前提にしていますか？
• スケジュール／リソースについて、何を前提にしていますか？
• 何が変わらないと前提にしていますか？

それぞれについて：

Assumption: [what we're taking for granted]
Evidence: [what supports this]
Risk if wrong: [what happens]
Test: [how to validate before committing]

ステップ 5：状況を再構成する

異論を経た後も、意思決定に必要な共通認識が残るようにします。反論と前提を確認した後、状況の捉え方を改めて整理します。

• 依然として正しいこと： 検証を経ても変わらなかったこと
• 最も弱い前提： 意思決定を覆す可能性が最も高いもの
• 変化した状況の捉え方： 反証となる証拠によって変わったこと
• 変化した確信度： 確信が高まった、または低下した点
• 次のアクション： 更新された状況認識に沿った、最小限の行動

これは /salvage ではありません。先に進む、調整する、または再検討するために必要な範囲だけを再構成します。

ステップ 6：結論を出す

• PROCEED — 重大な欠陥は見つからず、意思決定が強化された
• ADJUST — 対処可能な問題が見つかったため、アプローチを変更する
• RECONSIDER — 根本的な問題が明らかになったため、解決策の検討に戻る

「PROCEED：反論は［X］ですが、［Y］によって対処できます。重要な前提は［Z］であり、［方法］によって検証済みです。」

出力形式

## Dissent

### Dissent Report

**Decision under review:** [what's being challenged]
**Stakes:** [why this matters]
**Confidence before dissent:** [HIGH/MEDIUM/LOW]

### Steel-Man Position
[The best version of the current approach]

### Contrary Evidence
1. [Evidence point 1]
2. [Evidence point 2]
3. [Evidence point 3]

### Pre-Mortem Scenarios
1. **[Failure mode]:** [How this could fail]
2. **[Failure mode]:** [How this could fail]
3. **[Failure mode]:** [How this could fail]

### Hidden Assumptions
| Assumption | Evidence | Risk if Wrong | Test |
|------------|----------|---------------|------|
| [Assumption 1] | [Evidence] | [Risk] | [Test] |

### Reconstructed Story
- Still true: [what survived dissent]
- Weakest assumption: [assumption most likely to break]
- Changed situation model: [what changed]
- Changed beliefs: [confidence updates]
- Next action: [smallest fitting action]

### Decision

**Recommendation:** [PROCEED / ADJUST / RECONSIDER]
**Reasoning:** [Why]
**If ADJUST:** [Specific modifications]
**Confidence after dissent:** [HIGH/MEDIUM/LOW]
**Follow-up artifact?** [ADR / decision note / none — include path if needed]

セッションの引き継ぎ

セッションファイルを使用している場合は、## Dissent を置き換えるか、追記します。推奨事項、理由、検証した前提、およびフォローアップ成果物のパスを保持します。