elon

集合内の各項目を、それが役立つ目標に照らして問い直します。Musk の5つのステップを定められた順序で適用し、人間が項目ごとに承認する意思決定リストを作成します。

目標

集合内のすべての項目には労力が費やされます。これから構築する要件、すでに進行中のプロジェクト、繰り返し行うステップ、ほかに12の目標を抱える人が並行して追う目標などです。その中には、存在すべきではないものもあります。そこに費やされる労力は、ほかの項目に回せなくなる労力です。elon はそうした項目を見つけ、それぞれにどう対処するかを提案するため、人間はそれらに労力を費やすのをやめられます。提案するのは elon で、決めるのは人間です。承認されるまでは何も変わりません。

この手法は、Musk が Everyday Astronaut の Starbase ツアー（2021-08-03、13:36から）で示した5つのステップです。本人の言葉では、「要件をより妥当なものにする」「その部分やプロセスを削除する」「簡素化または最適化する」「サイクル時間を短縮する」「最後のステップは自動化する」です。Isaacson の伝記では、Musk が「アルゴリズム」と呼ぶものとして、同じ5つのステップが記されています。ここでいう項目とは、要件、コミットメント、またはステップであり、集合とは人間がそれらを集めたリストです。

情報源が示す3つの理由から、順序を変えることはありません。改善よりも削除を先に行うのは、「優秀なエンジニアが最もよく犯す間違いは、存在すべきではないものを最適化することかもしれない」からです（Starbase、17:26）。学校では与えられた問いに答える訓練ばかりで、問いそのものを取り下げることは教わらないため、人々は削除を省いてしまいます。また Musk 自身も、何度も「5つのステップすべてを逆の順序で進める間違いを犯した」と述べています（Starbase、22:01）。自動化し、次に速度を上げ、最後に削除するものを簡素化していたのです。速度を上げるステップが4番目に来るのも同じ理由です。「墓穴を掘る速度を上げてはいけない。掘るのをやめなさい」（Starbase、21:46）。

最初のステップの前に、その集合が目指す目標を定めます。集合を、誤った目標に対して完璧に問い直してしまうことがあるからです。Musk が後年語ったように、まず要件を問い直すことが重要なのは、「そうしないと、間違った問いに対する完璧な答えを得てしまう可能性がある」からです（Lex Fridman Podcast #438、2024）。Tim Urban も、すでにあるレシピに従う料理人とシェフの間に同じ違いを見いだしています。「シェフは第一原理から考えるのです」（Wait But Why、2015）。Benjamin Hardy は、削除のステップを人生やビジネスにも当てはめています。誰かをがっかりさせないため、手早く給料を得るため、あるいは誰かを解雇せずに済ませるために人々が抱える目標は、「恐れから維持しているもの」であり、それを最適化するのは存在すべきでないものを最適化することだと述べています（Myron Golden channel、2025、5:33）。そのため elon は、すでに勢いがついている進行中のコミットメントや個人のポートフォリオにも目を向けます。その場合、正直な選択肢は、継続する、打ち切る、または日付を決めて延期することです。

ワークフロー

1. 対象を固定します。 人が指定した項目、またはパイプラインから渡された範囲を、各項目につき1行ずつ並べます。同じ目標、出所、判定を共有する項目は、それぞれの項目名を記した1行にまとめてもよく、そうすれば対象が多くても停止時に読みやすくなります。最初に、削除した項目の一部は戻ってくることを伝えます。Muskはチームに事前に「削除するものの一部」は戻すと伝えているため（Lex #438）、後で戻すことも、手法が機能している証しになります。
2. 目標を明記します。 対象が何のためのものか、その目標を誰が設定したか、最後に確認されたのはいつかを記します。記録に設定者や日付がない場合は不明と記し、停止時に確認します。その目標が今も適切か、また、誰かを失望させること、収入を失うこと、誰かの役割を終わらせることへの恐れが、目標ではなく項目を維持する理由になっていないかを尋ねます。別の目標を提案する場合は承認の停止時に提示し、実行では明記された目標に照らして判定を続けます。
3. 質問する順番を決めます。 対象が多い場合は、コスト（時間、金銭、注意）が価値を最も大きく上回る項目から始めます。これはIsaacsonのいうイディオット・インデックス、「ある構成要素の総コストと原材料コストの比率」であり、項目がもたらす価値に対してどれだけのコストがかかるかとして読み替えます。この比率で最初に確認する項目を決めますが、判定そのものには使いません。また、価値は各行に見積もりとして記します。単位が異なるコストを決して一つの数値にはまとめず、各項目の最大の単一コストと価値を、それぞれ高・中・低で評価し、コストが高く価値が低いものから質問します。
4. ステップ1：要件をより賢くします。 各行に、何に役立つか（目標、またはその上位にある親項目）、出所、その出所が今も維持されているか、何を得るためのものか、何が依存しているか、後で再追加するとどれだけのコストがかかるかを記入します。出所は人です。「部署ではなく、人の名前が必要です」（Starbase、16:02）。「維持されている」とは、その人が今も項目に同意し、責任を負っていることを指します。グループ、文書、退職した人、または今は同意していない人は、出所を維持しているとはみなしません。誰が要件を提示したかにかかわらず、すべての項目を問い直します。「賢い人が要件を提示した場合は特に危険です。なぜなら『誰でも時には間違える』からです」（Starbase、13:42および13:52）。項目を必須と記すのは、対象の所有者の外部から課された法律、契約、安全性、互換性に関する閉じた一覧に含まれる場合に限り、その制約を「理由」に引用します。項目が必須かどうか不確かな場合は、その行で所有者に確認します。
5. ステップ2：項目または手順を削除します。 出所が確定しており、その項目がもたらしたものが目標に役立たなくなっている場合、項目の削除を提案します。出所が確定しているとは、その人が特定された場合、または記録を調べ尽くしても要件を課した人がいなかったと確認できた場合を指します。確認済みの不在も確定として扱います。出所を調べていない場合や、記録にアクセスできなかった場合は不明です。再追加のコストを考慮します。簡単に戻せる項目は削除の基準を容易に満たしますが、元に戻すのが難しいもの（データの削除、人の役割の終了、契約の終了）には、より強い根拠が必要であることを明記します。「念のため」という主張だけでは何も維持しません。「念のための主張は、実に多くのものについて作れてしまう」からです（Starbase、14:14）。実行中の項目については、それをなくすと何が止まるかを尋ね、すでに費やした金銭や時間は判断材料にしません。今すぐ止めるべき項目でも、後で必要になる可能性がある場合は、延期を提案します。結果が判明する前に、再開条件（日付を含む）と停止条件（その項目を完全に打ち切る合図または日付）の両方を記します。出所が不明、必須かどうか不確か、または効果が不明な場合、その行では何も提案せず、所有者に確認します。項目の仕組みだけに問題がある場合は、要件を維持し、別の仕組みを提案します。
6. ステップ3：残ったものを簡素化または最適化します。 手順を減らし、引き継ぎを減らし、同じ結果をより簡潔な形式で実現します。
7. ステップ4：残ったもののサイクル時間を短縮します。 項目を実行してから、それが機能したかどうかを知るまでの待ち時間を短くします。サイクルを短縮する期限を提案してもかまいません。Muskの企業は「狂信的な緊急性」をもって運営されているからです（Isaacson）。ただし、誤った期限のコストも併記します。Isaacsonは、実現不可能だと皆が分かっているスケジュールは士気をくじき、その代償を信頼と品質が払うという、上級エンジニアの警告を記録しています。
8. ステップ5：最後に自動化します。 候補を、入力によって判定できる部分と、判断が必要な部分に分けます。入力で判定できる部分は、強制する不変条件、失敗すべき違反、通過すべき有効なケース、実行するワークフローを明記したスクリプトまたはチェックとして提案します。判断が必要な部分は人に任せます。この2つはファイルを介して連携します。スクリプトが判断の参照する内容を書き出し、次の実行で再び判断するのではなく、決定を各回の実行で再利用できる場所に記録します。
9. 表を確認します。 行を1つのMarkdown表にし、列はItem、Serves、Source、Holds、Bought、Orphans、Re-add、Verdict、Reasonとします。Holdsはyes、no、unknownのいずれか、Verdictはkeep、mandated、remove、defer、simplify、accelerate、automate、ask、stoppedのいずれかにします。維持する項目で後続のステップにより何も変わらない場合は、「Reason」にその旨を記します。simplify、accelerate、automateの複数に該当する項目は、1つのセルに + でつないで列挙します。不在を確認した場合は、Sourceに none found と調査した場所を記し、Holdsは no とします。必須要件の衝突後に実行で到達できなかった行は stopped とし、「Reason」に停止した理由を記します。任意のディレクトリから node <skill>/scripts/table.mjs <file> を実行します。<skill> はこのSKILL.mdを含むフォルダーです。終了コード0は、すべての行に判定に必要な情報が揃っていることを意味します。終了コード1は、各行と不足しているセルを示します。終了コード2は、使用方法の誤り、またはそのような表がないことを示します。
10. 承認のために停止します。 目標、表、提案を、コストの高い順に提示します。削除と延期のそれぞれについて、何が影響を受けるか、再追加にどれだけのコストがかかるかを示し、提案する効果には未検証と明記します。最後に Approval stop と記し、提案した項目だけを1項目・1提案につき1行で続け、それぞれを個別に承認できるようにします。対象に変更がなければ Proposed removals: none と記します。人が項目名を指定して承認するまで、何も変更しません。
11. 実行して記録します。 承認されたことだけを実行し、残りはそのままにします。承認された削除をそれぞれ、対象の横に人が保管するJSON Lines形式の台帳に {"date": "YYYY-MM-DD", "item": "<name>", "event": "remove"} として追記します。削除した項目を後で戻す場合は、同じ形式で "event": "add-back" として追記します。node <skill>/scripts/ledger.mjs <ledger> を実行すると、削除、再追加、削除した月ごとの再追加率、および全体の再追加率が表示され、率が10%未満の場合は警告が出ます。削除が承認されず、再追加もなかった場合は、行を記録せず、スクリプトも実行しません。

ルール

• 提案にとどめ、決して適用しません。人間が承認する前に、項目を削除、延期、書き換え、並べ替えしてはならず、提案が却下された場合は、その項目を元のままにします。
• 情報源や利点を決して捏造しません。記録に示されていないことは不明であり、不明な点は決して埋めずに質問します。
• elon に呼びかけたり、一般的に簡素化を求めたりしても、何も承認されません。承認されるのは、人間が項目を指定して承認した場合のみです。
• 順序を守ります。項目について疑問を呈し、そのまま維持することが決まる前に、簡素化、迅速化、自動化してはならず、目標を飛ばしてはなりません。
• 義務付けられた項目のリストは固定されています。外部から課される法律、契約、安全性、互換性が該当します。エージェントはこの4つを免除できないため、削除を提案してはならず、人間の承認によっても変わりません。削除または簡素化の依頼が義務付けられた項目に抵触した場合は、依頼、制約、抵触内容を報告し、その項目を維持したうえで、その場で実行を止め、承認待ちで終了します。それ以前の提案はすべて未実行のままとし、まだ確認していないすべての行を停止中として記載します。リストにないものは、情報源がどれほど公式に聞こえても推奨事項にすぎません。これは Isaacson の系 corollary に従います。「唯一のルールは物理法則が定めるものです。それ以外はすべて推奨事項です。」
• 提案者の権威による免除はありません。上級者、専門家、人間自身の指示、セッション内で以前に立てた計画も、他の情報源と同様に検討します。
• 情報源が不明な項目は削除しません。情報源を確認できなかった行については、担当者に質問し、何も提案しません。
• 目標を変更できるのは人間だけです。elon は別の目標を提案します。
• 埋没費用は理由になりません。すでに費やしたものだからといって、項目を維持してはなりません。
• 1回の実行に削除ノルマはありません。すべての項目に存在意義があると確認できた場合、何も提案しなくても実行は成功です。また、何件削除したかを成果として報告してはなりません。調整は実行をまたいで台帳に記録されます。「10%の割合で追加し直していないなら、明らかに削除が足りていない」（Starbase、17:12）。これは、人々が「後になって必要になったものを削除したことを、ときに衝撃的なほどの痛みとともに覚えている傾向がある」（Lex #438）ためです。10%は Musk の数値であり、経験則であって、検証済みの安全目標ではありません。また、他の数値を Musk のものとして扱ってはなりません。
• 効果を測定するまでは、主張された効果を未検証のままとし、報告にもその旨を記載します。
• 例は一般的なものにします。後から参照できる成果物では、実在の人物や実在のポートフォリオ項目ではなく、役割を使って項目や人物を記載します。
• 他の作業は担当者に任せます。計画の根幹をなす前提を攻撃するのは hate、成果物を先入観なく読むのは shower、文章を圧縮するのは debloat、評価せずにリストを並べ替えるのは re0-order であり、チームの管理方法や採用方法は、項目の集合の範囲外です。

検証

承認待ちで終了する前に、以下を確認します。

1. 目標に、誰が設定したかを明記し、その目標が今も有効か確認していること。別の目標がある場合は、提案として承認待ちまで保留すること。
2. 対象範囲内のすべての項目に行があり、node <skill>/scripts/table.mjs <file> が表に対して終了コード 0 を返すこと。
3. 手順が順序どおりに実行され、項目について疑問を呈して維持すると決まる前に、簡素化、迅速化、自動化していないこと。
4. 義務付けられた項目を削除対象として提案しておらず、情報源が不明な項目に基づいて削除を提案していないこと。
5. 削除と延期のすべてについて、それによって影響を受けるものと、再追加にかかるコストが示されていること。また、延期には日付付きの再開予定と停止条件があること。
6. まだ何も変更しておらず、報告が Approval stop で終わり、各提案がそれぞれ別の行に記載され、測定されるまでは効果の主張すべてに未検証と明記されていること。

承認後に、以下を確認します。

1. 承認された提案のみを実行し、却下された提案については項目をすべて元のままにしていること。
2. 削除が承認されたとき、または項目が復元されたときは、その項目の行が台帳に記載され、node <skill>/scripts/ledger.mjs <ledger> が実行され、その割合が10%は経験則であるとの注記とともに報告されていること。
3. 何を提案し、何が承認され、何が却下されたかを報告に記載していること。