要約

  • Grace Hopperは1967年にU.S. Navyへ戻った後、コンパイラーのテストと検証体制づくりを支えた。1980年の口述史では、複数の計算機で共通のテストを動かす重要な方法をGeorge Bairdの工夫として紹介している。
  • テストが示したのは、選ばれたCOBOL機能をコンパイラーがどう処理し、どの出力を返したかである。すべての組み合わせや欠陥を網羅した証明でも、任意の業務プログラムが無修正で移行できる保証でもない。
  • 言語標準、実装に対する適合テスト、実際のアプリケーション移行テストは別の証拠である。三つをひとまとめに「移植可能」と呼ぶと、未検証の範囲が隠れる。

規格文書は合格証ではない

複数のメーカーから計算機を購入する政府機関にとって、COBOLのような共通言語は、特定の供給元にソフトウェアを固定しないための手段に見えた。しかし同じ言語名を掲げても、各社のコンパイラーが必須機能を同じように実装するとは限らない。標準は期待する動作を定めるが、納入された実装を測定してはくれない。

Grace Hopperの経歴であまり語られない局面は、この測定の空白にある。初期コンパイラーやFLOW-MATICとCOBOLの関係をめぐる定番の逸話から少し離れ、ここでは機関が実際に購入するシステムをどう確かめたかを見る。必要だったのは、コンパイラーに試験プログラムを走らせ、期待値と実測値を比べ、別の計算機でも同じ確認を繰り返せる仕組みだった。

この作業には前史がある。George N. Bairdが1972年に発表したDepartment of DefenseのCOBOLコンパイラー検証システムに関する論文は、1963年に始まった標準化グループの活動をたどる。そのグループは、標準で定める機能をコンパイラーが備えているか確認するテストプログラムを作った。全組み合わせを試すことでも、あらゆる欠陥を修正することでもなく、機能を選び、単独または組み合わせて実行し、結果を記録する仕事だった。

失敗を再現できる形にする

Bairdによると、U.S. Navyの初期ルーチンは既存のテストを引き継ぎながら、実際の出力と期待される出力を並べ、失敗した手続きも示すようにした。予備版は12本のプログラム、約5,000行のソースコードで構成されていた。

この差は調達判断を変える。「当社のコンパイラーはCOBOL対応です」という説明は広い。これに対し、「この構成では指定された必須機能を受け付け、期待した出力を生成した」という結果は、別の担当者が再実行できる。テストが技術者の判断を置き換えるのではない。判断の一部を記録に残すのである。

Computer History Museumが1980年に収録したインタビューで、HopperはNorman Reamから1967年に現役復帰を求められたと振り返った。彼女の説明では、標準を実装に結びつけ、プログラムを別のシステムへ移すための試験と検証手順を整える仕事だった。製品を標準に照らして試験するように、言語標準にも適合性を確かめる試験が必要だと考えていた。

Hopperは自分一人で行うのではなく、プログラマーを集めたいと申し出たという。彼女が挙げたのは、民間職員のEd Ford、若い中尉、二人の水兵で、その一人がGeorge Bairdだった。Arnold Johnsonは後から加わった。1971年1月のDatamationは、当時U.S. NavyがCOBOLコンパイラーの検証を要求し、Department of DefenseとNational Bureau of StandardsがANSI標準に対する共通テスト作成に原則合意したと報じた。「原則合意」は、連邦全体のサービスがすでに完成していたことを意味しない。

HopperがBairdに帰した設計

口述史で際立つのは、Hopperが功績を自分だけに集めなかったことだ。彼女によれば、George Bairdは計算機ごとに異なる特殊な名前や制御カードを、別個の設定データで処理する方法を考案した。共通のテスト本体は標準COBOLで維持し、対象機種の違いだけを小さな設定ファイルから与えられる。

移植性が必要だったのは、業務プログラムだけではない。コンパイラーごとにテスト一式を書き直せば、メーカー間の比較は維持しにくく、特定実装に都合のよい調整も混じりやすい。共通部分と機種固有の設定を分離すれば、同じ確認を繰り返しながら各システムの差も記録できる。

Hopperの語りは後年の回想なので、当時のチーム内の役割について彼女が何を伝えたかを示す証言として読むべきだ。Bairdの1972年論文は、検証システムの技術的な形を別の角度から支える。両者を合わせると、Hopperは任務とチームの立ち上げに関わり、Bairdは重要な機種間テスト方式を考案し、標準化や先行テストには他の組織や人々も参加した、という慎重な説明になる。COBOLや検証コード全体を一人の発明として扱う根拠にはならない。

合格が証明しないこと

テストに合格したとは、選ばれた言語機能をその環境で処理し、期待された出力を得たという意味だ。すべての有効な組み合わせを試した、すべての欠陥を発見した、あるいは任意のアプリケーションが別の計算機で無修正に動くという証明ではない。

これはCOBOL固有の限界ではない。NISTが記録した別系統のFORTRANテストは、Betty HolbertonとElizabeth Parkerが中心となった取り組みであり、有限のテスト集合ではコンパイラーの完全な正しさを証明できないと説明している。それはNational Bureau of Standardsの別プロジェクトで、HopperのCOBOL検証システムではない。この区別を残すと、異なる言語やチームが適合性試験という制度を並行して形づくったことが見えてくる。

コンパイラーが標準に適合することと、アプリケーションが移植できることも別問題だ。選ばれたテストに合格しても、業務プログラムはメーカー独自の拡張、OSサービス、ファイル形式、ランタイムの挙動、データ表現に依存しているかもしれない。これはテスト範囲から導ける判断であって、U.S. Navyのスイートがそれらすべてを調べたという意味ではない。移行時には実アプリケーション用のテストと実行環境の記録が必要になる。

教訓は標準やテストを疑うことではない。証拠の対象を正確に名付けることだ。標準は期待する動作を定め、適合テストは実装の一部を検査し、移行テストは組織が実際に動かすシステムを確かめる。「移植可能」という一語にまとめると、残るリスクが見えなくなる。

記録を残すことも設計の一部

Hopperの貢献は、誇張しない方が輪郭がはっきりする。彼女は相互運用という目標を、担当者と手順のある検証機能にすることを支えた。さらに彼女の回想には、個人の天才が独力で発明する話とは異なる管理の姿勢がある。協力者を求め、技術の仕組みを考えた人に功績を返している。

Bairdの工夫が示すのは、移植性が委員会の文書だけでは実現しないということだ。ケース設計、機種別の設定、結果の比較、同じ処理の再現がそろって初めて、実装差を測れる。観察可能な試験がない標準は買い手に主張だけを残す。作者が記録されないテストは再現の知識を失う。範囲を示さない合格ラベルは証拠より大きな保証に変わる。

長く使うソフトウェアでは、結論と一緒に根拠を保存したい。標準とテストの版、コンパイラーのビルド、対象機種、設定、実際の出力である。Hopperが関わったU.S. Navyの仕事はベンダー差を消したわけではない。差の一部を明らかにし、実装を比較し、より強い資料に基づいて調達する方法を整えた。「COBOLがソフトウェアを移植可能にした」という説明より控えめだが、長く使える成果だ。

出典