読書メモ『イーロン・マスク 上』/ Reading Notes: 'Elon Musk' - The 'Five Commandments' for Revolutionizing Development Processes
I’ve read Walter Isaacson’s biography ‘Elon Musk’. While it depicts his intense challenges at Tesla and SpaceX, what particularly struck me as a software engineer was the production “algorithm” described in Chapter 6, commonly known as the “Five Commandments.”
These are the principles that Musk repeatedly preached to his executives when the Tesla factory in Fremont fell into production hell. While they might appear to be Kaizen principles for manufacturing at first glance, I felt their essence is a universal truth that can be fully applied to software development and product management.
Today, I’d like to interpret these “Five Commandments” and the lessons derived from them from our perspective as software engineers.
The five commandments that Musk says he “repeats until everyone is sick of hearing them” are as follows:
必要だと考えられる要件にすべて担当者の名前を付けること。法務部や安全部門が要件を追加した場合でも同じだ。もしその要件が、本当に必要でないなら、いらない。定期的にその要件を見直すこと。そして、その作業をやめろ。
“Every requirement should come with a name attached to it. The same applies even when legal or safety departments add requirements. If the requirement isn’t truly necessary, it’s not needed. Review requirements regularly. And stop doing that work.”
This is about requirement definition itself in software development. How many times have features added for vague reasons like “seems necessary” or “would be nice to have” complicated systems and squeezed development schedules?
What this commandment teaches us is that every requirement needs a clear “why?” and “who?” Feature request tickets must always include the person requesting it and the underlying problem (the User Story’s “As a…, I want to…, so that…”). And it’s essential to have a culture where the entire development team healthily questions: “Does this feature really solve the user’s problem?” “Isn’t there a simpler way?”
もし元に戻す必要があるなら、すぐにやればいい。実際に戻すときには10以上も元に戻さなければならないということはまずない。エンジニアたちはあまりに多くのことを追加してしまう。そうなるとシステムを複雑化させ、最適化したつもりで逆に最適化しないことが多い。第一戒が守られていれば、第二戒も自然と守られることになる。
“If you need to add things back, you can do it immediately. In practice, you rarely need to add back more than 10 things. Engineers tend to add too much. This makes systems more complex and often de-optimizes rather than optimizes. If the first commandment is followed, the second naturally follows.”
This perfectly aligns with the principles of MVP (Minimum Viable Product) and YAGNI (You Ain’t Gonna Need It) in agile development. Engineers instinctively tend to add features and complicate systems. However, the cost of removing a feature once it’s integrated is many times higher than the cost of adding it.
Have the courage to cut features. First, release a product that can deliver minimum value, then consider the next move based on user feedback. This commandment represents an extremely important mindset in modern software development with high uncertainty.
工程はほとんどの場合、短縮可能だ。ステップを減らすこと。工場の自動化についても同じことがいえる。テスラの工場で最大の問題はスピードアップすることだ。つまり、ラインの時間を使うという愚を犯している。
“Processes can almost always be shortened. Reduce steps. The same applies to factory automation. The biggest problem at Tesla’s factory is speeding up. In other words, we’re making the mistake of using line time.”
This commandment puts the scalpel to the development process itself. Is your team’s CI/CD pipeline too complex? Has the code review flow become ritualistic? Do weekly regular meetings really contribute to decision-making?
We need to constantly question processes that continue only because “this is how it’s always been done.” Determine whether every step generates “value” and boldly cut away wasteful processes. This allows teams to work faster and focus on more essential work.
ネズミやフリーモントで一番よく見かける動物を思い出せ。自動化は必ず失敗する。まずは工程を簡単にし、手作業で実行してみて、それから自動化せよ。
“Remember the most common animals you see in Nevada or Fremont. Automation always fails. First simplify the process, execute it manually, then automate.”
This might be the most painful truth for us engineers who consider automation a virtue. But it’s the truth.
Automating broken or unnecessary processes only accelerates waste.
Before introducing new tools or writing complex deploy scripts, first execute the process manually. Discover bottlenecks and inefficiencies there, improve the process itself (Third Commandment: Simplify). Then, automate only the tasks that truly recur and have value. This sequence is critically important.
必ず例外が生じる。工程の見直しを続けること。
“Exceptions will always arise. Continue reviewing processes.”
Don’t make automation systems you’ve created into “sacred cows.” Business requirements and team situations constantly change. An automation pipeline that was once effective might now be technical debt that only incurs maintenance costs.
Automation doesn’t end with creation; you need to constantly monitor its effectiveness, improve it, and sometimes have the courage to “abolish” it.
Assuming these five commandments, several “discoveries” Musk mentions also deeply relate to our daily work.
- 技術的な課題は現実に接続されなければならない。 たとえばソフトウェアチームの課題なら、現場に出てコードを書くだけではなく、コードがどのように生産ラインの現場で使われているのか理解しなければならない。現場で働く作業員にインタビューし、彼らが直面している問題を理解することが不可欠だ。
- Technical challenges must be connected to reality. For example, for software team challenges, it’s not enough to just write code in the field; you must understand how the code is used on the production line. It’s essential to interview workers in the field and understand the problems they face.
Engineers should not only write code but also know how that code is used “in the field” - that is, by users. Participation in user interviews, reviewing customer support inquiry logs, and practicing dogfooding are essential.
- 仕事は分業できない。 ある仕事を一つのチームが担当するとしても、それだけで完結するわけではない。すべての仕事はほかの人の仕事と連携している。つまり、仕事は孤立して存在することはない。相互の連携を前提に動かなければならない。
- Work cannot be divided. Even if one team handles a job, it doesn’t complete on its own. All work is connected to other people’s work. In other words, work doesn’t exist in isolation. You must operate on the premise of mutual coordination.
Siloed teams like frontend, backend, infrastructure, and QA create delays in coordination and blame-shifting. This illustrates why DevOps philosophy and cross-functional team organization are important.
部門間での情報伝達が遅れると、仕事全体が停滞する。 部門ごとに分かれていると、連携を欠きやすくなる。問題が深刻化する前に立場に関係なく意見を言わなければならない。立場に追い込まれてからでは遅すぎる。
報告がうまくいかなければ、すべては無駄になる。 管理職に伝えて終わりにしないこと。階級を飛ばす必要があれば、ためらわずに飛ばせ。テスラではそれが許される。
When information transmission between departments is delayed, the entire work stagnates. When divided by departments, coordination tends to be lacking. You must speak up regardless of position before problems become serious. It’s too late once you’re cornered into a position.
If reporting doesn’t go well, everything becomes waste. Don’t just tell management and be done with it. If you need to skip ranks, don’t hesitate to skip them. That’s allowed at Tesla.
Don’t fear communication that leaps over hierarchies. People who discover problems should alert relevant parties directly, regardless of position. An open communication culture with high psychological safety prevents project stagnation.
- 長期的な成功は、必ず短期的な成果の積み重ねの上にある。 短期的な成果なくして長期的な成功はない。毎週必ず何かしら成果を出せ。仕事を前に進めること。それができなければ、力を失う。
- Long-term success always builds on accumulation of short-term results. There’s no long-term success without short-term results. Always produce some result every week. Move work forward. If you can’t, you lose power.
The phrase “always produce some result every week” is exactly what agile development sprints are about. Continue releasing working software (deployable increments) every week. This accumulation of small successes leads to great value.
- 規則といえるのは物理法則だけだ。 それ以外はすべて勧告である。
- Only the laws of physics are rules. Everything else is recommendations.
Internal rules, past technology choices, existing architecture are merely “recommendations.” If there’s a better way, question assumptions, challenge, and change. This hacker spirit is the source of innovation.
Elon Musk’s “Algorithm” is an extremely practical set of principles refined within the physical constraints of manufacturing. However, at its core lies a universal philosophy that transcends fields: “What is the essence?” - continuously questioning, confronting complexity, and thoroughly eliminating waste.
Question requirements, pare them down, simplify processes, identify the essence, then automate.
This sequence serves as a powerful compass showing the path we engineers should take in the ever-complicating world of modern software development. Does your team’s “algorithm” truly capture the essence?
That’s all from the Gemba.
As an Amazon Associate, codenote.net earns from qualifying purchases.