イーロンマスク氏がスペースXを案内するという動画（Starbase Tour with Elon Musk PART1 ）の中で語られた「開発の5ステップ」が僕的に衝撃でしたのでまとめます。
この内容、心底素晴らしいのですが、元動画では話が少しとっ散らかっていますし専門的すぎます。 僕自身、何度も内容を思い返して役に立ったのですが、見直すたび読解に苦労するので自分のためにまとめ直しました （ありがとう、僕！愛してるよ！）。
以降については、イーロンマスク氏が語る開発の5ステップについてまとめています。
余力があれば、自動字幕ありで動画を見ながらのほうが、イーロンマスク氏の熱意を感じられて楽しいと思います（下の動画では、この話が始まる辺りから始まるようにしています）。
VIDEO youtu.be
イーロンマスク、開発の5ステップ
開発の中では以下の順序を必ず守らないといけません。
要件をアホのままにしないこと。誰しもがアホにするので疑う
プロセスを削除する。無駄なのを積みたがるので徹底的に減らす
シンプル化・最適化する
サイクルを速くやる
自動化する
絶対に逆行してはいけません。
ステップ1：要件は必ずアホになる。アホのままにするな
要件は必ずアホになります 。それはあなたが書いても、誰が書いてもそうなります。
なので疑い、アホのままにしないでください。
とくに優秀な人が書いた場合、誰もが「完璧だ」と錯覚してしまい、質問できなくなるので危険です。
常に疑う必要があります。「その要件はなぜ必要なのか？」、「意味があるのか」と。
そして要件には署名すべきです。その要件を決めた人が責任を持って行動しなければいけません。たとえば2年前のインターン 生が、その要件の説明責任を果たせるでしょうか？ランダムに思いついた要件を、責任を取らずにいなくなってしまいます。
（注）
ここでいう要件はロケットに必要な耐荷重性能であったり、発生する振動の許容量などのことだと思われます。
ソフトウェア開発の世界でも要らない機能や、無視して良いデータフォーマットの都合、満たすべきでもないリクエス ト量の基準などたくさん要らない要件・制約が出てきます。
誰かがなぜか「必要」とした要件がすぐに発生します。疑いを持たないと、それらアホな要件をすぐ許容してしまいます。
この話が興味深いのは 「要件定義をしろ」ではなく「要件をアホなままにするな」と言っている点です 。誰がやっても最初はアホになるから疑えということです。
ステップ2：とにかくプロセスを削除する
要件に対して 人は必要なプロセスを積みたがりますが、ほとんどが不要です 。
「この要件ならこれも考慮しないと、あれも作ってカバーしておかないと」となりますが、削除してください。
私たちはタイトなマージンでやらないといけません（そうしないと軌道には乗りません）。そのためにプロセスは削除しないといけません。必要なら後で追加できます。むしろ、 追加し直していないのであれば、十分に削除していません 。
たとえばロケットのグリッドフィンも折り畳む必要はありません。シミュレーションして、迎え角が小さければ問題ないことを確認しています。追加のエンジン出力も必要ありません。そうすれば折り畳みに必要なモーターも機構もすべて不要になります。
（注）
ここでのプロセスをソフトウェア開発でいうと、具体的な動作や画面、モデルやテーブルのことでしょう。どうしてもアレコレと足してしまいがちですが、不要だとイーロンマスクは言います。追加し直すレベルに至ってないのであれば、まだ削除が足りていません。
この話、 常識的に考えればグリッドフィンは折り畳み可能としておきたい気持ちになります 。飛行機が飛び立った後には、タイヤを収納したい気持ちになりますよね？それと似た発想です。ですがそのプロセスそのものを削除してしまった、ということです。スペースXは宇宙に飛び立つ前に、常識という宇宙に穴を開けてしまっています。すごすぎます（グリッドフィンについてはイーロンマスク氏以外の人が思いついたものらしいです）。
ステップ3：やっと、シンプル化・最適化する
シンプル化・最適化を1つ目にしてはいけません。3ステップ目です。
優秀なエンジニアは「そもそも存在するべきでないもの」を最適化しがち です。
なぜ人はそうするのかというと、学校（中学校・高校）では問いに答えることを教えるからです。人は学校で問いに答えるべきであると刷り込まれ、問いそのものを疑うことを忘れています。問いを疑うと、成績を落とされてしまうからです。
なので人は、存在しないものを最適化したがります。
（注）
これは私を含めてエンジニアがすぐにやりたくなるやつです。
データ設計やクラス設計をより良くする
デプロイの過程を無駄なくする
画面の使い心地・手触りを良くする
アクセシビリティ を高める
要件やプロセスを削除してしまえば、これら全ては不要になります。「ここのボタンは『OK』じゃなくて『次へ』のほうが良いだろう」なんて、存在するべきでないポップアップや画面・機能、要件について議論しても無駄という話です。
ステップ4：速くやる
上記3ステップを忘れずに速くやります。サイクルの時間を加速しましょう。
あまりにも遅いときは、速く動いてください。ただし3ステップを忘れると、自分の墓を急いで掘ることになります。
とにかく、いつであっても早く・速くやることはできます。
ステップ5：自動化する
最後に、自動化してください。
（注）
この点について詳しく話されていませんが、前後の話から考えるにロボットを使って自動で作る工程を整備することでしょう。
ソフトウェア開発で言うならCIを導入したり、自動デプロイを整備したり、E2EテストやA/Bテスト・BlueGreenデプロイを整備することでしょうか。
イーロンマスクの失敗：モデル3のグラスファイバー マット
私（イーロンマスク氏自身）も、これについて何度も失敗しました。自動化し、速くやり、最適化し、削除したんです。
モデル3の製造であった、3つのバッテリーパックの上にグラスファイバー マットを敷くという生産ラインが、全体を阻害していました。バッテリーパックの生産、ひいてはモデル3の生産ライン全体を阻害していました。
失敗したのは、まずオートメーションを直したことです。ロボットの動作を速くし、経路を短くし、トルクを強くして改善しました。そして速く仕事をし、グラスファイバー マット用の糊を減らすよう最適化しました（糊は全体に塗る必要がなく、糊が延びることを加味して中心部に塗るだけで良かったのです）。
最後になって「これは何のためのグラスファイバー マットなんだ？」と疑問を持ちました。私がバッテリーセフティー チームに聴くと「ノイズと振動低減のためです」と答えたんです。でも彼らはバッテリーに責任があるはずですよね？そこでノイズと振動のチームに聴くと「火災防止のためです」と答えました。お互いが交差することを言っています！まるでDilbert の漫画です！Dilbert 漫画のシミュレーションの中にいるのか？と思いました。
よし、わかったと。グラスファイバー マットがある車・ない車で、マイクを積んで走らせました。試して聴き比べると、「で、どっちがどっち ？」となりました。違いがなかったんです。結果としてそのグラスファイバー マットは削除したんです。
過程を逆に行ったことで、それまでの自動化や最適化などすべてが無駄になってしまいました。存在すべきでないものを最適化したんです。
終わりに
これは本当にすごい洞察だと思います。まさにリーン的な発想というか、MVP（Minimum Viable Product）を求める姿勢そのものだなと感じます。
「機能を追加しよう」、ではなぜなのか？何のためなのか、どういう数値や体験を改善したいのか。
はたまた、その数値や体験の改善に意味はあるのか？
グリッドフィンを折り畳まないような発想ができているのか？
グラスファイバー マットを敷いてるんじゃないか？
そもそも存在すべきでないものを最適化してるんじゃないか？
とくに、エンジニアから出発したPdMや起業家は頭に入れておくべきことです。
イーロンマスク氏も言っているように、誰であれアホな要件を出すんです。プロセスを足したがるし、最適化したがるんです。
未来の僕、ぜひ読み直して、頭に入れておください。
動画を見た後に、失敗してたなって思ったでしょ？その後の仕事で何回も役に立ったでしょ？このステップをまとめておいたから、見返して思い出してね。
執筆：Kiyohara Hiroki (@hirokiky)
（Shodo で執筆されました
