HOME > 経営をよくする > SaaS & ASP 活用術

SaaS & ASP 活用術

SaaS&ASPサービス導入マニュアル

05.オープン・ソース・ソフトウェアとユーザ指向 〜SaaS/ASPの先へ

「サービスの基本と特徴」の第2回では汎用性の高いグループウェア系の製品を、第3回では特定の業種/職種向けのSaaS/ASP製品の代表としてSalesForceを、そして第4回では財務会計製品を紹介しました。

SaaS/ASPはIT調達の方法として非常に興味深い点も利点もありますが、まだ歴史も浅く、その欠点も十分に認識した上での利用が望まれます。本稿ではこれらの調達方法の利点・欠点をコストと変化への対応という二つの面からまとめておきます。

5.1.コスト面での優位性

例えば、SalesForceのような営業支援システムを考えてみます。そのシステムを使う営業部隊とマネジメント層が20人、従業員が全部で100人という会社を仮定します。

何のコンサルテーションもカスタマイズもなしにSalesForceのProfessional Edition(最小機能)を使うとすれば、1年間180万円のコストがかかります。10年間では1,800万円になります。実際にはこれにコンサルテーションやカスタマイズ、トレーニングの費用が上積みされる可能性があります。

一方、カスタム開発をしたとすれば初期構築費用は数百万円から数億円といった幅があります。ただし20人程度が使うシステムならば、SalesForceのような汎用性や多くの機能、高い安全性/信頼性は必要ありません。

その分、自分たちが必要なことに的を絞り、工夫を重ねたとして1,500万円というのは合理的な価格の一例だと思います。これに保守運用費用が翌年から毎年10%かかるとすると、10年間で総額2,850万円になります。

パッケージ製品の価格はまちまちで、契約の形態にも多様性があります。一般的に購入価格はカスタム開発よりは安く、その代わりにバージョンアップ費用などが高めに設定されていることが多いといえます。

ここでは例えば(初期カスタマイズ費用を含む)購入価格を750万円、保守運用費用が1年間に購入価格の20%、バージョンアップが4年に一度でそれぞれ250万円とすると、10年間で総額2,300万円です。

これらはあくまでひとつの例ですが、この程度の規模と期間ならば、やはりSaaS/ASPはコスト的にかなり有利であることが分かります。この違いはシステム開発/保守/運用の費用をどれだけ多くのユーザで分け合っているかの違いに由来していることになります。

逆に利用者数が増えればSaaS/ASPは正比例して金額が増えていきますが、カスタム開発の場合にはそれよりもゆるやかな増え方になります。パッケージの場合には契約によります(人数に応じて価格が設定される場合にはSaaS/ASPに近く、人数に関係ない場合にはカスタム開発に近い)。

図5.1システム形態による開発・運用費用例図5-1 システム形態による開発・運用費用例

5.2変化への対応

どんなITシステムでも、何の手も加えずに10年間も使い続けられることはありません。何らかのシステム変更は必ず必要になります。システムの変更では、以下の影響について検討する必要があります。

  • 変更可能性/制約
  • 変更に要するコスト

変化への対応がもっとも容易なのはカスタム開発です。システムのすべてのソース・コードは手元にあるのが普通です。標準的でオープンなシステムの上にシステムが構築されていれば、どのような変更でもいつでも可能で、開発者を探すのも容易です。

何よりも自分たちの業務に最適化されているため変更そのものの作業が容易で、比較的低いコストで済むという点です。その代わり、すべての変更は自分たちが主導して行わなければなりません。

一方、SaaS/ASPでは自分たちにとって必要な変更であっても必ずしも可能であるとは限りません。一定の範囲でのカスタマイズや拡張は可能になっている場合も多く見受けられますが、制約があります。もし自由に変更を行えるとしても、変更はすべてSaaS/ASPベンダかそのパートナーに任せざるを得ず、しかもコード・ベースは汎用的なものなので、カスタマイズは非常に高価につく可能性があります。

その代わり、SaaS/ASPでは多くの場合、余計な費用負担なしに日常的に細かな機能追加や性能向上が行われています(それが自分たちにとって必要なものかどうかは別問題ですが)。また国際的なベンダの場合、日本特有の法改正や商習慣にどの程度の対応ができるかは難しい場合もあります。

パッケージの場合には契約形態に依ります。変更は多くの場合で可能ですが、ソース・コードや技術がベンダ側にある場合には、まったく自由に変更することはできず、変更は非常に高くつく(例えばパッケージ本体の価格よりも高くなる)可能性もあります。その代わり、法令改正など一般的な変化への対応は、保守費用かバージョンアップ費用に含まれる場合もあります。

5.3中小企業にとってのIT調達のこれから

これまでも述べたように、SaaS/ASPもカスタム開発の長所を採り入れるべくカスタマイズ性や拡張可能性を強化してきています。PaaS(Platform as a Service)という言葉があることも紹介しました。

もちろんその一方で、カスタム開発やパッケージ製品にもSaaS/ASPが持つような長所を採り入れようとする動きがあります。特にパッケージ製品とSaaS/ASPは非常に似た性格を持っているため、今後急速に接近していく可能性があります。

実際、これまでパッケージとして提供されていた製品が、SaaS/ASPとしても提供されるようになる例が相次いでいます。これは最初に述べた「業」「務」の考え方でいえば、他社と共通化できるところはできるだけ共通化し、外出しにできるところはできるだけ外に出して(アウトソーシング)、コストを抑え、品質を上げればよい、という方向性です。

それに対して自社固有のノウハウ、他社との差別化の源泉、競争力そのものになるような部分は、今後ともやはりカスタム開発をせざるを得ないといえます。むしろ共通化/外出しが進めば進むほど、自社の強みをちゃんと自前で維持し、強化する必要が高まってくるものと思われます。

そのような部分に直接関連するITシステム調達では、カスタム開発が有望な選択肢となります。ただしカスタム開発も変わりつつあります。

ひとつはオープン・ソース製品を積極的に用いたコスト低減と品質向上です。オープン・ソース製品とは、ソース・コードが公開され、一定の条件下で自由に用いることができるソフトウェア製品です。

オープン・ソース製品は世界中のさまざまなITシステムに組み込んで利用されているため、開発・保守のコストを多くのユーザで分け合うという意味でSaaS/ASPに近いところがあります。また多くのユーザが利用し、その結果を公開されているソース・コードに反映するスタイルのため品質も向上しやすくなります。

さらにソース・コードが公開され、多くの開発組織が標準的に利用しているため、カスタム開発したITシステムの変更に携われる開発組織や技術者の数も多く、コストや容易さの面でも有利といえます。

つまりカスタム開発に際して、共通化できる部分はオープン・ソース製品を部品として用い、本当に自分たちのビジネスの核になる部分に開発コストや労力を集中すればよいという考え方です。なかにはSaaS/ASP製品として有償で提供しているサービスを実現しているソフトウェアを、一方ではオープン・ソース製品として公開している場合さえ見受けられます。

もう一つは、アジャイル開発と呼ばれるソフトウェア開発手法です。これは従来のカスタム開発で行われていたような重厚長大な開発手法に対して、小さなチームが小さな開発を繰り返しながら最終的に大きなシステムを高い品質で実現するやり方です。

従来の重厚長大な開発手法では、どうしても開発や必要な変更にコストや時間がかかり過ぎます。しかしこれを短縮し、「必要なときに低いコストで必要な機能を入手できる」ようになれば、カスタム開発とSaaS/ASPの距離は縮まります。

SaaS/ASP製品ならばWebサイトにログインさえすれば契約前から実際に動いているシステムを試用できるわけですが、カスタム開発でもアジャイル開発手法を使えば、ユーザが注文した機能を1〜数週間で確認することができるようになります。実はアジャイル開発手法を適用して作られているSaaS/ASP製品も多くあるのです。

 

そして最後がユーザの開発への参加です。最近ではカスタム開発に際して、すべての機能を最初からITシステムに作り込んでしまうのではなく、ユーザが手を入れて変えられる範囲を大幅に増やすやり方(アーキテクチャ)が進んできました。

例えば、大きな組織変更があったり、ビジネス・ルールが変わったり、業務フローが変わった場合に、いちいちITシステムの改修を開発組織に依頼するのは時間的にもコスト的にも労力的にも大きなムダです。このような場合にユーザがある設定をするだけで、ITシステムがその変化に追随できるようになります。

また経営データを分析したりするだけならば、データを破壊してしまう恐れがないため経営者のさまざまな視点を試しながら分析できるようになります。このような機能をビジネス・インテリジェンス(Business Intelligence、 BI)と呼ぶ場合もあります。

ユーザがより積極的にITシステムの開発に関われるようにするやり方は、カスタム開発の大きな長所をさらにユーザに有利なように伸ばすものです。

5.4全体としての最適化がキー・ポイント

今後、パッケージ製品のSaaS/ASP化を含めてSaaS/ASPの充実、拡大は止まることはないといえます。インフラ資源の共有と外出し(アウトソーシング)によって、IT調達はますます低コスト化、効率化していきます。

しかしその一方で、ユーザ企業の核になる部分、コア・コンピタンス(競争力の源泉)、差別化のためのノウハウを実現する部分におけるカスタム開発の重要性はますます増してきます。

そしてカスタム開発自身も、オープン・ソース製品の活用、アジャイル開発手法の利用、ユーザの開発への参加によって大きく変わってきています。

この二つのIT調達方法は、競争をして互いの長所を採り入れながら、それぞれの特徴を生かせる分野に棲み分けし、進化していくことでしょう。

図5-2 カスタム開発とパッケージ(SaaS/ASP/PaaSの競合、棲み分け、進化) 図5-2 カスタム開発とパッケージ(SaaS/ASP/PaaSの競合、棲み分け、進化)

IT調達を行う側としては、この二つをうまく組み合わせ、全体としての最適化を図っていくことがこれからのキー・ポイントになるのです。

知っておきたいSaaS&ASPサービスの基本と特徴目次

  1. 01.さまざまなシステム導入方法 - SaaS/ASP (1)[2008年2月22日]
  2. 02.SaaS/ASPサービスの実例 (1)-オフィス系(google、zoho)、グループウェア系(Cybozu)[2008年5月27日]
  3. 03.SaaS/ASPサービスの実例(2)-業務系(SalesForce)[2008年5月27日]
  4. 04.SaaS/ASPサービスの実例(3)-会計/財務系[2008年7月4日]
  5. 05.オープン・ソース・ソフトウェアとユーザ指向 〜SaaS/ASPの先へ[2008年8月12日]
Copyright(c)Metabolics,ltd. このコンテンツの著作権は、(有)メタボリックスに帰属します。著作権者の承諾なしに無断で転用することはできません。