セールスフォースの提供するSaaSは従来のASPとは異なる。なかでも特筆すべきは、ASPが抱えていたカスタマイズの難しさや、外部のアプリケーションとのデータ連携、 システムの信頼性への疑問といった問題点を解決したことだ。セールスフォースの凄みといってもよい。すでに、みずほグループに加え、ANAラーニング、NTTソフトウェアといった国内企業でも利用が進んでいる。

日経コンピュータ2006年4月17日号の記事を原則としてそのまま掲載しています。執筆時の情報に基づいており現在は状況が若干変わっていますが、SaaSやEnterprise2.0の動向に興味のある方に有益な情報であることは変わりません。最新状況は本サイトで更新していく予定です。

 今回は、セールスフォースのサービスを通じ、SaaSと従来のASPの違いを詳しく見ていこう。

ここまでできる(1) 画面要素の変更は自由自在

 ユーザー・インタフェースを自由に変えたり、データベースに項目(フィールド)を自在に追加したりできる。これがSaaSの重要な要素だ。簡単なことのように思えるかもしれないが、単一のアプリケーションを複数の企業ユーザーが共用するASPでは、カスタマイズの幅は決して大きくない。

 Salesforceの場合、画面上部の「タブ」で、作業画面を切り替える。実は、タブを追加したり、タブ の名称を変更する機能は、2004年4月にようやく実現した。それまでは基本項目については、カスタマイズできなかった。

 現在のSalesforceは、テーブル自体の追加や、テーブルの項目の追加・変更が自由。最大50のテーブル、2000の項目を追加・拡張できる。もちろん、データベースを参照・更新する作業画面のレイアウトも自在に変更可能だ。

 では、ASPモデルではできなかった大幅なカスタマイズをどのように実現しているのだろうか。Salesforceは、ユーザー・インタフェースや他のアプリケーションとの連携に必要なユーザー固有の情報を「カスタム情報テーブル」にまとめている。ユーザーがSalesforceにログインすると、カスタム情報テーブルを基に、ユーザー・インタフェースを作成したり、アクセスできるテーブルを制限したりする(図2)。アプリケーションは単一だがメモリー上に展開する際に、カスタマイズ情報を読み込むことで、あたかもユーザー専用のアプリケーションのように振る舞う。

図2●AppExchangeプラットフォームがサードパーティに提供する機能
図2●AppExchangeプラットフォームがサードパーティに提供する機能

 2004年4月までカスタマイズに対応しなかった理由について、セールスフォース・ドットコムの榎隆司 製品・サービス・技術統括本部長は、「Salesforceの事業が立ち上がって間もなく、ユーザーが少ない段階でシステムを増強するのはリスクが大きかった」と説明する。ユーザーごとにカスタマイズしたアプリケーションを動かすには、サーバーのCPUやメモリーの増強が必要になる。データ項目の追加を可能にするには、ディスク容量も増やさなければならなかった。2003年以降に大企業ユーザーが増え、カスタマイズのニーズが高まったため、必要なシステム増強に踏み切った。

ここまでできる(2) サードパーティ製アプリと連携

 ユーザーがASPに対して感じていた不自由さはカスタマイズだけではない。ASPモデルではベンダーが異なるアプリケーション間の連携は難しく、データをやり取りする場合、CSV形式のファイルなどを介するのが一般的だ。複数のアプリケーションを組み合わせてビジネス・プロセスをつくったり、データの転記を自動化したりする機能はSaaSの必要条件である。

 AppExchangeでは、Salesforceのデータベースを介してアプリケーション間でデータを連携する。例えば、企業情報の検索サイトで取引先候補のリストを作り、その取引先の企業情報を別のアプリケーションから呼び出して、Salesforceのデータベースに書き込むといった連携が可能だ。

 アプリケーション間で、データベース内の同じテーブルを参照・更新する場合は、すでにリアルタイムでデータを連携できる。一方、アプリケーション間で複数のテーブルを連携する場合は、現在のところトランザクション管理はできない。「2006年のバージョンアップで、トランザクション管理機能を提供する計画」(榎本部長)である。

DBアクセスのAPIを公開

 サードパーティがデータ連携できるアプリケーションをつくれるように、セールスフォースはSalesforceのデータベースにアクセスするためのAPIを公開している。APIは現在、(1)サービスへのログイン、(2)データ検索、(3)データ追加・更新処理、(4)パスワードやユーザー情報などの設定、(5)データの同期、(6)ユーザー・インタフェースなどの定義情報の取得――の6種類そろっている。

 実際のデータ交換は、XML(拡張マークアップ言語)と、Webサービス用の通信プロトコルであるSOAP(Simple Object Access Protocol)を使う。セールスフォースは年内をめどに、連携するアプリケーション側から、Salesforceのデータベースにテーブルや項目を追加できるAPIも公開する予定だ。

 これらのAPIは、Java、C#、Visual Basic、ASP.NET、PHP、Perl、Rubyの7種の開発言語で用意している。アプリケーション開発を容易にするため、ボーランドのJBuilderや、オープンソースのEclipseといった統合開発ツール向けの開発モジュールも提供している。

料金によって連携本数に制限

 ユーザーがSalesforceと連携して使えるアプリケーションの本数は、月額料金によって異なる。月額7500円のProfessional Editionは5本まで、同1万5000円のEnterprise Editionなら10本までという制限がある。同2万4000円のUnlimited Editionならば、有料・無料のアプリケーションを無制限に組み合わせて使うことができる。

 企業情報や地図情報、セミナー管理などは、サードパーティの有料サービス提供が始まっている。アプリケーションは4月初旬の段階で約300種類(日本語版は約30種類)まで増えた。ソフトベンダーは、AppExchangeの環境を使えばコストをかけずにSalesforceユーザーを取り込むことができるが、現在国内で提供しているアプリケーションのメニューは大半がセールスフォースの無料ソフト。AppExchange本来の機能を発揮するには、受発注や生産管理、在庫管理、会計など基幹システムを担うアプリケーションの充実が欠かせない。「そのためにAPIも公開したし、ベンダー会を組織してサードパーティ向けの講習会も始めた」と、セールスフォース・ドットコムの山本哲也経営企画本部長(当時)は技術情報開示の狙いを説明する。

ユーザーの独自アプリも連携

 多くのユーザー企業にとっては、既存の業務アプリケーションとの連携機能も必須である。AppExchangeでは、サードパーティ製に加え、ユーザーの独自アプリケーションも連携の対象としている。データ連携のためのAPIや開発モジュールをユーザー企業に公開しているだけでなく、テスト環境まで提供している。

 オンデマンド・アプリケーションは基本的に24時間365日稼働しているため、自社開発のアプリケーションを組み合わせた環境でのテストができない。

 セールスフォースは2006年1月、ユーザーが独自の環境で動作を検証できるサービス「Salesforce Sandbox」を発表した。ユーザーが実際に使っているデータベースやユーザー・インタフェース、独自に開発したアプリケーションなどを、丸ごとコピーし、本番と全く同じテスト環境で動かす。サーバーの構成も本番環境と同じだ。このサービスのために、セールスフォースはテスト専用の巨大なデータベース・サーバーを用意した。

ここまでできる(3) 稼働情報をリアルタイムで公開

 企業情報システムの一部としてSaaSを使うには、セキュリティや性能問題がネックになる。これまでのASPは、システムの信頼性に関する情報開示が必ずしも十分とは言えなかった。ブラックボックス化していることも少なくない。この点はどうなっているのか。

 セールスフォースはユーザーの不安を払拭するため、2006年2月にシステムの稼働状況を一般公開するWebサイト「Trust.Salesforce.com」を立ち上げた(図3)。

図3●システムの稼働状況を公開するWebサイト
図3●システムの稼働状況を公開するWebサイト  [画像のクリックで拡大表示]

 そのサイトを見ると、地域ごとに表示した緑と赤のマークがまず目に入る。緑は正常稼働を、赤は障害発生を意味する。赤のマークをクリックすると、障害が発生した時間帯や障害の内容、復旧の見通しや復旧方法の解説画面がポップアップする。1日のトランザクション数やシステムの平均応答速度も表示している。あたかも自社システムの運用管理画面を見るかのように、状況を把握することができる。

 セールスフォースがここまでの情報公開に踏み切ったのは、2005年12月20日に発生したシステム障害がきっかけだった。合計5時間もの間、システムにアクセスできない状態が続いた。米国で大手金融機関などの大口顧客をつかみ始めていただけに、信頼性に対する不安をぬぐい去るのがセールスフォースにとって最優先の課題となった。

データセンターを3カ所に分散

 セールスフォースは信頼性向上に向け、データセンターを分散させた。同社は、サンフランシスコのデータセンター1カ所で全世界にサービスを提供していた。システムを集中することが、効率化に不可欠だったからだ。

 今回の障害を機に、同社は約60億円を投じて、バージニア州とカリフォルニア州にバックアップ用のデータセンターを新設。システムが停止した際には自動的に処理を引き継げるよう、ディザスタ・リカバリの体制を整えた。

 同時に、データベースの稼働領域(インスタンス)も顧客の地域ごとに分け、さらにそれらを複数のデータベース・サーバーで並行稼働させる構成に変更した。Oracleのクラスタリング機能である「Oracle Real Application Clusters」を採用。データベースの領域を「北米地区」、「アジア太平洋地区」、「EMEA(欧州、中東、アフリカ)地区」、「テスト用」の四つに分けている。例えば、北米地区のデータベースに問題が発生した場合、他の地域のユーザーは影響を受けることなく、北米用の領域だけを止めたり、再起動したりできる。

 このような対策を施した背景には2005年後半から顕在化していたシステムの性能問題もある。ユーザーの増加に加え、AppExchangeによるデータ連携によって、システムの負荷が高まっていたのだ。データベースの処理全体に占める割合を見ると、API経由は2005年までは約2割だったのが、2006年3月には約4割まで増えた。しかも、「ユーザーがSalesforceと自社の基幹系システムを連携させた場合、どれくらいの頻度でSalesforceのデータベースにアクセスするのかは予測不可能。システムへの負荷が読めない」(榎隆司本部長)という事情もあったという。

 ただしユーザー企業から見た情報開示には、不十分な面もある。例えばSalesforceシステムの詳細な構成は、「競合の問題などから非公開」(同社)。自営のシステムと同等の運用性を提供するには、まだ課題がある。

▼SaaS活用例(1) ANAラーニング

 SaaSの活用事例も登場した。企業向け研修サービスのANAラーニングは、Salesforceの拡張機能を使って、わずか2カ月、500万円の投資で、研修業務の商談管理や見積書・請求書の作成、講師の手配といった一連の業務システムを構築した(図4)。

図4●ANAラーニングが開発した研修管理システム
図4●ANAラーニングが開発した研修管理システム

 同社がSalesforceを導入したのは2003年4月。当時、カスタマイズやアプリケーション連携の仕組みはなく、ANAラーニングは講師や顧客情報をSalesforceで管理し、見積書や精算伝票などの帳票の作成は表計算ソフトによる手作業でこなしていた。社員は見積書や注文書と同じデータをSalesforceに再度入力しなければならなかったのである。「伝票の作成を優先しがちで、Salesforceのデータ更新が遅れていた。最新の顧客情報や商談の進捗が把握できないこともあった」と飯塚慶乃 事業部営業企画グループリーダーは振り返る。

 2005年8月、ANAラーニングは研修管理業務のシステム化を決断。受講者や講師を管理できるようにしたり、見積書や請求書を作成・管理するアプリケーションを新規に開発した。「標準で備わっているアプリケーションやデータベースを流用できるため、新規に開発したのは全体の1割程度。開発工数や期間を大幅に削減できた」と、システム開発を担当したヘッド・ソリューションズの佐藤秀哉社長は明かす。

▼SaaS活用例(2) NTTソフトウェア

 SaaSと基幹系システムを連携する事例もすでにある。NTTソフトウェアは2005年8月、SalesforceとSAP R/ 3を連携し、商談の進捗と、システム構築受注後の収支を管理するシステムを構築した。

 このシステムでは、Salesforceで管理する商談情報と、SAP R/3にあるプロジェクト情報の管理番号を統一し、それぞれのデータを関連づけた。双方の情報を基に、プロジェクト・マネジャが赤字プロジェクトの原因を商談時点にさかのぼって探ったり、過去の案件を基に営業担当者が受注前に収益を推定できるようにした。

 ただし、SalesforceとSAP R/3を連携するためにNTTソフトが費やしたコストは、決して小さくはない。データ連携のためにEAIソフトとしてウェブメソッド社の「ウェブメソッド」とアプレッソの「データスパイダー」を導入した。いずれも500万円以上するソフトである。EAIソフトからSalesforceのデータベースにアクセスするためのモジュール(アダプタ)も自社開発している。

 「セールスフォースがAPIを公開したメリットは確かに大きい。しかし、ERPパッケージなどの基幹システムとSalesforceを連携させるには、それなりの投資を覚悟しなければならない」と、システム構築を担当したエンタープライズソリューション事業グループの田沢久EAI&BAMプロデューサーは打ち明ける。

反応し始めたパッケージ・ベンダー

 SaaSが、かつてのASPモデルから大きく進化した存在であることは、お分かりになっただろう。実は、セールスフォースがAppExchangeに込めた戦略は、アプリケーション間のデータ連携などソフトウエアとしての機能を高めることだけではない。

 米セールスフォース・ドットコムのジム・スティール社長は、「ニッチなものも含めて、1万本を超えるアプリケーションをAppExchangeのWebサイトにそろえる。企業ユーザーが必要とするアプリケーションはすべて手に入る場所にする」と意気込む。Salesforceが核となって、アプリケーション同士をつなげ、ユーザー企業をSaaSの世界に引き込もうとしているのだ。次章では、そんな風向きの変化を感じてSaaS市場に向かい始めた大手パッケージ・ベンダーの動きを追う。

厳しい安全性チェックを経てメガバンクも採用

 勘定系はもとより、末端の店舗システムまで、自前の開発にこだわるメガバンク。その一角であるみずほグループで、Salesforceが初めて採用された。第1号ユーザーとなったのが、資産5億円以上の富裕層に絞って金融コンサルティング・サービスを手掛ける「みずほプライベートウェルスマネジメント」だ。

 邦銀初のプライベート・バンクの構想が持ち上がったのが2005年5月。11月の開業まで、与えられた時間は半年もなかった。ただ、みずほプライベートは事業会社であり、いわゆる銀行のシステムは必要ない。開業までに用意しなければならなかったのは、グループの銀行、信託銀行、証券にまたがる資産管理状況報告書を作成、顧客の手元に毎月届ける顧客管理システムだった。ところが、付き合いのあるベンダーに打診しても、時間的な問題の解決策は見あたらない。そこで出会ったのが、Salesforceだった。

写真●富裕層をターゲットにしたみずほプライベートウェルスマネジメントの応接室
写真●富裕層をターゲットにしたみずほプライベートウェルスマネジメントの応接室

 みずほグループでの実績は当然ゼロ。グループ幹部にSalesforceの仕組みを説明しても、「大丈夫か? という反応がほとんどだった」(長野和郎副社長)。銀行側が最も心配したのは、システムの安全性。海外の、しかも一般企業と共同利用する施設で顧客情報を管理するなど銀行にとっては前代未聞だったのである。

 そこで、グループのみずほ情報総研の担当者に現地に飛んでもらい、セキュリティ面を詳しくチェックした。具体的には、金融情報システムセンターの「金融機関等コンピュータシステムの安全対策基準」や、みずほフィナンシャルグループのセキュリティ・ポリシーを基に、約300項目について検査した。

 指紋認証装置や監視カメラによる入退室管理といった設備面のほか、ITIL(ITインフラストラクチャ・ライブラリ)に即した運用ルール、運用保守の操作ログの記録状況などをチェック。データセンターがセキュリティ認証「ISO1799/BS7799」や、内部統制をみる規準「SAS70(Statement on Auditing Standards No.70)」に基づく監査を受けていることも確認、SaaS利用にゴーサインを出した。みずほ情報総研のお墨付きが出てようやく、グループ発足以降初めての新規事業会社が立ち上がった。