次の方法で共有


SaaS への体験を計画する

サービスとしてのソフトウェア (SaaS) の構築と運用のどの段階にも、そのビジネス独自の機会と独自の課題の両方があります。 SaaS の考慮事項は、SaaS オファリングを計画するときだけでなく、ビジネスを日常的に運営する際にも留意することが重要です。

次の図は、SaaS 製品の構築中に会社が経過する一般的な体験を示しています。 このプロセスを理解することが、現在の段階で適用されるリソースを把握するのに役立ちます。 この記事の残りの部分では、SaaS への体験の各段階を簡単に説明し、その段階に現在存在するビジネスに関連するすべてのリンクを提供します。

SaaS 製品の体験を示す図。

1. SaaS のビジネス モデルを計画する

SaaS への体験の最初の段階は、ビジネス上の決定が中心となります。 ビジネス上の決定は、最終的にアプリケーションのソフトウェア要件になるため、技術的な決定を行う前に慎重に検討する必要があります。 少なくとも、次の問題を考慮してください。

  • 解決しようとしている問題を明確にします。 SaaS ソリューションは、ビジネス上の問題を解決するように設計されています。 ソリューションを設計する前に、解決しようとしているビジネス上の問題を特定します。
  • そのソリューションで問題がどのように解決されるかを把握します。 設計した SaaS ソリューションが、特定した問題をどのように解決するかを明確に理解します。
  • 価格モデルを把握します。 SaaS ソリューションは、最終的には収益を生み出すために設計されています。 さまざまな価格モデルと、どれが設計するソリューションに最適かを理解します。
  • 顧客と、その顧客がアプリケーションとどのように対話するかを理解します。 顧客が誰であるか、および顧客が関心を持つ機能を把握します。 これを前もって知ることで、あまり活用されない機能を開発しないように、貴重な時間とエネルギーを節約できます。

アプリケーションの要件に加えて、ビジネス全体に関連する次の点も考慮してください。

  • SaaS アプリケーションを運用する責任をビジネスが担う準備ができていることを確認します。 SaaS ビジネスを運営するということは、顧客がサポートなどの際にあなたの会社しか頼れなくなることを意味します。 アプリケーションのサポートが 24 時間 365 日提供できるようにしてください。

  • レガシ オファリングからの移行のスムーズなパスがあることを確認します。 別のビジネス モデルからの移行を計画している場合は、あまり中断することなく顧客を移行できる計画を用意してください。

  • 確立したプロセスがどのようにスケーリングされるかを理解します。 計画中は、ビジネスの成長に合わせて、時間の経過と共にプロセスを変更する必要があることを理解してください。 少数の顧客しかいない場合は、手動でできる場合もありますが、このアプローチはうまくスケーリングされません。 詳細と例については、次の記事をご覧ください。

  • SaaS の基礎 SaaS の基礎に関する Microsoft Learn モジュール

  • リスクなしに SaaS への体験を加速させる SaaS の移行および最新化プロジェクトに関する重要な考慮事項、課題、その他のレッスンの概要を示す Microsoft Ignite 2021 のビデオ。

  • Microsoft SaaS Academy - 無料の SaaS 学習コース。

  • 価格モデルに関する考慮事項 - 価格戦略を決定する際に留意すべき重要な技術的考慮事項。

  • Microsoft for Startups Founders Hub - LinkedIn、Microsoft 365、GitHub Enterprise、Azure クレジットなどのビジネスを実行するための Microsoft ソフトウェアのような、ビジネスと技術のメンタリングを提供するソリューションを Azure 上で構築するスタートアップ企業向けのリソース センター。

  • Microsoft SaaS ストーリー - Microsoft の ISV パートナーが SaaS の構築経験について語る一連のビデオ インタビュー。

2. SaaS ソリューションを設計する

ビジネス要件を決定したら、体験の次の段階は、要件に対応するようにアプリケーションを設計することです。 SaaS 製品では通常、マルチテナントの概念を考慮する必要があり、多くの考慮事項が発生します。 このステップでは、特定の要件と考慮事項に対応するアプリケーション アーキテクチャを生み出す必要があります。 詳細と例については、次の記事をご覧ください。

3. SaaS ソリューションを実装する

開発したアーキテクチャを実装する必要があります。 この段階では、通常のソフトウェア開発ライフサイクル (SDLC) プロセスを使用して SaaS 製品を開発し、反復します。 この段階では、一度に多くの要件を開発に入れすぎないようにすることが重要です。 どの機能が顧客に最もベネフィットをもたらすかを把握し、実用最小限の製品 (MVP) から開始してみてください。 時間の経過と共に小さな改善を加えて反復する方が、大きなチャンクで開発するよりも簡単に実装できます。 詳細と例については、次の記事をご覧ください。

4. SaaS ソリューションを運用する

この段階では、顧客を新しい SaaS 製品にオンボードし、運用環境のユーザーを含む SaaS プロバイダーとして運用を開始します。 SaaS 製品を完了に近づけ、既存の顧客を移行したり、新しい顧客をオンボードしたりする戦略を用意します。 問題が発生した場合に顧客をサポートするための計画を用意します。 また、どの主要業績評価指標 (KPI) メトリックを収集できるかの特定を開始することも重要です。これは、後でさまざまなビジネスおよび技術的な決定を推進するのに役立ちます。 詳細と例については、次の記事をご覧ください。

5. SaaS ソリューションを市場に投入して販売する

この段階では、SaaS ソリューションを市場に投入して販売を開始します。 Azure MarketplaceMicrosoft AppSource に限らず、アプリケーションを販売するために利用できるあらゆる手段を調べましょう。 この段階では、前の段階からの KPI データの取得も開始し、それを使用して顧客が SaaS アプリケーションとどのように対話しているかの分析も行います。 その後、その分析を使用して、SaaS 製品のロードマップに関するビジネスおよび技術的な決定を行います。 詳細と例については、次の記事をご覧ください。

6. プロセスを繰り返す

SaaS ソリューションの開発は、循環的な体験です。 SaaS 製品を最大限に活用するには、顧客と市場のニーズに適応するように常に反復する必要があります。 製品の現在の方向性に関する決定を行った後、プロセスを段階 1 からやり直します。 詳細と例については、次の記事をご覧ください。

  • Azure Well-Architected レビュー - シナリオに合わせてキュレーションされ、パーソナライズされたガイダンスが得られる、Azure Well Architected Framework に対するワークロードの評価。 このレビューを定期的に完了して、改善できるアプリケーションの領域を特定します。
  • SaaS 体験レビュー - マルチテナント アーキテクチャに関する知識を調べ、SaaS 運用のベスト プラクティスへの準拠を評価する SaaS 製品の評価。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Landon Pierce | FastTrack for Azure のカスタマー エンジニア
  • Arsen Vladimirsky | FastTrack for Azure のプリンシパル カスタマー エンジニア

その他の共同作成者:

  • John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Irina Kostina | FastTrack for Azure、ソフトウェア エンジニア
  • Nick Ward | シニア クラウド ソリューション アーキテクト

次の手順