radical-simplification

根本的な単純化 — 複雑な問題を解きほぐすための思考の手立て

複雑な問題を一貫してシンプルな解決策へと導く数学者、物理学者、エンジニアの、文書化された実践手法をまとめたものです。このスキルは手順のリストではなく、思考の手立てを集めたツールボックスです。それぞれの手立ては、複雑さに直面した有能なモデルが陥りがちな特定の誤った思い込みを正します。各手立てはおおむね独立しているため、症状に合ったものを選んでください。

これは、リファクタリング（code-simplifier）、メトリクス設計（deterministic-metric-design）、レビュー（design-review）の上位に位置する思考のレイヤーです。これらのスキルは、形が明らかな成果物に対して方法論を適用します。このスキルは方法論そのものです。つまり、そもそもシンプルな形にたどり着く方法です。

適用するタイミング

次のような場合にこのスキルを使います。

• ユーザーが、問題が複雑すぎると感じる、チームが堂々巡りしている、またはもっとシンプルな方法があるはずだと言う
• 提案された設計にパラメーター、依存関係、分岐が積み重なり、過剰設計に感じられる
• 計画は作成済みだが未解決の決定事項が残っており、エージェントが仮定した答えを確定しようとしている
• バグ調査で、同じアプローチのバリエーションをいくつか試しても進展がない
• レビューで、不可避なものではなく偶発的な複雑さ（Brooks）を指摘される
• 難しいエンジニアリングまたはプロダクトの問題に対するエレガントな解決策を求められる
• 前向きの探索が行き詰まり、別の視点が必要になる（逆向きに考える、反転する、別の領域から応用する）
• 流暢に聞こえるものの、掘り下げられると根拠を示せない出力を生成している（ファインマン・テスト）

このスキルは、すでに正しく機能しているコードを整理するためのものではありません。それにはcode-simplifierを使います。このスキルを使うのは、シンプルにする必要があるのがアプローチそのものである場合です。

使い方

9つのカテゴリは、それぞれ独立した思考の手立てです。症状に合った手立てを選びます。

症状	選ぶ手立て	最初に読むルール
解決方法に違和感がある — 問題の捉え方が間違っているかもしれない	枠組みを定める	frame-restate-problem
計画は作成済みだが未解決の決定事項が残っている	明確にする	clarify-interview-one-at-a-time
ケース、パラメーター、分岐に圧倒されている	減らす	reduce-toy-case-first
部分同士が絡み合い、変更の影響が波及する	分解する	decomp-orthogonal-axes
前向きの探索が指数関数的に膨らむ、または行き詰まっている	反転する	invert-work-backwards
システムの構造的な真実を見落としている	制約する	constrain-name-the-invariant
現在の語彙の中にとらわれている	応用する	transfer-cross-domain-analogue
特定の問題がどうしても解決できない	一般化する	gen-rising-sea
根拠を示せない流暢な出力を生成している	監査する	audit-feynman-technique

各カテゴリの概要と順序の根拠については、references/_sections.mdを参照してください。

ルールのカテゴリ

#	カテゴリ	プレフィックス	方法	ルール数
1	問題を捉え直す	frame	言い換え、本質と偶発的な要素を切り分け、判断を見つける	3
2	インタビューを通じて明確にする	clarify	推奨する回答を添えて一問ずつ質問する。質問する前にソースを読む	2
3	最小のケースに縮小する	reduce	おもちゃの例、極限ケース、パレート圧縮	3
4	直交する軸に沿って分解する	decomp	直交する軸、WHAT と HOW	2
5	探索を逆転させる	invert	逆向きに考え、失敗を仮定する	2
6	不変条件と対称性で制約する	constrain	不変条件に名前を付ける、次元チェック	2
7	別の領域から転用する	transfer	領域横断の類例、用語への固執	2
8	問題が消えるまで一般化する	gen	上昇する海	1
9	自分の理解を監査する	audit	ファインマン、混乱に名前を付ける、フェルミチェック	3

クイックリファレンス

1. 問題を捉え直す

• frame-restate-problem — 解決に取りかかる前に、自分の言葉で言い換えます。誤った問題を解いている可能性に、まだ手遅れでない段階で気づけます
• frame-essential-vs-accidental — ブルックスの区別です。複雑さの要素をそれぞれ、本質的なものか後付けのものかに分類します
• frame-find-decision-point — 回答によって変わるべき判断を見つけます。文字どおりの質問ではなく、その判断に答えます

2. インタビューを通じて明確にする

• clarify-interview-one-at-a-time — 設計の分岐を一つずつたどります。すべての質問に推奨する回答を添えることで、ユーザーは回答を考え出すのではなく、提案された方針を確認できます
• clarify-prefer-source-over-asking — grep、ファイルの読み込み、実行時チェックで分かることなら、それを実行します。ソースからは分からないことだけを尋ねます

3. 最小のケースに縮小する

• reduce-toy-case-first — 一般化する前に n=1 を完全に解きます。大きな問題の構造が見えてきます
• reduce-limit-cases — ゼロ、無限大、空、単位元を調べ、設計が劣化する箇所を明らかにします
• reduce-pareto-compress — 結果の 80% を生み出す入力の 20% に合わせて設計します

4. 直交する軸に沿って分解する

• decomp-orthogonal-axes — 一方を変えても他方を変える必要がない場合、その軸は適切です。今日の名詞ではなく動詞を使います
• decomp-what-vs-how — HOW を議論する前に WHAT を書きます。仕様が判断基準になります

5. 探索を逆転させる

• invert-work-backwards — 順方向の探索が指数関数的になる場合は、ゴールの一歩手前で何が真でなければならないかを考えます
• invert-assume-failure — 設計を書く前に事後分析を書きます（マンガーの逆転思考）

6. 不変条件と対称性で制約する

• constrain-name-the-invariant — 変化しない性質は、答えを別の形で示していることがよくあります
• constrain-dimensional-check — 単位、型、カテゴリの不一致は、実行時エラーになる前からバグです

7. 別の領域から転用する

• transfer-cross-domain-analogue — 別の領域にある構造上の双子を探します。その解決策は転用できることがよくあります
• transfer-suspect-vocabulary-lock-in — 接尾辞の増殖（Manager、Helper、Coordinator）は、元の名詞が間違っている兆候です

8. 問題が解消するまで一般化する

• gen-rising-sea — グロタンディークの「上昇する海」です。より抽象的なバージョンのほうが簡単な場合もあります。ただし、概念が増えるのではなく、減る場合に限ります。

9. 自分の理解を監査する

• audit-feynman-technique — 技術的な略記を初心者にもわかる語彙の文に展開します。曖昧な説明が理解の抜けを示します。
• audit-name-the-confusion — 行き詰まったら、何がわからないのかを言葉にします。同じアプローチの変形を再試行してはいけません。
• audit-fermi-sanity-check — 答えを出す前に、桁違いの範囲で妥当性を確認します。10 倍の食い違いが手がかりです。

関連スキル

• code-simplifier — 適切なアプローチがわかった後に使うリファクタリングのパターンです（このスキルの後に、あちらのスキルを使います）。
• deterministic-metric-design — 指標を考案するという具体的な問題に、この方法論を適用します。
• design-review — UI をレビューするという具体的な問題に、この方法論を適用します。

作成時の注意

これらの手法は不可欠な要素であり、飾りではありません。各ルールが正すべき誤った既定の考え方は、そのルール自体に記されています。有能なモデルがすでに正しく実行できていることをルールが言い換えているだけなら、そのルールは削除してください。このスキルの網羅性は、ルール数を満たすことでなく、実際の複雑な問題のプロンプトに対する /dev-skill:eval によって実証されます。