1999年、人類の宇宙開発史に残る「事件」が起きました。NASA（アメリカ航空宇宙局）が巨額の予算を投じた火星探査機「マーズ・クライメイト・オービター」が、目的地の火星に到達した直後、忽然と通信を絶ったのです。当時の金額で約3億2760万ドル（約340億円）もの費用が投じられた国家プロジェクトの、あっけない幕切れでした。しかも、その事件の原因は驚くほど単純なものでした。そこで、今回は本記事では、この歴史的な失敗の経緯を振り返り、その背景に隠されていた問題から、エンジニアとしてどのような教訓が得られるか探ってみたいと思います。
- もくじ
1. 消えた火星探査機
1-1. マーズ・クライメイト・オービター計画とは？
火星探査機「マーズ・クライメイト・オービター（Mars Climate Orbiter: MCO）」は、1998年12月11日に打ち上げられました。その名が示す通り、主な任務は火星の軌道上から、火星の気候、大気、そして地表の変動を長期間（火星の1年＝地球の約687日）にわたって観測することでした。火星の気象パターンや季節変化を記録し、水や二酸化炭素の循環を調査することで、火星の気候変動の謎に迫ることが期待されていました。
さらに、MCOにはもう一つ重要な役割がありました。それは、MCOの約3週間後に打ち上げられた着陸機「マーズ・ポーラー・ランダー（Mars Polar Lander: MPL）」からのデータを地球に中継する通信基地局としての機能です。つまり、MCOの成功は、続くMPLミッションの成否にも直結する、非常に重要なものだったのです。
当時のNASAは、「より速く、より良く、より安く（Faster, Better, Cheaper 略称 FBC）」というスローガンのもと、低コストで高頻度な探査ミッションを目指していました 。MCOもその方針のもとで開発された、期待の探査機でした。
1-2. 火星軌道で運命の交信途絶
1998年12月の打ち上げから約9か月半、MCOは順調に宇宙を航行し、1999年9月23日、ついに目的地の火星に到達しました。この日、探査機は火星の軌道に入るため、ミッション最大の山場となるエンジン噴射（逆噴射）を開始しました。
計画では、この噴射によって減速し、火星を周回する軌道に乗るはずでした。そして、火星の裏側に隠れて一時的に通信が途絶えた後、再び姿を現し、地球との交信を再開する予定でした。
しかし、運命の時が訪れます。MCOは火星の裏側に隠れ、電波が途絶えました。これは予定通りの動きです。しかし、探査機が再び姿を現すはずの時刻になっても、MCOからの信号は二度と地球に届くことはありませんでした。
地上管制室は必死に交信を試みましたが、応答はありませんでした。約3億2760万ドルの探査機は、火星到達と同時に、宇宙の闇へと消えてしまったのです。なお、MPLにも何らかの不具合が発生。2機はいずれも失敗してしまいました。
1-3. 全米が震撼した「歴史的失敗」
このニュースは、全米、そして全世界に衝撃を与えました。NASAの華々しい成功の歴史に大きな失敗が刻まれた瞬間でした。
問題視されたのは、その莫大な損失額です。ミッションの総費用は3億2760万ドル（当時のレートで約340億円）に上りました。NASAの宇宙探査プログラムへの信頼は揺らぐことになります。前述の「より速く、より良く、より安く」というスローガンが、性急な開発スケジュールと予算削減による、品質管理の低下を招いたのではないかという厳しい批判が噴出したのです。
2. 世界を驚かせた「事件の真相」
2-1. 原因の一つは「単純ミス」
探査機喪失の直後、NASAは直ちに事故調査委員会を設置し、原因究明にあたりました。そして、通信途絶から約1か月半後の1999年11月、調査委員会は最終報告書を発表しました。
Mars Climate Orbiter Mishap Investigation Board - Phase I Report
PDF Mars Climate Orbiter Mishap Investigation Board - Phase I Report
そこで明らかにされた原因の一つは、技術的な故障や未知の宇宙現象ではなく、どちらかといえば初歩的ミスで、「ヤード・ポンド法」と「メートル法」という、異なる単位系の混在だったのです。具体的には、以下のソフトウエア間でのデータのやり取りに問題がありました。
地上ソフトウエア
探査機のスラスター（小型エンジン）が生成する力積を計算するもので、ソフトウエアはデータを「ポンド重秒」というヤード・ポンド法の単位で出力していました。
航法ソフトウエア
力積データを入力値として、探査機の正確な軌道を計算・予測するもので、データは「ニュートン秒」というメートル法（国際単位系：SI）の単位で入力されているものとして扱っていました。
つまり、探査機の軌道を制御する最も重要なデータが、地上ソフトウエアはヤード・ポンド法で、もう一方の航法ソフトウエアはメートル法で、お互いにその違いに気づかないままやり取りされ、計算が続けられていたのです。
プロジェクトでは、組織間でデータの仕様を定義する「ソフトウエアインターフェース仕様書（SIS）」が交わされていました。そこには、データはメートル法で提供されるべきと明記されていましたが、実際に納品されたソフトウエアはその要件を満たしていなかったことになります。
2-2. 単位ミスマッチが軌道に与えた影響
この「単位の勘違い」が、どれほど致命的な結果をもたらしたのでしょうか。
1ポンド重は、約4.45ニュートンに相当します。これは、航法ソフトウエアが、地上ソフトから送られてくるスラスターのデータを、実際よりも約4.45倍、小さく計算していたことを意味します探査機は、太陽風の影響などで姿勢がずれるのを補正するため、航行中に何度もスラスターを噴射します。軌道修正のたびに、ヤード・ポンド法とメートル法の誤差が積み重なっていったと推測されます。
航法チームは、計算上の軌道と、実際に観測される探査機の軌道との間にズレがあることに気づいていたようです。しかし、その原因を単位ミスとは夢にも思わず、太陽風の影響が想定より大きいなど別の要因によるものとして処理し、軌道修正を続けていました。
その結果、MCOは火星への最終アプローチにおいて、計画よりもはるかに低い軌道を進むことになりました。本来、MCOは火星の大気圏から十分離れた高度の安全な軌道に入る予定でした。しかし、実際には、大気圏の非常に深い部分の高度まで降下してしまったと推定されています。MCOは、想定をはるかに超える大気抵抗と摩擦熱にさらされ、おそらくはその場で燃え尽きたか、制御不能となって宇宙の彼方へ飛び去ってしまったと考えられています。
実際には、事故の原因はヤード・ポンド法とメートル法の違いだけではなく、複合的な理由の積み重なりによるものと考えられていますが、単位の取り間違いは誰にもわかりやすい、衝撃的なものだっただけに世間に与えたインパクトは大きかったと言わざるを得ない一面があると思います。
2-3. 組織間の壁が作った致命的な仕様
なぜ、このような基本的なデータの受け渡しミスが起こったのでしょうか。それは、地上ソフトウエアの開発側と航法ソフトウエアの開発側の2つの異なる開発組織間の「壁」が生じさせたといわれています。
このプロジェクトでは、探査機の開発・製造を行う組織と運用を行う組織での分業体制がとられていました。組織が異なれば、使われる「常識」や「文化」、「慣習」も異なります。地上ソフトウエアはアメリカの航空宇宙産業で伝統的に使われてきたヤード・ポンド法を社内の慣習として使っていたのかもしれません。一方、航法ソフトウエア側は国際的な科学コミュニティの標準であるメートル法を「常識」としていました。
問題は、このお互いの「常識」の違いが、確認作業を怠らせたことにあります。「まさか、そんな単位でデータが来る（送る）はずがない」という、双方の「思い込み」が、仕様書（SIS）に書かれていたはずのルールを機能不全に陥らせ、致命的な仕様の不一致を生み出してしまったのです。
これは、現代の一般的な開発プロジェクトに置き換えると、非常によく似た状況が想像できます。例えば、「別の部署が開発したAPIから返される数値が『ドル』単位だと思っていたら、実は『ユーロ』単位だった」「外部ベンダーが納品したCSVファイルの文字コードが、指定と違っていた」といった問題です。組織の壁は、私たちが思う以上に、こうした初歩的かつ致命的なミスの温床となりうるのです。
3. なぜ見抜けなかったのか？
3-1. 形骸化したチェック体制
最大の謎は、「単位の間違い」がなぜ9か月半もの航行期間中、そしてミッション開始前の度重なるテストやレビューの段階で、誰にも発見されなかったのかということです。事故調査委員会の報告書は、この「見逃し」の背景にある、より深刻な組織的・システム的な問題を浮き彫りにしています。実は、こちらは「真の原因」なのかもしれません。
まず指摘されたのは、プロジェクト全体におけるチェック体制の不備、とくにシステムエンジニアリング機能の弱さでした。
MCOプロジェクトでは、地上ソフトウエアと航法ソフトウエアという、異なる組織が開発したコンポーネント同士を「繋いだ」状態での、エンドツーエンド（端から端まで）のテストが十分に行われていなかったという指摘があります。
検証と妥当性確認（V&V）のプロセスが適切に機能していなかったという指摘もあります。開発段階で地上ソフトウエアが出した値を、航法ソフトウエアが正しく解釈して軌道計算できるかという結合テストが厳密に行われていれば、単位の不一致は早期に発見できたはずです。
また、航法チームは前述の通り、実際の軌道と計算上の軌道のズレに気づいていました。しかし、この「異常」が重大な問題として正式に報告され、徹底的に原因究明されるプロセスが十分に機能していなかった可能性も指摘されています。チェックリストやレビュープロセスは存在していたものの、それが手順をこなすだけの形骸化したものになっていて、本質的な問題を見抜けなかった可能性があります。
3-2. 「まさか単位が違うとは」思い込みの罠
次に挙げられるのが、関係者全員が陥った「思い込み」の罠です。世界最高峰の科学者やエンジニアが集うNASAのプロジェクトにおいて、単位を間違えるというミスは想定の範囲外だったのかもしれません。
航法チームが軌道のズレに気づいた際も、まさかデータの単位が間違っているという発想には至らなかったようです。はじめは計算モデルや、太陽風などの外部要因の想定が甘かったのではないかと別の可能性を探っていたようです。
人は思い込むと、それに反する証拠（今回は軌道のズレ）が現れても、「自分の思い込みが間違っている」とは考えにくく、「別の要因があるはずだ」と、自分の思い込みを補強する方向に解釈しがちだといわれます。「まさか」という思い込みが、問題の早期発見を妨げる最大のヒューマンエラーになりえるのではないかと思います。
3-3. 組織間のコミュニケーションの壁
2-3で述べた「組織間の壁」は、仕様の不一致だけでなく、日々の運用におけるコミュニケーションの壁としても機能していたようです。事故調査報告書は、プロジェクト内のコミュニケーションとトレーニングが不十分であったことを指摘しています。プロジェクト内の各チームが独立して作業を進めており、チーム間の相互交流がほとんどありませんでした。
異なる組織、異なる文化の間には、見えない「遠慮」や「壁」が存在し、円滑な情報共有や、問題を率直に指摘し合う文化が阻害されていた可能性があります。「コミュニケーション不足」が異常の兆候を見過ごす遠因となっていた可能性は否めません。
3-4. 今後への教訓
このMCOの失敗から、私たちは何を学ぶべきでしょうか。事故調査委員会は、いくつかの重要な教訓を提示しています。
単位管理の重要性と、国際標準（SI単位系）への統一の徹底
複数の組織や国が関わる複雑なプロジェクトにおいて、単位系を統一し、それを厳格に守ることは、システム設計の基本中の基本といえます。NASAは以降のすべてのミッションで国際単位系（メートル法）の使用を標準化しました。
システム全体の統合的な検証（エンドツーエンド・テスト）の重視
個々の部品（ソフトウエア）が正しく動作するだけでは不十分であり、それらをすべて接続した「本番さながら」の状態で、システム全体として意図した通りに機能するかを徹底的に検証しなければなりません。
組織や文化、慣習の違いを超えるコミュニケーションの強化
インターフェース（データの受け渡し口）の仕様は、文書で明確に定義するだけでなく、関係者間で思い込みがないか、確認し合うプロセスが不可欠です。また、プロジェクトの末端で発見された「小さな異常」や「違和感」を、決して見過ごさず、正式な問題として上層部まで迅速に報告できる、風通しの良い組織文化（心理的安全性）を醸成することが求められます。
この事件は、「誰でもミスを犯す」という前提にあること、そして個人の能力に依存するのではなく、ミスを早期に発見し、致命的な結果になる前に修正できる「仕組み（プロセス）」を構築することがいかに重要であるかを教えてくれていると思います。
4. まとめ
1999年のマーズ・クライメイト・オービターの失敗は、ヤード・ポンド法とメートル法の単純な換算ミスが原因の一つでした。しかし、その背景には、異なる組織間の連携不足、形骸化したチェック体制、そして「まさか」という思い込みといった、根深い組織的・人的問題が潜んでいました。開発にはコミュニケーションが大切だという教訓を大切にしたいですね。
