はじめに
まず、長い間この連載に付き合って下さった方々にお礼を申し上げます。Cachéに関しては、まだまだたくさんお伝えしたいことがありますが、この連載は、今回で一応終わりにしたいと思います。
Cachéは、結局の所、開発ツールに過ぎないので、これをポンと生のまま提供しても何の役にも立ちません。Cachéの価値を際出させるには、これを使って開発者の皆さまに何か価値のあるもの、差別化できるものを作っていただく必要があります。
「そのために、何ができるか？」
インターシステムズという会社は、30年間、そのことを考え続け、こだわり続けてきた会社です。
ツールとは
ここで、もちろん異論があるのは承知ですが、ソフトウェア開発者を職人として考えてみると、例えば『大工さんにとっての道具というのは、いろいろあると思いますが、手になじんだ道具で、しかもなるべく少ない道具で作業できた方が良い』はずです。
そうすることによって覚えることが減り、作業効率が上がっていきます。さらに、そのなじんだ道具がどんどん機能アップして、ますます使いやすくなるというのが理想です。
結果として、余った時間をより良いサービスを考えるために使うか、さらなる技量アップに使うか、遊ぶ時間を増やすために使うかは大工さんの自由ですが、ちょっとでも野心を持っている大工さんならば、前者を選ぶことでしょう。
ところが、残念ながら一般的なソフトウェア開発の世界は、そうなっていません。
ハードウェアの進歩と共に、アプリケーションの開発パラダイムにもいくつかの変遷がありました。その都度、新しい考え方や手法に迅速に対応するため、作業分担が可能なように、あるいは新しいものを容易に追加可能なようにと、そのパラダイムに対応するために必要な複数のパートをブロック化して、構築していく手法がとられました。
これは、ある意味、理にかなったことなのですが、使う立場から考えると、統一感という観点から実に使い勝手の悪い環境です。
家を建てるときに、すべての道具を持っていくのは、大変なので、必要なものだけ持っていこうと考えますが、建てる家の要件ごとに、その道具の組み合わせが違うとなると、まず必要な道具をそろえる所から考えないといけません。作業の段取りを考えると、その道具箱の中での道具の配置にも気を配らないといけないかも知れません。
開発者の皆さんは、多かれ少なかれ、日々似たようなことに忙殺されているのではないかと思います。
開発ツールとしてのCACHÉ
Cachéは、アプリケーション開発ができるだけCachéだけで完結するように、必要なものがあらかじめ環境の中に統合されています。
もちろん、Cachéは1つでなんでもかんでもできる魔法の杖のようなものではありませんが、どこにいく場合でも1つの道具箱で事足りるというイメージです。
その一例として、データベースとプログラム言語の統合があります。
一般的に、プログラム言語とデータベースは相容れないもので、まったく別々に存在すべきものと固く信じられていますが、実は、言語とデータベースは密接にかかわるべきものと考える人は多いのです。
大手リレーショナルデータベースベンダーの開発動向を見ても、プログラム言語との統合に相当力を入れているのが、見て取れます。
ある人は、これはCOBOLを開発した際にデータ部をData Divisionとして分けたことから始まっているといっていますが、確かにコンピュータの黎明期には計算機と言われたくらいですから、計算が主体で、ファイルは結果を単に置いておく場所に過ぎなかったという事実からは、当然の流れだったのかもしれません。
しかし、コンピュータの利用方法が進化するにつれ、データと処理の関係も段々複雑になってきました。その結果として、さまざまな考え方のデータベースシステムが考案され、現在では、リレーショナルデータベースが主流となっています。しかし、プログラム言語とデータベースは分離されたままです。
Cachéの基本的な考え方は、1960年の後半に考えられたものですが、当時の主流の環境は、汎用機＋COBOL＋インデックスファイルまたは階層型データベースまたはネットワーク型データベースの組み合わせでした。
この環境で、可変長データや複雑な関係を表現したり、構造変化が激しいデータを処理するのは、非常に骨の折れる作業でした。
もっとデータを柔軟に扱える仕組みがほしいと考えた人々が、プログラム言語の変数をそのまま永続データとして格納できたり、それを後で参照できたら面白いと考えました。
Cachéのデータベースの基本的な考え方は、こうして生まれました。
プログラム言語と開発効率
変数はプログラム言語にとって必要不可欠なものなので、この概念を実現するためには、その永続化エンジンとプログラム言語が密接に連携する必要がありました。こうして、Cachéの多次元データベースとそれを操作するためのプログラム言語が誕生しました。
この新しい仕組みでアプリケーションを開発すると、驚くほど短期間に、機能豊富で軽快に動作するアプリケーションを開発することができました。これは、一重にその開発環境がもたらす生産性の高さに負う所が、大きかったと思います。つまり、生産性が高いが故に、一人の開発者がカバーできる範囲が広がったのです。
一般に大規模なアプリケーションは、1人で開発するのが大変なので複数の人々で開発するのが当たり前ですが、生産性は、人数が増えたからといって正比例で増えるわけではありません。1つのものを開発するために複数の人々が携わるには、さまざまな取り決めや情報交換の時間が必要になってきます。そして、それは人数が増えるほどにその負荷が増してしまうわけです。
もし仮に1人の開発者の生産性が10倍上がったとしたら、10人月の仕事が0.5人月でこなせるかもしれません。
実際、Cachéのアプリケーションの中には、こんな人数でよくこんなものをそんな短期間でできたなぁと驚いてしまうアプリケーションがあります。
外部連携の問題
このように、開発生産性とその処理性能という点では画期的な仕組みでしたが、問題がないわけではありませんでした。
一番の問題点は、データの2次利用を含む外部連携でした。
当然ながら、すべてのアプリケーションをこの仕組みで全部作り変えることは、いくら生産性が高くても不可能なため、旧来の仕組みで作られたアプリケーションとなんらかの連携を行う必要がでてきます。Cachéのデータベースは、Cachéのプログラム言語でしかアクセスできなかったため、外部連携するには、その連携に合う形にデータを抽出するプログラムをその都度作らなければなりませんでした。
今風に言えば、データベースから抽出したデータを使って、EXCELで分析するといった使い方の場合もそうです。EXCELにデータをロードするためのCSVファイルを出力する際に、違うデータ、違う形式で出力する度に、毎回プログラミングしなければならないというのは、すごく手間がかかりすぎます。リレーショナルデータベースが主流の地位を獲得した大きな理由が、この2次利用の柔軟性を提供した点にあったのではないかと思います。
さらにデータのファイル交換だけではなく、違うプログラム同士で自由にデータを交換する仕組み（異機種プラットフォーム間、異なるプログラミング言語間、ネットワーク間でのリモートプロシジャコール）が必要になった場合も、非常に苦労してその仕組みを実装する必要がありました。
インターシステムズは、1990年代にこれらの問題をどう解決したらよいか検討を始めました。
2次利用の問題は、リレーショナルデータベースの概念を適用することで、解決できそうでした。アプリケーション連携の問題は、そんなに単純ではありませんが、オブジェクト指向によるインターフェイスの概念を適用することにより、解決できるのではないかと考えました。
オブジェクトとリレーショナル ～ 統一データアーキテクチャ
残った問題は、オブジェクトとして見えるデータとリレーショナルなデータをどう調停するかという問題でした。
オブジェクトのデータ構造は、比較的単純にCachéが持っている多次元データ構造にマッピングできそうでした。リレーショナルのテーブル構造も実は、その多次元データ構造を次元単位に横串にスライスすると、その1つ1つの構造をテーブル構造にマッピングできることが分かりました。
この様なアイデアのもと、開発されたのが統一データアーキテクチャとそれを支えるCachéオブジェクトモデルです。
統一データアーキテクチャにより、1つのスキーマ定義（クラス定義）からオブジェクトアクセスおよびSQL（リレーショナル）アクセスをするための実行コードを自動生成します。
Caché開発者は、そのオブジェクトフレームワークが定めたセマンテックス、シンタックスに基づいてプログラムを書きます。 それを実行すると、自動生成された実行コードが動作し、その実行コードの中で、適切な多次元データを操作します。
Caché開発者は、SQLが定めたセマンテックス、シンタックスに基づいてプログラムを書くこともできます。それを実行すると、自動生成された実行コードが動作し、その実行コードの中で、適切な多次元データを操作します。
そのオブジェクトフレームワークのセマンティク、シンタックスとSQLのセマンティック、シンタックスはまったく異なるもののように見えますが、最終的には、それらに対応する多次元データにアクセスしますので、見かけとは関係なく同じデータを扱うことができます。
さらなる進化
そして、Cachéオブジェクトモデルに基づき、さまざまなものが追加されてきました。
各種言語バインディング（Java、.NET、Perlなど）、Web Services対応、他リレーショナルデータベースをCachéからアクセス可能にするSQL Gateway、Webアクセス用フレームワークCSP、さらにそれを拡張したコンポーネントベースのZenなどなど（詳しくは、連載各章で記述していますのでご参照ください）。
そして、これらは、首尾一貫したCachéオブジェクトモデルの上に成り立っていますので、心地よい統一感があります。
このCachéオブジェクトモデルは、複数回にわたる製品のバージョンアップによって、内部的なリファクタリングが行なわれ、年々完成度、安定度を増しています。さらに、このモデルに基づき、さまざまなものが追加されてきています。
インターシステムズは、InterSystems Ensembleというアプリケーション統合プラットフォームも提供していますが、これも実は、Cachéのオブジェクトモデルの上にアプリケーション統合に必要な機能を付け加えたものです。
InterSystems HealthShareという製品（日本では未発表）もありますが、これはEnsembleの上にさらに国レベル、リージョンレベルの医療連携に求められる機能を付け加えたもので、やはり、Cachéのオブジェクトモデルの上に成り立っています。
今後もいろいろなものがこのオブジェクトモデルの上に構築されて製品化および製品に組み込まれることと思います。
さらに開発者の皆さんの開発効率を上げるためのコード自動生成、コード入力アシスト、さまざまな便利なクラスライブラリの追加など、さまざまな機能拡充が予定されています。
当然、データベースの処理速度の向上、スケーラビリティ向上、可用性の向上の面でもさまざまな性能拡充が予定されています。
アプリケーション開発にかかわるすべてのことがCachéでまかなえる、そんな日が来るのもそんな遠い日ではないかもしれません。
今後のインターシステムズ製品の進化にご期待ください。
