ispaceは3月27日、ミッション2「改善タスクフォース」による検討結果を公表した。これは、同社が実施した月面着陸ミッションが2回連続の失敗となった後、設置したもの。第三者の視点から、着陸失敗に関する技術的・システム的要因の分析を行い、7項目の改善案を提言。これを受け、ispaceから具体的な改善策が発表された。
提言を「良いロールモデル」に
ispaceはこれまで、独自開発の「RESILIENCE」ランダーにより、ミッション1(2023年)、ミッション2(2025年)と2回の月面着陸に挑戦。どちらも月の周回軌道までは順調だったものの、最後の着陸段階で失敗していた。両ミッションの詳しい経緯については、過去記事で解説しているので、こちらを参照して欲しい。
ispace月面着陸失敗 関連記事
失敗の直接的な原因は、ミッション1はソフトウェア(高度推定)、ミッション2はハードウェア(レーザーレンジファインダ=LRF)と異なるものの、重要なのはこれを単発のミスと捉えるのではなく、その背景にあった要因まで見つけ、改善していくことである。今後、成功を続けられる企業に変わるためには、それが何より必要なことだ。
改善タスクフォースの狙いは、まさにそこにある。より広い視野で意見を取り入れるため、メンバー12名は外部の専門家を中心に構成。米国マサチューセッツ工科大学のOlivier L. de Weck教授と、慶應義塾大学大学院の神武直彦教授の2名が共同議長をつとめ、約100日間の活動期間中、5回の会合で議論を重ねてきた。
今回発表されたのは、同タスクフォースがまとめた7つの提言だ。分析には、CAST(Causal Analysis based on System Theory)と呼ばれる手法が採用され、運用レベル、システム開発レベル、経営判断レベルの3階層で改善点を指摘。共同議長の一人である神武教授は、「他のベンチャー企業にとっても、良いロールモデルとなる」と期待を示す。
どうすれば成功できていたのか
運用レベルの提言は、以下のふたつ。
- (1)地形相対航法(TRN)の導入
- (2)着陸運用時の残燃料の活用
ミッション1と2の失敗原因で共通するのは、どちらも高度推定に関わるところということだ。RESILIENCEランダーは降下中、慣性計測装置(IMU)とレーザーレンジファインダ(LRF)のふたつで高度を推定していた。提言1は、第三の手法として、カメラの画像認識を利用した地形相対航法(TRN)を導入しよう、という話だ。
IMUが直接計測しているのは加速度であり、誤差が累積する欠点がある。外部情報を直接参照するセンサーなら誤差の累積はないが、今回の問題となった高度において、使えるのはLRFのみだった。もうひとつ高度推定の手段があれば、単一センサータイプやIMUへの依存を減らすことができる、というわけだ。
またミッション2は、順調に月周回軌道まで到着したため、降下開始前のランダーの推進剤は約4%の余裕があった。提言2で問題視されたのは、推進剤が余っていた場合の利用を想定していなかったことだ。もし、この余剰分の推進剤を活用し、より降下速度を抑えた安全なアプローチが取られていたら、減速が間に合って成功した可能性がある。
システム開発レベルでは、以下の3つが提言された。
- (3)ベンダー選定プロセスの改善
- (4)試験に割り当てるプロジェクト・リソースの増強
- (5)故障検出・隔離・回復(FDIR)の設計と検証
LRFのように宇宙であまり使われないセンサーなどは、地上用の製品を購入し、環境試験等を実施した上で使用することが多い。しかし完全なブラックボックスのままでは正確な理解が難しく、メーカーからの協力は欠かせない。提言3では、協力を拒否されたときには、別メーカーのセンサーの採用も検討すべき、とされた。
ミッション2では、LRFは性能仕様のみに基づくブラックボックスとして扱われ、試験とモデル化が行われた。さらに、実際の降下速度での試験も実施されていなかった。本番同様にテストを行い(TEST AS YOU FLY)、テストと同じように本番を行う(FLY AS YOU TEST)というのが原則であり、提言4は、より試験を重視すべき、という意見だ。
またミッション1では、事前により広範囲のシミュレーションをしっかり行っていれば、問題に気付けていたはずだった。センサーの試験という話とは異なるものの、事前の試験や検証にもっとリソースが必要だったという観点は共通するだろう。
提言5は、より堅牢なFDIR(故障検出・隔離・回復)戦略が必要、という指摘だ。RESILIENCEランダーのソフトウェアでは、冗長性を持たせるため、ふたつ搭載されているLRFの片側の故障は想定されていた。しかし、今回のような両方の性能低下はリスク自体は認識していたものの、その異常動作に対する代替案(プランB)は、組み込まれていなかった。
FDIRというのは、ランダーが順調なときには出番がないものの、異常発生時はまさに生死を分ける非常に重要な機能だ。ミッションの成功率を上げるためには、可能な限りの異常事態を想定しておく必要があり、改善タスクフォースは、センサーの性能不足、劣化モード、共通故障モードまでカバーすることを求めた。
経営判断レベルでの提言も非常に重要だ。
- (6)ispaceとドレイパー間の連携の改善
- (7)企業のリスク管理アプローチ強化
ミッション1と2では、月面への降下時のGNC(誘導航法制御)は、アポロ時代からの実績がある米ドレイパーが担当していた。両者の関係は良好と評価されたものの、GNCはシステムの中核であり、独立したサブシステムとして扱うべきではないと指摘。提言6では、経験豊富なGNCエンジニアを追加採用するか、ドレイパーがより深く関わることを求めた。
LRFの性能低下については、GNCソフトウェアの詳細設計審査会(CDR)で残存リスクとして認識され、ドレイパーからispaceへ伝達されていた。しかし、このリスクに対する経営層の認識が適切でなかったと指摘。提言7では、リスク処理/評価の強化を求め、高リスクの場合、ミッションの延期も視野に入れ、リスク低減を図るべき、とした。
スタートアップならではの改善を
ispaceは民間企業である。リスク低減が重要であることは間違いないが、特にスタートアップなどではコストの制約も大きく、取れる手段には限りがある。経営を考えれば、ミッションの延期も決して簡単にできる決断ではない。リスクとリターンの最適なバランスを探っていく必要があり、これは商業プレイヤーとしての本質的な課題といえる。
自社のリソースも踏まえ、どうやって実行可能な形に落とし込むか。改善タスクフォースがまとめた提言を受け、ispaceは今回、それに対する具体的な対策として、7つの改善策を発表した。
提言1では、地形相対航法の導入が推奨されたが、後続のミッションではRESILIENCEより大きな新型ランダーが使われる計画で、搭載する機器は大きく異なる。すでに地形相対航法の搭載は決まっており、宇宙航空研究開発機構(JAXA)が小型月着陸実証機(SLIM)で実証したピンポイント着陸技術も活用される予定だ。
提言4に対しては、同社の「フライトオペレーション部門」を「テスト&フライトオペレーション部門」へ拡張する。試験と運用をひとつの部門が担うよう組織を変更することで、試験を実施するリソースを拡充。さらに、試験で得られた知見やノウハウを、効率的に運用にフィードバックする効果も期待できる。
提言5のFDIR設計に関しては、従来、ハードウェア故障を起因とした分析手法(FMECA)で行っていたが、「ミッションクリティカル故障分析」を追加。これは、ミッションクリティカルな運用に対し、異常シナリオを念頭に分析する手法ということで、プランBも含めたFDIR設計とする。
提言7については、社内に「技術リスク評価委員会」を新設。経営層に対し、独立した立場で技術リスクを報告する機能を持たせることで、リスクを正しく判断できるようにする。一般的に、リスク情報は現場から上層部に伝達する過程で解釈が変わってしまう恐れがあるが、そういった懸念もこれで解消していく。
ispaceの袴田武史CEOは、改善タスクフォースへの感謝を述べた上で、「提言を真摯に受け止める」と回答。さらに「失敗から学ぶことが我々の責任。確実に実行すべきことを徹底しながら、既存の枠にとらわれず、革新的な挑戦を続けていきたい。今回の提言を踏まえ行動していくことが、成功への最短ルートだと信じている」とした。
ミッション1もミッション2も、ランダーを無事に月周回軌道まで運び、着陸も最終段階までは順調だったことから分かるように、ispaceには成功させるだけの実力があったのだと思う。ミッション1の目的地がクレーター内という特殊な地形の場所でなければ、初挑戦で成功できていた可能性もあり、よけいに惜しい。
ただ、失敗が「たまたま」とか「運が悪かった」のかといえば、やはりそうではなく、同社には足りないものがあったのだと思う。今回の改善を表面的なもので終わらせず、しっかり本質を理解して、組織の文化として根付かせることができるか。2回の失敗を糧に、より強い企業に成長することが、今の同社に求められていることだ。
ispace月面着陸関連記事











