基盤技術で占うSaaSの未来第1回

データ連携

   私が、SaaSとASPが一番大きく違うと考える点は、SaaSは複数ベンダーの製品をポータルサイトとしてサポートする構想を持っていることだと考えています。1つのSaaSサイトの中には複数かつ競合するアプリケーションが多く含まれます。ユーザは、その中から自社に合ったサービスを選択して利用します。

   例えば、先月まではSFA（Sales Force Automation、営業支援システム）と会計を使い、今月からはそれに加えて販売管理とBI（Business Intelligence、データ分析ツール）を利用するというような使い方です。

   このように複数アプリケーションを利用する際、各アプリケーション間のデータ連携ができていないと非常に不便です。例えば販売管理と会計で仕訳トランザクションデータの連携ができていないと、販売側で発生した「売上」や「仕入」などの処理を伝票に印刷し、会計側の仕訳入力で再度手入力しなければなりません。

   データ連携が必要なのは、SaaSサイト上のアプリケーション間だけとは限りません。通常、ユーザは自社システムを持っており、そこでカバーできていない一部のアプリケーションをSaaSに求めることになります。つまり、このような外部システムとのデータ連携を行うためのEDI（Electric Data Exchange、データ交換ツール）機能も求められます。

   Best of Bleed時代を標榜するSaaSポータルサイトでは、このような各製品間のデータ連携や既存システムとのデータ連携をスムースに行うことができる仕組みが必要になります。

開発環境（API、開発ツール、カスタマイズ性）

   アプリケーションには、SaaSで提供されやすいサービスとそうではないものがあります。

   たとえばSFAやグループウェアなど非基幹業務ソフトは、仕組みがシンプルでありSaaSに載せやすい部類でしょう。基幹業務の中でも、会計や給与計算などカスタマイズがあまり発生しない業務システムがSaaSにサービスインしやすいと考えられます。

   一方、生産管理業務や販売・在庫管理業務など、複雑で企業ごとに異なる大型業務システムは、SaaSに載せにくい代表格です。

   ASPやSaaSの中には、パッケージソフトウェアを「利用形式」でサービス提供するモデルがあります。基となるソフトウェアはパッケージとして成熟しており、完成度や顧客満足度の高さを備えています。ユーザごとの異なる要求仕様に対しては、パラメータ調整やある程度のカスタマイズ機能で対応できる仕組みを用意します。

   しかし一方で、SaaS化した際にデータ連携やマスタ一元化、共通機能の共有など、全体として統合しにくいという問題もあります。そのため、SaaS上に新たなアプリケーションを作成するための開発ツールや連携のためのAPIを用意するケースも増えています。

   既存製品のサービスインではなく、提供される開発環境を使って新規にSaaS用にアプリケーションを構築するという構想は1つの理想です。しかし、既存の有力製品と対抗できるような優れたアプリケーションを作るのはそんなに簡単な作業ではありません。

   現実的には既存製品のサービスインが主、それを補なう新規サービス構築が従という関係で初期のSaaSは発展していくと思われます。

IT環境

ASPからSaaSの間には、約8年もの年月が流れています。当然、サイトを取り巻くIT技術基盤も大きく進化しており、「Web 2.0」というキーワードで総称されるAjaxをはじめとしたさまざまな技術がSaaSの作りに数多く取り入れられています。

ただし、見誤って欲しくないのは、これらはあくまでもSaaSを支えるための基盤技術であり、SaaSの花形スターはあくまでもアプリケーションなのです。確かに、サービスを支える基盤技術があってこそスターが輝くわけですが、あまりに基盤ばかりが議論されていると、ユーザを置き去りにしているように感じることがあります。

次回は

   一般にパッケージソフトは、バージョン1.0で大ヒットすることはまれです。ユーザニーズをフィードバックし、認知度がじわじわ拡大し、販売体制も整備したバージョン 2.0か3.0からが本格的な普及期になります。

   SaaSがASP 2.0だとしたならば、同じようにこれからが成功を収める段階なのだと思えます。

   その成功を収めるための1つの方策として、次回は「MIJS（Made In Japan Software Consortium）の考えるSaaS」について解説します。