1970年4月、月を目指して飛び立ったアポロ13号でトラブルが発生。これは人類の宇宙開発史上、最もドラマチックなサバイバル劇となりました。月面着陸という壮大なミッションは、酸素タンクの爆発という想定外中の想定外の事態によって、一瞬にして「いかにして地球に生還するか」という戦いへと姿を変えました。この絶体絶命の危機を救ったのは、最新鋭の理論でも巨大な予算でもなく、地上にいるエンジニアたちが手元にある「ありあわせの道具」だけを使って、不可能と思える課題を解決した驚異的な現場対応力と「エンジニア魂」でした。今回は、アポロ13号のエピソードから、ツールに頼り切らずに課題を解決する突破力を考えてみたいと思います。
1. アポロ13号事故に見られた「エンジニア魂」
1-1. ミッション失敗、しかし全員生還
アポロ13号は、1970年4月11日に打ち上げられた、アメリカのアポロ計画において3度目の有人月着陸を目指すミッションでした。しかし、3人の宇宙飛行士を乗せた打ち上げから約2日後、月まであと一歩というところでサービスモジュール内の酸素タンクが爆発するという致命的な事故に見舞われてしまいます。
Apollo 13: The Greatest Feat of Improvised Engineering - Engineering.com
この事故が特別だったのは、それがマシンの故障ではなく、宇宙という究極の閉鎖空間で発生した未知の複合トラブルだったことです。爆発によって電力と酸素の供給源の多くが失われたため、即座に月面着陸は断念。地上との距離は約32万kmあるので、もちろん物理的な救助は不可能です。管制官とエンジニア、そして宇宙飛行士たちは、限られたリソースと情報だけで、課題を解決し事故を回避しなければなりませんでした。
アポロ13号は、月着陸という当初の目的を果たせなかったため、一般的には「失敗したミッション」に分類されます。しかし、乗組員3名全員を無事に地球へ帰還させたことから、NASAはこのミッションを「成功した失敗」と呼んでいます。この奇跡を支えたのが、人間の創意工夫と的確な判断の積み重ね、そしてそれを支えた「エンジニア魂」でした。
1-2. 「丸い穴に四角い杭を」とは？
事故発生後、帰還用の電力と酸素を確保するため、司令船を諦めて2人乗りの月着陸船を「救命ボート」として使用します。しかし、ここで深刻な問題が浮上します。
人間は呼吸によって二酸化炭素（CO2）を排出しますが、月着陸船に備え付けられたCO2除去装置（スクラバー）のカートリッジは、本来2人が2日間過ごすための容量しかありませんでした。乗員3人が4日間かけて帰還するには、CO2除去能力が不足していて、二酸化炭素中毒の危機がありました。このままでは、宇宙飛行士たちは自らが吐き出す二酸化炭素によって中毒死してしまいます。
そこでエンジニアたちは、まだ予備が残っていた司令船のカートリッジを活用しようと考えました。しかし、ここで致命的な設計上のミスが判明します。司令船のカートリッジは「四角い箱型」であるのに対し、なんと、月着陸船の接続口は「丸い穴」だったのです。それぞれの機体が異なるメーカー（ノースアメリカン社とグラマン社）によって設計・製造されていて、規格の標準化が行われていなかったことが原因でした。
物理的に形が合わないという絶望的な状況を指して、「Putting a Square Peg in a Round Hole（丸い穴に四角い杭を）」という有名なフレーズが使われました。下のNASAのサイトでは、その状況を写真で確認できます。
1-3. 極限状態で問われるのは「対応力」
地上のエンジニアたちに与えられた猶予はわずかでした。CO2濃度が危険域に達する前に、彼らは「宇宙船内にあるものだけを使って、四角いフィルターを丸い穴につなぐアダプター」を即興で設計しなければなりませんでした。
通常、宇宙機器の開発には数ヶ月の設計期間と厳密なテスト、そして高度な素材が必要になります。しかし、今回の極限状態では、教科書に載っているような正しい設計や理論は通用しないといってよいでしょう。地上のエンジニアたちは、宇宙飛行士たちが持っているものと同じアイテムを見て考え込むことになります。アイテムは、フライトプランのマニュアルの表紙、ビニール袋、ホース、ダクトテープ、そして靴下などだったといわれています。
彼らに求められたのは、「今、目の前にあるもので何とかする」という対応力でした。
2. ありあわせで解く技術
2-1. 「ブリコラージュとは何か？」
アポロ13号のエンジニアたちが示した「ありあわせの工夫」は、フランスの文化人類学者・クロード・レヴィ＝ストロースが提唱した「ブリコラージュ（Bricolage）」という概念で説明できます。ブリコラージュとはフランス語で「寄せ集めて作る、修繕する」を意味します。しっかりした計画と専用の道具を揃えて取り組む、伝統的なエンジニアリングとは対照的なアプローチといってよいでしょう。いってしまえば、過去の遺物や別の用途で使われていたものの「残り物」を本来の用途とは異なる方法で組み合わせて、新しい機能や解決策をひねり出すのがブリコラージュです。
エンジニアリングというと、厳密な計算と設計図に従う世界だと思われがちですが、実際の現場ではこのブリコラージュ的な能力が欠かせないことは、皆さんおわかりのことだと思います。完璧な仕様書や潤沢な予算、理想的なフレームワークが常に揃っているわけではない現代の開発現場において、「手元にあるリソースを最大限に活用して問題を解決する」態度は、エンジニアとしての生存戦略といってよいかもしれません。
2-2. あらゆるものを解決策につなげる
さて、話をアポロ13号に戻します。今回の事故対応で使われた「メールボックス」と呼ばれる即興のCO2除去アダプターの接続に使用された材料は、驚くほど身近なものばかりでした。地上にいたエンジニアたちは、上で述べた、宇宙船内に実際にある物品と同じものを自分たちの机の上に広げて「この中にあるものだけで解決策を作れ」という極限の条件で設計を進めることになりました。以下のような"素材"でした。
- マニュアルの表紙＝段ボール素材
- ビニール袋
- 宇宙服のホース
- ダクトテープ
- 靴下
新しい部品を調達したり、規格を合わせたりして、製品を作り直すことはできません。そこにあるものを使うしかなかったのです。そして、これらを使って彼らは四角いフィルターと丸い穴をつなぐアダプターを創造しました。
2-3. 制約条件が創造性を引き出す可能性
なぜ、何もない極限状態の方が、かえって驚異的な創造性が発揮されるのでしょうか。心理学や経営学の研究では、適度な制約がむしろ創造性を高めるというメカニズムが指摘されています。選択肢が無限にあると人は迷いやすくなりますが、制約によって選択肢が絞られることで、限られた材料の中での組み合わせや用途の転換に意識が集中しやすくなるという説もあります。
アポロ13号のケースでは、エンジニアたちは見た目の美しさや再利用性といった副次的な要素をすべて削ぎ落とし、「二酸化炭素を除去する」という一点のみに思考を集中させました。そして、制約が「とりあえず動くもの」を作ろうという開き直りを引き出して決断が早まったのかもしれません。
もし、地上で潤沢な時間と資源があれば、エンジニアたちはもっとエレガントな解決策を探し続けて、決定を遅らせていたかもしれません。制約は不自由を強いるものではなく、想像力を最大化させるための強力なトリガーになっていた可能性があります。
3. 現代の開発現場にもある「アポロ13号的瞬間」
3-1. 仕様変更・障害対応・納期直前
現代のシステム開発において、アポロ13号のような爆発事故は決して遠い世界の出来事ではありません。サービス公開直前に発覚する致命的なバグ、リリース後の急激なトラフィック増によるサーバーダウン、あるいは深夜に鳴り響くオンコールのアラート。これらはいわば、ITの現場における「酸素タンクの爆発」といってよいでしょう。特に納期直前や本番障害の真っ只中では、まるで「アポロ13号の事故のような」場面に遭遇する可能性はあり得ます。
こうした局面では、計画段階で描いた理想的なアーキテクチャやスケジュールはあっさり崩れてしまいます。私たちは、きれいに整理されたスプリント計画を一旦横に置き、手元にある限られたツールと知識だけで戦うことを強いられます。仕様変更という名の「軌道修正」もまた、燃料が限られた宇宙船で地球を目指すような緊迫感を私たちに与えるのです。
3-2. きれいな設計だけでは乗り切れないトラブルシューティング
ソフトウェアエンジニアリングの世界では、クリーンアーキテクチャやデザインパターンの重要性が繰り返し強調されます。しかし、トラブルシューティングの現場において、きれいな理論が時として牙を剥くことがあります。厳密なルールが急場を凌ぐ発想の妨げになったりするケースです。
アポロ13号で月着陸船を「救命ボート」として使うという発想は、本来の設計思想からは大きく外れた、いわば禁じ手ともいえます。もし「本来の用途ではないから使わない」と考えたら、乗組員の命は救えなかったでしょう。究極の危機管理においては、「エレガントさ」よりも「機能すること（It works）」が優先されます。
だからといって、平常時から汚いコードを書いてよいわけではないことは肝に銘じておく必要がありそうです。ただ、炎上している最中に躊躇していては、手遅れになりやすいという話です。いざという時にはあえてルールを破る柔軟性とバランス感覚が必要なのかもしれません。
3-3. 属人化と即興力の違いをどう考えたらよいか
「現場対応力」や「即興力」の重要性を説くと、しばしば、それは即興力が高い人に依存する属人化を助長するのではないかという懸念が生まれます。しかし、アポロ13号の奇跡を支えた即興力と、属人化には違いがあります。
属人化すると、情報や権限の流れが停滞して何も進まなくなりますが、エンジニアが目指す即興力は、個々のエンジニアが持つ深い知識の引き出しを、チームの共通目的のために開放して、その場で最適に組み合わせる動的な能力だからです。
アポロ13号の救出劇でも、地上の各担当者は自分の専門領域（電力、軌道、生命維持など）を把握しつつ、互いの知見を即興的にマッシュアップ（融合）させています。即興力そのものを個人の勘や経験だけに閉じ込めず、インシデント対応後に「なぜその判断をしたのか」というプロセスを言語化し、ドキュメントとして共有することで、それは組織全体の資産へと変わります。
4. エンジニアはどうやって「現場対応力」を身につける？
4-1. 知識を増やすより、組み合わせる力を鍛える
現場対応力を身につけるために、膨大な知識をただ暗記する必要はありません。ITの発達で知識量が決定的な差にならない現代において、エンジニアに問われるのは、既存の知識を予期せぬ形に結びつける「組み合わせの妙」です。
まず、基本原理の深い理解は必要です。つぎに自分の専門領域の少し外側にある技術や、一見無関係に見えるツールにも触れておくことで、知識を結ぶ線を増やしておくことも大切です。これがブリコラージュ的な発想につながります。
4-2. 失敗事例・修羅場経験をプラスに変える
現場対応力は、単なる座学や知識の暗記だけで身につくものではありません。最も強力な教科書は、自らが体験した、あるいは他者が経験した「失敗」と「修羅場」の中にあります。アポロ13号の生還も、それ以前の数々のミッションや過酷な訓練での失敗があったからこそ、何が致命的で何が許容できるかの判断が瞬時に下せたと考えられます。
私たちが現場でできる具体的な学習法の一つは、トラブルが解決したあと、事後検証を徹底することでしょう。単に「解決してよかった」「直ってよかった」で終わらせるのではなく、「なぜ、解決できたのか」「他に使える道具や選択肢はなかったか」を検証して、言語化します。また、他人の失敗談やインシデントレポートを対岸の火事とせず、自分ならどう動いたかをシミュレーションすることも重要でしょう。
さらに、現代のエンジニアリングでは、意図的にシステムに障害を起こして対処する「カオスエンジニアリング」や「ゲームデイ」といった訓練手法も広まっています。修羅場での判断の型を事前にストックしておくことで、いざ本当の爆発事故が起きた際に、パニックに陥ることなく「さて、手元には何がある？」と冷静に問いかけられるようになります。失敗を「恥」ではなく「知見」に変える文化こそが、個人の、そして組織の現場対応力を磨き上げるのです。
4-3. AI時代だからこそ人間に問われる「突破力」
昨今、生成AIの登場によって、プログラミングや設計の大部分をAIが担えるようになりつつあります。しかし、AIが最も苦手とするのが「前例のない、極限状態でのブリコラージュ」といえます。AIは過去の膨大な学習データから「正解に近いもの」を提示してくれますが、アポロ13号のように「規格の違う部品を、靴下とテープでつないで二酸化炭素を除去する」といった、論理的には破綻して見えるが物理的には成立する解決策を、その場の文脈から生み出すことはまだまだ苦手なようです。
物理的な制約、複雑な人間関係、そして刻一刻と迫るタイムリミット。こうした多層的な制約が絡み合う現場で、「どの前提を疑い、どこまでをリスクとして許容するか」という泥臭い判断を下せるのは、今のところ人間です。AIが導き出せない「非効率だが、今この瞬間には唯一の解」を選び取る。この突破力と「エンジニア魂」こそが、AI時代における人間のエンジニアの生存戦略なのかもしれません。
5. まとめ
アポロ13号の生還劇は、エンジニアリングが完璧な計画であると同時に、不完全な状況下での最善の即興を生み出すことも示してくれました。四角いフィルターを丸い穴に入れようとした執念は、現代の複雑なシステム開発に挑む私たちにとって、最大の「お手本」といってよいでしょう。
