最終回　オブジェクトデータベース「CACHÉ」の未来

SQLも使えるオブジェクトデータベース「CACHE'」を知る 13

本連載では、オブジェクトデータベースとして注目のCache'（キャシエ）をさまざまな側面から解説してきました。最終回となる今回は、Cache'の歴史やその根底にある思想を総括し、今後の展開についてお話して締めくくりたいと思います。

はじめに

　まず、長い間この連載に付き合って下さった方々にお礼を申し上げます。Cachéに関しては、まだまだたくさんお伝えしたいことがありますが、この連載は、今回で一応終わりにしたいと思います。

　Cachéは、結局の所、開発ツールに過ぎないので、これをポンと生のまま提供しても何の役にも立ちません。Cachéの価値を際出させるには、これを使って開発者の皆さまに何か価値のあるもの、差別化できるものを作っていただく必要があります。

　「そのために、何ができるか？」

　インターシステムズという会社は、30年間、そのことを考え続け、こだわり続けてきた会社です。

ツールとは

　ここで、もちろん異論があるのは承知ですが、ソフトウェア開発者を職人として考えてみると、例えば『大工さんにとっての道具というのは、いろいろあると思いますが、手になじんだ道具で、しかもなるべく少ない道具で作業できた方が良い』はずです。

　そうすることによって覚えることが減り、作業効率が上がっていきます。さらに、そのなじんだ道具がどんどん機能アップして、ますます使いやすくなるというのが理想です。

　結果として、余った時間をより良いサービスを考えるために使うか、さらなる技量アップに使うか、遊ぶ時間を増やすために使うかは大工さんの自由ですが、ちょっとでも野心を持っている大工さんならば、前者を選ぶことでしょう。

 

　ところが、残念ながら一般的なソフトウェア開発の世界は、そうなっていません。

　ハードウェアの進歩と共に、アプリケーションの開発パラダイムにもいくつかの変遷がありました。その都度、新しい考え方や手法に迅速に対応するため、作業分担が可能なように、あるいは新しいものを容易に追加可能なようにと、そのパラダイムに対応するために必要な複数のパートをブロック化して、構築していく手法がとられました。

　これは、ある意味、理にかなったことなのですが、使う立場から考えると、統一感という観点から実に使い勝手の悪い環境です。

　家を建てるときに、すべての道具を持っていくのは、大変なので、必要なものだけ持っていこうと考えますが、建てる家の要件ごとに、その道具の組み合わせが違うとなると、まず必要な道具をそろえる所から考えないといけません。作業の段取りを考えると、その道具箱の中での道具の配置にも気を配らないといけないかも知れません。

　開発者の皆さんは、多かれ少なかれ、日々似たようなことに忙殺されているのではないかと思います。

開発ツールとしてのCACHÉ

　Cachéは、アプリケーション開発ができるだけCachéだけで完結するように、必要なものがあらかじめ環境の中に統合されています。

図2 CACHE'システム管理ポータル ホーム画面

　もちろん、Cachéは1つでなんでもかんでもできる魔法の杖のようなものではありませんが、どこにいく場合でも1つの道具箱で事足りるというイメージです。

　その一例として、データベースとプログラム言語の統合があります。

　一般的に、プログラム言語とデータベースは相容れないもので、まったく別々に存在すべきものと固く信じられていますが、実は、言語とデータベースは密接にかかわるべきものと考える人は多いのです。

　大手リレーショナルデータベースベンダーの開発動向を見ても、プログラム言語との統合に相当力を入れているのが、見て取れます。

　ある人は、これはCOBOLを開発した際にデータ部をData Divisionとして分けたことから始まっているといっていますが、確かにコンピュータの黎明期には計算機と言われたくらいですから、計算が主体で、ファイルは結果を単に置いておく場所に過ぎなかったという事実からは、当然の流れだったのかもしれません。

　しかし、コンピュータの利用方法が進化するにつれ、データと処理の関係も段々複雑になってきました。その結果として、さまざまな考え方のデータベースシステムが考案され、現在では、リレーショナルデータベースが主流となっています。しかし、プログラム言語とデータベースは分離されたままです。

　Cachéの基本的な考え方は、1960年の後半に考えられたものですが、当時の主流の環境は、汎用機＋COBOL＋インデックスファイルまたは階層型データベースまたはネットワーク型データベースの組み合わせでした。

　この環境で、可変長データや複雑な関係を表現したり、構造変化が激しいデータを処理するのは、非常に骨の折れる作業でした。

　もっとデータを柔軟に扱える仕組みがほしいと考えた人々が、プログラム言語の変数をそのまま永続データとして格納できたり、それを後で参照できたら面白いと考えました。

　Cachéのデータベースの基本的な考え方は、こうして生まれました。

プログラム言語と開発効率

　変数はプログラム言語にとって必要不可欠なものなので、この概念を実現するためには、その永続化エンジンとプログラム言語が密接に連携する必要がありました。こうして、Cachéの多次元データベースとそれを操作するためのプログラム言語が誕生しました。

　この新しい仕組みでアプリケーションを開発すると、驚くほど短期間に、機能豊富で軽快に動作するアプリケーションを開発することができました。これは、一重にその開発環境がもたらす生産性の高さに負う所が、大きかったと思います。つまり、生産性が高いが故に、一人の開発者がカバーできる範囲が広がったのです。

　一般に大規模なアプリケーションは、1人で開発するのが大変なので複数の人々で開発するのが当たり前ですが、生産性は、人数が増えたからといって正比例で増えるわけではありません。1つのものを開発するために複数の人々が携わるには、さまざまな取り決めや情報交換の時間が必要になってきます。そして、それは人数が増えるほどにその負荷が増してしまうわけです。

　もし仮に1人の開発者の生産性が10倍上がったとしたら、10人月の仕事が0.5人月でこなせるかもしれません。

　実際、Cachéのアプリケーションの中には、こんな人数でよくこんなものをそんな短期間でできたなぁと驚いてしまうアプリケーションがあります。