クラウド上でのビジネスアプリケーション開発が実際にはどのように変わっていくのか。第1回は、米セールスフォース・ドットコムが提供する「Force.com」とは何かについて、その機能を紹介した。第2回第3回では、Force.comの開発者環境を使って人事管理アプリケーションの開発し、機能強化を施した。今回は、既にある情報をインポートする方法について説明する。

 第2回第3回を通じて、Force.com上ではビジネスアプリケーションをどのように開発していくのかがイメージできたと思う。

 ところで第1回でも述べたように、Force.comが持つ高生産性ツールという側面において、クラウドであるかどうかは直接関係していない。Force.comのような環境がソフトウエアパッケージとして存在していても不思議ではない。にもかかわらず、なぜオンプレミス型のソフトウエアパッケージには、こうした高生産性ツールが生まれなかっただろうか。

アプリケーションの進化論

 進化論を持ち出すと大げさになるかもしれないが、Force.comの開発環境が、このような高生産性ツールに進化しなければならなかったのは、クラウドにあるSaaS(ソフトウエア・アズ・ア・サービス)環境そのものに理由があると考えられる(図1)。

図1●Force.comのような高生産性ツールが生まれた環境
[画像のクリックで拡大表示]

 オンプレミス環境では、導入アプリケーションに対するカスタマイズの自由度が高く、ソースコード変更による対応が許された。外付けのアプリケーションも自由に開発できるし、環境設定も導入企業専用に自由にチューニングできる。システム連携も、特に大きな制約を受けることはなかったはずだ。

 確かに、色々と独自にカスタマイズするとバージョンアップが大変になる。しかし、ソフトウエアをバージョンアップするタイミングは導入企業の判断に任されている。つまりバージョンアップしないという自由があるわけだ。セキュリティについても、ソフトウエアが置かれている環境がファイアウオールの内側にある社内環境なので、それほど気にしなくてもセキュリティが担保された。

 これに対し、クラウドにあるSaaS環境は厳しい世界である。SaaSとして提供されているアプリケーションは、カスタマイズニーズがあったとしてもソースコードは一切変更できないし、顧客ごとに独自モジュールを開発しサーバーに載せることもできない。設定情報も共通でなければならい。

 システム連携も、インターネットを介してファイアウオールの内側にある企業システムと、標準化された方法で実現しなければならない。バージョンアップやパッチリリースも定期的かつ一斉に行わなくてはならない。SaaSとは、共通あるいは共有されたアプリケーションインフラによって、画一したアプリケーションサービスを不特定多数の企業に提供するモデルだからである。ここが、従来のホスティングと決定的に異なる点だ。

 しかし、アプリケーションがクラウドにあろうとオンプレミスにあろうと、ユーザーニーズは全く変わらない。そこでは、クラウドだから、という理由は通じない。利用企業はパッケージに合わせるのではなく、自社の要件に合わせて個別にカスタマイズしたいし、社内システムとも連携したい。もちろん社内システムと同等以上のセキュリティが求められる。