Windows Azureのメリットは、既存の.NETで開発したアプリケーションを、クラウドにシームレスに移行できることだ。もっとも、そのメリットは既存の問題点も引き継ぐことを意味すると内田氏は指摘する。
「アプリケーションをそのままクラウドに移せたとしても、保守は以前と同じ。OSのバージョンアップはクラウド側がやってくれるが、アプリケーションの動作確認はユーザーがやらなければならない。その作業からは解放されない」(内田氏)
クラウドで要件定義に長い時間をかけるのは無駄
基本的にプログラミングも品質テストも不要となると、企業側にとっては大きな変化だ。
内田氏は「10年前はこうした技術は無かった。ここまで進化させなければ、誰も我々のサービスを使ってくれなかっただろう」と話す。
カスタマイズに対する企業のニーズは高い。だから、項目と型の追加やレイアウトの変更などを可能にしたり、カスタムテーブルを作成できるようにしたり、生成したテーブル間にリレーションを張れるようにしたりと、柔軟性を高めてきた。Force.comがあるのは「プラットフォームを常に進化させてきた結果」だという。
「創業当時、Marc Benioffでさえ開発基盤を提供することまでは想定していなかっただろう。最終的にプラットフォームとして完成したのは、業務とのギャップを従来方式で埋めるために、ApexやVisualforceによるカスタムアプリケーションのコーディング環境ができた時だ」(内田氏)
Apexでコーディングする以上、バグが出てくる可能性はあるし、プログラミングによってはパフォーマンスが悪くなることもある。当然、そうした手当てはユーザーがやる必要がある。ただ、Force.comで開発したアプリケーションは、ベースがバージョンアップされても動作が保証されるメリットがある。動作テストが不要なら、企業のIT管理者の負荷は低減される。
カスタマイズ部分が影響することもない。それはなぜだろう。
内田氏は「ソースコードに一切、手が入っていない」ことを理由に挙げる。「プログラミングといっても、カスタマイズ部分やアプリケーションコードは、すべてパラメータ(メタデータ)として格納されている。完全に独立したモジュールとして作成されており、メタデータを読み取って、保存データを表示させる機能さえ保証できればいい」という。
セールスフォース側も、カスタマイズの中身がどうであれ、千差万別のカスタマイズパターンをすべてテストする必要がない。こうした仕組みはForce.comのコアテクノロジだ。ユーザーはカスタマイズを試しながら、改良していける。いわゆる、アジャイル型の開発手法が使えるわけだ。「クラウドでの開発で要件定義に長い時間をかけるのは無駄」と内田氏は言う。
セールスフォースではOracleのRDBを用いている。その理由は、出自がOracleであるがゆえ、Oracleを熟知しているからだ。
「Oracle Databaseは基本的にシングルテナント型。そのまま使ってもマルチテナント型のシステムはできない。そこでシングルテナント型のOracleの上に、マルチテナント用の新たなデータベースを乗せている。ユーザーがテーブルを生成したときに、Oracleのテーブルがそのままできているわけではない」と説明する。Oracle DBの上に汎用的なテーブルがあり、そこにすべてのユーザーのテーブルが混在している。