Part3 アーキテクチャがもたらす特性を理解しSaaSの真の実力を知る

成熟度で知るSaaSの本質

「SaaSとASPは同じもの。単に、マーケティング的な要請から新しい名前を付けたにすぎない」－。 日本ではいまだに、そんな誤解がまかり通っている。しかし、SaaSがビジネスにもたらすインパクトはASPの比ではない。 パート3では、SaaSのアーキテクチャを解説し、その意義を伝える。

「SaaSとASPはどう違うんですか？」－。これは、SaaSという言葉がよく聞かれるようになった2006年ごろから、筆者が最も多く受けた質問である。

総務省主催の「ASP・SaaSの情報セキュリティ対策に関する研究会」が取りまとめた「ASP・SaaS情報セキュリティガイドライン」では、ASPとSaaSを「ともにネットワークを通じてアプリケーション・サービスを提供するものであり、基本的なビジネスモデルに大きな差はない」とし、特に区別していない。総務省とASPIC（ASP・SaaSインダストリ・コンソーシアム）による「『ASP・SaaSの普及促進策に関する調査研究』報告書」にも、「『ASP』を『ASP・SaaS』と同義語として用いる」と明記されている。

上記のような抽象化したレベルで定義すると、ASPとSaaSに違いは出てこない。確かに、「ソフトウェアの機能をインターネットを通じて提供する」というコンセプトは両者に共通する。しかし、1999〜2000年ごろにブームになったASPと、ここ1〜2年で急激に注目を集めるようになったSaaSでは、そのアーキテクチャや機能面に大きな違いがある。筆者は、「ASPの進化型がSaaSである」ととらえるのが適切と考えている。

SaaSの肝はアーキテクチャにあり

では、ASPとSaaSの違いは何だろうか。最も重要なのは、「シングルテナント」のアーキテクチャだったASPに対して、SaaSは「マルチテナント」のアーキテクチャを備えている点だ（図3-1）。

図3-1　シングルテナントとマルチテナントの違い

かつてのASPの多くは、顧客ごとにサーバー環境を割り当てるシングルテナント形式だった。少数ユーザーの顧客に対しても、サーバーやデータベースを個別に割り当てていたため、コスト効率が悪かった。

これに対し、SaaSでは複数のユーザーがサーバーやデータベースをシェアするマルチテナント・アーキテクチャを採用する。これにより、ベンダーは設備投資や運用管理費用を抑え、スケールメリットを最大化できる。そしてそれは、ユーザーに対して比較的安価な月額料金でサービスを提供することにつながる。

さらに、SaaSでは全ユーザーが同じバージョン、同じコードベースのプログラムから成るソフトウェアを使用する。これを、「シングルインスタンス」と呼ぶ。シングルインスタンスの採用により、ベンダーはソフトウェアの設計・開発作業を劇的に効率化できる。ユーザーが所有する多種多様なプラットフォーム環境を想定して設計・開発しなければならないパッケージソフトと異なり、自社のサーバー環境だけを想定して設計・開発すればよいからだ。

バージョンアップ作業の負荷も大幅に軽減される。たった1つのプログラムをバージョンアップすれば、全ユーザーのプログラムをバージョンアップしたことになる。このため、頻繁にバージョンアップして常に最新機能をユーザーに提供できる。例えば、セールスフォース・ドットコムは、アプリケーションを1年に平均3回もバージョンアップしている。

メタデータでユーザーによるカスタマイズを容易に

これまでに述べたマルチテナント・シングルインスタンス以外にも、SaaSとASPには違いがある。

第1は、カスタマイズのしやすさである。従来のASPは基本的に、ユーザー自身がアプリケーションをカスタマイズすることは不可能だった。しかし、SaaSではユーザーごとのカスタマイズ情報を記録した「メタデータ」を利用し、ユーザー自身が個別にカスタマイズできる。この仕組みにより、ユーザーは項目の追加やページレイアウトの変更、ビジネスフローの改変、データモデル（フィールドやテーブル構成など）の拡張を設定変更レベルの容易さで実施できる。メタデータはアプリケーションサーバーとは別に用意したデータベース上に保持されるので、システムをバージョンアップしてもそのまま引き継げる。

外部アプリケーションとの連携という点でも、SaaSとASPは大きく異なる。従来のASPの場合、既存アプリケーションとの連携はファイル転送ベースの単純なデータ統合インタフェースの利用が主流で、洗練されたものとは言えなかった。一方、SaaSでは、既存アプリケーションやSAP、Oracleなどのパッケージ・アプリケーションとの連携を可能とするAPI（アプリケーション・プログラミング・インタフェース）が提供されているケースが多い。

このように、SaaSはマルチテナント・アーキテクチャによりスケールメリットを最大化しながらも、メタデータによってユーザー側でのカスタマイズ性を大幅に高めた点に大きな特徴がある。図3-2にSaaSと従来のASPの違いをまとめたので、参考にしてほしい。

SaaSの成熟度モデル〜ASPからPaaSまで

一口にSaaSといっても、現在の日本市場に氾濫する“自称SaaS”の成熟度はまちまちである。単にソフトウェアをベンダー側でホスティングし、料金体系をライセンス販売からサブスクリプション形式に変更しただけのものから、マルチテナント・シングルインスタンスを実現し、設定変更レベルでカスタマイズを可能にしているもの、さらにサードパーティ製アプリケーションとの連携を可能とするものまで多岐にわたる。賢いユーザーとなるには、ベンダーが提供するSaaSの成熟度も理解しておくべきである。次ページの図3-3にSaaSの成熟度モデルを示す。

図3-3　SaaSの成熟度モデル（図をクリックで拡大）

レベル1は、広義のSaaSにおいて最も初期の段階である。顧客ごとにサーバーやデータベースなどの環境を割り当て（シングルテナント）、顧客ごとに異なるソフトウェアを稼働させる（マルチインスタンス）。顧客側ではカスタマイズできない。アプリケーションに追加や修正を加えたい場合、顧客はベンダーに別途料金を支払ってカスタマイズを依頼する必要がある。こうしたレベル1の段階にあるSaaSはむしろ、ASPと呼ぶほうがしっくりくるだろう。

レベル2は、顧客ごとに異なるソフトウェアを一括して運用管理するモデルである。基本的なアーキテクチャはレベル1とほとんど変わらず、ユーザーが期待するような設定変更レベルでのカスタマイズは困難だ。既存アプリケーションとの連携も、ファイル転送ベースの単純なデータ統合インタフェースの利用にとどまる。

レベル3は、レベル1やレベル2から大きく進化したモデルである。マルチテナント・シングルインスタンスで設計されている。メタデータを利用して、ユーザーごとに個別にカスタマイズしたサービスも提供できる。

このレベル3をさらに進化させ、Webサービス技術を利用して他のアプリケーションとの連携用プラットフォームを提供する段階が、レベル4である。マルチテナントのアーキテクチャを実装しているため、連携対象のアプリケーションがあたかも同じコンピュータ上にあるかのように簡単に実行できる。

レベル5は、最も成熟したSaaSの形態である。このレベルに達したSaaSは、ユーザーによるカスタマイズ範囲をユーザーインタフェースやデータモデル（フィールドやテーブル構成など）にまで広げる。加えて、全く新規のアプリケーションを開発するための汎用的な開発プラットフォームも提供する。このレベルに達したSaaSは結果的に、後述するPaaS（プラットフォーム・アズ・ア・サービス）を提供していることになる。

国内ベンダーはアプリケーション設計から見直すべき

現在、米国でSaaSと呼ばれているサービスの基本形は、レベル3である。セールスフォース・ドットコムはレベル3からスタートし、その後も年々進化を続けて現在はレベル5にまで到達している。米国発のSaaSベンダーのもう1つの代表格であるネットスイートもレベル3からスタートし、現在はレベル4の段階にある。

一方、国内ベンダーが提供しているSaaSを見ると、その多くはまだレベル1〜2にとどまり、レベル3に達しているサービスは限られる。筆者が現在の日本のSaaSブームに対して危惧を感じるのは、まさにこの点である。

と言うのも、レベル1や2と言えば、かつてASPと呼ばれたサービス。ユーザー数が増加してもスケールメリットは出ないし、かと言ってユーザーが少ないままでは売り上げの絶対額が上がらず、ビジネス的なうまみは少ない。つまり、このレベルにあるサービスはユーザーがSaaSに期待する要件を満たさないばかりか、事業の継続性に疑問符がついてしまう。

実は、オラクルやマイクロソフトといった米国の大手パッケージベンダーは、SaaS参入に際し、自社のパッケージソフトをマルチテナント・シングルインスタンスに書き換える作業を進めている。こうした作業は手間はかかるものの、長期的にみて、SaaSビジネスの成功には欠かせない。

現在のSaaSブームの立役者であるセールスフォース・ドットコムと日本の多くのSaaSベンダーのサービスでは、スタート時点から差がついているうえに、その進化のスピードにおいても大きな差があると言わざるを得ない。日本のベンダーは安易にSaaS市場に参入せず、基本に立ち返ってアプリケーションの設計から見直すべきだ。それは必ず、ビジネスの成功につながるはずである。

インフラと経験生かしてPaaSも米国勢がリード

大手SaaSベンダーはここへ来て、PaaSビジネスに注力していくことを宣言している。PaaSは、SaaSベンダーが自社アプリケーションのプラットフォーム部分もサービスとして提供し始めたことで生まれた。その代表例が、セールスフォース・ドットコムの「Force.com」である。

PaaSとSaaSの違いは簡単に言うと、ベンダーが所有するITリソースのうち、どこまでをインターネット上のサービスとして提供するかにある（図3-4）。SaaSの場合、ハードウェアからOS、ミドルウェア、アプリケーションのすべてがインターネットの向こう側にある。これに対して、ベンダーがPaaSにおいて提供するのは、ハードウェアやOS、CPU、ミドルウェア。アプリケーションではなく、アプリケーションの稼働環境を貸し出すわけだ。

図3-4　SaaSとPaaSのサービス提供範囲の違い

米国のSaaSベンダーはこれまで、安定したサービスを提供するためインフラに多額の投資をしてきた。PaaSに関しても、自社のサービスを支えてきた基盤としての実績が豊富だ。日本の大手ベンダーや通信業者の間にもPaaSを提供しようという機運が高まっているが、SaaSだけではなくPaaSでも既に差がついているということは認識しておくべきだろう。