本連載ではパブリッククラウドを使った企業向けシステム構築について解説している。第1回は、Amazon Web Services(以下、AWS)について概説した(参考:「コンピュータリソースを無制限に活用できるAmazon Web Services」)。第2回の今回は「Force.com」を取り上げる。毎度申し上げていることではあるが、変化の激しい分野なので、記載されている情報は原稿執筆時点のものであることをご了解いただきたい。
Force.comは、Salesforce.comが提供しているビジネスアプリケーションの開発プラットフォームである。同社はマーク・ベニオフ氏が1999年に設立。当初よりITのユーティリティ化(水や電気のように即座に利用可能なサービス)を唱え、エンタープライズ向けのアプリケーションをASP形式で提供してきた。その意味で同社は、消費者向けサービスを原点とするGoogleやAmazon.comとは異なる、生粋のエンタープライズ向けサービス企業である。
Salesforce.comが提供するクラウドサービスは、SaaS(Software as a Service)として提供される「SalesforceCRM」と、PaaS(Platform as a Service)として提供されるForce.comとに二分される。Force.comはSalesforceCRMの稼働を支える基盤でもあるが、当初はサービスとして一般開放されていなかった。欧米ではSalesforceCRMをそのまま利用する企業が多いとされ、Force.comのようなカスタマイズ自由度の高いサービスへの需要が希薄だったと推察される。実際、海外ではSalesforceCRMとForce.comの売上比率は90対10といわれている。一方、日本ではアプリケーションを自社の業務に合わせ高度にカスタマイズすることを好む企業が多く、Force.comは日本のエンタープライズ市場のニーズをくんでリリースされたものと考えられる。現在、日本国内において、SalesforceCRMとForce.comの売上比率は55対45とされている。

Force.comは2007年9月にリリースされたサービスである。これによっていわゆる「アプリ開発(高度のカスタマイズ含む)」が可能になり、従来のCRMやSFAを利用しつつその枠を超えたアプリケーションを開発・利用できるようになった。以下はForce.com上でのアプリケーションの事例である。
| 利用者 | 対象業務 | 特徴 |
|---|---|---|
| 官公庁 | エコポイントの申請受付、発行、交換 | 高い信頼性と可用性を求められる公的サービス。ピーク時には4000万アクセス/月を見込む。構築期間は2カ月といわれている |
| 大手コンビニエンスストア | 本部社員や加盟店オーナー、店員、取引先との情報共有 | 加盟店支援の仕組みと基幹系システムとを連携。オンプレミスの場合と比較して開発期間やコストが6分の1になったと推察される |
| 大手通信事業者 | 複数の外注業者等が関与する受発注管理業務 | 当初はSalesforceCRMを導入。その後の拡張をForce.com上で実施。ビジネスプロセスの変化に合わせ、アプリケーションを使い続けながらシステムの変更・機能追加を実現した |
以下、本稿では「企業向けシステム構築」というテーマに則し、Force.comに力点を置いて解説をする。
クラウド基盤を利用することで、インフラ面のキャパシティープランニング、機器調達・構築、テストなどが不要になり、開発期間が短縮されることが期待できる。これはパブリッククラウド利用の全般において享受できる共通のメリットだが、Force.comは、さらにアプリケーション開発自体も高速化できる点に特徴がある。
図は、さまざまなクラウド基盤におけるサービスの提供範囲をレイヤー別に示したものである。青系色の部分がクラウドによって提供されているサービス、白い部分はユーザーの作業である。Force.comは最も右側の赤点線枠部に位置すると掲げているが、図からも分かる通りこの領域では利用者による開発/運用の負担が小さいことが見て取れる。これはレイヤーの上位にある「統合エンタープライズアプリケーション基盤」が提供されていることに起因する。SalesforceCRMで培ったさまざまな業務アプリケーションの開発ノウハウがこの部分に蓄積されており、テンプレートや開発環境として提供されている。開発の際にはこの基盤を最大限活用することで、極めて効率の良い開発が可能になる。
例えばForce.com環境での開発は、従来型のJava環境やMicrosoft .NET環境での開発に比べ、生産性が5倍高いというリポートがある(2009年Nucleus Research調べ)。 この数字は、実際に開発に従事した弊社開発メンバーの実感としても決して大げさなものではないようだ。
Force.comでの開発はいわゆる「プロトタイピング手法」で進めることができる。開発中の画面を交えながらユーザーと打ち合わせし、その場でプロトタイピングを行うことで、仕様の細部を詰めながら同時並行的にシステムを作り上げていくことが可能だ。通常、1回当たり半日程度の打ち合わせを週1、2回、数週間〜数カ月にわたり実施するといわれている。この作業によりユーザーと開発者の認識の擦り合わせが即時に行われ、次々に仕様とアプリケーションがフィックスされていくため、極めて効率性が高く、手戻りの可能性も希少である。この手法は、業務がまだ固まっていない場合においても非常に有効だと考えられている。
SalesforceCRMは米国のセキュリティ監査基準である「SAS70 TypeII」を取得しており、当然、その基盤であるForce.comも堅固なセキュリティ基盤上にある。近年、日本の金融機関や地方自治体などでもForce.comの利用事例が増えてきているが、これらのユーザーがForce.comを利用する際の最大の理由がアプリケーション基盤もカバーする強固なセキュリティ基準であるとわれわれは推測している。実際「自社でシステムを抱えるよりも安心だ」という意見すらあるようだ。
パブッククラウド全般のメリットでもあるが、利用しなくなったシステムは簡単に廃棄できる。また利用停止後は原則として料金が掛からない。従来は、企業向けシステムにおいて「廃棄」を前提にシステム構築することは珍しかったが、今後はこのような利用が進みそうだ。例えば、新商品のキャンペーンや不具合製品のリコール対応などでは、短期間のうちにコールセンターを立ち上げ、一定期間の後にはクローズさせるなどの一過性の措置が必要と考えられる。Force.comを利用すればこのようなことは容易に実現できる。
これまで幾つかの大きなメリットを見てきたが、Force.comも万能ではない。下記のような点についてはあらかじめ留意する必要がありそうだ。
Force.comの「統合エンタープライズアプリケーション基盤」が、いわゆるテンプレートとなってシステムの早期立ち上げに貢献していると述べた。逆にいえば、テンプレートが用意されていない分野の業務アプリケーションをForce.com上で構築する場合には、このメリットを享受できない。例えば、営業支援、代理店管理、コールセンター業務、社内のワークフローなどを扱う業務についてはシステム構築が容易だが、ERP、会計、ECサイトなどの業務についてはまだまだこれからと言わざるを得ない。今後、基盤が強化され、業務の適用範囲は広がっていくだろうが、現状適用できる業務は限定的であり、構築前の見極めを正しく行うことが重要である。
Force.com上で作られる画面は、見た目も操作性も「SalesforceCRMによく似た」ものになる。それ以上の「凝った画面」を望む場合は作り込みに工数が掛かり、結果的にForce.comを使うメリットが得られなくなる。特に日本のユーザーは「かゆいところに手が届く」ようささいな仕様の作り込みにこだわる傾向が強いが、Force.comの根本思想とは相いれないので、留意が必要である。
Force.comは原則としてユーザー数(named)に応じた課金体系を採用している。例えば以下のような場合には注意が必要だ。
(1)季節性の高いシステムを何年も使うような場合
AWSやGoogle App Engineのように、「リソースを利用した分だけの課金」ではないので、利用頻度にかかわらず登録ユーザー数で課金される。オンプレミスで専用システムを構築した場合と比べコスト高になる恐れがある。
(2)ユーザー数が著しく多い場合
利用総額が膨大になる可能性がある。例えばユーザー数が1000人であれば、利用料は月間1500万円、年間1億8000万円に達してしまう。5年利用することを考えるとかなり割高感があることは否めない。
もちろん、ある程度以上の規模のユーザー数を想定したシステムをオンプレミスで高品質に開発するには相当の期間が必要であり、リスクも大きい。ハードウェア類の維持・管理・運用などのコストも無視できないだろう。高品質アプリを低リスクで短期開発可能で、かつインフラ維持に気を遣わなくて済むForce.comは、そうした意味では圧倒的に有利といえる。開発のための社内稟議(りんぎ)などを上げる際には、見かけの費用総額を単純比較した判断に陥らぬよう、前述のようなメリットを訴求する必要があるだろう。
Force.comは複数のユーザー企業が相乗りして利用するPaaS基盤である。全ユーザーに安定したパフォーマンスを保証するために、個々のプログラムにはさまざまな制限が課せられている。アプリケーション実行時には「ガバナ制限」と呼ばれるルールがあり、これを超えるとプログラムが正常に動作しない恐れがある(表に主要な例のみ記載。ほかにも多数ある)。一見すると余裕があるように感じられるが、多少込み入ったアプリケーションであれば簡単に抵触してしまうケースもみられる。
| 1プログラム辺りの制限内容 | 上限 |
|---|---|
| SOQL*クエリの発行回数 | 100 |
| SOQLクエリ(複数)によって取得できるレコードの総数 | 10,000 |
| プログラム実行ステップ数 | 200,000 |
※SOQLとは、Salesforceのデータベースとやりとりする独自クエリ言語
ガバナ制限以外にも、利用できる文字数の制限(1クラス当たり10万文字)や、1組織当たりのプログラムサイズの制限(1Mバイト)、テンポラリファイルの作成ができないなど、さまざまな制限がある。アプリケーション開発者は、これらの制限をあらかじめ熟知し、意識しながら設計およびコーディングする必要がある。
Force.comは、基本的にオンラインのリアルタイム処理を意識したプラットフォームであり、夜間にまとめてデータ処理を行うようないわゆる「バッチ処理」については、まだまだ改善の余地がある。最近、機能が追加されApex(後述)のスケジューリングが可能になったものの、実行速度は(通常のバッチ処理との比較において)著しく遅く、大量データの一括処理には向いていないとされている。どうしても高速なバッチ処理が必要な場合には、バッチ処理用のサーバを別のクラウドサービス上か、あるいはオンプレミス環境内に用意し、Force.comとWeb Service APIなどを通してデータ連係しながら処理するといった工夫が必要である。
Force.comでもデータベースは利用でき、SQLに似たSOQLというクエリ言語も用意されている。しかしながら通常のRDBではないため、ジョインやインデックスの作成などRDBであれば適用可能な各種テクニックに制限があり、最初からこのような特性を意識して設計・開発する必要がある。特にレスポンスが思わしくないからといって、事後的にパフォーマンスチューニングなどで速度を稼ぐような手法は通用しない。複雑な処理を組み込む必要がある場合には、一定のノウハウを持ったベンダーの協力が不可欠だろう。
Force.com上でのプログラミングは、現在はJavaライクな独自スクリプト言語「Apex」しか利用できない。Javaも利用可能になるというアナウンスもあるが、リリースは2011年とされている(後述)。Apex自体の習得は難しくないとはされているが、現段階では(ほかの開発言語と比較して)プログラマーの調達は平易ではないといってよいだろう。
以上、Force.comを利用する上でのメリットおよび留意点を概観してきた。なおSalesforce.comは少なくとも年3回のバージョンアップを実施し、新機能の追加と改善を繰り返している。2010年も既に2回の新バージョンがリリースされ、ガバナ制限の一部廃止や、データベースクエリの強化が盛り込まれた。新たなサービスとしてSalesforce Chatter(Force.com上で稼働するFacebookのようなもの。企業内でのノウハウの流通に利用できる)が正式にリリースされ、既存ユーザーの間で利用が始まっている。VMForce(Force.comを使ったJavaアプリケーションのPaaS)構想や、東京データセンターの開設もアナウンスされている(いずれも実現は2011年の予定)。機能追加に懸ける同社の執念にはすさまじいものがあり、より高度なエンタープライズクラウドコンピューティングの実現に向け、一層進化していくものと期待できよう。
次回は、Google App Engineを取り上げる。
システム開発のPMやビジネスコンサルタントなどを経て、現在は自社内のビジネス企画に従事。クラウドに軸足を置いて調査、企画、情報発信、営業支援、および社外とのアライアンスを担当する。