 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| カスタマイズ能力に磨きをかけるSaaSベンダー | ||||||||||
|
マルチテナント技術が「1つのシステム上に複数組のルールセットを組み込む技術」であることは、「第1回：SaaSというビジネスモデルの成功要因とは」で述べた通りである。マルチテナント技術を確立し、より多くのユーザを、そしてデータを1つのシステムで処理することによって、SaaSのビジネスモデルは成立する。 複数組のルールセットの1つ1つは、ユーザのビジネスルールを反映するように、柔軟かつ正確に、さらに短期間でカスタマイズできることが要求される。このため、もしSaaSベンダーが提供するカスタマイズ能力で満足してくれる企業が、想定した数よりも少なければ、規模の経済は働かなくなってしまう。ASPの二の舞とならないためにも、SaaSベンダーはカスタマイズ能力に磨きをかけるのである。 |
||||||||||
| カスタマイズの3条件 | ||||||||||
|
カスタマイズという単語は、使う人によってかなりの幅がある。テンプレートの提供をカスタマイズと呼ぶASPベンダーもいれば、コードを書くことをカスタマイズとよぶシステムインテグレータ（SIer）もいる。 しかし、SaaSの先駆者達は、以下の表1にあげた3条件を同時に満たすカスタマイズ能力を開発してきた。
表1：SaaSの先駆者が開発したカスタマイズ能力 これらの3条件がトレードオフの関係にあることは明らかである。 テンプレートの提供をカスタマイズと呼んできたASPベンダーは、条件2と条件3を満たしている。ユーザの要望を満たすまでの期間は短く、その作業がソフトウェア本体の保守性に影響を与えることはまずない。 しかし、テンプレートにより実現できる範囲はごく狭く浅く、たいていの場合はユーザの要求を完全に満たすことができない。ユーザの要求の多様性はベンダーの想像力を常に上回るものなのだ。 一方、コードの書き直しをカスタマイズと呼ぶSIerは条件1を満たしており、コードを書き直すことによってユーザの望む通りの機能を実現しようとする。しかし考えてみれば、コードさえ書き直せばソフトウェアに望み通りの機能を追加できるのは、むしろ当然である。 問題は、コードを書き直すには時間が必要であり、しかも往々にして保守性は損なわれることだ。明確な方法論をもっていない限り、コードはスパゲッティ化し、OSやミドルウェアをアップグレードするたびに、影響範囲の調査に膨大な時間を消費することになる。つまり、コードの書き直しでは条件2と条件3は満たせない。 この3条件を同時に満たすために、パッケージソフトのベンダーは様々な工夫を施してきた。コア部分に手を加えることを許さず、周辺部分にコードをアドオンする方法などがその代表例である。しかしたとえさまざまな工夫を凝らしたとしても、ユーザのビジネスルールに合致する機能を、短期間に、しかも保守性に影響を与えずに実現するのは容易ではない。 トレードオフの関係にあるこれらの3条件を同時に満たすカスタマイズ技術の開発が、マルチテナント技術の次に乗り越えるべき技術障壁である。SaaSの先駆者達は「ゼロから開発したからこそカスタマイズ可能なマルチテナント技術を実現できた」という発言を繰り返してきた。 SaaSとパッケージソフトとは、アーキテクチャからして異なっている可能性が感じられる。 |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
