SaaS への移行

SaaS を採用するプロバイダーの多くは、(前述の) 従来のインストール済みソフトウェアモデルから SaaS に移行します。これらのプロバイダーにとって、SaaS の中核となる原則をしっかりと理解することは特に重要です。

ここでもやはり、SaaS モデルへの移行が意味することについて混乱が生じる可能性があります。例えば、クラウドへの移行を SaaS への移行と見なす人もいるでしょう。また、インストールとプロビジョニングのプロセスを自動化することで移行を実現できると考える人もいます。

組織によってスタート地点が異なり、レガシーに関する考慮事項も異なり、市場や競争圧力も異なる可能性が高いと言っても過言ではありません。つまり、それぞれの移行は見え方が異なります。

それでも、それぞれのパスは異なるものの、移行戦略を形成する中核的な原則をめぐって、一部のエリアでは話がつながらない部分があります。概念と原則をうまく調整することは、SaaS への移行の全体としての成功に大きな影響を与える可能性があります。

前に概説した概念から、SaaS への移行は、ビジネス戦略と目標から始めることが明らかです。できるだけ早期に SaaS に移行しなければならないというプレッシャーがある移行環境では、この点を見失う可能性があります。

この状態になると、多くの場合、組織は移行を主に技術的な作業と見なしてしまいます。現実には、SaaS への移行は、どれも対象となるカスタマー、サービスエクスペリエンス、運用目標などを明確に把握することから始める必要があります。SaaS ビジネスがどうあるべきかをより明確に把握することは、ソリューションを SaaS に移行するための形状、優先順位、および道筋に大きな影響を与えます。

移行の初期段階からこの明確なビジョンを持つことで、SaaS への移行の一環としてテクノロジーとビジネスの両方の移行について、それらの基礎を築くことができます。この道筋を歩むときは、自分が向かう先について最も詳しい情報を提供してくれる質問を重視します。

次の表は、テクノロジーの移行とビジネスの移行の考え方の対照的な性質を示しています。

表1 — テクノロジー優先の移行とビジネス優先の移行

テクノロジー優先の考え方	ビジネス優先の考え方
テナントデータをどのように分離するか。	SaaS はビジネスの成長にどのように役立つか。
ユーザーをテナントにつなげるにはどうすればよいか。	どのセグメントをターゲットにしているか。
ノイジーネイバーの状況をどのように回避するか。	これらのセグメントのサイズとプロファイルは。
A/B テストはどうすればよいか。	どの階層をサポートする必要があるか。
テナントの負荷に基づいてどのようにスケーリングすればよいか。	どのようなサービスエクスペリエンスをターゲットにしているか。
どの請求プロバイダーを使うべきか。	価格設定とパッケージ戦略は何か。

左側に示しているのは、テクノロジー優先の移行の具体的な例です。エンジニアリングチームは、従来のマルチテナントのトピックを追求するのに全力を注ぎます。これは確かにどの SaaS アーキテクチャにとっても重要です。

ただし問題なのは、左側の質問に対する多くの回答は、右側の質問に対する回答に直接影響されることが多いことです。移行を検討している人にとって、これは目新しいことではないでしょう。しかし、現実として、多くの組織では、ビジネスの部分は機能するだろうと想定し、最初のステップとして運用効率とコスト効率の追求から始めています。

この移行戦略では、レガシー環境をどのように進化させて SaaS モデルに適合するかについても混乱が生じる可能性があります。この分野でも、SaaS への移行にはさまざまな選択肢があります。しかし、どの移行に対しても一般的に提唱している共通の価値体系があります。

SaaS の原則についての前述の説明では、SaaS 環境の説明に使用されるさまざまなパターンと用語について概説しました。これらのソリューションすべてに共通するテーマの 1 つは、アプリケーションを囲む共有サービスを持つという考えです。ID、オンボーディング、メトリクス、請求など、これらはすべて SaaS 環境の中核となる共通要素として挙げられています。

さて、移行について検討するとき、これらと同じ共有サービスは、あらゆる移行シナリオで重要な役割を果たしていることがわかります。次の図は、移行先環境の概念図を示しています。

SaaS への移行

この図は、あらゆる移行パスのターゲットエクスペリエンスを表しています。これには、前に説明したのと同じ共有サービスがすべて含まれています。中央にはアプリケーションのプレースホルダーがあります。

重要なのは、この環境の真ん中には、アプリケーションモデルをいくつでも配置できるということです。移行の最初のステップでは、各テナントがそれぞれ独自のサイロで運用している場合があります。あるいは、何らかのハイブリッドアーキテクチャがあり、要素がサイロ化され、他の機能は最新のマイクロサービスのコレクションを通じて処理されている場合もあります。

最初にアプリケーションをどの程度モダナイズするかは、レガシー環境の性質、市場のニーズ、コストに関する考慮事項などによって異なります。変わらないのは、これらの共有サービスの導入です。

どのような SaaS への移行でも、ビジネスが SaaS モデルで運用できるように、これらの基礎的な共有サービスをサポートする必要があります。例えば、アプリケーションアーキテクチャのすべてのバリエーションで SaaS ID が必要です。SaaS ソリューションを管理および監視するには、テナント対応のオペレーションが必要です。

これらの共有サービスを移行の最初に導入することで、基盤となるアプリケーションがテナントごとにフルスタックのサイロで運用されている場合でも、カスタマーに SaaS エクスペリエンスを提供できます。

一般的な目標は、アプリケーションを SaaS モデルで実行することです。そうすれば、アプリケーションのさらなるモダナイゼーションと改良に目を向けることができます。また、このアプローチでは、ビジネスの他の部分 (マーケティング、販売、サポートなど) をより速いペースで移動させることも可能です。さらに重要なのは、これによってカスタマーからのフィードバックをエンゲージさせて収集し、それを活用して環境の継続的なモダナイゼーションを形成できることです。

導入する共有サービスには、最終的に必要となる機能やメカニズムがすべて含まれていない場合があることに注意してください。主な目標は、移行の初期段階で必要な共有メカニズムを作成することです。これにより、アプリケーションアーキテクチャの進化および運用の進化にとって不可欠なシステムの要素に集中できるようになります。