「スペースX」という企業は、ロケットの再利用や全世界高速インターネット衛星通信網など、常人では実現できない“奇策”で成長してきました。そのため同社の経営は「天才・イーロン・マスクがやることだから」で思考停止しがちです。が、実はいくつかの補助線を引くと、スペースXのテクノロジーやマネジメントについての考え方は案外すっきり理解できます。宇宙航空研究開発機構（JAXA）の現役ロケットエンジニアと、ディープテックへの投資経験が長いベンチャーキャピタリストが、ビジネスパーソンに参考になる形で、スペースXの考え方を読み解く書籍『 ロケット開発者と投資のプロが読み解くスペースX 』から、抜粋してお送りします。その第7回。＝一部再編集あり、文中敬称略
スペースXの創業者、イーロン・マスクはITのいわば申し子で、自身もプログラマーでITベンチャー企業を立ち上げましたから、ITの強みやその活かし方をよく理解していました。前回（「ロケットの歴史を『今あるもの』で塗り替えたマスク氏」）紹介したファルコン9の開発にも、IT技術が大きな役割を果たしています。
今回はその中でも著者がとりわけユニークだと感じた「開発コストを顧客に無理なく分担してもらう方法」をご紹介しましょう。
そう聞くと「特にITと関係がないのでは？」と思われるかもしれません。確かに純粋にIT技術ということではありませんが、考え方として、ITの世界では一般的な「アジャイル開発」という手法に極めて近い、そしてスペースXならでは、と思えるものがあります。
アジャイル開発は主にソフトウエア業界で多用され、ベータ版（開発途中段階、基本機能に絞った試用版）を短期間で開発し、ユーザーからのフィードバックにより継続的に良いものに進化させていく、というプロセスを指します。
失敗から学ぶ、できればコストも掛けずに
スペースXが「失敗を忌避せず、むしろ積極的にそこから学ぶ」スタンスであることはよく知られています。失敗を恐れず果敢にチャレンジし、もし失敗したら、その原因をつかむことで成功への階段を一歩上れる、というものです（注：スペースXはモデルベースというシミュレーション手法を駆使して、事前にコンピューター上でさんざん「失敗」して検証したうえで飛行実証にチャレンジしていることに留意が必要です）。
しかし、ソフトウエアのユーザーなら多少出来が甘くても使ってくれますが、ファルコン9のユーザーは、巨額を投資して開発した大事な人工衛星の打ち上げを依頼した顧客です。
「ベータ版ロケットの実験台になってもらっていいですか？ 打ち上げに失敗して衛星が失われるかもしれませんけど」
と依頼しても、OKしてくれるわけはありません。では、どうすれば協力してもらえるのでしょうか。
切り離した後なら問題ないだろう？
マスクのアイデアはこうでした。
「顧客の衛星を載せたロケットで実験するのは難しい。だが、顧客の衛星は第2段に載っている。となれば、切り離した後の第1段機体を実験に使っても、何の支障もない」
第1段に追加する着陸脚やフィンが、第2段と分離するまで悪さをしないことを顧客に納得してもらう必要がありますが、切り離した後の第1段でどんな実験をしても、顧客の衛星は安全です。
スペースXは実際に顧客衛星の衛星軌道投入契約を受けたロケット打ち上げの機会を活用し、ファルコン9の第1段着陸実証実験を何度も繰り返しました。シミュレーションでは計算し切れない実際の気象条件や機体の動作などを確認する貴重な経験を積むことができ、お客さんからお金をいただきながら、ロケットでもアジャイル開発を行うことができたのです（参照：YouTube動画「How Not to Land an Orbital Rocket Booster」）。
説明されれば「それはそうだ」と思えますが、しかし、「顧客の衛星を載せたロケット」と言われたら、その打ち上げを完全に成功させねば、という意識が前面に出て、たとえ打ち上げの成否とは別の話、と分かっていても「自社の実験にも使おう」という発想はなかなか出てこないのではないでしょうか。「余計なことをしたらリスクが増える」と、安全策を採りたくなってしまいそうです。
「やり直しの利かない打ち上げは準備に万全を期し、万一のリスクも潰しておかねば」という思いは、これまで、数々のロケット打ち上げ失敗や人工衛星の致命的不具合に悩まされてきた宇宙開発関係者の経験に基づいて、開発手法の定石となっていました。
仕様設定や設計上のミスを避ける「ウォーターフォール開発」
一般的な宇宙開発のプロジェクトでは、水が上から下に流れるように、一本の流れで一つずつ順番に開発が行われ、「ウォーターフォール開発」と呼ばれます。
たとえば通信衛星の開発を例に挙げてみます。顧客のニーズを調査して衛星の仕様を決め、衛星システムと地上システムを設計し、試作して機能・性能の検証を行ったのちに実際の衛星を製造、地上試験、打ち上げを経て、顧客へ引き渡すことでプロジェクトを完了させます。
人工衛星の開発は一発勝負で、打ち上げて宇宙に行ったあとはもちろん、製造途中でも仕様変更が困難なことが多く、無理に変更するとひどいときには衛星をイチから造り直す羽目になります。
そういった事態を避けるため、なるべく早い時期に仕様を固める、仕様の取りこぼしが発生しないよう入念に時間をかけて顧客要望を調査分析する、という考え方が浸透し、開発期間、開発コストの増大につながっていました。
それに対して、スペースXの衛星（スターリンク）の場合は、常に衛星を造り続け、打ち上げ続け、アップデートし続ける、「終わらないプロジェクト」として進められています。
ベータ版を短期間で開発し、打ち上げ、使ってもらい、ユーザーからのフィードバックにより真の顧客ニーズを把握しながら継続的に良いものに進化させていく、というプロセスを取るわけです。
これはまさしくIT業界で一般的な「アジャイル開発」で、マスクはスペースXの事業全体にアジャイル開発のアプローチを浸透させました。スターリンク衛星にも、ファルコン9にも、その進め方を適用したのです。
商品として失敗するリスクを避ける「アジャイル開発」
よく誤解されていますが、「ウォーターフォール開発はゆっくり時間をかけてよい」とか、「アジャイル開発は仕様を固めずに見切り発車で開発してよい」とか、そういう意味ではありません。
重要なのは優先度の違いです。
ウォーターフォール開発でも、もちろんスピーディーな開発を目指しますが、それ以上に、仕様設定のミスや設計上の過誤などの失敗を回避することを「優先」します。
アジャイル開発では、ベータ版を早期完成してユーザーからのフィードバックを得ることを優先します。事前ニーズ調査や仕様の設定も行いますが、世の中のニーズを正確に捕まえることに限界があるという認識の上で、ベータ版を早く世に出すことによって、商品として失敗するリスクを低減させることを「優先」するわけです。
ファルコン9の場合で言えば、もし、「設計上の過誤を避けることを優先する」というウォーターフォール的思考を採用していたとしたら、顧客の衛星打ち上げそのものには関係がない装備（例：再使用のための脚）を搭載した第1段を使うというアプローチは選ばれないでしょう。
ファルコン9の再使用の将来性とその技術課題を「アジャイル開発で乗り越えられる」と信じるマスクは、粘り強く顧客を説得し、お客さんがお金を払って衛星を載せたロケット、その衛星を載せた部分（第2段）の切り離し後の第1段を、着陸の飛行実証として使うという前例のない手法で、開発を成功させたのでした。
打ち上げ能力をソフトウエアで調整
20世紀後半から21世紀にかけて、半導体技術の加速度的な進歩に後押しされ、コンピューターの計算能力、そして取り扱えるデータ量は数万倍となりました。それに対し、たとえば金属強度や耐熱温度などの進歩はずっと緩やかですから、ロケットの技術を進歩させるには、ITの活用が死活的に重要になりました。
第一段の再使用が可能な「ファルコン9ブロック5」の運用にも、IT流の方法がたくさん盛り込まれています。ここでは一つだけ紹介しておきましょう。
人工衛星のサイズ、重さはそれぞれ異なり、ロケットの打ち上げ能力にぴったり合うことはめったにありません。重い衛星を打ち上げるときにはロケットの能力を増やし、軽いときは減らせるのが理想で、そのためにはエンジンの数を変更したり、固体ブースターを増減したりして調整することがよくあります。これはロケットの設計が複雑になり、組み立て工程や作業を切り替えねばならず、コスト増を招きがちです。
マスクは、ファルコン9ブロック5の打ち上げ能力をソフトウエアで変更できるようにしました。具体的には、A・第1段を発射場付近まで戻して陸上着陸させる、B・洋上の着陸船に着陸させる、C・第1段を使い捨てにする、という3段階の変更で打ち上げ能力を変更できます。打ち上げ能力はA＜B＜Cとなり、コストもA＜B＜Cになりますので、軽い衛星を打ち上げたい顧客には安い価格を、重たい衛星の顧客には高い価格を設定できます。
ハードウエアは同一で、ソフトウエアのパラメーターで変えられますので、現場のロケット組み立て作業員は毎回同じ手順で打ち上げの準備ができ、コスト増を避けられます。
ちなみに、Cの使い捨てには、さんざん再使用してくたびれた第1段の機体がよく使われます。「最後のご奉公」のような感じで打ち上げ能力を上げてくれる、けなげなロケットだと感じてしまいます。
［日経ビジネス電子版 2026年9月30日付の記事を転載］
小松伸多佳、後藤大亮（著）／日経BP／2200円（税込み）