エンジニアリング哲学：マーガレット・ハミルトン

要点

• 彼女は「ソフトウェア工学（software engineering）」という言葉を生み出し、この分野に正当な地位を勝ち取りました。 MITのInstrumentation Laboratoryでアポロの飛行ソフトウェア開発を率いる中、マーガレット・ハミルトンはこの仕事を意図的に「software engineering」と呼び始めました。人類を月へ送るコードを書くことは、ハードウェアやシステム工学と同じ厳密さと敬意に値する——ソフトウェアが二の次に扱われていた時代に、そう主張するためでした。¹²
• 誘導コンピュータが1202と1201のアラームを発したとき、彼女のソフトウェアがApollo 11の着陸を救いました。 最終降下中、誤って設定されたランデブーレーダーのスイッチが、本来与えられるはずのない処理をApollo Guidance Computer（AGC）に押し付け、エグゼクティブはそれをスケジュールするためのメモリを使い果たしました。これが有名な1202（「core setなし」）と1201（「VAC areaなし」）のアラームです。ハミルトンのチームは優先度スケジューリングとリスタート保護を組み込んでソフトウェアを構築していたため、コンピュータは優先度の低いレーダー処理を切り捨て、着陸に不可欠な誘導処理を動かし続け、着陸は成功しました。³⁴⁵
• 彼女を定義する信念は防御的設計です。二度目のチャンスはないからこそ、失敗の側を見越して設計する。 「二度目のチャンスはありませんでした。私たちはそれを分かっていたのです」と、彼女はアポロについて語っています。² エラー検出、回復、非同期の優先度スケジューリング、そして人間を介在させる表示——これらは正常系が動いた後に付け足された機能ではなく、設計の中心そのものでした。だからこそソフトウェアはクラッシュではなく、優雅に劣化したのです。⁶
• 彼女は正しさを最初から作り込みました——「Development Before the Fact」です。 アポロの後、彼女はHigher Order Software（1976年）とHamilton Technologies（1986年）を設立し、Universal Systems Language（USL）と、エラーをテストで捕まえるのではなく、構築の段階で丸ごと一群のエラーが起こりえないように設計する方法論を発展させました。NASA Exceptional Space Act Award（2003年）と大統領自由勲章（2016年）を受章しています。¹⁶

原則

「二度目のチャンスはありませんでした。私たちはそれを分かっていました。私たちはこの仕事を真剣に受け止めていたのです。その多くが、まだ20代でこの旅を始めていました。」 ——マーガレット・ハミルトン、アポロ飛行ソフトウェアについて²

たいていのエンジニアリングは、すべてがうまくいく場合に最適化されています。正常系を作り、想像できる範囲のいくつかのエラーを処理して出荷する——そして本番で何かが壊れたら、修正して再デプロイする。ほとんどすべてのソフトウェアは、この心地よいループの中で生きています。失敗が回復可能なのは、つねに次のチャンスがあるからです。ハミルトンの仕事は、その正反対の前提から始まりました。彼女が率いたソフトウェアは、3人を地球から25万マイルの彼方へ飛ばし、そのうち2人を月へ着陸させるものでした。そしてパッチも、再デプロイも、次のチャンスもありませんでした。 一度で動かねばならず、誰も完全には予行演習できない条件下で、メロディを奏でるグリーティングカードよりも少ないメモリしか持たないコンピュータの上で動かねばならなかったのです。² たった一つの見逃したエラーの代償が乗組員の命であるとき、「失敗の側を見越して設計せよ」はもはや良いアドバイスではなく、仕事そのものになります。

そこから導かれる原則が、後始末ではなく設計の中心としての防御的設計です。ソフトウェアが想定外を生き延びねばならないなら、エラーの検出、そこからの回復、優雅な劣化は、正常系が完成してから足す機能ではありえません。それらは正常系がぶら下がる骨格そのものでなければならないのです。ハミルトンのチームは、コンピュータが自分の能力を超える要求をされていることを気づき、重要でない処理を投げ捨て、既知の正常な状態へクリーンに再起動し、止まれば乗組員の命を奪う唯一の処理をやり続けるように、アポロのソフトウェアを構築しました。このシステムは、あらゆる失敗を回避するために作られたわけではありません——あれほど小さな機械で、あれほど容赦のないミッションに対しては、それは不可能です。失敗が訪れたとき、その失敗が生き延びられるものになるように作られていたのです。³⁶

この原則には後半があり、それこそが前半を現実のものにします。最後にバグをテストで追い出すのではなく、正しさを最初から作り込む。 実行時にエラーを検出して回復するのは最後の防衛線です。より深い規律は、そもそも丸ごと一群のエラーが起こりえないようにシステムを設計することにあります。ハミルトンはキャリアの後半を、まさにこれを形式化することに費やしました——彼女が「Development Before the Fact」と呼んだ方法論と、インターフェースのエラーを構造的に不可能にするために作られた言語です。⁶ この二つの半分は、一つの考えを二つの距離から見たものです。二度目のチャンスがないとき、実行時に防御し、そして設計時に失敗を表現不可能にする。なぜなら、完全に信頼できる唯一のエラーとは、システムが決して犯すことのできなかったエラーだからです。

背景

マーガレット・ハミルトンは、1936年8月17日、インディアナ州パオリで、マーガレット・ヒーフィールドとして生まれました。¹ アーラム大学で数学を学び、1958年に副専攻を哲学として学位を取得しました——この組み合わせは、後に彼女がコードと同じくらいシステムについて考える際の姿勢に表れます。¹ 彼女はコンピュータサイエンスの教育課程を経てアポロにたどり着いたわけではありません。1950年代後半にはそんなものは存在しなかったからです。彼女がたどり着いたのは、数学を通じて、そして仕事そのものを通じてでした。

彼女の最初のプログラミングは、最初から現実世界の、高い賭け金のかかったものでした。1959年、彼女はMITの気象学部門で働き始め、カオス理論の創始者であるエドワード・ローレンツのもとで、LGP-30とPDP-1の上に天気予報ソフトウェアを書きました。¹ おおよそ1961年から1963年まで、彼女はMIT Lincoln LaboratoryでSAGEプロジェクトに携わり、米空軍が接近する航空機を検知するために使用したAN/FSQ-7コンピュータ向けのソフトウェアを書きました。¹ SAGEは、これまでに作られた中で最初期の、大規模なリアルタイムかつ障害に敏感なソフトウェアシステムの一つでした。そこで彼女が築いた評判——最も難しく、最も失敗しやすいコードを引き受ける者としての評判——が、彼女をアポロへと導いたのです。

1965年、彼女はMIT Instrumentation Laboratory（後のDraper Lab）に加わりました。この研究所はNASAのアポロ計画のための機載飛行ソフトウェアを構築する契約を持っていました。彼女は昇進してSoftware Engineering Divisionを統括し、司令船と月着陸船の双方でApollo Guidance Computer上を走る機載飛行ソフトウェアを担うチームを率いました。¹ その仕事の真っ只中で、彼女は「software engineering」という言葉を使い始めたのです——流行語としてではなく、一つの主張として。彼女自身の言葉を借りれば、「それをハードウェアや他の種類のエンジニアリングと区別しつつ、各種のエンジニアリングを全体のシステム工学プロセスの一部として扱う」ためにこの言葉を使った、ということです。¹ ソフトウェアは名前を持つに値する、そしてその名にともなう厳密さを持つに値する分野である——彼女はそう主張しました。アポロの後、彼女は1976年にHigher Order Softwareを、1986年にHamilton Technologiesを設立し、そこでUniversal Systems Languageと「Development Before the Fact」の方法論を発展させました。¹⁶

仕事

Apollo 11の1202アラーム：優先度スケジューリングとリスタート保護

ここから始めましょう。これは、考えうる最悪のプレッシャーのもとで、原則が機構へと姿を変えたものだからです。Apollo Guidance Computerは小さな機械でした——数十キロバイトのメモリしかなく、現代的な意味でのオペレーティングシステムも持たず——ハミルトンのチームが設計したリアルタイムのエグゼクティブを走らせていました。処理を実行するには、エグゼクティブは空きメモリを見つけねばなりませんでした。「core set」（処理の状態を格納する小さなブロック）と、浮動小数点演算を行う処理のための「VAC area」です。⁴ 処理がスケジュールされたときに空いているcore setがなければ、エグゼクティブはアラームルーチンへ分岐し、アラーム1202を発しました。空いているVAC areaがなければ、1201を発しました。⁴ これらはクラッシュコードではありません。エグゼクティブが自分の能力を超える要求をされたことを告げ——そして、それに対して何かをした、その合図でした。

Apollo 11の降下の最後の数分間、まさにそれが起こりました。宇宙飛行士のチェックリストでは、乗組員がランデブーレーダーのスイッチを誤った位置に残すようになっていました。これによってレーダーがプロセッサのサイクルを盗み、本来決して動いてはならないデータ処理の処理を、エグゼクティブが繰り返しスケジュールしてしまったのです。³⁴ この余計な処理が空きメモリをすべて消費し、1202アラームが発火しました——そしてまた発火し、1201アラームも発火し、接地までの数秒間に4回も鳴りました。すべてをやれと求められた素朴なコンピュータなら、すべてをやろうとし、唯一重要な処理で遅れをとり、フリーズしたでしょう。ハミルトンのコンピュータはそうしませんでした。

二つの設計判断が着陸を救いました。一つ目は優先度スケジューリングです。エグゼクティブは優先度に従って処理を実行し、最も優先度の低い処理を切り捨てることができたので、着陸に不可欠な誘導と乗組員ディスプレイ（DSKY）はつねに動き続け、ゴミであるレーダー処理は飢えさせられました。³⁵ 二つ目はリスタート保護です。各アラームがソフトウェアの再起動を引き起こし、過負荷になった処理キューをクリアして既知の正常な状態へ再起動し、「降下エンジンの操舵やDSKYの稼働といった重要なもの」を再開させましたが、誤ってスケジュールされたレーダー処理は再開させませんでした。⁴⁵ コンピュータは事実上ノイズを投げ捨て、宇宙船を飛ばし続け、対処していることを乗組員に伝えたのです——だからこそ管制は、劣った設計であれば中止を意味したはずのアラームに対して「GO」を告げることができました。

なぜこれがエンジニアリングとして重要なのか。アラームは失敗ではなく——失敗処理が設計どおりに働いたことだったからです。チームはエグゼクティブを、過負荷を見越し、その下でトリアージし、そこから回復するように構築していました。そしてその回復を徹底的にテストしていたので、管制官たちはソフトウェアがこれまでさらされた中で最も大きなプレッシャーのもとでそれを信頼したのです。これが一つの瞬間に凝縮された全教義です。失敗は前提とされ、失敗の側こそが設計の中心であり、システムは倒れる代わりに「乗組員を生かす唯一のことだけをやる」へと劣化したのです。同じ本能は今日も生きています——負荷を切り捨てるあらゆる優先度キュー、クラッシュしたワーカーをクリーンな状態へ再起動するあらゆるスーパーバイザー、圧倒されることを生き延びるために作られたあらゆるシステムの中に。

「software engineering」を生み、正当性を求めて戦う

1202の物語は有名ですが、命名のほうがおそらくより重大です。1960年代、ソフトウェアは広く「本物の」エンジニアリングの軟弱で真剣味のない兄弟として扱われていました——ハードウェアが設計された後に何とかするもので、それ自身の厳密さを持つ分野ではない、と。ハミルトンはその枠組みを拒みました。アポロの内側で彼女はこの仕事を意図的に「software engineering」と呼び始め、その理由を明確に語っています。「それをハードウェアや他の種類のエンジニアリングと区別しつつ、各種のエンジニアリングを全体のシステム工学プロセスの一部として扱う」ためだ、と。¹ 要点は語彙ではありませんでした。要点は地位だったのです。ミッションを飛ばしたコードがエンジニアリングであるなら、それはエンジニアリングの規律に値します——仕様、レビュー、テスト、トレーサビリティ、そして単に動くようにするのではなく正しく作るという期待に。

この言葉は当初、おもしろがられて受け止められたと彼女は語っています——ソフトウェアが「エンジニアリング」でありうるという考えは、人々にはこじつけのように映ったのです。¹ しかし彼女が求めて戦った正当性は、構造を支える重みを担うものでした。失敗の側を見越して設計し、エラー回復をシステムの骨に組み込み、正しさを譲れないものとして扱え——そう要求することはできません。もしその仕事が、後で誰かが片付ける気軽なスクリプト書きと見なされているなら。分野に名前を与えることは、それを一定の基準で律するための前提条件だったのです。その10年が終わる頃には、この言葉はMITを飛び出して一つの分野の名前になっていました。今日「software engineering」はあまりにありふれていて目に見えないほどですが、それこそ主張が勝ち取られたという最も確かな証なのです。¹²

防御的設計：「ローレンのバグ」と人間に抗うエンジニアリング

ハミルトンの考え方を最も明瞭に覗き込める窓がほしいなら、それは「ローレンのバグ」です。彼女の幼い娘ローレンは、ときどき研究所にやってきて司令船シミュレータで宇宙飛行士ごっこをしていました。そしてある日、彼女はそれをクラッシュさせたのです——シミュレートされた宇宙船がすでに月へ向かう飛行の途中だったにもかかわらず、プリローンチプログラムであるP01を選択して。⁷ 航行の途中でプリローンチの初期化を読み込むと、航法データが消去され、コンピュータは迷子になりました。ハミルトンの本能は「そんなことをする宇宙飛行士はいない」ではありませんでした。それは——シミュレータが子供にそれをさせたのなら、ソフトウェアはそれを許したのであり、ソフトウェアが許すことはいずれ必ず起こる、というものでした。彼女は、飛行中にP01を選択することを防ぐエラー検出コードを追加することを提案しました。⁷

彼女は却下されました——宇宙飛行士は訓練を受けたプロであり、そんなミスを決して犯さないと言われ——ドキュメントに注記を加えることだけを許されました。⁷ そして、まさに次のミッションであるApollo 8で、ジム・ラヴェルがローレンとまったく同じことをしたのです。飛行中にP01を選択し、人類初の月周回飛行で航法データを消去しました。⁷ その後、修正は組み込まれました。ハミルトンが引き出し、繰り返し語った教訓は、防御的設計の核心です。失敗が「起こりえない」と決めつけ、起こらない前提で設計することはできない。宇宙飛行士、レーダースイッチ、午前3時のオペレーター——システムはループの中にいる人間に対して堅牢でなければならず、人間が完璧だと仮定して責めから守られていてはならないのです。彼女の優先度表示は、反対の方向から同じ考えを体現していました。人間を情報の中に、制御の中に留め置く。そうすれば、コンピュータが過負荷の下でトリアージしたとき、乗組員はそれが何をしているのかを理解し、判断できたのです。⁶

Higher Order Software、USL、そして「Development Before the Fact」

アポロはハミルトンに、エラーがどこから来るのかを教えました。そして彼女は残りのキャリアを、それを根本から攻めることに費やしました。アポロのエラーを研究して、彼女はその大部分が個々のモジュールの内側ではなく、モジュールとモジュールの間のインターフェースに潜んでいることに気づきました——あるソフトウェアが別のソフトウェアにデータを渡すとき、その前提がぴたりとは噛み合わない場所です。Higher Order Software（1976年）、そしてHamilton Technologies（1986年）で、彼女はそうしたエラーをテストで捕まえるのではなく、構築によって取り除く一連の仕事を築き上げました。¹⁶

その方法論は「Development Before the Fact」と呼ばれます。名前そのものが主張です。システムを作ってから後付けで欠陥を狩るのではなく、それを定義する——形式的なシステムであるUniversal Systems Language（USL）を使って——丸ごと一群のエラー、とりわけインターフェースと統合のエラーが構造的に不可能になるほど厳密に。モデルは証明可能なほど一貫しており、そこから正しいコードを生成できるので、欠陥は実行時に発見されるのではなく、設計時に防がれます。⁶ それはアポロのエグゼクティブと同じ確信を、もう一段深く押し進めたものです。実行時の回復はセーフティネットですが、本当の勝利はそもそもエラーを犯すことのできなかったシステムにあります。業界の大半は今なお反対のループを回しています——出荷し、バグを見つけ、パッチを当てる——まさにそれが、正しさが本当に重要なとき逆向きだとハミルトンが30年にわたって主張し続けたループなのです。

方法

アポロのエグゼクティブ、「software engineering」という造語、ローレンのバグ、そしてDevelopment Before the Factを横断して読むと、同じ信念が繰り返し現れます。ハミルトンの方法は、スローガンというよりも、変わらぬ一連の習慣です。

まず失敗の側を見越して設計する——二度目のチャンスはない。 アポロのエグゼクティブは、過負荷処理を後付けしたスケジューラではありませんでした。過負荷を生き延びることがそのまま設計だったのです。月の上空でフリーズしたコンピュータは乗組員を死なせるからです。³⁴ この教訓は宇宙飛行をはるかに超えて応用が利きます。動く経路を書く前に、システムがどう失敗するかを列挙し、すでに失敗を生き延びる構造から動く経路が自ずと落ちてくるようにする。これは信頼性に適用された証拠の関門です——「シミュレータでは動く」は証拠ではない、「レーダーが溢れさせても負荷を切り捨てて飛び続ける」が証拠だ——優雅な劣化に対するこの同じ基準を、数十年後にヴェルナー・フォーゲルスはクラウドの建国の前提に据えました。

人間はありえないことをやると仮定する。 ローレンのバグはこの法則を凝縮したものです。システムが危険な操作を許すなら、誰か——子供、宇宙飛行士、疲れたオペレーター——がいずれそれを取るのだから、「誰もそんなことはしない」は防御にはなりません。⁷ 変わらぬ習慣は、決して到達しえないと請け合われた入力に対して境界を守ることです。なぜなら、最も痛い失敗とは、あらかじめ起こりえないと決めつけたものだからです。これは、ノードが嘘をついても正しさを保つルーティングをラディア・パールマンが組み込んだのと同じ、敵対者に対する堅牢性の本能です。

負荷の下でトリアージする——重要でないものを切り捨て、不可欠なものを守る。 エグゼクティブがメモリを使い果たしたとき、それはすべての要求に応えようとはしませんでした。最も優先度の高い処理を動かし、残りを飢えさせ、そしてクリーンに再起動したのです。³⁵ 規律とは、決して止まってはならない唯一のものが何かをあらかじめ決め、プレッシャーの下ではその一つを動かし続けるために他のすべてを犠牲にするようにシステムを構築することです。優先度を持たないシステムは、乗組員ディスプレイとゴミのレーダー処理を対等に扱ったがゆえに、最悪の瞬間に失敗するシステムです。

正しさを作り込め、テストで入れるな。 Development Before the Factは、出荷してからデバッグするループの拒絶です。システムを作ってから後でエラーを狩るのではなく、エラーが表現できないようにシステムを定義する。⁶ 教訓は、最も安価で最も信頼できる欠陥とは、設計が不可能にした欠陥だということです——バーバラ・リスコフが型の規律と抽象に変えたのと同じ確信であり、レスリー・ランポートがコードを書く前に正しさを精密に仕様化することに変えたのと同じ確信です。これは品質こそが唯一の変数であるを作業の進め方に落とし込んだものです。正しさは最後の一段階ではなく、最初からその物の形そのものなのです。

分野に名前を与え、一定の基準で律せるようにする。 仕事を「software engineering」と呼ぶことが、他のすべてを許可した行為でした——仕様、レビュー、厳密さへの期待。¹ 変わらぬ習慣は、仕事には名前と基準があると主張することです。組織が使い捨てと見なすものに、職人技を要求することはできないからです。それは最小限の価値ある成果物の精神です。その物はきちんとやるに値するから、きちんとやる。そして、きちんとやることだけが唯一許される道だと声に出して主張するのです。

影響の連鎖

彼女を形づくった人々

MITにおける数学とリアルタイムの伝統。 ハミルトンは数学を通じて、そしてSAGE——最初期の大規模なリアルタイムかつ障害に敏感なソフトウェアシステムの一つ——を通じて、さらにカオス理論の創始者エドワード・ローレンツとの気象モデリングを通じて頭角を現しました。¹ その素地が表れています。彼女はソフトウェアを、誰も完全には予測できない条件下で正しさを保たねばならないシステムとして考えていました。アポロにたどり着くずっと前から、です。（形成的影響）

宇宙飛行そのものの容赦ない規律。 アポロのミッションは、どんな人物にも劣らぬ教師でした。たった一つのエラーが乗組員の命を奪い、パッチも二度目のチャンスもない領域は、ある働き方を強います——失敗の側を防御し、実行時に回復し、設計時にエラーを防ぐ——通常のソフトウェアが決して要求しない働き方を。制約が哲学を形づくったのです。²（直接的影響）

アポロ計画のシステム工学の文化。 彼女のソフトウェアがハードウェア、ミッション管制、人間の手順と統合されねばならないプログラムの内側で働いたことが、ソフトウェアをいくつかある工学分野の一つとして見るよう彼女を促しました——これこそ、「全体のシステム工学プロセス」の一部としての「software engineering」という彼女の造語の背後にある、まさにその枠組みです。¹（形成的影響）

彼女が形づくった人々

ソフトウェア工学という分野そのもの。 その時代で最も賭け金の高いソフトウェアプロジェクトの内側から、この分野に名前を与え、その厳密さを主張することで、ハミルトンはプログラミングを二の次のものから、仕様、レビュー、正しさへの期待をともなう工学分野へと変える助けをしました。¹²

あらゆる耐障害性リアルタイムシステム。 優先度スケジューリング、負荷の切り捨て、既知の正常な状態への再起動、そして人間を介在させる表示——アポロのエグゼクティブが1202アラームを生き延びるために用いたパターンは、いまや回復力あるシステムの標準的な語彙です。飛行制御から、過負荷の下でWebサービスを生かし続けるスーパーバイザーに至るまで。³⁶

形式的で、構築によって正しいことが保証される方法。 Development Before the FactとUniversal Systems Languageは、正しさは後付けでテストするのではなく設計に組み込み証明可能にすべきだと主張する系譜の一部です——形式手法とモデル駆動開発を通じて今日まで貫く主張です。⁶

貫く一本の筋

ハミルトンは、このシリーズにおける信頼性の系譜の起点です——「失敗の側を見越して設計する」が好みではなく、譲れないものとなった場所。命がそれにかかっていたからであり、分野の残りが追いつくよりも数十年早くでした。ヴェルナー・フォーゲルスは「すべてのものは常に失敗する」の上にクラウドを築き、惑星規模で優雅な劣化を設計しました。ハミルトンは、ブリーフケースほどの大きさのコンピュータの上で、その上に乗組員を乗せて優雅な劣化を設計し、本当に二度目のチャンスがないとき教義が機能することを証明しました。³ ラディア・パールマンは、ノードが嘘をついても自己修復し正しさを保つネットワークを築きました。ハミルトンのエグゼクティブは、月の上空でそれ自身をリアルタイムに修復し、クリーンに再起動して、壊れたレーダーが送りつける嘘を切り捨てたのです。⁴ そしてレスリー・ランポートは、正しさを、作る前に精密に定義し証明するものにしました——それはまさにDevelopment Before the Factが手を伸ばしたもので、一世代早く、同じ的を狙ったものでした。⁶ フォーゲルスがすべては失敗する、だから失敗を貫いて可用性を保てと言い、パールマンが自己修復するように作れと言うところで、ハミルトンはそれを最初に、そして最も強く言ったのです。二度目のチャンスはない、だから失敗が起こる前に失敗を見越して設計し、起こったときには回復し、そして最悪のエラーがそもそも起こりえなかったようにシステムを構築せよ、と。（シリーズの架け橋）

私がここから受け取るもの

ハミルトンから私が手放さない教訓は、明らかに二度目のチャンスがあるときでさえ、二度目のチャンスがないかのように作るということです。私が出荷するほとんどすべては、彼女が持たなかった心地よさの中で生きています。壊れたら、修正を押し出せばいい。そのセーフティネットは本物で、それが静かに基準を下げます——正常系を出荷して、失敗の側は後で対処すればいいと自分に言い聞かせることを許すのです。後が存在するからです。アポロはその叱責です。本当にパッチを当てられないとき、「失敗は後で対処する」がそもそもエンジニアリングなどではなかったと気づきます。失敗の側こそがエンジニアリングであり、動く経路とは、システムがすでに壊れることを生き延びた後に残るものにすぎないのです。だから今、何かを作るとき——溢れさせられる処理、誤って呼ばれうるAPI、間違ったタイミングで取られうる経路——私は「ここでの誤った位置のレーダースイッチは何か、そしてこれはそれを切り捨てて飛び続けるか」を、正常系が動くかどうかを問う前に問おうとします。正しい入力しか生き延びられないシステムは、私がまだ作り終えていないシステムなのです。

二つ目の教訓は、最も信頼できるエラーとは、設計が不可能にしたエラーだということです。ローレンのバグが私の心に残るのは、ハミルトンが正しかったのに「誰もそんなことはしない」によって却下され——そして宇宙が即座に、次のミッションでまさにそれをやったからです。私の本能は、実行時にエラーを捕まえること、危険な呼び出しをガードで包んで先へ進むことです。ハミルトンのより深い一手、彼女が30年を費やした一手は、危険な呼び出しがそもそもできないようにシステムを設計することです——悪い状態を単に検出するのではなく、表現不可能にすることです。実行時の回復はネットです。正しさを作り込むことは、そのネットが要らないように立つ床です。私はいつもその基準に届くわけではありませんが、それは目標を捉え直しました。問いは「これが間違ったときに私はそれを捕まえられるか」だけではなく、「そもそも間違いようがないように、これを形づくれるか」でもあるのです——そして後者の問いは、答えられるときには、つねによりよい問いなのです。

FAQ

マーガレット・ハミルトンは「software engineering」という言葉を生み出したのですか？

マーガレット・ハミルトンは、「software engineering」という言葉を生み出した——あるいは少なくとも広めた——人物として広く認められています。彼女は1960年代、MIT Instrumentation Laboratoryでアポロの飛行ソフトウェア開発を率いる中でこの言葉を使い始めました。¹² 彼女はこれを意図的に使い、ソフトウェアを書くことがハードウェアや他の工学分野と同じ正当性と厳密さに値すると主張しました。彼女自身、「それをハードウェアや他の種類のエンジニアリングと区別しつつ、各種のエンジニアリングを全体のシステム工学プロセスの一部として扱う」ことを望んだのだと説明しています。¹ 当時、ソフトウェアが「エンジニアリング」でありうるという考えは、いくらかおもしろがって受け止められました。今日この言葉はあまりに標準的で目に見えないほどであり、それこそ主張がいかに徹底的に勝ち取られたかの尺度なのです。¹

Apollo 11の最中の1202と1201のアラームとは何だったのですか？

それらは、月着陸降下の最後の数分間にApollo Guidance Computerのエグゼクティブが発したプログラムアラームでした。誤って設定されたランデブーレーダーのスイッチが原因で、レーダーがプロセッサのサイクルを盗み、本来動いてはならないデータ処理の処理を、エグゼクティブが繰り返しスケジュールしてしまい、空きメモリをすべて消費したのです。³⁴ メモリの「core set」が使えないとき、エグゼクティブはアラーム1202を発しました。「VAC area」が使えないとき、1201を発しました。⁴ これらのアラームはクラッシュではありませんでした——エグゼクティブが、自分の能力を超える要求をされたと報告し、そしてトリアージしていたのです。ソフトウェアは優先度スケジューリングとリスタート保護を用いていたため、余計なレーダー処理を切り捨て、既知の正常な状態へ再起動し、着陸に不可欠な誘導と乗組員ディスプレイを動かし続け、着陸は成功しました。³⁵

マーガレット・ハミルトンはアポロ計画のために何をしたのですか？

ハミルトンは1965年にMIT Instrumentation Laboratoryに加わり、昇進してSoftware Engineering Divisionを統括しました。この部門は、司令船と月着陸船の双方でApollo Guidance Computer上を走る機載飛行ソフトウェアを担っていました。¹ 彼女のチームは、非同期の優先度スケジューリング、リスタート保護、エラー検出と回復、そして宇宙飛行士を情報の中に制御の中に留めておく優先度表示を備えたリアルタイムのエグゼクティブを設計しました——Apollo 11のコンピュータが1202アラームを生き延び、着陸を完遂することを可能にしたアーキテクチャです。³⁶ 彼女の大統領自由勲章の表彰文は、彼女が「非同期ソフトウェア、優先度スケジューリングと優先度表示、そして人間を介在させた意思決定能力の概念」に貢献し、それが「現代の超高信頼ソフトウェア設計と工学の基盤を築いた」と讃えています。⁶

「Development Before the Fact」とは何ですか？

「Development Before the Fact」は、アポロの後、ハミルトンがHigher Order SoftwareとHamilton Technologiesで発展させたシステム方法論で、彼女のUniversal Systems Language（USL）を中心に組み立てられています。¹⁶ その主張は、システムを作ってからテストを通じて「事後に」欠陥を狩るのではなく、丸ごと一群のエラー——とりわけ、アポロの欠陥を支配していると彼女が見出したインターフェースと統合のエラー——が構築によって構造的に不可能になるほど、システムを厳密かつ形式的に定義する、というものです。⁶ モデルは証明可能なほど一貫しており、そこから正しいコードを生成できるので、欠陥は実行時に発見されるのではなく、設計時に防がれます。それは彼女のアポロでの確信を形式手法として表現したものです。最も信頼できるエラーとは、システムが決して犯すことのできなかったエラーである、という確信です。

出典