🔥

イーロン・マスクから学ぶアルゴリズム戒律

2024/12/18に公開

はじめに

イーロン・マスクがテスラやスペースXでの生産に関する会議では、「アルゴリズム」なるものを持ち出すことが多いそうです。イーロン・マスクがネバダとフリーモント工場で経験した生産地獄から学んだ知見が詰め込まれています。

会議では、同席した幹部がイーロン・マスクの言葉に合わせて、神官と一緒に祈りの言葉を口にするかのように、この「アルゴリズム」を復唱するそうです…。

イーロン・マスク「アルゴリズム、アルゴリズムって壊れたレコードみたいですが、でも、耳タコになるほどくり返すべきものだと思うんです」

この記事の目的

以下では、イーロン・マスクがテスラやスペースXでの生産体制改善から得た「アルゴリズム」を紹介します。その思想をソフトウェアエンジニアリングの領域で応用するために、
この「アルゴリズム」をソフトウェア開発版として改変して自分への戒めにしたいと思います。

イーロン・マスクはテスラやスペースXの生産性・品質向上にあたり、工程全般を「疑い」、「シンプル化」し、「最適化」し、「自動化」するという一連のステップ(いわば「アルゴリズム」)を強調しています。これは単なる工場生産ラインだけの話ではなく、あらゆるクリエイティブなものづくりの現場(ソフトウェアエンジニアリング)にも適用可能です。

ソフトウェア開発では、往々にして複雑な要件、増大するコード量、冗長なプロセス、過度なツールやフレームワークへの依存が生じやすくなります。こうした状態では、プロジェクトは肥大化し、デプロイサイクルが遅れ、品質低下のリスクも高まります。

以下に、元々の「アルゴリズム」をソフトウェアエンジニアリングに当てはめ、具体的な行動指針へと落とし込んだ「エンジニアリング戒律」を提示します。

「アルゴリズム」

戒律は五つだ。

第1戒──
要件はすべて疑え。要件には、それを定めた担当者の名前を付すこと。「法務部」や「安全管理部」など部門名しか付されていない要件を受理してはならない。必ず、定めた本人の名前を確認しろ。そして、その要件を疑え。担当者がどれほど頭のいい人物であっても、だ。頭のいい人間が決めた要件ほど危ない。疑われにくいからだ。私が定めたものであっても、要件は必ず疑え。そして、おかしなところを少しでも減らせ。

第2戒──
部品や工程はできるかぎり減らせ。あとで元に戻さなければならなくなるかもしれないが、それでいい。実際のところ、10%以上を元に戻さなければならなくならないのなら、それは減らし足りないということだ。

第3戒──
シンプルに、最適にしろ。これは第2戒のあとにやるべきことだ。そもそもそこにあってはならない部品やプロセスをシンプルにしたり最適化したりしてしまうのは、よくあるまちがいだ。

第4戒──
サイクルタイムを短くしろ。工程は必ずスピードアップが可能だ。ただし、第1戒から第3戒までが終わったあとにやること。テスラの工場では、なくすべきだったとのちに気づく工程をスピードアップするのにかなりの時間を使うという愚を犯してしまった。

第5戒──
自動化しろ。これは最終段階だ。ネバダでもフリーモントでも、一番のまちがいは、ステップの自動化から始めてしまったことだ。要件をすべて洗い直し、部品や工程を減らせるだけ減らし、バグをつぶし切るまで自動化は待たなければならない。

このアルゴリズムを前提にするなら、必然的に導きだされることがいくつかある。例を紹介しよう。

  • 技術系管理職は実戦経験を積まなければならない。たとえばソフトウェアチームの管理職なら仕事時間の20%以上は実際にコーディングをしていなければならない。ソーラールーフの管理職なら、自分も屋根に上って設置作業をしなければならない。そうしなければ、馬に乗れない騎兵隊長、剣の使えない将軍になってしまう。
  • 仲間意識は危ない。相手の仕事に疑問を投げかけにくくなるからだ。仲間を苦しい立場に追いこみたくないという意識が生まれがちだからだ。これは避けなければならない。
  • まちがうのはかまわない。ただし、自信を持った状態でまちがうのだけはやめよう。
  • 自分がやりたくないことを部下にやらせてはならない。
  • 解決しなければならない課題に直面したら、管理職に伝えて終わりにしないこと。階級を飛ばし、管理職の下の人間と直接会うこと。
  • 採用では心構えを重視すべし。スキルは教えられる。性根をたたき直すには脳移植が必要だ。
  • 気が狂いそうな切迫感をもって仕事をしろ。
  • 規則と言えるのは物理法則に規定されるものだけだ。それ以外はすべて勧告である。

「エンジニアリング戒律」

さて、これをエンジニア向けに改変してみましょう。

第1戒──
要件定義、機能仕様はすべて疑え。要件定義、機能仕様には、それを定めた担当者の名前を付すこと。部門名しか付されていない要件を受理してはならない。必ず、定めた本人の名前を確認しろ。そして、その要件を疑え。担当者がどれほど頭のいい人物であっても、だ。頭のいい人間が決めた要件ほど危ない。疑われにくいからだ。要件は必ず疑え。そして、おかしなところを少しでも減らせ。

第2戒──
コード量、開発プロセスを極限まで減らせ。あとで元に戻さなければならなくなるかもしれないが、それでいい。もし10%以上を元に戻す必要が出るようなら、それは最初の削減が足りていなかったということです。

第3戒──
シンプルに、最適にしろ。これは第2戒のあとにやるべきことだ。そもそもそこにあってはならないコードやプロセスをシンプルにしたり最適化したりしてしまうのは、よくあるまちがいだ。

第4戒──
サイクルタイムを短くしろ。工程は必ずスピードアップが可能だ。ただし、第1戒から第3戒までが終わったあとにやること。無くすべきだった工程をスピードアップするのにかなりの時間を使うという愚を犯さないようにしろ。

第5戒──
自動化しろ。これは最終段階だ。一番の間違いは、ステップの自動化から始めてしまうことだ。要件をすべて洗い直し、コードや工程を減らせるだけ減らし、バグをつぶし切るまで自動化は待たなければならない。

  • 技術系管理職は実戦経験を積まなければならない。たとえばソフトウェアチームの管理職なら仕事時間の20%以上は実際にコーディングをしていなければならない。そうしなければ、馬に乗れない騎兵隊長、刀の使えない将軍になってしまう。
  • 仲間意識は危ない。相手の仕事に疑問を投げかけにくくなるからだ。仲間を苦しい立場に追いこみたくないという意識が生まれがちだからだ。これは避けなければならない。
  • 間違うのはかまわない。ただし、自信を持った状態で間違うのだけはやめよう。
  • 自分がやりたくないことを部下にやらせてはならない。
  • 解決しなければならない課題に直面したら、管理職に伝えて終わりにしないこと。階級を飛ばし、管理職の下の人間と直接会うこと。
  • 採用では心構えを重視すべし。スキルは教えられる。性根をたたき直すには脳移植が必要だ。
  • 気が狂いそうな切迫感をもって仕事をしろ。
  • 規則と言えるのは物理法則に規定されるものだけだ。それ以外はすべて勧告である。

終わりに

自己紹介と採用の募集です。
私は、ヒューマンハッカー株式会社の共同創業者兼CTOをしています。

弊社では、エンジニア社員第1号を募集しています。(現在私1人でUIデザインから開発までを行なっております。)

どんな会社かと言うと…。
日々、アプリにどんな機能があったら面白いか、習慣化コンテンツを作るにはどうすればいいかなどは会社のメンバー全員で話し合っています。
また、心理学、ゲームデザイン、行動経済学、神経伝達物質、哲学、SF、思考実験、統計などなど、あらゆる知識を持ち合わせて人間の行動をハックする方法を考えており、各メンバーがプライベートでも実験的なハックをしています。また、属性と性格に関する論文を大量に集めているなど、人間の特性を理解するための情報を集めています。

私と一緒に、組織のカルチャー形成、開発体制の構築などからコーディング、アプリの機能提案などを行なっていきましょう。

MBTIなどのあらゆる診断コンテンツをマージして、自分のトリセツを作成して、交換できる、そんな感じのアプリを作っています。
技術スタックは以下のようになります。

  • フロントエンド: Flutter
  • バックエンド: FastAPI
  • インフラ: AWS
  • ベクトルDB: Pgvector,LanceDBなど
  • 生成AI: OpenAI,Claude,Geminiなど

ここでは全て伝えきれないため、興味がある方は、ご連絡ください。
m@humanhacker.ai

(あ、弊社は完全出社です)

Discussion