 |
||||||||||||||||||||||||
|
||||||||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
| 従来のASPの課題を解決したSaaS | ||||||||||||||||||||||||
|
アーキテクチャ面以外では、従来のASPが抱えていたカスタマイズの問題とアプリケーション連携の問題を解決したのが大きい。 パッケージアプリケーション導入の際によくいわれるように、業務アプリケーションがカスタマイズなしで利用されるケースはほとんどないだろう。従来のASPと違い、SaaSではコンフィギュレーションなどにより、個々のユーザの要求に合わせたタブ名称の追加や、新しいフィールドの追加などのカスタマイズが比較的容易に行えるようになっている。 従来のASPが抱えていたもう1つの大きな課題が、他のアプリケーションとの連携性だ。この点においてもSaaSでは大幅に向上している。SaaSでは、顧客企業の既存アプリケーションやSAP、Oracleなどのパッケージアプリケーションとの連携を可能とするAPIがベンダーから提供されているケースが多い。 また、後述するSalesforce.comの「AppExchange」のように、SaaSアプリケーションと連携して動作可能なアプリケーションを他社が構築できるプラットフォームが提供されているケースもある。もちろん、複数のアプリケーションにわたって、リアルタイムにデータ連携を行うようなケースでは簡単にはいかないが、以前のASPと比べれば格段の進化といえるだろう。 SaaSと従来のASPの違いをまとめると表2のようになる。
表2:SaaSと従来のASPの違い このようにASP 2.0と呼ぶべき現在のSaaSは、シングルインスタンス、マルチテナントによりスケールメリットを最大化しながらも、ユーザ側でのカスタマイズ性を大幅に高めた点にポイントがある。しかしながら、サーバやデータベースを他社と共有することに対して、ユーザ側から不安の声があるのも事実であり、いかにこのバランスをとっていくかが、今後SaaSベンダーにとっての大きな課題となるであろう。 |
||||||||||||||||||||||||
| SaaSに分類されるアプリケーション範囲 | ||||||||||||||||||||||||
|
一般的にSaaSの代表的なアプリケーションというと、Salesforce.comに代表されるCRMを真っ先に思い浮かべる読者が多いだろう。 しかし、その一方で、Googleが提供する「Google Docs & Spreadsheets」やThinkFreeの「Office Online」などのワープロや表計算ソフト、あるいはMicrosoftの「Office Live」やGoogleの「Google Apps for your Domain」などのようにメールやカレンダーソフトなど、インターネットを通じて無償、あるいは有償で提供されるサービスもSaaSの範疇に含まれるのかどうか、疑問に思われる読者の方も多いのではないか。 筆者はこうしたインターネットサービスもシングルインスタンス、マルチテナントのアーキテクチャであり、個々のサービスごとに違いはあるものの他のアプリケーションとの連携も可能であることから、SaaSと呼んで差し支えないと考えている。 しかしながら米国では、こうしたオフィスアプリケーション（Microsoftのサービス以外）をSaaSモデルで提供するサービスは「オフィス 2.0」と特別な名称で呼ばれるようになってきており、業務アプリケーションのSaaSとは区別されるケースが多い。この点には一応留意されたい（図1）。  図1：SaaSの分類 （画像をクリックすると別ウィンドウに拡大図を表示します） なお本連載では、議論が拡散してしまうのを防ぐため、業務アプリケーションのSaaSにフォーカスして解説していく。 |
||||||||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
-
-
連載
