thinking-inversion

逆転思考

別の方法： ほとんどのリスク予測作業では、thinking-pre-mortem を優先してください。一般的なチェックリストよりも豊かで具体的な失敗原因を明らかにする、将来を振り返るナラティブ形式の分析を行います。逆転思考は、範囲を限定した機能や設計の失敗モードを手早く列挙する場合にのみ使用してください。計画全体、ローンチ、戦略的な意思決定には、プレモーテムのほうが有効です。

トリガーカード

楽観的な見方によってリスクが隠れている可能性のある、範囲を限定した機能や設計を計画するとき：

1. 目標を明確に述べます。
2. 「これを確実に失敗させるにはどうすればよいか？」と問いかけます。 — 具体的な失敗経路を10個以上挙げます。
3. 上位3〜5個を、明示的な回避要件に変換します。（例：「平文のパスワードを使わない」→「コスト係数12以上の bcrypt を使用する」）
4. 計画がそれぞれの要件に対応していることを確認します。

タスクが小規模でやり直し可能な場合や、失敗モードが既存のチェックですでに十分カバーされている場合はスキップしてください。計画全体やローンチには、代わりに thinking-pre-mortem を使用してください。

概要

チャーリー・マンガーが提唱し、数学者カール・ヤコビの原則「逆に考えよ、常に逆に考えよ」に根ざす逆転思考は、問題をその反対側から考えるアプローチです。「どうすれば成功できるか？」と問う代わりに、「確実に失敗させるにはどうすればよいか？」と問い、その経路を避けます。

基本原則：「私が知りたいのは、自分がどこで死ぬかだけです。だから、そこには行きません。」— チャーリー・マンガー

使用する場面

• 新しいプロジェクト、機能、取り組みを計画するとき
• 決定を下す前に評価するとき
• 楽観的な思考では見えにくいリスクを特定するとき
• 良い結果を達成する方法がわからず行き詰まったとき
• 計画の前提に疑問を投げかける必要があるとき
• 要件や受け入れ基準を作成するとき

判断フロー：

Have a goal? → yes → Can you list ways to achieve it? → maybe → INVERT FIRST
                                                      ↘ no → Definitely invert
           ↘ no → Define goal, then invert

使用しない場面

• ローンチ、プロジェクト、戦略的な意思決定全体を計画している場合。 代わりに thinking-pre-mortem を使用してください。チェックリスト形式の列挙よりも豊かで具体的な失敗原因を明らかにする、将来を振り返るナラティブ形式の分析を行います。逆転思考はより手軽で迅速なツールであり、プレモーテムはより深く掘り下げるツールです。
• タスクが小規模でやり直し可能で、失敗しても損失が小さい場合 — まず実行し、問題があれば修正します。
• 「テストがない」「命名が不適切」といった、ここでは当てはまらない一般的な定型の失敗モードしか挙がらない場合。具体的なものが出てこなければスキップしてください。
• 失敗モードが既存のチェック（CI、リンター、型システム）ですでに十分カバーされている場合。すでに防止されていることを再列挙しないでください。

プロセス

ステップ1：目標を明確に定義する

成功がどのような状態かを述べます：

Goal: "Ship a reliable authentication system by Q2"
Goal: "Build a high-performing engineering team"
Goal: "Launch product with strong user retention"

ステップ2：逆に考える —「どうすれば失敗するか？」と問う

失敗、破綻、または目標の正反対を確実に招く方法をすべて挙げます：

Goal: Ship reliable auth system
Inversions (How to guarantee failure):
- Skip security review and pen testing
- No rate limiting or brute force protection  
- Store passwords in plaintext
- No monitoring or alerting
- Skip edge cases in testing
- No documentation for on-call
- Single point of failure, no redundancy
- Ignore compliance requirements
- No rollback plan
- Deploy on Friday before vacation

ステップ3：失敗モードを分類する

種類と深刻度に基づいてグループ化します：

カテゴリ	失敗モード	深刻度
セキュリティ	平文のパスワード	致命的
セキュリティ	レート制限がない	高
運用	モニタリングがない	高
運用	ロールバック計画がない	高
プロセス	セキュリティレビューを省略する	致命的
プロセス	ドキュメントがない	中
信頼性	単一障害点	高

ステップ4：回避チェックリストに変換する

それぞれの失敗モードを要件に変換します：

Anti-goal: Store passwords in plaintext
→ Requirement: Use bcrypt/argon2 with appropriate work factor

Anti-goal: No rate limiting
→ Requirement: Implement rate limiting with exponential backoff

Anti-goal: Deploy Friday before vacation
→ Requirement: No deploys within 48h of team unavailability

ステップ5：影響度で優先順位を付ける

次のような失敗を避けることに注力します：

• 発生した場合に最も大きな損害をもたらすもの
• 明示的に防止しなければ最も発生しやすいもの
• 復旧が最も困難なもの

適用パターン

技術設計の場合

Goal: Build scalable API
Invert: How to make it fail under load?
- No caching → Add caching layer
- Synchronous everything → Add async where appropriate  
- No connection pooling → Implement pooling
- N+1 queries → Eager loading, query optimization
- No circuit breakers → Add circuit breakers

コードレビューの場合

Goal: Merge high-quality code
Invert: What would make this PR problematic?
- Introduces security vulnerability
- Breaks existing functionality
- No tests for new behavior
- Unclear intent/poor naming
- Performance regression
- Missing error handling

キャリア／チーム構築の場合

Goal: Build successful engineering career
Invert (Munger's list of what to avoid):
- Be unreliable
- Learn only from your own mistakes (ignore others')
- Give up after first failure
- Be resentful and envious
- Stay within comfort zone
- Avoid difficult conversations
- Don't learn continuously

プロジェクト計画の場合

Goal: Successful product launch
Invert: How to guarantee launch failure?
- No user research → Validate with users
- No load testing → Load test before launch
- No rollback capability → Build rollback
- No success metrics defined → Define metrics upfront
- Team burnout → Sustainable pace
- No communication plan → Prepare stakeholder comms

プレモーテムとの組み合わせ

逆転思考とプレモーテムを組み合わせることで、強力なリスク特定が可能になります：

1. 逆転思考： プロジェクトが失敗する可能性を列挙する（理論上）
2. プレモーテム： プロジェクトが実際に失敗したと想像し、その理由を説明する（ナラティブ形式）
3. 統合： 両方のリストを組み合わせ、優先順位を付け、対策を講じる

ソフトウェアでよくある逆転思考

領域	目標	避けるべき主な逆転要因
セキュリティ	安全なシステム	ユーザー入力を信頼すること、脆弱な認証、秘密情報の露出
パフォーマンス	高速なシステム	キャッシュがないこと、ブロッキング呼び出し、インデックスがないこと
信頼性	安定したシステム	監視がないこと、冗長性がないこと、適切な縮退ができないこと
保守性	クリーンなコード	テストがないこと、分かりにくい名前、密結合
チーム	高いパフォーマンス	コミュニケーション不足、心理的安全性の欠如、不明確な目標

検証チェックリスト

• 目標が明確に定義されている
• 失敗する、または正反対を達成する方法を10個以上挙げた
• 失敗を種類と深刻度で分類した
• 重大な失敗要因を明示的な要件に置き換えた
• 計画が最も重大な逆転要因に対処していることを確認した
• 見落としがないか、実際の設計と照らして重大な逆転要因を再確認した

重要な問い

• 「ここで確実に失敗するには、どうすればよいでしょうか？」
• 「他の人はどのような間違いをよく犯すでしょうか？」
• 「自分が最も見落としそうなことは何でしょうか？」
• 「これが派手に失敗したら、事後分析では何と言われるでしょうか？」
• 「他の人に避けるよう伝えることは何でしょうか？」
• 「成功の正反対は、具体的にはどのような状態でしょうか？」

マンガーの警句

「私たちのような人々が、一貫して愚かなことをしないよう努めることで、非常に賢くなろうとするよりも、長期にわたって大きな優位性を得てきたのは驚くべきことです。」

逆転思考の力は、楽観によって見えなくなりがちな明らかな誤りを避けることにあります。単純に避けるほうが、巧妙な最適化に勝ることもよくあります。