第一原理思考

🔍ステップ1：惰性の前提の特定 #

「昔からこうやっている」を全部文章にする

現在のやり方に敷かれた前提を残らず文章にする。「この機能にはサーバーが要る」「この価格より下では売れない」。書き出すまで、前提は空気のように見えない。最良の採集道具は新人と部外者の質問だ。「なぜこうするんですか？」に「昔からこうなので」と答えてしまう地点が、すべて候補だ。

前提の分類質問 #

物理法則か、規制か、ただの慣行か

書き出した前提を3つの等級に分ける。自然法則と数学は動かせない。規制と契約は高くつくが変えられる。慣行と業界の通念は、単に誰も問い直さなかっただけのものだ。ほとんどの組織で3つ目が圧倒的に多いという事実そのものが、このステップの収穫だ。等級付けの最速のリトマス試験は「これを破った事例が誰かにあるか」だ。

🔨ステップ2：分解 #

これ以上砕けない事実の単位まで下りる

問題を構成要素に分けるが、各パーツが検証可能な事実になるまで砕く。「クラウド費用が高い」は分解ではない。「リクエストあたりの平均演算量、単位演算の市場価格、トラフィック分布」まで下りて初めて分解だ。砕いていくうちに問題定義そのものが間違っていたと気づくことが多く、それがこのステップのよくあるボーナスだ。

分解の単位 #

コストならBOM、プロセスなら必要条件

どこまで下りるべきかは対象によって違う。モノなら部品表（BOM）と市場単価、ソフトウェアのコストなら演算・保存・転送の原単位、プロセスなら各工程が本当に満たすべき要件だ。判定法は1つ。そのパーツの値を第三者が独立に確認できるなら、事実の単位に到達している。

🏗️ステップ3：再組立 #

事実の上で最適解を積み直す

分解で得た事実だけを持って、白紙から解法を組み立てる。既存の解法は参考ではなく比較対象だ。再組立の結果が既存のやり方と同じでも失敗ではない。今度はそのやり方を「他社がやっているから」ではなく「事実が支持しているから」使うのだから、守備力がまるで違う。違う結果になったなら、どの前提を捨てたから変わったのかを指させなければならない。

再組立の規律 #

変わった地点ごとに捨てた前提を指す

新しい解法が既存と分かれる地点ごとに「捨てた前提の何番のため」という札を付けておく。この札がなければ、再組立はただの目新しいアイデアと区別が付かず、反対者との議論も好みの争いになる。捨てた前提が実は規制だったと後で判明するのが最悪のケースなので、ステップ1の分類がここで再び呼び出される。

罠：分解で止まる #

批判だけで再組立がなければ半人前

前提を壊す快感で終わるセッションが多い。既存のやり方の穴のリストだけが残り、代案がない。分解は中間生成物にすぎず、成果物は常に「だから何を変えるか」という再組立案だ。セッション開始前に成果物の形式（新しい構成案＋捨てた前提のリスト）を釘付けにしておけば、この罠はほぼ避けられる。

🪞類推思考との対比 #

敵ではなく、用途の違う道具

類推は実証済みのやり方を借りてくることで、速くて安く、だいたい正しい。日常の決定の9割は類推で処理するのが正しい。第一原理は類推が詰まったとき、つまり既存のやり方のコストが構造的におかしく見えるとき、全員が同じ壁の前に立っているときに取り出す道具だ。全部を第一原理でやるという宣言は、たいてい何一つ終わらない状態に行き着く。

いつどちらを使うか #

巻き戻しコストと慣行の値段で判断する

決定を巻き戻しやすいなら、類推で速く進み、間違えたら直す。巻き戻しにくく（アーキテクチャ、長期契約）、その領域の慣行の値段が異様に高い匂いがするなら、第一原理の出番だ。良いシグナルは「全員がそのコストに文句を言いながら、誰も構造を計算し直したことのない」項目だ。

💰実務例：コスト構造 #

見積もりではなく原単位から計算し直す

「業者の見積もりがこれくらい」は類推だ。第一原理では、そのサービスが消費する原材料（演算、ストレージ、人件費の時間）に市場単価を掛け直し、理論上の底値を作る。見積もりと底値の差が、そのまま交渉の余地であり内製化の機会だ。ロケットの材料費が完成品価格の一桁パーセントだという計算から再使用ロケットが生まれたのが、このパターンの教科書的な事例だ。

原価の底を探す #

差額の正体を3つに解剖する

理論上の底値と実際の価格の差は、普通3つに分解される。供給者のマージン、非効率（使わない機能の抱き合わせ）、そしてリスクプレミアムだ。3つのどれが大きいかで対応が変わる。マージンなら交渉と競争入札、抱き合わせなら要件の再定義、リスクプレミアムならそのリスクを自分で吸収するかを計算する。

⚙️実務例：技術選定 #

「みんな使っているから」の構成から要件の構成へ

「最近はみんなこのフレームワークを使う」は類推であり、大半の場合はそれで十分だ。第一原理が必要になるのは、その選択がコストや制約として跳ね返ってくるときだ。このときは実際の要求量（トラフィック、遅延の上限、データサイズ、チームの運用力）を数字で並べ、最小で満たす構成を逆算する。流行の構成の多くは、うちには存在しない規模の問題を解く道具だ、という結論が頻繁に出る。

要件を物理量に #

形容詞を数字に変えると選択肢が減る

「大容量」「リアルタイム」「スケーラブル」のような形容詞を、秒間リクエスト数、許容遅延ミリ秒、年間データ増加量に変える。数字が出れば、候補技術の半分以上がひとりでに脱落するか、過剰装備だと判明する。数字が出せないなら、それは技術選定の問題ではなくプロダクト定義が未完成なのだから、選択を先送りするほうが正しい決定だ。

⚠️乱用への注意 #

すべての会議を白紙から始めると沈む

第一原理はセッションあたりのコストが大きい。チーム全体が前提を掘り出して検証するのに数日かかる。だから四半期に1〜2個の構造的な問いだけに使い、残りは慣行で速く処理するのが健全な配分だ。すべての議題に「なぜ？」を投げる人は、第一原理の思考者ではなく、会議を麻痺させる人になりやすい。