存在すべきでないものを、賢く改善しない。

2026.6.23

イーロン・マスクは本当に別次元だな、と最近改めて思う。

この人がいなかったら、電気自動車も、いまの宇宙開発も、ここまで進んでいなかっただろう——

中島聡さんのメルマガで、マスクの「5ステップのアルゴリズム」が取り上げられていた。あらためて、ウォルター・アイザックソンの伝記を見返してみた。

その5ステップは、ざっくりこういうものだ。

1. すべての要求仕様を疑う
2. 減らせる部品や工程は、すべて削除する
3. シンプルにして、最適化する
4. サイクルタイム（一周にかかる時間）を速くする
5. 自動化する

大事なのは、「何をするか」以上に、「この順番を守ること」。

多くの人は、いきなり④や⑤から始めてしまう。
でもマスクは、①と②をやっていないなら、こう言い切る。

「賢いエンジニアが犯す最もよくある間違いは、存在すべきでないものを最適化することだ。」

ステップ1：「賢い人の要求ほど、疑え」

いちばん居心地が悪いのが、このステップ1だ。

「すべての要求仕様を疑う。特に、賢い人が決めた要求ほど疑え。」

「頭の良い人がちゃんと考えて出した条件なんだから、正しいはずだ」と、周りが勝手に信じてしまう。
その結果、誰も「そもそもこれは必要なのか？」を問い直さなくなる。

だからマスクは、要求仕様には必ず「決めた人の名前」を添えるよう指示する。

「『○○部門の要求です』という言い方は絶対に受け入れるな。」

部門は責任を取らない。
個人なら、「なぜそれが必要だと思ったのか」を説明しないといけない。

Model 3の生産ラインでは、バッテリーパックのセンサーが「最初からずっとあったから」という理由だけで残っていた。
たどってみると、そのセンサーを要求したエンジニアはとっくに辞めていて、その問題自体ももう存在していなかった。

外してみても、何も壊れなかった。

「誰かが昔決めたから」というだけで残っているものを、どれだけ抱え込んでいるか——そこにまずメスを入れる。

ステップ2：「削除してから、壊れたら足す」

ステップ2は、マスクがいちばん好きだと言われる「削除」の工程だ。

普通の感覚だと、「明らかに不要なものから、慎重に消していこう」になりがちだ。

でもマスクのルールは、真逆に近い。

「削除できるものは、すべて削除する。そして何が壊れるかを見る。本当に必要なものだけを、後から足し戻せ。」

さらに、

「削除したものの少なくとも10％を足し戻していないなら、それは削除が足りない証拠だ。」

とまで言う。

SpaceXのラプターエンジンでは、この考え方で部品を次々と削り、機能をまとめ、システムごと消していった。

テスラの自動運転では、業界の「常識」だったレーダーすら、

「人間は目だけで運転している。カメラだけでいけるのではないか？」

と疑って、まるごと削除した。

危険だという批判も多かった。
それでもマスクはこう考える。

「必要に見えるものを削除しない限り、何が本当に必要なのかは永遠にわからない。」

この「怖さごと削る」感覚は、普通の会社ではなかなか真似できない。

ステップ3：「複雑さを最適化しても、複雑なまま」

ステップ3の「シンプルにして最適化する」が3番目に来るのが、実は一番重要だと思う。

多くの賢い人は、ここから始めてしまう。どう効率化するか、どう自動化するか、どう処理を早くするか。

でも、①と②を飛ばしてここに行くと、「本来存在しなくていいものを、ものすごく賢く改善してしまう」ことになる。

Model Xのファルコンウイング・ドアは、マスク自身が「間違いだった」と後に認めた例として有名だ。

どれだけ最適化しても、「そもそも不要な複雑さ」は不要なまま。
いくらチューニングしても、「なかったほうが良かった機能」は、やっぱりいらないままだ。

ステップ4・5：速さと自動化は「最後」

ステップ4は「サイクルタイムを速くする」。
SpaceXがロケットの試作とテストを驚異的なスピードで繰り返すのは、この哲学があるからだ。

ただし順番が大事で、「間違った方向に進んでいるなら、スピードはただ間違いを加速させるだけ」になる。

だから、問題設定→削除→シンプル化・最適化、ここまでやったうえで、速く回す、自動化する、が来る。

「自動化」は、企業がいちばん最初に手を付けたがるところだ。

でもマスクは、ここをいちばん後ろに置く。自動化すると、工程が固定化されてしまうからだ。

実際、テスラはModel 3の生産で、過剰な自動化に失敗した。
マスク自身が「人間は過小評価されている」と認めて、ロボットを減らし、人間の作業を増やした。

固定化する前に、本当に必要な工程だけを残し、それをシンプルにしてから自動化する。
この順番を守る。

「賢さ」を、どこに使うか

この5ステップで一番刺さるのは、「優秀な人ほど、順番を逆にしてしまう」という指摘だと思う。

賢い人ほど、不要な仕組みをうまく最適化できてしまう。本来いらない機能を、美しく自動化してしまう。

でも本当に重要なのは、「どう改善するか」ではなく、「そもそも必要なのか」を問い続けること——とマスクは言い続けている。

ラプターエンジンの進化を見ると、余計なものを削り、必須のものだけを残し、それを徹底的にシンプルにしたときに、初めて「異次元の性能」が出てくる。

自分が改善しようとしているものの中に、そもそも「存在しなくていいもの」は紛れ込んでいないだろうか——そう考えてみると、この5ステップは仕事やプロジェクトだけじゃなく、日常の習慣や予定の見直しにも、そのまま効いてきそうだ。

ーーーー
ーーーー

Don’t Optimize What Shouldn’t Exist

I keep thinking lately that Elon Musk really does operate on a different level.

Without him, electric vehicles and modern space exploration probably wouldn’t have come this far.

I came across a piece in Nakajima Satoshi’s newsletter about Musk’s “five-step algorithm,” and went back to take another look at Walter Isaacson’s biography.

The five steps go roughly like this.

1. Question every requirement
2. Delete every part or process that can be removed
3. Simplify, then optimize
4. Speed up cycle time
5. Automate

What matters isn’t just what each step is, but keeping this exact order.

Most people jump straight to step four or five. Musk’s position on skipping steps one and two is unambiguous.

“The most common mistake a smart engineer makes is optimizing something that shouldn’t exist.”

Step 1: Question the requirements — especially from smart people

This is the most uncomfortable step.

“Question every requirement. And be especially suspicious when smart people set them.”

Because the assumption tends to form on its own: this person is careful and capable, so the requirement must be sound. The result is that no one asks whether it was necessary to begin with.

So Musk requires that every requirement carry the name of the person who set it.

“Never accept ‘it’s a requirement from such-and-such department.'”

A department doesn’t answer for anything. An individual has to explain why they thought it was needed.

On the Model 3 production line, a sensor in the battery pack had been left in for no reason other than that it had always been there. When they traced it back, the engineer who originally required it had long since left, and the problem it was meant to address no longer existed.

When they removed it, nothing broke.

The first cut is into whatever remains only because someone decided it once, long ago.

Step 2: Delete first, add back what breaks

Step 2 is the deletion stage, which is said to be Musk’s favorite.

The natural instinct is to be careful — remove only what’s clearly unnecessary.

Musk’s rule runs almost the other way.

“Delete everything that can be deleted. Then see what breaks. Add back only what truly needs to be there.”

He goes further.

“If you haven’t added back at least 10 percent of what you removed, you haven’t deleted enough.”

With the SpaceX Raptor engine, this thinking led to successive rounds of cutting parts, consolidating functions, eliminating entire systems.

On Tesla’s Autopilot, even radar — considered standard practice across the industry — came into question.

“Humans drive with their eyes alone. Maybe cameras are enough.”

So radar was removed entirely. There was no shortage of criticism. But Musk’s reasoning held.

“Unless you’re willing to delete things that seem necessary, you’ll never find out what actually is.”

That willingness to cut through the fear of cutting — that’s not something most organizations can replicate.

Step 3: Optimizing complexity still leaves you with complexity

The fact that step 3 — simplify, then optimize — comes third is, I think, the most important thing about it.

Many capable people start here. How do we make this more efficient? How do we automate it? How do we speed it up?

But if you skip steps one and two and land here, you end up brilliantly improving something that didn’t need to exist in the first place.

The Model X’s Falcon Wing doors are a well-known case that Musk himself later acknowledged as a mistake.

No amount of optimization changes the fact that unnecessary complexity is still unnecessary. No amount of tuning makes a feature worth keeping if it was better off not being there.

Steps 4 and 5: Speed and automation come last

Step 4 is speeding up cycle time. The reason SpaceX iterates on rocket prototypes and testing at such a remarkable pace comes from this principle.

But the order still matters. Moving in the wrong direction and then going faster only accelerates the mistake.

So: define the real problem, delete, simplify and optimize — and only then, speed up and automate.

Automation is usually where companies want to start. Musk puts it last, because automating locks a process in place.

Tesla found this out with the Model 3 production. The over-automation failed. Musk acknowledged that “humans are underrated,” pulled back the robots, and brought more human work back into the line.

Before anything gets locked in, keep only the steps that genuinely need to be there, make them simple, and then automate. That order holds.

Where intelligence gets applied

The part of this framework that stays with me is the observation that capable people tend to reverse the sequence.

The smarter you are, the better you are at optimizing systems that should have been removed. At elegantly automating features that were never worth building.

But what Musk keeps saying is that the more important question isn’t how to improve something — it’s whether it was needed at all.

Looking at how the Raptor engine has evolved, the picture is consistent: remove the excess, keep only what’s essential, strip it down until there’s nothing left to strip — and that’s when performance on a different order becomes possible.

I noticed myself wondering how much of what I’m trying to improve contains things that were never necessary to begin with. Looked at that way, these five steps seem applicable not just to work or projects, but to habits and routines as well.