Future Systems プロジェクト

Future Systems プロジェクトは、IBMが1970年代初めに行った研究開発プロジェクトであり、革新的なコンピュータ製品系列を開発し、合わせてソフトウェア開発を単純化する新たなソフトウェアモデルを開発することを目標としていた。
背景と目標.
1960年代末、IBMの収益の大部分はハードウェアによるもので、ソフトウェアとサービスはハードウェアの付属品的扱いだった。価格が付いているのはハードウェアだけだが、その価格にはソフトウェアとサービスの代金も含まれていたのである。
他の製造業者が、主に磁気テープ装置や磁気ディスク装置などの周辺機器の互換ハードウェアの製造販売を開始しており、その価格はIBMのものよりずっと安価だった。このため、ソフトウェアやサービスの代金に回されるはずだった収入が減ってしまうという問題が発生していた。1971年初め、ジーン・アムダールがIBMを退社して互換メインフレームの会社を立ち上げると、IBM社内にタスクフォースが結成され、互換機市場は今後も成長すると結論付け、ソフトウェアとサービスのコストをハードウェアの価格に転嫁するビジネスモデルは早晩成り立たなくなるとした。
もう1つの戦略的課題は、ハードウェアの価格が着実に低下しているのに対して、人件費が大部分を占めるプログラミングと保守運用のコストが着実に上がっていることだった。したがって、顧客企業のIT予算は今後減っていき、それに依存しているIBMの売り上げも減少すると予測された。アプリケーション開発と保守運用のコスト問題に対処し、顧客企業のIT予算が減ってもIBMの取り分を増やすようにすることが至上命令となった。
同じ頃、IBMは市場の寡占とソフトウェアおよびサービスのコストをハードウェア価格に転嫁している点を法的に攻められてもいた。そのため、方針転換は技術的にも法的にも非の打ち所のない形で行う必要があった。
1971年5月から6月にかけて、IBMの当時の副社長 John Opel を中心とする国際的タスクフォースがニューヨーク州アーモンクに招集された。その使命は、それまでのコンピュータ全てに取って代わり（IBMの従来機とは互換性を保ちつつ）IBMの技術的優位性を確かなものとする新たなコンピュータ製品ラインの実現可能性の検討であった。タスクフォースの結論は、プロジェクトは実行する価値があるが、市場で受け入れられるためには、アプリケーションソフトウェアの開発・運用・保守のコストの大幅な削減が必要とした。
FSプロジェクトの主な目的は、以下のように定められた。
より低価格のハードウェアによってソフトウェア開発が簡素化し、IBMにとっても顧客企業にとってもコスト削減になることが期待された。
技術.
データアクセス.
FSにおける設計原則の1つとして、仮想記憶を永続性データにも拡張した単一レベル記憶があった。メモリ、ファイル、データベースをアドレスを抽象化することで一様な方式でアクセスできるようにする考え方である。
したがって、プログラマはアクセスしようとしているオブジェクトが、メモリにあるのかディスクにあるのかを考慮する必要がない。
これを含めた各種改良によってプログラミングが容易になり、ソフトウェア開発コストが削減されると期待された。
その実装には、記憶装置階層の管理システム全体とそれまでアドオンソフトウェアだったデータベース管理システムの主要部分をマシンの中核となるアドレッシング機構に組み入れる必要があった。
プロセッサ.
もう1つの設計原則は、マイクロコードを実装することで非常に複雑な命令を使うことだった。例えば、CreateEncapsulatedModule という命令はリンケージエディタそのものだった。他にも、内部のデータ構造をサポートする命令、FORTRAN、COBOL、PL/I などのプログラミング言語での操作をサポートする命令などがあった。結果として FS の設計は超CISCとでも言うべきものになった。
同じコンセプトは別の形でも適用され、それまでハードウェア、オペレーティングシステム、データベースなどで構成されていた機能をまとめ、全体を統合されたシステムと見なし、その上でそれに含まれる基本機能ごとに電子回路・マイクロコード・ソフトウェアの多数の階層で実装するものとした。マイクロコードを複数の階層に分けることまで検討された。このため、人によって「マシン」と言ったときの意味は、電子回路で実装された部分だけを指す場合もあるし、ユーザーに提供される機能群全体を指す場合もあり、その中間の意味で使う人もいた。
メインプロセッサ以外に、入出力操作を処理する "Universal Controller" と呼ばれるものが全体の設計として必要とされた。Universal Controller の命令セットは非常に限定的で、入出力に特化していた。
歴史.
開始.
Future Systems プロジェクトが公式に開始されたのは1971年9月のことで、上述のタスクフォースの提言を受けてのことだった。その後、IBMの他の研究プロジェクトもFSプロジェクトの一部とされたり、関連付けられたりしていった。
プロジェクト運営.
このプロジェクトでは常に厳しいセキュリティ管理体制が敷かれていた。プロジェクトは多数のサブプロジェクトに分割され、各チームに割り当てられた。文書も同様に多数の断片に分けられ、各チームには知る必要のある部分に関する文書だけが公開され、どのチームがどの部分を知る必要があるかはプロジェクト本部が決定した。文書の所在は常に監視され、必要があれば即座に回収された。
結果として、プロジェクト関係者の多くがプロジェクトの全体像を知らないまま働いた。チームによっては、自分達の仕事がFSプロジェクトの一部だということも知らされなかった。このため、当時の関係者にFSプロジェクトの定義を訊ねても、人によって答えが違う。
計画された製品ライン.
FSアーキテクチャの実装として3種類のマシンが計画された。最上位モデルはこれまでも大型機を開発してきたニューヨーク州ポキプシーで設計された。中型モデルは中型機を従来から受け持っているニューヨーク州エンディコットで設計された。小型モデルはスモールビジネスコンピュータを従来から担当しているミネソタ州ロチェスターで設計された。
3つの実装レベルのそれぞれでプロセッサ数を加減することで、切れ目のない広範囲な性能を提供する。
1973年初め、プロジェクトの本部とこれらの実装より上位の共通部分に関わる人々は Mohansic ASDD laboratory に集められた（アーモンクにある本社とポキプシーの中間あたりに位置する）。
終結.
FSプロジェクトは1975年に中止となった。中止の理由を訊いてみても、訊ねる相手がプロジェクトのどの部分に関わっていたかによって、返ってくる答えが異なる。実際、プロジェクトの成功には、回路設計や製造技術からマーケティングや保守に至るまで、すべての分野でブレークスルーが必須だった。個々の分野では問題が解決されたかもしれないが、すべてが相互に組合せ可能な形で解決する見込みは全くなかった。
1つの兆候として、最上位機の実装の性能が極めて悪かったという事実があるが、社内でCISC対RISCなどの技術的論争が延々と続いたこともプロジェクトに傷をつけた。命令セットの複雑さも問題で、IBMの技術者自身も「不可解 (incomprehensible)」と感じていた。さらに、シミュレーションの結果は、ハイエンドマシン上でのネイティブFS命令の実行は、同じマシン上のSystem/370エミュレータよりも遅いことを示した。
360アーキテクチャからのアプリケーションの妥当な移行経路がなかったため、FSプロジェクトを歓迎する顧客は当初予想したよりも少なくなることが判明し、プロジェクトは最終的に中止となった。真に革新的なシステムを設計することを至上命令としていたため、アプリケーション移行の容易性は重要な目標とされておらず、単に新たなアーキテクチャを前提とした移行のための対策をとることになっていた。しかし、COBOLやアセンブリ言語で書かれたユーザーの多数の資産を移行するコストは、新システムを購入するコストよりも大きくなることが判明した。
結果.
FSプロジェクト全体としては中止となったが、小型マシンのアーキテクチャを単純化したものはロチェスターで開発が続行された。最終的にそれが IBM System/38 としてリリースされ、プログラミングしやすいよい設計であったことを証明した。ただし、性能は良くなかった。後継の AS/400 ではアーキテクチャを継承しつつ、性能も改善されている。皮肉なことに、この系統の現在のシリーズ System i は、ジョン・コックのRISCマシンの流れを汲む POWER プロセッサベースであり、従来機との互換性は純粋にソフトウェアだけで実現されている。
System/38 の他にも、Future Systems プロジェクトの成果が製品としてリリースされたものは存在する。以下にその一部を示す。