さて、今お話ししているのは、1950年代後半から60年代初頭にかけてのことです。私たちは、パンチカードと電子機械の組み合わせについて、好奇心をもって見てきました。ソフトウェア危機は、ますます深刻になってきていました。しかし、ハードウェアのビジネスに関して言えば、当時はまだ、こうした独立型のマシンがありました。
IBMも、科学用、ビジネス用と、さまざまな分野のマシンを作っていて……その多くは大金を稼ぎだしていたのですが、顧客は満足していませんでした。顧客に喜んでもらえなければ、幸せなビジネスとは言えません。
なぜ顧客に満足してもらえなかったのか？ それは、同様のソフトウェアを何度も書き直して実行しなければならなかったからです。もっと速いマシンが欲しいという顧客には、わかりました、喜んで販売します、という状態でした。実際にはIBMは、マシンを販売していたわけではなく、レンタルしていたのですが。とにかく、顧客はソフトウェアを書き直さなければならず、それが大変だったというわけです。
このころ、抽象化の度合いが上がった別の分野があります。ジョン・ピンカートン（John Pinkerton、図表51）が作ったLEO（図表52）というコンピュータの登場です。
商業用のコンピュータを初めて使ったのはどんな会社かご存知ですか？ それは、イギリスのお茶会社でした。彼らが、1951年にLEOというマシンを作ったのです。この名前は確か、Lyons Electronic Ofiiceの略だったと思います。このコンピュータを中心となって作ったのが、ピンカートンでした。
なぜ彼らは仕事を自動化したかったのでしょうか？ そこには、グローバルなビジネスに特有の、雑務という問題がありました。この会社は、世界中とお茶の取引をしていました。しかしその仕事は、人間がやるには面倒な仕事ということになってきていたのです。そこで、なんとかして自動化しよう、ということになり、エドワード・マークリーとの協力で、LEOというコンピュータが生まれました。
図表51 ジョン・ピンカートン（John Pinkerton） ＊Wikipedia
図表52 LEO ＊Wikipedia *
同じころ、グレース・ホッパーやロバート・バーマー（Robert Bemer、図表53）、ジーン・サメット（Jean Sammet、図表54）といった面々が活躍していました。ジーンは、後に「COBOL」となるアイデアを思いついた人で、IBMでも勤務していました。FORTRANが科学のベースとなることを意図して作られた言語だったのに対し、COBOLはビジネスのベースになる言語として生まれたものでした。
図表53 ロバート・バーマー（Robert Bemer） ＊Wikipedia
図表54 ジーン・サメット（Jean Sammet） ＊Wikipedia
ちなみに、IBMの組織「SHARE」（図表55）が設立されたのもこのころです。今はオープンソースと言いますが、SHAREは初のオープンソース組織でした。IBMは、ソフトウェアの販売を行っていませんでした。ほとんどの場合、IBMがマシンを貸し出して、顧客はそれを使うという形だったのです。
SHAREという組織は、文字どおりコードを共有したいと思っていたIBM顧客のためのコンソーシアムとして誕生しました。ですから、早くも1955年には、初めてのオープンソースでの共有が行われていたのです。
図表55 SHARE ＊Wikipedia ＊SHARE.org
それから、SAGE（図表56）の登場です。面白いことに、SAGEの登場が、ソフトウェア危機の本当の始まりとなりました。
第2次世界大戦後のこの時期、冷戦の只中にあった米国にとって、最大の脅威はソ連でした。私たちは、ソ連が北極圏を越えて爆撃機を飛ばしてきて、攻撃を仕掛けてくるのではないかと恐れていました。レーダーはありましたが、早期の警告が必要でした。
そこでアメリカは、北方の国境線沿いに、BMEWS（図表57）という弾道ミサイル早期警戒システムを建設しました。そうすれば、ソ連の爆撃機が来ればわかるというわけです。ちなみに、指令制御プログラムのためにコンピュータを構築したのはIBMでした。
SAGEは、「Semi-Automatic Ground Environment：半自動式防空管制組織」の略語です。このシステムで、ライトペンとCRTディスプレイが登場しました（図表58）。これは、ソフトウェアという観点からは興味深いシステムでした。なぜなら突然に、リアルタイム処理の大規模なソフトウェアが生まれたのですから。
このシステムを構築するには、とてつもない費用がかかりました。私の記憶に間違いがなければ、その大部分はFORTRANで作られていました。この作業には、非常に大量の人員が関わっていました。軍は、こうした形のままでは続けていけないことに気づきました。
この経験から生まれたのが、最初のほうでも述べた、「ソフトウェアエンジニアリングに関するNATOカンファレンス」（図表59）です。
図表56 SAGE（Semi-Automation Ground Environment：半自動式防空管制組織） ＊Wikipedia
図表57 BMEWS（Ballistic Missile Early Warning System：弾道ミサイル早期警戒システム） ＊Wikipedia
図表58 SAGEで採用されたCRTディスプレイ ＊Wikipedia
図表59 「ソフトウェアエンジニアリングに関するNATOカンファレンス」
ボブ・エバンス（Bob Evans、図表60）はこの時期に、複数プロジェクトのプログラムマネージャーをしていました。タイムシェアリングという考え方を生み出したクリストファー・ストレイチー（Chris Strachey、図表61）と、ダイナ・スト・ジョンストン（Dina St Johnston、図表62）が、ソフトウェアエンジニアリングの歴史のこの段階で登場します。
ダイナはイギリス在住でした。彼女は、ソフトウェア開発を軸にビジネスを構築することは現実的に可能だと気づきました。ダイナは、ソフトウェア開発の分野で最初に起業した人物の1人です。イギリスで、ソフトウェアを書くサービスを一般に対して販売するグループを立ち上げました。
図表60 ボブ・エバンス（Bob Evans） ＊Wikipedia
図表61 クリストファー・ストレイチー（Chris Strachey） ＊Wikipedia
図表62 ダイナ・スト・ジョンストン（Dina St Johnston） ＊Wikipedia
興味深い時代に差し掛かりました。1960年代のことです。この時代は、ソフトウェアが大きなビジネスになろうとしていた時代です。
このころにIBMが登場して、「IBM System/360」（図表62）によってすべてを変えてしまいました。なぜIBM System/360がそれほど大きな変化をもたらしたのでしょうか？ 以前少しお話ししたように、このころは、独立型のマシンがたくさんあったのですが、IBMはこの時代、共通のインストラクションセットをもったマシンにしようとしていました。新しいマシンを所有する場合でも、ソフトウェアはそのまま使い続けられるのです。
また、ソフトウェアでお金を稼ぐことができるという素晴らしいアイデアをIBMがもつようになったのもこの時期でした。ですからIBMは、ソフトウェアとハードウェアを分離したのです。この2つの出来事が、ソフトウェアビジネスを根本からすっかり変えました。なぜなら、今では、ソフトウェアそのものが経済的価値の一部となったからです。エンジニアリング分野では多くの場合、有望なプロジェクトに資金が集まります。そして、資金が集まるところに、より多くのエンジニアリング的な活動が見出されます。
図表62 IBM System/360 ＊Wikipedia
ここで、フレッド・ブルックス（Fred Brooks、図表63）が登場します。私はフレッドが大好きです。一度イギリスで、彼と丸一日一緒に過ごしたことがありました。フレッドは、愉快で心の温かい紳士でした。もちろん彼は、IBM System/360に関して、プロジェクトを管理し始める方法など、さまざまなアイデアを導入し始めた人物です。
しかし、最初のソフトウェアエンジニアリング専門家を挙げるとするなら、それはおそらくラリー・コンスタンチン（Larry Constantine、図表64）のような人でしょう。
ラリーは、FORTRANの考え方をベースに、モジュラープログラミングは優れているという考えをもっていました。モジュラープログラミングという考え方を導入したのはラリーです。彼は、「結合度」（Coupling）と「凝縮度」（Cohesion）というコンセプトを導入しました。まずは、基本的に、疎結合のほうが望ましく、互いの独立性がかなり高いサブルーチンを作り上げるべきという意味です。そして、それらを凝集度の高いものにしたいときには、サブルーチンそのものが、十分に自己完結的なものである必要があります。
図表63 フレッド・ブルックス（Fred Brooks） ＊Wikipedia
図表64 ラリー・コンスタンチン（Larry Constantine） ＊Wikipedia
ここでも、ソフトウェアエンジニアリングは主に、単なるアルゴリズム解析にすぎませんでした。しかし、ヨーロッパに住んでいたエドガー・ダイクストラ（Edsger Dijkstra、図表65）はそこに、形式手法（formal methods、図表66）のアプローチを導入し始めました。これは、興味深い文化的なルールのようなものです。
アメリカでは、人々は何かを作り上げたい、と単純に考えています。より偉大な数学的基礎をもつヨーロッパでは、人々は何かを作り上げたいと思うとき、それを、正しい方法で、ルールに則して作り上げようとします。こうした形式的なアプローチを導入した人物として、ダイクストラや、ニクラウス・ヴィルト（Niklaus Wirth、図表67）、トニー・ホーア（Tony_Hoare、図表68）などがいました。これらの人々が、現在モダン・ソフトウェア・エンジニアリングと呼ばれる理論で私たちを導き始めたのです。
そのころにはロバート・フロイド（Robert Floyd、図表69）も登場して、プログラミング言語を表現する形式手法について述べました。ホーアやこれらの人物のおかげで、理論的基礎が築かれていったのです。このころから形式手法が大きな役割を果たすようになり、その中心人物として活躍したのがホーアでした。
図表65 エドガー・ダイクストラ（Edsger Dijkstra） ＊Wikipedia
図表66 形式手法（formal methods） ＊Wikipedia
図表67 ニクラウス・ヴィルト（Niklaus Wirth） ＊Wikipedia
図表68 トニー・ホーア（Tony_Hoare） ＊Wikipedia
図表69 ロバート・フロイド（Robert Floyd） ＊Wikipedia
オーレ＝ヨハン・ダール（Ole-Johan Dahl、図表70）とクリステン・ニゴール（Kristen Nygaard、図表71）は、本当に素晴らしい発想をもっていました。その考え方については、後でもう一度、説明します。私たちがこういった数学的なものを作り上げられるのは、それが世界を見るもう1つの方法だからです。そしてそれは、単にアルゴリズムを通じてだけではなく、オブジェクトを通じても行われます。アルゴリズムとオブジェクトは類似しているのです。この点については、すぐあとでまた検討します。
それから、マーガレット・ハミルトン（Margaret Hamilton）が現れます。ここで、初期の歴史にあった複数の道筋が交わることになります。SAGEの経験を経て、今度は宇宙計画に加わったわけです。マーガレットは、プリントアウトされて山のように積み上げられている紙の山のそばに立っています（図表72）。宇宙ロケットの誘導システムのリスティングなどがプリントアウトされたものです。
ここで、ソフトウェアエンジニアリングは、本当の意味で「現実のもの」となりました。
マーガレットの言葉を引用しましょう。「私が最初に、『ソフトウェアはやがて必然的に、他のあらゆる分野と同じように尊重されるようになるでしょう』という言葉を使ったときは、何かの冗談と受け取られていました。ところが、ソフトウェアが現実のものとなったのです」 ［第7回へ続く］
図表70 オーレ＝ヨハン・ダール（Ole-Johan Dahl） ＊Wikipedia
図表71 クリステン・ニゴール（Kristen Nygaard） ＊Wikipedia
図表72 プリントアウトの山の横に立つマーガレット・ハミルトン（Margaret Hamilton） ＊Wikipedia
････････
◎グラディ・ブーチ氏講演 「ソフトウェアエンジニアリングの歴史」
第1回 エンジニアリングは高級神官イムホテプから始まる
第2回 ソフトウェアエンジニアリングのさまざまな定義
第3回 Adaから始まりエンジニアリングの基礎が築かれる
第4回 ソフトウェアエンジニアリングへ
第5回 サブルーチン、コンパイラ、FORTRANの誕生
第6回 ソフトウェアが現実のものになる
第7回 アルゴリズムからオブジェクト指向へ
第8回 ソフトウェアエンジニアリングの第3の黄金時代
第9回 ソフトウェアは、ハードウェアの可能性の物語を囁く
････････
◎グラディ・ブーチ（Grady Booch）氏
グラディ・ブーチ（Grady Booch）氏は1955年、米国テキサス州生まれ。オブジェクト指向ソフトウェア開発方法論Booch法とソフトウェア開発モデリング言語UMLの開発者。現在、IBM フェロー。ACM フェローおよびIEEEのフェローでもある。＊Wikipedia
［IS magazine／i Magazine］
