初期動機

SaaS を理解するために、SaaS ビジネスを構築する際に達成しようとしていることについて、非常にシンプルな概念から開始しましょう。まずは、従来の (SaaS 以外の) ソフトウェアがどのように作成、管理、運用されてきたかを調べでみましょう。

次の図は、複数のベンダーがどのようにソリューションをパッケージ化して提供してきたかを示した概念図です。

ソフトウェアソリューションのパッケージングとデリバリーのクラシックモデル

この図では、一連のカスタマー環境を示しています。これらのカスタマーは、ベンダーのソフトウェアを購入したさまざまな企業や団体です。これらのカスタマーはそれぞれ、基本的にソフトウェアプロバイダーの製品をインストールしたスタンドアロン環境で運用しています。

この場合、各カスタマーのインストールは、そのカスタマー専用のスタンドアロン環境として扱われます。つまり、カスタマーは自身をこれらの環境の所有者とみなし、必要に応じて 1 回限りのカスタマイズや独自の構成を要求する可能性があります。

この考え方によく見られる問題の 1 つは、実行する製品のバージョンをカスタマーが制御してしまうことです。この問題はさまざまな理由によって発生する可能性があります。カスタマーは、新機能に不安を感じたり、新しいバージョンの採用に伴う混乱を懸念しているかもしれません。

このような動きがソフトウェアプロバイダーの運用フットプリントにどのように影響するかは想像できるでしょう。カスタマーに 1 回限りの環境を許可すればするほど、各カスタマーの異なる構成の管理、更新、サポートが難しくなります。

このような 1 回限りの環境を必要とするとき、多くの場合、組織はカスタマー別に管理およびオペレーションエクスペリエンスを提供する専任チームを結成する必要があります。これらのリソースの一部はカスタマー間で共有される可能性がありますが、このモデルでは、新規カスタマーがオンボーディングするたびに経費が増加するのが一般的です。

各カスタマーが独自の環境 (クラウドまたはオンプレミス) でソリューションを実行することも、コストに影響します。これらの環境のスケーリングを試みることはできますが、このスケーリングは 単一のカスタマーのアクティビティに限定されます。基本的に、コストの最適化は、個々のカスタマー環境の範囲内で達成できることに限定されます。また、カスタマーごとのアクティビティの差異に対応するため、個別のスケーリング戦略が必要になる場合もあります。

当初、一部のソフトウェア企業はこのモデルを強力なコンストラクトと見なすでしょう。1 回限りのカスタマイズ機能を販売ツールとして活用し、新規カスタマーがその環境に固有の要件を課せるようにします。カスタマー数の増加とビジネスの成長は大きくありませんが、このモデルは完全に持続可能に思われます。

しかし、企業の成功が大きくなるにつれ、このモデルの制約は、現実的な課題を生み出し始めます。例えば、ビジネスが急成長し、多くの新規カスタマーが急速に増えているシナリオを想像してみてください。この増加により、運用上のオーバーヘッド、管理の複雑さ、コスト、その他多くの問題が追加されます。

そして最終的には、このモデルの全体的なオーバーヘッドと影響により、ソフトウェアビジネスの成功を根本的に損なう可能性があります。運用効率が最初の課題となる場合もあります。カスタマー獲得に伴って人員とコストが増加すると、ビジネスのマージンが損なわれ始めます。

ただし、運用上の問題は課題の一部にすぎません。本当の問題は、このモデルがスケーリングするにつれ、新しい機能をリリースし、市場と歩調を合わせるビジネスの能力に直接的に影響し始めることです。各カスタマーが独自の環境を保有する場合、プロバイダーはシステムに新しい機能を導入するとき、多数の更新、移行、およびカスタマー要件の間でバランスを取る必要があります。

通常、これはリリースサイクルを長く複雑にし、毎年行われるリリースの数を減少させる傾向があります。さらに重要なのは、この複雑さによって、チームは、カスタマーにリリースするずっと前から各新機能の分析により多くの時間を費やさなければならないということです。チームは、デリバリーのスピードよりも、新機能の検証に重点を置くようになります。新機能のリリースのオーバーヘッドが非常に大きくなるため、チームはサービスのイノベーションを促進する新機能よりも、テストの仕組みに集中するようになります。

この遅く、より慎重なモードでは、チームのサイクル時間が長くなる傾向があり、アイデアを思いついてからカスタマーの手に渡るまでの時間がますます大きくなります。全体として、これは市場のダイナミクスや競争圧力に対応する能力を損なう可能性があります。