本動画は、SpaceXやTeslaで経験を積んだ後、ハードウェア関連のスタートアップを立ち上げた二人の起業家（Galedineのチャンドラー・ルジッツァとMariana Mineralsのターナー・コールドウェル）を招き、両社で培った開発手法や組織文化について掘り下げたインタビューである。フラットな組織構造、クリティカルパスの特定、垂直統合の戦略的な判断基準、そして優秀な人材を採用・育成するための独自のアプローチなど、複雑な物理的プロダクトを迅速に構築し世に出すための実践的な教訓が詳細に語られている。
テスラとSpaceXの出身者が語る起業のきっかけ
SpaceXには4回も入社したんですよ。もう夢のような場所で、離れられませんでしたね。
私はテスラに10年ほど在籍して、バッテリーのサプライチェーン周りを飛び回っていました。
チャンドラー・ルジッツァは次世代ミサイル推進技術を手がけるGaledineのCEOです。ターナー・コールドウェルは、重要鉱物のサプライチェーンを構築するMariana MineralsのCEOです。
イーロンが非常に攻撃的な目標を設定する時、その本当の狙いはチームに深く熟考させることなんです。やるべきことが1000個あったとして、そのうちの100個は6ヶ月では絶対に終わりません。だからこそ、私たちはその100個に集中して取り組む必要があるんです。ミサイル業界には少し疎かったのですが、飛び込んでみて気づいたのは、数が圧倒的に足りていないということでした。コストが高すぎますし、製造スピードも遅すぎます。私のバックグラウンドはSpaceXやUCLAでの液体ロケット打ち上げなど、純粋に液体推進の分野です。この技術をミサイルシステムに応用するのは非常に現実的なアプローチだと気づき、実行に移すことにしたんです。
SpaceXやテスラで学んだことで、現在ご自身の会社で毎日実践している最も重要なことは何でしょうか。
ご存知の通り、私は物理的な世界でプロダクトを構築する起業家たちと多くの時間を過ごしていますが、頻繁に話題に上るのは、彼らの多くがテスラやSpaceXで経験を積んでいるということです。世間ではよく、徹夜での作業やフラットな組織構造、不可能な締め切りといった神話めいたエピソードが語られますよね。最高の部品は部品がないことだ、というような言葉も有名です。しかし、そうした神話の奥には、複雑なハードウェアをチームで構築し世に出すプロセスを根本から変える、再現性のある実践的な手法が存在します。本日は、次世代ミサイル推進技術を開発するGaledineのCEOであるチャンドラー・ルジッツァさんと、重要鉱物のサプライチェーンを手がけるMariana MineralsのCEO、ターナー・コールドウェルさんをお招きしました。チャンドラーさんはStarshipのリード推進エンジニアを務め、ターナーさんはテスラでバッテリーやその鉱物・金属部門を率いていました。イーロン・マスクの元で学んだ経験についてお二人からお話を伺えることを、とても嬉しく思います。まずは最初のきっかけからお話しいただけますでしょうか。お二人の会社の創業ストーリーや、目をつけた課題、最初のプロトタイプを作った時のこと、そしてこれが本格的なビジネスになると確信した瞬間について、簡単にお聞かせください。チャンドラーさん、あなたからお願いできますか。
はい。昨年の夏にこの業界に飛び込むまで、私はミサイル産業にはほとんど馴染みがありませんでした。しかし実際に見てみると、数が全然足りていないことに気づいたんです。コストは高すぎるし、製造スピードも遅い。それなのに、業界の誰もが昔ながらの同じやり方を続けているように見えました。全く違う結果を出したいなら、全く違うやり方をしなければなりません。私自身はSpaceXやUCLAで液体ロケットの打ち上げに関わってきたので、液体推進の専門家です。この技術をミサイルシステムに応用すれば確実に道は開けると考え、実行に移すことにしました。
素晴らしいですね。ターナーさんはどうですか。
私はテスラに10年ほど在籍し、バッテリーのサプライチェーン全体を奔走していました。特に直近では、鉱物や金属の分野に多くの時間を費やしていましたね。私たちの主な焦点は、サプライチェーンのボトルネックをいかに解消し、バッテリー製造のペースに合わせて必要な鉱物を確実に供給できる体制を作るかということでした。先ほどチャンドラーが言ったことと似ていますが、この業界の主要なプレイヤーは歴史が50年から100年もあるような古い企業ばかりです。そうした大規模で保守的な企業は、昔ながらのやり方に完全に凝り固まっています。テスラ時代にそうした企業と交渉したり、この分野のインフラを構築したりする中で非常に明確になったのは、この業界にはソフトウェアが決定的に不足しているということでした。
インフラを構築しようとする際に立ちはだかる課題の多くは、実は調整やオーケストレーションの層にあるんです。人材が不足していく中で、大規模で複雑な精製所をどうやって管理するのか。同じく人材難の中で、巨大で複雑な採掘現場をどう運営していくのか。私たちがたどり着いた結論は、自動車や人型ロボットの分野で進んでいる自律化の技術をフルに活用し、それを精製所や採掘現場に導入していくしかない、ということでした。
テスラとSpaceXから学んだフラットな組織と意思決定のスピード
テスラやSpaceXの企業文化については本当に多くの伝説が語られていますよね。バズワードは抜きにして、両社で学んだことで、今のご自身の会社で毎日実践している最も重要なことは何でしょうか。
そうですね、フラットな組織構造は極めて重要だと思います。情報を可能な限り素早く流通させる必要がありますし、情報へのアクセスを民主化しなければなりません。それこそがフラットな組織の本当の目的です。やり方を間違えるとただの混沌に陥ってしまいますが、フラットな組織の本来の狙いは情報の流れとコラボレーションを促進することにあります。ですから、どんな若手エンジニアであっても、いつでも経営陣やシニアメンバーのところへ行き、意思決定者に直接話をすることができるべきなんです。マネージャーを経由して情報を上げ、またチームに下ろすといった手間をかけずに、社内の様々なチームと直接コラボレーションできる環境が必要です。これは非常に重要で、私たちの会社づくりの大きな柱にもなっていますね。
チャンドラー、何か付け加えることはありますか。
はい、付け加えさせてください。そうしたフラットな組織を成功させるためのもう一つの要素は、私の経験から言うと、組織全体に迅速な意思決定ができるリーダーを配置することだと思います。バズワードを使わずに言えば、意思決定のスピードは本当に重要です。強い信念を持って力強く決断できるリーダーシップがあれば、開発のペースも生産サイクルも上がり、あらゆるものが加速します。例えば人間を宇宙に送るというミッションでも、多くのリスクが伴いますよね。そうした場において、強い信念を持ったリーダーが迅速な決断を下すことで、現場の若手エンジニアが抱える精神的な負担やリスクを取り除くことができます。結果として、彼らはより速く動けるようになるんです。
SpaceXやテスラに入社したばかりの若手エンジニアが、これは何十万、何百万ドルもかかるようなとんでもなく大きな決定だ、もし失敗したらどうしよう、と一人で思い悩んでいたとします。そんな時にリーダーがやってきて、ポンと決断を下し、いけ、と言ってあげることで、若手エンジニアの不安は取り除かれ、格段にスピードが上がるわけです。
すべての情報が出揃うまで意思決定を待つことなんてできませんからね。それに、大抵の場合、決断を下して実行し、高速でイテレーションを回してみるまでは、その決定が正しかったかどうかなんて分からないものです。常に正しい決定ができるわけではありませんが、正しい決定を下せる確率を常に最大化しようと努めることが大切なんですよね。
すべては賭けのようなものです。常に賭けをしているんです。
おっしゃる通りです。しかし、とにかくスピードが命です。スピードと、実行の卓越性。この2つに尽きます。
とはいえ、決断を下すためにはやはり情報が必要ですよね。
自ら設定した時間的な制約の中で可能な限り多くの情報を集め、決断を下し、そこから学ぶ必要があります。
ええ。そして、その新しい情報をまた次のプロセスに組み込んでいくということですね。
データのサイロ化を防ぎ、クリティカルパスに集中する
お二人はどちらも技術的な領域にかなり深く精通しています。元々はエンジニアであり、現在は企業のCEOを務めていらっしゃいますね。テスラやSpaceXでの前職での教訓や経験のうち、GaledineやMarianaでの結果や考え方に直接変化をもたらしたものは何でしょうか。
個別の技術的な問題を解決すること自体、もちろん難しいことです。多くの場合、前例のない問題に取り組むことになりますからね。しかし、そうした前例のない問題の解決に向けて大勢の人間を協力させる段階になると、実はそこで摩擦や混乱が生じ始めるんです。チーム間でね。いくら迅速な意思決定を心がけ、みんながコミュニケーションを取るようにしても、全員のベクトルがしっかり合っているかを確認する必要があります。全員が同じ目標に向かって、同じ方向へ進んでいなければなりません。
だからこそ、Marianaを立ち上げる際、私たちはチーム間の情報へのアクセスをいかに民主化し、データのサイロ化を防ぐかに注力してきました。10人から30人規模のチームなら、そうした問題はあまり起きません。しかし、100人以上の規模になると確実に起こり始めます。大規模なインフラを構築しようとチームが成長していく過程で、経営陣が情報の偏りやデータのサイロ化をなくせといくら口を酸っぱくして言っても、自然とそうした壁ができてしまうんです。ですから、私たちは情報共有の仕組みをコアとなるオペレーティングシステムに直接組み込もうと努めてきました。
なるほど。では、その課題に対して、具体的にどのようにプロダクトやシステムを構築したのでしょうか。
基本的にはすべてをウェブアプリでホストするようにしています。アクセス制御は原則として廃止しました。少なくとも社内においてはですね。コアとなるエンジニアリング情報を確認する際、どこかのハードドライブに保存されているとか、特定のグループにだけ送られたメールに書かれていて、転送してもらわないと読めない、といった状況は作らないようにしています。私たちは、誰でもアクセスできて、なぜその決定が下されたのか、あるいはどんな決定が下されたのかという文脈を理解できる統合されたデータ基盤の構築に本当に力を入れてきました。
チームが大きくなると、人々の間のつながりの数が激増し、それがプロジェクトの実行を困難にする主な原因になるからです。だからこそ、その情報へのアクセスを民主化しなければなりません。設計や調達、建設といった大規模な資本プロジェクトの実行においては、エンジニアリング部門、調達チーム、建設チームの間に信じられないほどのデータサイロが存在します。ですから、一つひとつの決定の履歴が追跡され、誰もがその履歴を見ることができる全く新しいオペレーティングシステムを構築する必要があるんです。最近では大規模言語モデルがあるので、データリポジトリの上でLLMを自由に動かすことができます。フォルダの構造がわからなくても、LLMに質問すれば必要な場所にすぐにたどり着けるようにできます。
採掘というビジネスは、理想的には永遠に終わらない一つの長い建設プロジェクトのようなものです。そのため、地質学、採掘計画、メンテナンス、採掘現場の運営、そして処理施設の間で、同じような課題がたくさん発生します。プロジェクト全体の文脈や、現場全体で下されているあらゆる決定事項の背景を共有しないと、人々は自分たちの手元にある限られたデータの中だけで判断を下してしまいます。私たちが目指しているのは、意思決定のスピードを上げつつ、誰もが全体最適を見据えた決断を下せる環境を整えることです。
チャンドラーさんはどうですか。
私の答えは、とにかくクリティカルパスに集中するということですね。クリティカルパスを追いかけ、火消し役として走り回るというのは、SpaceXのエンジニアはもちろん、テスラのエンジニアも日常的にやっていることだと思います。
それがどういうものか、説明していただけますか。
もちろんです。クリティカルパスというのは、スケジュールを直接左右する要因のことです。次のフェーズに進むため、あるいは最終目標に到達するために絶対に完了させなければならない、スケジュールの要となるタスクや調達活動を指します。Galedineはまだ若い会社ですが、次のフェーズやマイルストーンに到達するために、常にクリティカルパスを追いかけ、モグラたたきのようなゲームを延々と続けています。
では、現在のクリティカルパスの次に来る決定事項に遅れを出すことなく、どのようにチームをクリティカルパスに集中させているのでしょうか。
私から一つお答えしてもいいですか。小学2年生のサッカーみたいな真似をしてはいけない、ということです。クリティカルパスにばかり視野を狭めていると、時々そういう状態になりがちなんです。小学2年生のサッカーというのは、全員がボールの周りに群がってしまう状態のことですね。ですから、クリティカルパスに対処するためにコアとなるチームを動員しつつも、次の課題が遅れをとらないようなシステムを構築する必要があります。そのための有効な手段が、並行して走っている課題に独立して対処できる小さなSWATチームを編成することです。すべてのリソースをクリティカルパスに振り向けるのではなく、今はクリティカルパスではないけれど進めておくべき事柄を、並行して処理できるようにするんです。私たちはそのように考えています。
本当にそうなりがちなんですよね。常にベクトルを合わせる努力をしていないと、みんな騒ぎの方に引き寄せられてしまいます。その時はそれが一番熱い話題に見えるからです。うわ、これのせいでロケットの打ち上げが止まっているぞ、とか、生産ラインが完全に止まっている、となれば、みんな、手伝いたい、手伝いたい、と群がってきます。でもそこで、次の課題が予定より早くクリティカルパスになってしまわないよう、リソースを分散させて集中させないといけない、とコントロールする必要があるんです。
チャンドラーさん、Galedineはまだかなり初期の段階ですよね。社内でそれをどのように管理しているのでしょうか。それとも、まだ本当にクリティカルパスが一つしかないような段階なのでしょうか。
間違いなく後者ですね。今のチームは6人なので、そのコントロールは比較的簡単です。しかし、それでも非常に重要です。初期メンバーの多くは専門分野やドメインに基づいて役割分担していますから、エンジン設計の問題で生産が止まっているからといって、アビオニクスのエンジニアがそのトラブルシューティングに行くのはあまり理にかなっていません。
クリティカルパスの解決にはおそらく役立ちませんね。
その通りです。だから私たちの場合は少し管理しやすいのですが、今後チームが急拡大していく中で、コントロールを失ってリソースを無駄にしないようにすることは、常に頭の片隅にあります。
情報共有の仕組みとスプリントの活用
より実践的、あるいは戦術的なアドバイスとして、テスラやSpaceXからご自身の会社に持ち込んだ具体的なプロセスやリズムのようなものはありますか。
これについては私から先にお話ししますね。私がとても気に入っているやり方で、直感に反するように聞こえるかもしれませんが、メールでの進捗報告です。特にクリティカルパスに関連する事柄について、シグナルが高くノイズの少ないメール報告を行うことは極めて重要です。より多くの人に情報を共有するという目的がありますからね。
それは、あなたからチームへのメールですか、それともチームから発信されるものですか。
チームから発信されるものです。誰でも構いません。先ほどの火消しチームの話で言えば、通常、その問題を解決に導く極端なオーナーシップを持った責任者が一人はいるはずです。その人が責任を持ち、高い頻度でメール報告を送り、問題の困難な部分を乗り越えていく過程を共有することは、チーム全体がそれを知るためだけでなく、プロジェクトに取り組んでいる本人にとっても、その日何があったかを振り返り、文字にするという意味で、とてつもなく重要だと思います。
文字に書き起こすというのは本当に絶大な効果があります。私は常にポケットにノートを入れていますよ。頭の中にあるものを書き出し、それを客観的に見ることで、今日は目標に向けて一番直線的な進み方ができなかったな、明日は軌道修正しよう、と気づくことができるんです。
そうですね。そして2つ目ですが、非常に忙しい時って、どうしても書き出したりレポートを作成したりする時間がなくなるのが自然な流れです。私たちが試みているのは、製造プロセスを回している時の日々のオペレーションのようなやり方です。シフト間で引き継ぎ事項が毎日メールで送られますよね。プロセス開発やR&Dの現場でも、製造プロセスのように思考を促したいなら、一日の終わりにそのシフトの引き継ぎと同じようなことをするのが一番の強制力になります。今日はこれをやりました、本来はこれをやる予定でした、予定していたことができなかった理由はこれです、といった具合に共有するんです。
ただ、チームが大きくなり様々なことが動き始めると、それを作成するのは負担になってきます。そこで私たちが力を入れているのは、すべてのデータが同じ統合データ基盤に入るようにして、引き継ぎ事項の大部分を自動入力できるようにすることです。そうすれば、人間は引き継ぎ内容を一から書くのではなく、レビューする立場になれます。
編集したり、少しコメントを加えたりするだけになるんですね。
ええ。大規模なオペレーションであっても、引き継ぎ業務は非常に手作業が多いことがわかりました。データ自体は集まっているのに、誰かが1時間かけてその日に起きたことを正確に書き出さなければならない。ですから、そうしたものをいかに自動生成するかに多大な労力を注いできました。とはいえ、最終的には人間に目を通してもらいたいんです。送信ボタンは人間に押してもらいたい。中身に対するオーナーシップと説明責任は人間が持つべきですからね。
私たちが試みているもう一つの大きなことは、バランスの問題になりますが、会社全体にドラムビートを設定する必要があるということです。会社のリズムを作らないと、みんな自分が何に向かって進んでいるのかが分からなくなってしまいます。フラットな組織に一定の構造を与え、ある種のリズムで意思決定が上がっていくことを全員に理解させるんです。もちろん、その日中に下さなければならない超重要な決定もありますから、柔軟性は必要です。それでも、会社に構造とリズムを与え、全員が事実上同じリズムで動けるようにしたいんです。
スプリントのようなものですね。
スプリントという言葉は、会社にとって本当に極めて重要なもののために取っておくようにしています。もちろん、ソフトウェアエンジニアリング部門は2週間のスプリントで動いていますよ。でも、絶対に達成しなければならない大きなマイルストーンがある時は、それをスプリントと名付けて、さあ、会社全体でこれに向かって全力疾走するぞ、と宣言します。
ただ、ドラムビートというのは少し意味合いが異なります。大規模なインフラを構築する場合、それは12ヶ月や18ヶ月のプロジェクトになりますから。
そうですよね。クラウドにソフトウェアをリリースするのとは訳が違います。その気になれば毎日でもリリースできる世界とは違うわけです。
ええ。キャリア全体をソフトウェアの世界だけで過ごしてきた人たちにとって、12ヶ月から18ヶ月にわたって一つのことに取り組み続けるというのは、頭で想像するのが難しい部分だと思います。
確かに長いサイクルですよね。
ただ、このリズムを設定するもう一つの目的は、中間地点での小さな勝利を祝う時間を作ることでもあります。18ヶ月という期間の中で、自分たちがどれだけ多くの進歩を遂げているかを見失いがちだからです。後から振り返って、おー、これを作り上げたぞ、すごいな、と思うことは簡単です。でも、そのリズムを作り出すことは、チームに対する報酬機能でもあるんです。よし、自分は正しいことをやっているぞ、正しい方向に向かっているぞ、と実感させることができますから。定期的にそうした調整や確認ができる機会を設けるんです。
目標設定と燃え尽き症候群の防止
マイルストーンの設定について、チャンドラーさんはどうお考えですか。
人間が可能な限り最速で、ですね。ターナーも影響を受けていると思いますが、常にイーロン・タイムというものが存在していて、それと戦うのは普段から大変です。
私もマイルストーンを設定する時は、間違いなくそちらの傾向に寄っていると言えますね。
ここまでお話を伺っていれば、よく分かります。
ええ。幸運なことに、私はこれまでの短くも密度の濃いキャリアの中で、ロケットの様々な部分に触れることができました。だから、何にどれくらいの時間がかかるかについては、ある程度の尺度が自分の中にあります。先ほどのドラムビートの話にも通じますが、チームの認識を合わせるために、初期段階で、これくらいの時間がかかると思うけど、実際に実行する立場として、これは妥当だと思うか、と率直に話し合うようにしています。早い段階で議論をぶつけ合い、最初からそのスケジュールを設定してしまうんです。
実際に私たちもそうしました。みんなで座って話し合い、6月までにロケットを打ち上げるという非常に野心的なスケジュールを設定しました。そこに至るまでに必要なことを細かく分解してみると、実はとても理にかなっているんです。もしその道筋から外れ始めたら、何がおかしいんだ、とすぐに原因を探ることができます。
リーダーシップのポジションに技術的に優れた人材がいることが、本当に重要になってくる部分ですね。
ええ。説得力がなければいけませんから。何が本当に困難で、でも達成可能なのかという感覚を、コアとして持っている必要があります。
非常に攻撃的なマイルストーンを設定する目的についてですが、私は全員がそうすべきだと思っています。その本当の目的は、実際のクリティカルパスが何であるかを洗い出すことなんです。先ほどの話に戻りますが、過去にやったことがあるから、36ヶ月かかるはずだ、と言う代わりに、イーロンがとんでもなく攻撃的な目標をドカンと設定するのは、チームに深く熟考させるためです。その短すぎる期間の中で、何が機能しないのか、何が解決できないのかを徹底的に考えさせるためなんです。
そうすることで、優先順位のリストができあがります。6ヶ月でやり遂げたいなら1000個のことをやらなければならない。そのうち900個は6ヶ月でできるが、残り100個はどうやっても無理だ。よし、じゃあその100個に集中攻撃を仕掛けよう、となるわけです。
集中攻撃というのは、それを削除してしまうことも含まれますよね。
その通りです。それらを表面化させて、切り捨ててしまうんです。
まさにそうですね。
テスラもSpaceXも、徹夜続きの非常に激しい労働文化や長時間の労働、そして普通なら36ヶ月かかることを6ヶ月でやろうとするような、過酷な締め切りで有名ですよね。そうした状況で、チームが燃え尽きないようにするにはどうしているのでしょうか。
これは結局のところ、会社がどれだけミッションと一致しているか、あるいは会社のミッションがどれだけ強力かというところに帰結します。楽しければ、仕事という感覚にはならないんですよね。特に、会社のミッションに深く共鳴している人たちにとってはそうです。SpaceXの場合で言えば、人類を多惑星種にする、というミッションは、全力で働き、サポートするに値する素晴らしい目標です。だからこそ、長時間労働や徹夜が続いても、精神的なダメージがそれほど大きくないんです。
私自身、今とても深く考えているのは、これまで防衛について考えたこともなかった多くの人々に、防衛分野に情熱を持ってもらうにはどうすればいいかということです。現実として、SpaceXやRocket Lab、Firefly、Relativityといった企業にはとんでもない才能を持つ人材がたくさんいて、彼らにもこの防衛の課題に取り組んでもらう必要がありますからね。しばらく誰も手をつけていなかったアメリカン・ダイナミズムに焦点を当てた新しい課題に対して、SpaceXなどの企業が労働力と共に実現してきたような、燃えるようなミッションへの共感をどうやって作り出すか。それができれば、すべてが苦痛ではなく、楽しいことのように感じられるはずです。
そうですね、ミッションへの共感は間違いなく中核となる要素です。実際に燃え尽き症候群を引き起こす原因は、無駄な摩擦やチャーン、目標に向けて前進している感覚の欠如だと思います。何か目標に向かって働いていて、実際に進歩しているという実感があれば、そしてミッションに共感していれば、困難な問題を解決することは楽しいことになり得るんです。目標に向かって前進している限りはね。
仕事を楽しくなくしてしまう要因はいくつかあります。無駄な摩擦というのは、チームをバラバラな方向に動かすような一貫性のない意思決定から生じることがあります。素早く機敏に動くスタートアップでは、これは多少なりとも避けられない部分です。しかし2つ目の要因として、社内政治は信じられないほどの摩擦を生み出します。データのサイロ化や、自分のレゴブロックを抱え込む、と私たちは呼んでいますが、情報を囲い込む行為も膨大な摩擦を生みます。そうしたものに対処しなければならず、よし、解決すべき問題がある、道筋は明確で、決定も下されており、優先順位もはっきりしている、という本来の仕事に集中できない状況になると、情熱が失われてしまいます。道筋さえ明確なら、みんな死に物狂いで働くんです。チームの周りに、コアとなるミッションから意識を逸らさせるような要因があると、ワクワクする気持ちは間違いなく破壊されてしまいます。
不可能に思えるような目標だからこそ、人々は熱狂できるんです。自分たちがそれを証明してやる、ってね。不可能に感じられるからこそ、本当に心が躍るんです。
ただし、チャンドラーが言ったように、攻撃的であっても可能な目標を設定している限りは、という条件がつきます。可能性の範囲内であることが絶対に必要です。達成するための技術的な道筋が全く存在しないような、あまりにも無謀すぎる目標を設定してしまうと、逆に士気を下げることになります。ですから、可能な限り無駄な摩擦を取り除き、モチベーションを下げない、やる気を引き出せる目標を設定するというバランスが大切ですね。
大企業とスタートアップの違いと製造の捉え方
視点を変えてみましょう。テスラやSpaceXでの原則のうち、新しい会社では上手くいかなかったことや、ドメインや会社の規模などの理由で適用できず、アンラーン（学習棄却）する必要があったパターンはありますか。
面白い例を挙げると、やらないと決めたわけではなく、導入を遅らせているものがあります。Starshipの開発で確実に採用されていましたし、Dragonでも少しありましたが、SpaceXのような巨大なリソースが背後にあると、信じられないようなことができます。クリティカルパスと戦うために、効率は悪くても目標を達成できるような力技が使えるんです。多くのことを並行して進めるというのは、時間的にもコスト的にも非常にリソースを消費します。今の私たちの規模ではそれはできません。しかし、成長するにつれてスピードを出すためには、可能なことはすべてやらなければなりません。現在の私たちにとっての可能と、SpaceXにとっての可能は種類が違います。ですから、さらにスピードを上げるために、いつその手法を導入できる規模になるのかを見極めることは、常に意識していますね。
テスラでのコアな原則の中で、模倣しないとピンポイントで決めたようなものは特に思い当たりません。むしろ、摩擦や離職、燃え尽きといった問題に対処するために、導入の仕方を少しマッサージして柔らかく調整しているという表現の方が近いと思います。
テスラの場合、会社の規模が桁違いに大きくなる過程を経験されていますよね。つまり、全く異なる2つのバージョンの会社を見てきたわけです。ですから、テスラが10万人を超えた頃の教訓の中には、今のあなたにはあまり関係のないものもあるのではないでしょうか。
初期の頃は当然ながらもっとフラットでした。13万人、14万人という規模になると、どうしても階層構造を少し入れざるを得なくなりますからね。
工場のフロアで働いていて、設計の意思決定にはあまり関わらないような巨大なグループも存在しますしね。
ええ。それでも、そうした組織はフラットで機敏な状態を保ちましたし、それは今日でも続いています。テスラの運営方法の大部分を私自身も信じているので、完全に否定するような原則はありません。ただ、チームにとってより持続可能な形にするために、プロセスの中で細かな微調整を重ねているという感じです。
少し話題を変えましょう。テスラとSpaceXは、あらゆる問題に対してファクトリーマインドセット、つまり工場マインドセットでアプローチすることで有名です。すべては工場である、と。先ほどターナーさんも触れましたが、すべては製造上の問題に行き着くという考え方ですね。これが実際にどういう意味を持つのか、少しお聞きしたいと思います。チャンドラーさんからお願いします。Starshipでのイテレーションについて教えていただけますか。V1からV2、V3へと進む中で、システムの複雑さと生産速度のバランスをどのように取っていたのでしょうか。
背景を説明しておくと、私がStarshipのプログラムに参加したのはフライト3の時期でした。フルスタックという意味ではV1に少し触れ、その後V2の開発サイクル全体を推し進め、退社する前にV3に触れてその基礎を固め始めたという感じです。
私たちにとってこのトレードオフの核心であり、スピードを生み出し、この工場マインドセットや生産への集中を可能にしたのは、要件、つまり要件定義でした。設計の段階で、馬鹿げていると思える要件を可能な限り早く洗い出し、それらを方程式から叩き出して消し去る機会を作れれば、残されたものは非常にシンプルになります。
例えばどんなものですか。
少しマニアックな話になりますが、面白い例があります。ブースターからハードウェアを流用する機会があったんです。ブースターのチームはV3の設計において、シップのチームより少し先行していました。彼らはブースターのV2をスキップして、V1から一気にV3へ進んでいたんです。そこで、V3の機体用に設計されたハードウェアの中に、シップに簡単に組み込めるものがあることがわかりました。
推進システムのハードウェアを大量に設計しなければならないのに、エンジニアの数は非常に限られていました。そこでおっ、これが使えるぞ、と気づき、前倒しで持ってくることにしたんです。ブースターよりも早く実装することになります。そこで出てきた少しおかしな問題が、それが燃料タンクの中にあるシュノーケルのようなものだったということです。
そのシュノーケルの中に液体が結露する可能性があり、タンクのガス抜きをしているバルブは液体を嫌います。よし、タダでハードウェアが手に入った、設計サイクルを丸ごとスキップできるぞ、早く生産に入ろう、と急いでいた時に、あ、これの中にも液体が入ってくるぞ、バルブが耐えられるかわからないな、と気づいたんです。
そこで私たちがやったのは、それが問題ないことを証明するために必要なリソースをすぐに投入したことです。その結果、このハードウェア設計全体を予定より早く生産に回すことができただけでなく、ブースター側も準備ができた時に同じハードウェアを使えるようになりました。会社の目標という観点から見れば、完璧な方向性で素晴らしい結果でしたね。
このアイデアは私一人の功績ではありません。今もチームに残っている別のメンバーが私のところに持ってきて、うわ、それ最高じゃん、やろうぜ、ぶっ飛ばそう、となったんです。要するに、すべての要件を疑うという明確な意図を持ち続けるということです。そうすることで、いざエンジニアがハードウェアの設計に取り掛かる時に、非常にシンプルな解決策を設計できるようになります。シンプルであることは、速くて安い、ということです。SpaceXのこのスローガンは本当に真実で、Starship全体で起きていますし、Dragonの修正においても起きています。
生産のことを2歩先まで考えて集中していなかったら、与えられた要件に合わせて一から完璧に特注のものを設計してしまっていたわけですね。
その通りです。要件に合わせた特注品ですね。あ、あっちを使えばいいじゃん、そうすれば、この少し複雑な溶接部品をどう作るか早く考え始められるし、量産体制もすぐ作れるぞ、と気づく前に、文字通りすべてのハードウェアの設計図を丸ごと作ってしまっていたんですから。
そこで情報へのアクセスが本当に重要になってくるんですね。
絶対にそうです。
建設と採掘の現場における製造マインドセット
ターナーさんはどうですか。あなたはテスラがコーパスクリスティに建設した10億ドル規模のリチウム精製所の立ち上げに貢献し、現在は稼働していますね。そこで乗り越えた最も困難な課題は何でしたか。そうした工場や生産のマインドセットでどのようにアプローチしたのでしょうか。
製造を見据えた設計、Design for Manufacturingというのは、プロダクト設計を行う上で、非常に短いタクトタイムで大規模な生産にスケールできるようにするためのアプローチです。
ええ。でも普通、精製所を一つのプロダクトとしては考えませんよね。
その通りです。私たちがかなりの時間を割いて考えたのは、もちろんテスラ時代にも考えていたことですが、基本的に建設現場というのは特注品を作っている環境だということです。ですから、それをオフサイトで製造して現場に持ち込めるような、モジュール化されたサブセットに分解しなければなりません。
そして、すべてのものに対してタクトタイム分析を行う必要があると考えるべきです。つまり、何かを効率的に構築するために必要な個別のステップをすべて細かく分解するということです。
タクトタイム分析というのは、テスラやSpaceXの用語ですか。それとも業界用語ですか。
業界用語です。私たちが発明したわけではありませんよ。ここで重要なのは、R&Dや分析ラボの運営といったバリューチェーン全体を通じて、サンプルがラボに入ってきてから結果が出るまでの個別のステップは何なのかを考える必要があるということです。分析ラボも小さな製造プロセスのように運営しなければなりません。
建設においては、ボルトを実際に締める、継ぎ目を溶接するといった具体的なタスクのレベルまで細かく落とし込み、そこから積み上げて実際のスケジュールを割り出す必要があります。これを建てるのに大体これくらいかかるだろう、というトップダウンの見積もりではダメなんです。
採掘のオペレーションにおいても、現場で発生するあらゆる個別のタスクに対して、非常に詳細なタクトタイム分析を行う必要があります。建設業界では、もちろんやっている人もいますが、個々のプロジェクトが特注品であるという性質上、何かに実際にどれくらいの時間がかかるのかをボトムアップで計算するには、多大な時間と労力、そしてリソースを割り当てる必要があります。
建設を製造オペレーションのように運営するにはどうすればいいか。一般的な建設現場の回し方は、現場監督がその月の目標を与えられ、毎日現場に出て職人たちと円陣を組み、お前は今日何をする、お前は、と確認します。そして一日の終わりに、今日は何をした、と報告させます。そこには、定期的な数値化や定量化はほとんど存在しません。実際に数値化された、短い間隔での建設作業のコントロールが行われていないんです。
そこで私たちがMarianaで始めたのは、それを細かく分解することです。これは結局、データ管理とリソースの最適配置の問題になります。現場には資材と機材のセットがあり、人員のセットがあり、完了すべきタスクのセットがあります。現在は人間がこの3つのデータベースの間に座って、よし、現場でどのタスクを実行するか、を決定しようとしています。私たちは、これをアルゴリズムで処理できる巨大なチャンスがあると考えています。
すべてのデータが揃えば、1日ごと、あるいは1時間ごとの目標を設定できるようになります。さらに現場でのデータ収集を自動化できれば完璧です。Boston Dynamicsの四足歩行ロボット、Spotなんかは素晴らしいですね。現場を歩き回って3Dスキャンを撮ってくれます。取得した3Dスキャンをモデルと照合させるために、ソフトウェア側でかなりの作業が必要にはなりますが。
それができれば、建設現場で短い間隔でのコントロールが可能になります。これこそが事実上の製造なんです。超短間隔のコントロールです。誰もがダッシュボードを見て、今日のこのステーションではいくつ部品を作るんだと把握でき、目標に向かって順調に進んでいるのか、遅れているのか、あるいは上回っているのかがわかるようになります。建設、採掘、精製において重要なものを測定する、こと、これこそが変革すべき文化的な部分なんです。
テスラでもかなりの程度、これを実践しようと努力しました。しかし最終的には、それを可能にするソフトウェアのバックボーンに投資しなければなりません。
私がこれまでに会った起業家の中で、予定より早く、予算内で進んでいます、とあなたほど頻繁に言う人はターナーさん以外にほとんどいませんよ。
まあ、努力はしています。結局は測定し、数値化することに尽きます。製造業では、1時間に何千という部品を作ったりしますから、深く理解しようと努めますよね。目標に対して測定し、ターゲットを設定するというそのレベルの管理が、大規模インフラのエコシステムでは起きていないだけなんです。
垂直統合を行うべき真の判断基準
垂直統合についても少しお話ししましょう。これはテスラとSpaceXの原則として最も明白で、よく語られるものの一つです。同時に、非常にコストがかかり、困難なものでもあります。最近もTVPNでこの件についての良いセッションがありましたね。すべてのハードテック・スタートアップは垂直統合すべきなのか。いつ、どこを垂直統合すべきなのか。お二人はどう考えていますか。スピードと資本集約度、そして運用リスクのバランスをどう取っているのか、ぜひ垂直統合についてのご意見を伺いたいです。チャンドラーさんからいかがですか。
はい、私からお話しします。マイク・ヴィンチアタと直接この件について議論したんですよ。
かなり波紋を呼んでいましたね。
ええ、いい議論ができました。面白かったですよ。私は概ね、そこで出た意見に賛成です。
見ていない方のために、どういった意見だったのか教えていただけますか。
私が解釈した内容としては、戦略的でなければならない、ということです。白紙の状態から理想論だけで、うちは垂直統合するぞ、というのは、ある意味でナイーブだと思います。垂直統合は決して簡単ではありません。
確かに簡単ではありませんね。
非常に困難です。私たちは、それをいとも簡単にやってのけているように見える企業から来ているので錯覚しがちですが、実際は全然違います。
外から見れば、ですよね。
ええ、外から見ると超簡単に思えるんです。
とてもロマンチックな夢ですよね。
その通りです。実際にその痛みを経験したことがない人が多いので、戦略的に垂直統合を進めることに伴うトレードオフを理解できていないんだと思います。私がどう考えているかというと、自分たちのサプライチェーンや生産ラインのボトルネックになるようなアセンブリは、可能な限り早く社内に取り込まなければならないということです。
私たちのケースで言えば、かなり大きな溶接部品などがそれに当たります。これを早い段階で内製化するのは比較的簡単に着手できることですが、実際には複数のステップを伴う非常に複雑な工程です。これを社内に取り込めれば、年間1万発のミサイルを製造するという目標に向けて、テーブルの上の厄介なモグラを1匹叩き潰したことになります。
もちろん他にも課題はたくさんあります。最終的なプロダクトを見据えた時、何が自分たちのスケジュールを最も圧迫しているかを見極めなければなりません。私たちの場合、今まさに助けてくれと叫んでいるような要因がおそらく5つほどあります。そうしたものは当然、どうやって解決するか、どんな方法でやるか、と真っ先に考える対象になります。そこから初めて、それを実現するための資本の集中度や、必要な時間を分析し始めるんです。とにかく戦略的でなければなりません。うちは完全に垂直統合している、と手放しでアピールしているような会社は、間違いなく大量の資金を浪費することになります。
私も、垂直統合すること自体を目的とした垂直統合は全く意味がないと思います。チャンドラーの意見に賛成ですね。垂直統合に関する決定事項は数千にも及びますが、特に創業初期の段階では、すべて一つの質問に集約されるべきです。もし垂直統合するという決定を下さなかった場合、この会社は存続できるのか、という問いです。
Marianaが存続するか、しないか。そういう二項対立の問題のレベルまで落とし込めば、決定は簡単になります。その要因はいくつかあります。必要な部品が存在しないのか、技術が存在しないのか、あるいは外部に頼むとコストが異常に高すぎて、垂直統合しないと会社が成り立たないのか。サブコンポーネントであれソフトウェアスタックの一部であれ、自分たちでやらなければ会社が存在できなくなる、ような事柄であれば、それが究極の戦略的な決定要因になります。
ですから、垂直統合すればこのサブコンポーネントのコストを5パーセント、10パーセント、あるいは20パーセント、50パーセント削減できる、というだけの理由で手を出してはいけません。やらなければ会社が存続できないか、というチェックボックスにチェックが入らないなら、やるべきではないんです。
つまり、第一の目的はコスト削減ではないということですね。
初期段階ではそうあるべきではありません。他の多くのスタートアップと同様に、リソースが少なく、成長を続けるチームをどこに配置するかを判断しなければならないようなリソース制約モードにある時は、会社が存続するかしないか、という二元的な結果をもたらすものにのみ垂直統合を行うべきです。
やがて大きなチームが動き出し、ユニットエコノミクスを下げていく段階になれば、そこで初めてコスト主導の垂直統合が興味深い選択肢になってきます。しかし、ここでの決断はより長期的な視点が必要です。机上の計算では素晴らしく見えても、サプライヤーから自社へのリスクの移転が最大の懸念事項になるからです。
サプライチェーンに関わる業者たちは皆、その活動においてリスクを背負っています。垂直統合によってサプライチェーンの接点が減るわけではありません。むしろ、上流工程を垂直統合すれば、彼らが持っていたサプライチェーンを今度は自分たちが吸収しなければならず、結果としてサプライチェーンとのやり取りは拡大してしまうんです。
私たちは、ソフトウェア企業でありながら、自ら鉱物インフラを構築・運営する企業になるという決断を下しました。主な理由は、採掘企業にソフトウェアを販売するだけの企業は、この分野に参入するのが非常に難しいからです。純粋なSaaS企業としてやった場合、ソフトウェアやテクノロジーの導入スピードが、顧客となるべき企業によって制限されてしまうという問題があるんです。
ええ。
ですから、この点に関して私たちの問いは常にMarianaは存続できるか、でした。ソフトウェア企業と採掘企業の両方を兼ね備えていなければ、答えはノーであり、会社は存在できません。だから私たちはそうせざるを得なかったんです。しかし、ひとたびその道を選ぶと、次はどこでパートナーシップを結ぶか、どの分野のエコシステムが十分に豊かで、競争が激しく、サブコンポーネントやソフトウェアスタックのコストが確実に下がるという確信が持てるか、という問題に直面することになります。
採用の哲学とインターンシップの重要性
テスラとSpaceXのどちらも、採用する人材の優秀さで非常に有名ですよね。先ほどお話しいただいたような、ミッションへの共感という部分も大きいでしょう。優秀な人は、他の優秀な人と一緒に働き、学びたいと思うものです。それにしても、両社からこれほど多くの優れたエンジニアや起業家が輩出されているのは驚異的です。こうした企業での採用活動はどのように行われているのでしょうか。どうやってあれほど優秀な才能やエンジニアを惹きつけているのですか。そして、そこでの教訓を、今ご自身が構築している会社にどのように取り入れていますか。
少なくともテスラでは、そして間違いなくSpaceXでもそうですが、採用プロセスの鍵となるのは技術的な評価です。これが非常に深いんです。エンジニアのポジションに応募した場合、オファーをもらうまでに6人のエンジニアと話すことになるでしょう。そしてほぼ確実に技術テストを受けさせられます。問題に対してどう思考を巡らせるか、履歴書に書かれている問題を本当に解決できる能力があるかを見るためです。
入社希望者を評価するための技術的な厳格さは相当なものです。オファーに至るまでに8回から10回は面接をすることになります。
それが一つの特徴なんですね。
100パーセントそうです。それによって採用プロセスが遅くなるかと言われれば、間違いなく遅くなります。しかし、入社してくる人が自律的に動き、権限と説明責任のバランスを取れる人材であることを確実にするために、全力を尽くすことは本当に重要なんです。そのためには、彼らが担当する分野について極めて深い技術的理解を持っていなければなりません。
私たちはこのやり方を事実上、自社でも真似しています。テスラやSpaceXのようなブランド力がないと難しい部分もあります。あの2社に入りたい人たちは、もちろん技術テストやりますよ、何人とでも面接しますよ、という姿勢ですからね。なので、候補者との間である程度の調整は必要になります。それでも、ミッションに心から共感し、会社にワクワクしている人たち、つまり私たちがどうしても採用したいような人たちは、このプロセスをくぐり抜けてくれます。
私たちは通常、これを双方向のものとしてアピールしています。いいですか、あなたが参加しようとしているのは、本質的に高いリスクを伴うスタートアップです、だからこそ、あなたも私たちのチームをしっかり知るべきです、と。双方向のお見合いのようなものですね。
極めて厳格で困難な面接プロセスというのは、そうした過酷なプロセスにこそモチベーションを感じるような人材を、ポジティブにスクリーニングしてくれると常々感じています。
ええ。超一流のエンジニアなら、他の超一流のエンジニアと一緒に働きたいと思うものです。そして、他のエンジニアたちも自分と同じ厳しいプロセスを通過してきたという確証が欲しいんですよね。本当に難しい面接というのは受ける側としては楽しいものですが、設計するのは非常に難しい。面接官の側にとっても、生半可な気持ちではできません。
ターナーの言ったことを繰り返すだけにならないようにお答えします。非常に似ていますが、私が一つ付け加えられる独自の価値があるとしたら、フルタイムの採用、つまりSpaceXにやってくる数年の経験を持つような人材については全くその通りだということです。4回、5回、6回とスクリーニングを経て、最後にパネル面接で仕上げるわけですから。
私が強調したいのは、インターンシップからの採用ファネルについてです。テスラやSpaceXのブランド力があれば、文字通りデータとして実証されていますが、史上最も応募の多いプログラムになり、世間から狂気的なほどの関心を集めます。これは当然、諸刃の剣でもありますよね。優秀な人材も集まりますが、全く適性のない人も大量に集まってきます。幅が広すぎるんです。
しかし、こうしたプログラムが最終的なフルタイムの候補者や社員に与える影響を見てみると、彼らに3ヶ月のお試し期間を与えているようなものなんです。そこで圧倒的な成果を出した人はそのまま残り続けます。私自身もそうでした。SpaceXには4回も入りましたからね。離れられなかったんです。夢のような場所でした。最初はソフトウェアの部門からスタートしました。
夏の間に別のインターンシップも試してみようかな、みたいな感じだったんですね。
そのまま残るために大学を中退しようかとさえ思いましたが、昔とは違うからもうそういうのはダメだ、と言われました。でも実際、StarshipやDragon、Falconといったプロジェクトで極めて重要な仕事をしている人たちの圧倒的多数は元インターンなんです。このプログラムは将来のエンジニア層を形成する上で、とてつもなく重要だと思います。そうだ、俺は最強のエンジニアだ、俺ならできる、ということを実際に証明する本物のチャンスを与えてくれるんですから。
Galedineはまだ小さなチームで、これから拡大していくところですよね。
ちょうどインターンシッププログラムを立ち上げたところです。
まさにそれをお聞きしようと思っていました。
立ち上げたばかりです。
それについてどう考えていますか。最高のクオリティの人材を迎え入れるために、インターンシップだけでなく、全体的な面接プロセスをどのように設計しているのでしょうか。
まだ非常に規模が小さいので大したことは言えませんが、もちろん応募者全員と直接話しています。ターナーが今もそうしているかは分かりませんが。きっとやっているでしょうね。
何度もやってますよ。
ええ、何度もですね。電話で口説き落としたり、説得したりして。
行動面接のようなものと、技術的な深掘りの面接、両方やっているんですか。
はい。私はいつも一つの大まかな質問から始めて、そこから色々と掘り下げていくアプローチで多くの収穫を得ています。オープンな質問を投げかけて、相手の課題解決の周りをジャブを打ったりパンチを出したりして探るための遊び場を作るんです。具体的には、あなたが過去に解決した問題について、プロセスを説明してください、と聞きます。15分から20分かけてその説明を聞けば、優秀かどうかがすぐにわかります。相手の専門分野が何であれ、私自身もその問題の周りを少しつつき回して感触を確かめるくらいの知識はありますから。本物ではない人が私のこのスクリーニングを通過するのは、かなり難しいと思いますよ。
フルタイムの採用プロセスでは、2、3回のスクリーニングを経て、パネル面接を行っています。私が重視しているもう一つの大きな枠組みは、あなたをチームに紹介したい、という姿勢です。私たちのチームは非常に小さく、あなたは事実上このチームと一緒に生活していくことになります。私たちがあなたに満足し、あなたも私たちに満足できるかどうかを確認したい。この場はそのための完璧なフォーラムです、と伝えています。これがフルタイム採用の最後の仕上げですね。
インターンについては今まさに模索中です。プロセスは短くしていますが、この第一陣となるミサイルエンジニアたちに私が本当に求めているのは、情熱です。入社して圧倒的な成果を出してくれる人が必要なんです。
どんなバックグラウンドのインターンを採用しようとしているんですか。
大学のプロジェクトチーム出身者ですね。分野は何でもいいです。学生フォーミュラでも、ドローンや無人航空機のチームでも。もちろんロケットのチームもです。実は国内に、私たちが使っているのと同じ推進剤でロケットを作っているチームを見つけたんですよ。少し珍しい推進剤なので存在を知りませんでしたが、今はその学校にターゲットを絞っています。
全員引き抜きましょう。全員です。
ええ、チーム全員をバスに乗せてここに連れてきますよ。
若きエンジニアへのアドバイスと起業のタイミング
さて、そろそろまとめに入りましょう。インターンや若い才能の採用についてお話ししましたが、お二人とも比較的若くしてテスラやSpaceXでキャリアをスタートさせています。現在SpaceXやテスラにいる若手エンジニア、あるいは将来自分で会社を立ち上げようと考えている若いエンジニア全般に対して、どんなアドバイスを送りますか。その道のりをどう考えるべきでしょうか。
そうですね、もしあなたが今、人材の密度が極めて高い会社にいて、常に学び続け、毎日が成長の機会だと感じられるようなポジションにいるなら、初期の混沌としたフェーズから、中間の泥沼のフェーズ、そして展開段階のゴタゴタまで、プロジェクトの全貌を見ることができるはずです。そうした経験は信じられないほど価値があります。
最初から最後まで見届けるということですね。
その通りです。ですから、一つのプロジェクトを最初から最後まで見届ける経験を何度か繰り返すまでは、会社を立ち上げるべきではないと私は言いたいですね。コンセプトから展開までのイテレーションを繰り返すことで、自分がどれだけ成長できるかを知ることができますし、世界で最も素晴らしい人たちと一緒にそれを成し遂げるというのは、将来起業するための基盤となる、非常にユニークな経験です。急いで辞めて起業しようとは考えない方がいいでしょう。
なぜなら、人材を惹きつけるための信頼性が必要だからです。結局のところ、会社というのは、全員がワクワクするようなミッションに向かって突き進む素晴らしい人たちの集まりです。苦痛やリスクが伴うミッションに人を巻き込むには、あなた自身がその実行サイクルを何度も経験している方が、はるかに説得力があります。プロセスのどの部分にどれくらいの時間がかかるのか、全体でどれくらいの時間が必要なのかを体感として理解していれば、チームが団結して目指せるような信頼性のある目標を設定できます。
そういう経験を積むために、そうした機会を与えてくれるエコシステムや会社を最大限に活用すべきです。そうした環境では、起業すれば自ら背負わなければならないリスクから、ある程度守られた状態で挑戦できます。社内で与えられた領域において権限と説明責任を持ち、それをどんどん拡大していける限り、それは将来の成功を決定づける計り知れない価値のある経験になるはずです。
チャンドラーさん、頷いていらっしゃいましたね。
ええ、どうやって言おうか考えていました。ターナーと私は同じ人生を歩んでいる気がします。彼の方が数年先を行っているというだけで。私は18歳の時にSpaceXに入りました。それが私がSpaceXという楽しいお菓子の国に足を踏み入れた瞬間で、まさに夢のようでした。初日から、私はスポンジになるんだ、と自分に言い聞かせました。可能な限り巨大なスポンジになって、この素晴らしい人たちから信じられないほどの量の情報を吸収してやろうと。それはインターン時代に限ったことではなく、永遠に続くものです。今でもやり続けています。
SpaceXやテスラに行くかどうかにかかわらず、一般的にどうアプローチすべきかというと、どうすれば世界最高の才能たちに囲まれながら、一つのプロジェクトを最初から最後までやり遂げ、ターナーが言ったような反復練習を積むことができるか、を考えるべきだと思います。
ただし、注意点として、それは簡単なことではありません。学校を出たばかりだと、それがどんなものか見当もつかないでしょう。ですから具体的なアクションとしては、ネットワークに頼ることです。学校の友人や、他の会社に入って違う環境を見た同世代の仲間、あるいは大学の教授など、人生において特定の会社のミッションやプロダクトについて有意義な会話ができる人がいるなら、ぜひ話を聞いてみてください。まだ経験していないことは怖く感じるものですし、自分では分からないことも多いですから。
何が良いものなのかが分からないんですよね。
まさにそれです。何が良いのか分からないんです。だからこそ難しいという注意は添えておきますが、ひとたび自分がいるべき理想の場所を見つけたら、あとはただスポンジになればいいんです。
何が良いものなのかを知り、卓越したチームがどうやって物を作り上げるのかについて理解と直感を深めることができるのは、非常に価値のあることですね。
ええ。SpaceXで数年間経験を積まなかったら、私はGaledineを立ち上げることはできなかったと思います。最後に一つ付け加えるなら、会社を立ち上げるための完全な訓練なんてものは決して終わらないということです。レシピなんてありません。どこかに10年いれば起業できるというものでもないんです。
いつリスクを取る自信がつくのか、いつ準備ができたと感じるかは人それぞれ違います。ですが一般論として、採用や資金調達、会社を取り巻くエコシステムやインフラの構築など、会社づくりのあらゆる側面を学ばなければならなくなる前に、可能な限り強固な技術的基盤を築いておくべきだと思います。起業すれば嫌でも学び続けることになりますが、まずは強固な技術的基盤を構築することに異常なほど集中することが鍵ですね。
そうですね。私はすでに技術的基盤を持った状態で、資金調達など自分がやり方を知らなかった他のことを学びながら成長しようとしていますが、それでも十分に大変です。その逆なんて想像もできません。自分が今持っている技術的なスキル、あるいは自分たちがやろうとしていることを成功させるために必要な技術をゼロから学びながら起業するなんて、極めて困難だと思います。
起業家になってから、仕事の中でロケットの作り方を学ぼうとしてはいけない、ということですね。良いアドバイスです。素晴らしいセッションでした。お二人とも、ありがとうございました。
コメント