さて、こちらも久しぶりのエントリーになります。テーマは最近の流行であるSaaSあ（Software as a Service）とSOA（Service Oriented Approach）についてです。
このふたつのキーワードに熱いまなざしが向けられている。それは、バズワードという、一見専門用語のように見えるがそうではない、明確な合意や定義のない用語のことではないかという人もいる。筆者はそうではないと考えるが、定義の仕方がひとによってばらばらのような気がする。
それはどうしてかというと、特に3文字略語の場合、その言葉やコンセプトを作ったひとはどういうことかもちろんわかっているが、そうでない人たちは、まずは3文字ありきなのであって、その3文字を自分の知識や理解で勝手に解釈してしまうからだ。だから、そうした言葉を使いながら話をしていて、お互いに全然違う定義でしゃべってしまい、かみ合わないことがある。
結局、言葉から入るのではなく、自分のやりたいこと、考えていることがそのコンセプトやアーキテクチャに合っているかどうかという視点が重要で、それが合っていれば腹に入って来るのだ。
そうした目で見ていくと、まずSOAから言うと、多くの間違いは、ＳＯＡを技術やソフトウエアだと思っている人がいることだ。わけが分からないのは、さあ今からＳＯＡを構築しましょうというやつで、それどうやって作るの、何に使うのということになる。これでは、ベンダーがだまそうとするバズワードになってしまう。
ＳＯＡはあくまで、思想であり、概念である。システム全体をフレキシブルでアダプティブな構造にして、ビジネス環境の変化にシステムが迅速に対応していこうという考えかたなのである。だから、システム側の要求でもなんでもなくて（まあメンテナンス性の向上はあるがメインではない）、ビジネス側が望んでいることなのである。
ここをしっかりと理解する必要がある。すなわち、ビジネス側の要求として、必然的にＳＯＡが求められたのだ。それが、これまでは技術的に難しいところがあってできなかったのが、ここへきてやっと実現できるようになったから、注目されているわけで、そういう意味でバズワードではないと言っているのです。
つぎにSaaSだが、これと同じような仕組みにASP（Application Service Provider）というのがある。2000年くらいに若干もてはやされていたが、いまはこの言葉を聞くことは少ない。実は、筆者はその当時、ASPを実際に始めた経験を持っている。この仕組みを適用しようとしたきっかけは、情報システム部門の子会社化である。
情報子会社の使命のひとつにグループ会社の支援がある。グループ会社というのは、だいたいが中小規模でシステム部門をもたないようなところが多い。その当時はどこの会社も子会社の情報システムはあまり面倒をみていなかった。独立心の強い会社が多い（昔は親会社がそう仕向けた面もある）せいでもあったが、自分たちでできないから地元のITベンダーにまかせっきりになっていた。
ところが、2000年3月期から連結決算の開示の義務化により、単体経営から連結経営重視へ舵がきられたため、親会社も子会社のシステムについて知らんぷりもできなくなってきた。典型的な例が、連結決算データの集約が早く正確にやらなくてはいけなくなったことなど、グループ全体のシステム化という視点を持たざるをえなくなった側面がある。
で筆者が掲げたのは、情報子会社はグループ会社のための、Application Service Providerになろうと決めたのである。すなわち、グループ会社はIT資産はPCとLAN以外は持たないということである。親会社のシステム部門に開発から運用まで全部任す形態である。
そのために、一箇所にアプリケーションを置いてそれを各社が共同利用するというシェアリングの考え方を採用したのである。その頃はまだ、Webアプリケーションも少なく、ネットワークパフォーマンスやサーバーのスケイラビリティイの問題があってなかなか難しかった。
いまや、ASPとはあまり言わず、SaaSという言葉が主流となっているが、どこが違うのだろうか。これについて昨年栗原潔さんがブログに書いてあるのを借用してみる。いま言ったようなことを踏まえると筆者の考えを代弁してくれている。
現状のSaaSの定義は、「アプリケーション・ソフトウェアをユーザーが自分のシステムに導入して使うのではなく て、ソフトウェア・ベンダーが所有するインフラで稼働してもらって機能だけをネット経由で使うモデル」という感じでしょう。そうなりますと、SaaSと ASPモデルはどこが違うのという話になります。ネット上で「SaaSとASPはここが違うんだ」という意見をサーチすればするほど、私的には「やっぱり同じでは」と思えてしまいます。たとえば、
１．ネットコストの違い： 昔のASPは通信費が高かったが、SaaSは高速回線を安価に使用できる
これは利用環境が変わったというだけで、特に本質的な違いではないのでは？
２．ホスティング方式の違い： ASPではシングルテナント（１サーバ＝１ユーザー）が普通だったが、SaaSではマルチテナント（１サーバ＝複数ユーザー）が主流
これまた利用環境の違いであって、モデルの本質的な違いとは思えません。
３．アプリケーション設計の違い： ASPはクライアント・サーバ・アプリケーションを無理にネット対応にしたもの、SaaSは最初からネット向けに設計
そうなんでしょうか？ASP時代にもネット・ネイティブのアプリケーションはあったと思います。ということで、今の私の結論は「SaaSとASPに本質的な違いなし、ASPにはあまりビジネス的に成功できなかったという悪いイメージがあるので それを避けるために、ベンダーがマーケティング上SaaSという新しい言葉をプロモートしている」というものです。そもそも、1990年代末のASP時代 から"software as a service"という言い回しはよく聞かれてました（SaaSという短縮形は一般的ではなかったかもしれませんが）。
まさにこの通りで、ASPといわれた時代の技術的な限界がいまはなくなって、その当時思い描いていたことが実現できるようになったということだと思う。
そこで、SaaSの利用の仕方についてである。現時点で有名なのは「SalesForce.com」であるが、これが正しいSaaSの利用の仕方なのだろうか。どうも疑問がある。まず、ユーザサイドでいうと、大企業から見るのと中小企業から見るのとはだいぶ違う。
中小企業は、全社システム丸ごとという利用の方向であるが、大企業は必要なサービスだけをもってくるという方向であると思う。大企業は、基幹業務システムは自社で保有するが非基幹系あるいは情報系については必要に応じて外部サービスを使うというのが多いでしょう。
こうしてみると、「SalesForce.com」はSaaSで提供されるべきものなのだろうかと考えてしまう。しかも、営業の業務というのは様々な形態があるし、またその会社あるいは部署によって特徴のあるプロセスだったりするわけで、それをある決まった型に押しこめるのはいかがなものだろうか。そもそも基幹業務なのではと思う。
SaaSに向いている業務サービスは、差別化しなくてもいい、あるいは自社でメンテしにくいもの、専門的なものが適している。例えば、プロフェッショナルサポートと呼ばれるような税務、法務・特許、労務、与信などのサービスを外部にまかせるというのが取るべき形態であると思う。
いまや多くの業務がSaaSに取って替わられるような勢いで語られることもあるが、そう簡単に移行できるとは思わない。むしろ、以前のASP的なアプローチで最終的にはBPO（Business Process Outsourcing）につながるような形態が多くなるような気がする。