first-principles

第一原理思考法

複雑な問題を基本的な真理に分解し、そこから筋道を立てて考える体系的なアプローチです。類推による思考の落とし穴を避けます。

awesome-skills/first-principles-skill v0.2.0 を基にカスタマイズし、イーロン・マスクの要件を問い直すマントラに従ってフェーズ 0（まず削除する）を追加しています。

このスキルを使う場面

• アーキテクチャや設計が本当に最適かを評価するとき
• 現在の状況に合わない可能性のある「ベストプラクティス」に疑問を呈するとき
• 従来の解決策では不十分に感じられるとき、打開策を探る
• 長期的な影響をもたらす基礎的な意思決定をするとき
• レガシーシステムに引き継がれた前提に異議を唱えるとき
• 既存のパターンを盲目的にまねることなく、新しいシステムを設計するとき
• 要件や手順がそもそも存在すべきかどうかを問い直すとき

中核となるプロセス

フェーズ 0：要件そのものに疑問を呈する（まず削除する）

問題を「どのように」解決するかを分析する前に、そもそも解決すべき問題なのかを問いかけます。

イーロン・マスクのマントラ：「要件はすべて、ある程度は愚かです」。存在すべきでないものを最適化するのが、最も愚かなことです。

1. 要件を完全に削除してみる - この手順／機能／制約なしでシステムは動作しますか？
2. 削除できるなら、削除する - 取り除くべきものを最適化してはいけません。
3. 削除できなければ、元に戻す - 分析に進むのは、その後です。
4. 誰が要件を定めたかに異議を唱える - 聡明な人が定めた要件は、疑問を抱きにくいため最も危険です。必ず問いかけましょう。「この要件を課した人は、免除できますか？」

重要な質問：

• この要件は存在する必要がありますか？
• この手順を単純に削除すると、どうなりますか？
• これは実際の制約ですか、それとも過去の経緯で残ったものですか？
• これがなくなったことに、ユーザーは本当に気づきますか？

注意すべき兆候（要件は不要かもしれません）：

• 「この手順はずっと続けてきた」
• 「法務／コンプライアンスで必要とされている」（確認しましょう。多くの場合、情報が古くなっています）
• 「ユーザーが期待している」（最近、ユーザーに確認しましたか？）
• 「仕様書に書いてある」（誰が、なぜ仕様書を書いたのでしょうか？）

フェーズ 1：問題の本質を特定する

実装の詳細を取り除き、問題の核心を見つけます。

1. 問題を明確に述べる - 具体的に何を解決する必要がありますか？
2. 症状と原因を分ける - これは本当の問題ですか、それとも問題の表れですか？
3. 成功基準を定義する - 完璧な解決策は何を実現しますか？

重要な質問：

• ここで本質的に達成すべきことは何ですか？
• このシステムが存在しないとしたら、ユーザーが実際に必要とするものは何ですか？
• どのような方法で実現するかに関係なく、重要な成果は何ですか？

フェーズ 2：あらゆる前提に異議を唱える

すべての前提を特定し、問い直します。

1. 明示的な前提を列挙する - 何を所与のものとして受け入れていますか？
2. 暗黙の前提を明らかにする - 疑問を持たずに、どのような慣習に従っていますか？
3. 前提を一つずつ検証する - これは本当の制約ですか、それとも単に昔からそうしてきただけですか？

前提の分類：

分類	問いかけること
技術	「この技術／パターンを使う必要がありますか？」
ビジネス	「この要件は本当に変更できませんか？」
リソース	「これらの制約は実際に存在しますか、それともそう思い込んでいるだけですか？」
歴史的経緯	「この決定は、もともとなぜ下されたのでしょうか？」

注意すべき兆候（誤った前提である可能性が高いもの）：

• 「ずっとこのやり方でやってきた」
• 「業界標準では……」
• 「これには誰もが X を使っている」
• 「単純すぎて動くはずがない」

フェーズ 3：確かな事実を確立する

これ以上分解できない事実を特定します。

1. 物理／数学上の制約 - 何に違反できませんか？
2. ビジネス上の不変条件 - ビジネスにとって、何が常に真でなければなりませんか？
3. ユーザーのニーズ - ユーザーが本質的に必要としているものは何ですか？

確かな事実のテスト：

• さらに分解できますか？
• これは一般に信じられているだけでなく、証明できますか？
• これに違反すると、必ず失敗しますか？

フェーズ 4：上向きに推論する

基本的な真実からソリューションを組み立てます。

1. 最小限から始める - 基本的な真実を満たす、最もシンプルなものは何でしょうか？
2. 必要なものだけを追加する - 追加するものには、それぞれ明確な理由が必要です
3. 各層を問い直す - この層は、その複雑さに見合う価値がありますか？

構成要素のアプローチ：

Ground Truth → Minimal Solution → Justified Additions → Final Design
     ↑              ↑                    ↑
  (proven)     (sufficient)        (each defended)

フェーズ 5：推論を検証する

ソリューションが妥当であることを確認します。

1. 基本的な真実に立ち返る - すべての設計判断を、根本的なニーズに結び付けられますか？
2. 弱い部分を特定する - 推論が前提に依存しているのはどこですか？
3. ストレステストを行う - このソリューションのどこが破綻しますか？

出力形式

第一原理思考を適用する際は、次の形式で分析を構成します。

## First Principles Analysis: [Topic]

### 0. Requirement Check (Delete First)
**Tried deleting:** [What was attempted]
**Result:** [Deleted / Cannot delete because: ...]
**Verdict:** [Proceed / Requirement eliminated]

### 1. Problem Essence
**Core problem:** [One sentence]
**Success criteria:** [Measurable outcomes]

### 2. Assumptions Challenged
| Assumption | Challenge | Verdict |
|------------|-----------|---------|
| [Assumption] | [Why question it] | [Keep/Discard/Modify] |

### 3. Ground Truths
- [Irreducible fact 1]
- [Irreducible fact 2]
- [Irreducible fact 3]

### 4. Reasoning Chain
Ground Truth → [Step 1] → [Step 2] → Solution

### 5. Conclusion
**Recommended approach:** [Description]
**Key insight:** [What the first principles analysis revealed]
**Trade-offs acknowledged:** [What we're accepting]

よくあるパターン

パターン：複雑さの罠

症状： ソリューションが、問題に見合う以上に複雑になっている

第一原理の確認：

1. コンポーネントを 1 つ取り除く - それでもシステムは核心的な問題を解決できますか？
2. 解決できる場合、そのコンポーネントは必須ではありません
3. 核心的な機能が損なわれるまで、これを繰り返します

パターン：類推の罠

症状： 「Company X がこの方法を採用しているから、私たちもそうすべきだ」

第一原理の確認：

1. Company X が実際に解決しようとしていた問題は何ですか？
2. 関連するあらゆる側面で、私たちの問題と同一ですか？
3. Company X にはあって私たちにはない制約（およびその逆）は何ですか？

パターン：レガシーの罠

症状： もはや役に立たない判断との互換性を維持している

第一原理の確認：

1. この判断の当初の理由は何でしたか？
2. その条件は今も存在していますか？
3. 変更の真のコストと、維持するコストはどれくらいですか？

他の思考ツールとの統合

第一原理思考は、次の補完的なアプローチと相性がよいです。

ツール	組み合わせるタイミング	方法
トレードオフ分析	基本的な真実を特定した後	基本原則に照らして選択肢を評価します
5 Whys	前提が浮かび上がったとき	根本原因を見つけるために、さらに掘り下げます
プレモーテム	ソリューションを確定する前	推論の連鎖にストレステストを行います
仮説検証	基本的な真実が不確かなとき	前提を経験的に検証します

適用範囲

行うこと：

• 前提に体系的に疑問を投げかける
• 第一原理から基本的な真実を特定する
• 基本事項から推論の連鎖を構築する
• 従来の通説が当てはまらない場合を明らかにする
• 要件そのものが必要かどうかを問い直す

行わないこと：

• 既存のソリューションをすべて誤りとして退ける
• あらゆる判断に無制限の時間を費やす（重要な判断に限って適用します）
• 理論上の純粋さを優先して、実際的な制約を無視する
• 「最善」のソリューションを保証する（完璧な答えではなく、よりよい推論を明らかにします）

クイックリファレンス

第一原理チェックリスト：

• 削除できるか要件を検証した — 完全に取り除けますか？
• ソリューションではなく、成果の観点から問題を定義した
• すべての前提を明示的に列挙した
• 各前提に疑問を投げかけ、正当性を確認した
• 基本的な真実を特定し、検証した
• 基本的な真実だけを基にソリューションを組み立てた
• すべての設計判断を基本的な真実に結び付けられる
• 推論の連鎖を文書化した

追加リソース

リファレンスファイル

• references/elon-musk-examples.md - SpaceX と Tesla の実例
• references/software-examples.md - ソフトウェアエンジニアリングへの応用

サンプルファイル

• examples/architecture-review.md - マイクロサービスに関する判断の第一原理分析