多くの点で、現代のコンピュータ時代はコネチカット州グリニッジのニューイングランダー モーター ホテルから始まりました。
1961年、IBMのトップエンジニアによる特別委員会が秘密裏に会合し、次世代のIBMコンピューターの構築方法を検討しました。
新しい設計が切実に必要とされていました。IBMはすでに、全く異なる製品ラインではあるものの成功を収めたコンピュータ製品を数多く販売していましたが、それらの保守とアップデートはますます困難になってきていました。
「IBMはある意味、複数の互換性のない製品ラインをサポートしなければならないという重圧に耐えかねて崩壊しつつあった」と、System/360の開発と成功に関するデジタルアーカイブを保管しているコンピュータ歴史博物館の最高コンテンツ責任者、ダグ・スパイサー氏は語る。
50 年前の 4 月 7 日、IBM はタスク フォースが設計したコンピューター、System/360 を発表しました。
このシステムは最終的に同社にとって大成功を収め、そしてそれは喜ばしいことでした。当時のIBM社長トム・ワトソン・ジュニアは、IBMの他のコンピュータ製品ラインを廃止し、System/360に全力を注ぎました。IBMの売上高は1965年の36億ドルから1971年には83億ドルにまで膨れ上がりました。1970年代を通じて、販売されたメインフレームの70%以上がIBM製でした。1982年までに、IBMの売上高の半分以上がSystem/360の後継機種によるものでした。
しかし、その影響は、IBM にもたらした成功だけでは測れません。
「IBMは誰もが働きたがる会社だった」と、フィラデルフィアのラサール大学のコンピュータサイエンスの助教授で、1970年代後半にスペリー/ユニバック・システム/360クローンのオペレーティングシステムのコードのデバッグも行っていたマーガレット・マッコーイ氏は語る。
System/360 は、コンピュータ システムの設計と構築に関するまったく新しい考え方をもたらしました。この考え方は、今日私たちにとって非常に基本的なものと思われるため、50 年前にはそれがかなり革新的であったことに気付かないかもしれません。
System/360の登場以前は、メーカーは新しいコンピュータモデルを一つ一つゼロから開発していました。時には、顧客ごとに個別にマシンを製造していたことさえありました。あるマシンで動作するように設計されたソフトウェアは、たとえ同じメーカーのものであっても、他のマシンでは動作しませんでした。各コンピュータのオペレーティングシステムもゼロから開発する必要がありました。
コネチカットのホテルで生まれたアイデアは、単一のアーキテクチャーのもとで、コンピューターの統合ファミリーを構築するというものでした。
Gene Amdahl 氏がこのシステムの主任設計者であり、Fred Brooks 氏がプロジェクト リーダーでした。
アムダールは後にアムダールの法則を提唱しました。これは、大まかに言えば、コンピュータタスクを並列処理に分割することで得られるパフォーマンスの向上は、複数のスレッドを管理することによる追加のオーバーヘッドによって相殺されるというものです。また、ブルックスは『人月の神話』を執筆し、ソフトウェア開発プロジェクトに人員を追加すると、その人員管理の負担が大きくなり、ソフトウェア開発が実際には遅くなるという同様の考えを主張しました。
彼らが思いついたアイデアは、ローエンドの安価なマシンと最高級の高速モデルに共通のアーキテクチャを採用するというものでした。ハイエンドモデルはローエンドモデルの40倍の速度で動作します。1960年代初頭には、コンピュータの設計に「アーキテクチャ」という言葉を使うこと自体がほとんど考えられませんでした。
しかし、特定の実装ではなくアーキテクチャを指定することで、異なるモデル間の互換性が実現しました。
「IBMは、科学技術系とビジネス系の両方の顧客向けに上位互換性と下位互換性を備えたシステムを設計することで、単一のアーキテクチャーを用いて、かつてないほど広範な顧客層のニーズを満たそうとしていました」と、1987年にACM（Association for Computing Machinery）が発表したSystem/360のケーススタディには記されています。実際、このマシンの名称の「360」は、規模の大小、ビジネス系から科学技術系まで、あらゆる顧客層に対応できることを意味していました。
「System/360は、市場におけるビジネスとコンピューティングの両方のスレッドを1つのシステムに統合しました」とスパイサー氏は語った。
このアイデアは今日では当然のように思えますが、統合されたコンピュータ ファミリの概念は、IBM、その顧客、そして業界全体に大きな影響を与えました。
IBMは、すべてのコンピューターに単一のOSを使用できるようになりました（ただし、最終的には異なるユースケースに対応するために3つのバージョンを作成することになりました）。個別のコンピューター向けにソフトウェアを開発する作業が大幅に削減され、エンジニアは新しいアプリケーションの開発に集中できるようになりました。
IBMはハードウェアに関しても多くのリソースを節約しました。プロセッサやメモリなどのコンポーネントをマシンごとに設計する必要がなくなり、異なるモデル間で汎用コンポーネントを共有できるようになり、IBMはより大きなスケールメリットを享受できるようになりました。
顧客にもメリットがありました。System/360マシン用に書かれたコードを別のマシンで実行できるようになったのです。System/360のコードを書き直すことなく、より大きなマシンに移行できるだけでなく、より小型のモデルにも移植できました。
1960年代初頭、組織が新しいコンピュータを購入する際、「通常はすべてのソフトウェアを破棄するか、少なくとも新しいハードウェアで動作するように再調整する必要がありました」とスパイサー氏は述べた。「何世代にもわたって互換性のあるソフトウェアを実行できるコンピュータを持つという考えは、当時は存在しなかったのです。」
IBMはその後数十年にわたり、後方互換性を堅持してきました。オリジナルのSystem/360用のプログラムは、場合によってはわずかな変更を加えるだけで、今日のIBMメインフレームでも動作します（ただし、IBMがパフォーマンス向上のために最新モデルへのアップグレードを顧客に積極的に勧めていないわけではありません）。
ソフトウェア市場におけるIBMの最大のライバル企業の1社と比べてみてください。マイクロソフトは今月、リリースからわずか10年でWindows XPのサポートを終了します。
System/360 とその後継機である System/370 は、パンチ カードが徐々にグリーン スクリーンとして知られる IBM 3270 端末に置き換えられる中、1970 年代まで売れ続けました。
グリーンスクリーンはSystem360/370の使い方を一変させました。当初は、パンチカードでジョブを送信するバッチ処理を行っていました。マシンはデータを高速処理し、結果を返していました。グリーンスクリーンの登場により、マシンとのよりインタラクティブなセッションが可能になったと、CAのシニアプリンシパルプロダクトマネージャーであり、メインフレーム開発に45年携わってきたGreg Beedy氏は述べています。
Beedy 氏は、3270 端末の幅は常に 80 列で、これはパンチ カードの列数と同じであると指摘しました。
端末が導入された後でも、1970年代にはプログラミングははるかに退屈な仕事だったが、今日ではプログラマーは「すぐに満足感を得られる」とマッコイ氏は語った。
「リターンキーを押すと、すぐに答えがポップアップ表示されるんです。そんなことは一度もありませんでした。私たちは新しいユニットを組み立てて、夜勤のオペレーターに任せていました」と彼女は言った。「テストの実行には約10時間かかり、すべてが正しく動作するかを確認するのに2、3時間もかかっていました。」
当時のデバッグ作業は、16進コードだけが書かれた紙の山を精査する作業でした。マッコーイは、そのコードを元のプログラマが考案したルーチンに書き直し、コード内の論理的なエラーを見つけ出さなければなりませんでした。
「私にとって、あれはとても楽しかった。まるでパズルのようだった」とマッコイは語った。
プログラミングの世界も当時は小さかった。ビーディは1970年代半ばにSystem/360や類似のシステムに携わり始め、保険会社向けのCOBOLコードを書き始めた。
「当時は、ごく小さな集団でした。みんな知り合いでしたが、世間の人たちは私たちの仕事について何も知りませんでした。とても難解で、よく知られていないものでした」とビーディ氏は語る。「『ソフトウェア』という言葉さえ、あまり知られていませんでした。ソフトウェア会社で働いていると言うと、みんな私を変人呼ばわりするような目で見ていました」
System/360の開発初期段階のエンジニアの一人であり、後にIBMの部門社長となったパット・トゥール・シニアは、メインフレーム時代にはSAPやOracleのような商用エンタープライズソフトウェア企業が存在しないことに気づいた。IBMは銀行向けにいくつかの標準プログラムを提供していたものの、顧客は独自のソフトウェアを開発しており、それは大規模な事業だった。
「企業が銀行業務アプリケーションのプログラムを書くのに大金と2、3年を費やしたのに、ハードウェアでそれが実行できず、基本的にすべてをやり直さなければならないとなると、それは大問題だった」とトゥーレ氏は語った。
マッコイ氏は、スペリーを退職した後に勤めていた保険会社が、ワナメーカー百貨店のメインフレーム上で請求書プログラムを運用していたことを思い出した。
「彼らは月に2回、週末に請求業務を停止し、ワナメーカーのすべてのアカウントを管理していたので、ワナメーカーは独自のIT部門を雇う必要がありませんでした」とマッコーイ氏は語った。
それにもかかわらず、企業は System/360 やその他のメインフレームの価値を認識しました。
「これらのソリューションは、企業の事業運営を迅速化し、競争優位性を獲得するだけでなく、製品やサービスの柔軟性を大幅に高めることにもつながりました。単一の標準製品だけでなく、多様な価格体系を用意できるようになったのです」とビーディ氏は述べた。
1970年代後半に低価格のミニコンピュータが登場して初めて、IBMのコンピュータプラットフォームにおける優位性は薄れ始めました。しかし、その後10年間で、同社はコンピュータ、PC、そしてサーバーの次の波に乗りました。IBMはメインフレーム事業も順調に成長させています。
スパイサー氏は、他のプラットフォームで実行するためにアプリケーションを移植または書き換えるコストが、より安価なハードウェアから得られる節約をはるかに上回るという理由だけで、組織はコア業務にメインフレームを使い続けていると述べた。
「IBMは、時に動きの鈍い巨大企業ではありましたが、長年にわたり、メインフレームの重要性を維持するために巧みに適応してきました。価格性能比を下げ、メインフレーム・コンピューティングが生き残れるレベルまで引き下げることに成功しました」とビーディ氏は述べた。「メインフレームは終焉を迎え、ミニコンピュータやサーバーに取って代わられたと何度も言われてきましたが、私たちがこれまで見てきたのは、これらの新しいテクノロジーが、メインフレームをバックボーンとして、既存のものを拡張してきたということです。」
（IDGニュースサービス編集者のジェームズ・ニコライ氏がこのレポートに貢献しました。）
