米Salesforce.comが提供する「Database.com」。インターネットを介してRDBMS機能を提供するサービスである。このサービスの基盤には米OracleのRDBMSが使われている。ただし、普通の使い方ではない。

 Salesforce.comのサービスの特徴は「マルチテナント」であることだ。つまり、複数社の多数のアプリケーションを、一つのシステムとして動作させている。一つのシステムとして動作しているので、サービス利用者(この場合、アプリケーション提供者)が増えてもDatabase.comの運用は煩雑になりにくい。

「マルチテナントを実現する」というエンジニアの強烈な意思

 Oracle Databaseを直接使うのに比べれば制限はあるが、サービス利用者はDatabase.com上に自由にテーブルを定義できる。いったい、どんな仕組みなのだろうか。同社のホワイトペーパーなどを読んで筆者が理解した範囲で説明すれば、サービス利用者が定義したすべてのテーブルは、一つの大きなテーブルに格納している。

 例えば、A社の販売管理アプリケーションに「商品テーブル」「顧客テーブル」などがあり、B社の人事アプリケーションに「従業員テーブル」「部署テーブル」などがあるとする。それらがすべてOracle Database上では一つのテーブルに格納されているということだ。

 サービス利用者やアプリケーションなどを示すIDのカラムを除いて、その大きなテーブルのカラムはすべて可変長の文字列型である。実際のデータ型などを示すデータベーススキーマは、別のテーブルに格納している。大きなテーブルから安全に(つまり、間違って他のアプリケーションのデータを対象とすることなく)データを取り出したり更新したりするために、さまざまなテーブルがある。普通のRDBの設計とは大きく異なる。

 Database.comは、同社の提供する各種サービスのデータベースと同じだという。同社の利用実績を見れば、このデータベース設計は十分に実用的といえる。

 この設計を解説したホワイトペーパーを読んだときは目を疑った。「何て無茶苦茶な設計なんだ」と思ったものだ。だが、その設計からは「こうすればマルチテナントを実現できるんだ」というITエンジニアの強烈な意思が感じられた。

 この設計をしたエンジニアは、おそらく「運用負担を上げないためにマルチテナント型に」という要件を与えられたんだと思う。そして、その命題に見事に応えている。こう想像したとき、先の設計に感心した。

優れたアーキテクチャー(設計思想)に学べ

 システムは要件を実現したものである。システムは設計に基づいて作られている。注目したいのは、要件が決まれば一意に設計できるわけではないということだ。要件を実現するのが難しい場合もあるが、一般には要件を実現する方法はさまざまで、いろいろな技術が選択肢になる。それらの中から適切に選択し、組み合わせて、システムを設計する。要件と設計の間には何かがある。突飛な考えとお叱りを受けるかもしれないが、要件と設計の間にあるもの、それが「アーキテクチャー」なんだと思う。

 アーキテクチャーとは何かという定義をしたいわけではない。ここでは「要件を満たす設計を行うためのITエンジニアの考え」くらいに思ってほしい。言いたいことは、ITエンジニアとしての設計力をアップするには、優れたアーキテクチャーに触れるのが効果的だということだ。

 システムを構築するとき、同じ要件は無いので同じ設計になることはない。だから、考えた結果である設計の内容より、そこに至った「考え方」に触れる方がより役に立つのではないだろうか。優れたアーキテクチャーに触れれば、設計アイデアの引き出しが増え、設計力の高いエンジニアになれるというわけだ。

 経験豊富なITエンジニアは、もっとアーキテクチャーを語ってほしい。そうすれば、ITエンジニア全体の底上げができるように思う。