AWS と始める SaaS 化への道

本連載は開発者向けということもあり、あまり多くは触れてきませんでしたが、SaaS を作る上で最も重要かつ最初にやるべきことは、ビジネスプランニング (事業計画立案) です。

• 「ターゲットとするユーザーは誰か ? ユーザーはどんな課題を持っているか ? (= ペルソナの定義)」
• 「このサービスはどんな価値を提供できるか ?」
• 「市場における他社の製品と比べてどんな優位性があるか ?」
• 「いつまでにどれくらいの顧客 / 売上を獲得して、どのような成長モデルを描くか ?」

アーキテクチャについて検討を始める前に、まずこれらの要点が文書化され、プロジェクトチームまたは会社全体で共通認識が取れていることを確認しましょう。

組織間の壁を取り払い、プロダクトマネージャーだけでなく、営業やマーケティング、カスタマーサポート、開発者 / 運用者などステークホルダー全員を巻き込んでディスカッションを行い、チーム全体での共通認識を作っていきましょう。

ここで判断の軸になるのが、前述のビジネスプランニングのフェーズで定義したペルソナです。ターゲットとするユーザーがどんなセキュリティ、可用性、パフォーマンス要件を求めているのか、インフラコストはどこまで許容できるのか、どんなティアをサポートするのか、こういった観点があらかじめ整理できていれば、分離モデルの選定はそこまで難しくありません。上記の要件から自然と定まってきます。料金プランの設計については SaaS における料金プランとメータリング、ビリング (第 9 回) にヒントがあります。

分離モデルが決まったら、同様にデータパーティショニングについても検討を進めます。AWS はさまざまなデータベース / ストレージサービスを提供しており、それぞれで取れる戦略は異なります。データ要件から使用するサービスを先に決める、または採用したいパーティショニングのパターンから候補を絞り込んでサービスを選定する、どちらの方法を取ることもできますが、やはり重要なのはユーザーの要件やサービスが提供する体験です。データパーティショニング (第 6 回) の記事では、コンプライアンス、パフォーマンス、コストの 3 つの観点に着目していますが、自社のワークロードに合わせて何を一番重視するべきかプランニングの段階で整理しておきましょう。

さて、大枠が決まったところでアプリケーションの開発に入っていくわけですが、まず最初にほとんどの SaaS で共通している部分、かつユーザーが最初に触れるサービスの入口となる認証 / 認可について考えていきましょう。SaaS における "アイデンティティ" の考え方については SaaS on AWS における認証認可の実装パターンとは ? (第 4 回) をご覧ください。JWT (JSON Web Token) をベースにした統一した仕組みを用いることで、複雑な実装のコストやミスを減らすことができます。また、この JWT を活用したテナントコンテキストの伝達の仕組みを作ることで、動的なポリシー生成によるテナント分離 (第 3 回) のガードレールを設けることもできるようになります。これは、SaaS 開発において特に注意を払う必要があるクロステナントアクセスの防止に役立ちます。

次に、運用についても考えておきましょう。スケールする SaaS ビジネスを構築するためには オンボーディング (第 5 回) の自動化も重要です。付加価値を生まない作業をなるべくオフロードすることで、サービスエクスペリエンスの改善に集中できます。より芯を捉えた改善を行うためには、データドリブンな意思決定が不可欠です。システムのパフォーマンス、ビジネス KPI など各種 メトリクスを収集して可視化 (第 7 回) しましょう。価格戦略や提供するプラン (ティアモデル) を含めたビジネスモデルの最適化を行うためには、コスト関連の分析 (第 8 回) も忘れずに行なってください。

各トピックの詳細については、過去の連載記事をご覧ください。また、AWS SaaS Factory Insights Hub では、これらの設計のヒントとなるブログやウェビナーなどのリソースを公開しています。ビジネス / 技術問わず、AWS が持つ SaaS のベストプラクティスのコンテンツポータルとしてご活用ください。

このフレームワークは、いつでも利用可能です。一回限りではなく、設計段階、リリース前の検証、リリース後の定期的なチェックといった形で、繰り返し見直していただくことをおすすめします。

さて、本連載では、初めての方でも一から新しく SaaS を立ち上げることができるようなナレッジの提供を目的としておりましたが、既存ソリューションの 移行についても最後に少しだけ触れておきます。

読者の皆様の中には、すでにソフトウェアのソリューションをお持ちで現在 SaaS 化を検討している、またはすでに SaaS のソリューションをお持ちで、AWS のベストプラクティスに沿った最適化を目指しているという方もいらっしゃるかと思います。

SaaS Boost は、2022 年 3 月時点ではコンテナアプリケーションのみをサポートしていますが、アプリケーションがコンテナ対応していない場合はどうすればよいでしょうか ?

コンテナ化や Web ベースのアプリケーションに書き換える工数が取れない場合は、Amazon AppStream 2.0 を通じた配信モデルを構築することで、市場投入までの時間を大幅に短縮できます。これは本連載で紹介してきた SaaS とは形態が異なりますが、ユーザーが得られる本質的な体験は変わりません。ユーザーは使い慣れた Web ブラウザを通じて、AppStream 2.0 からストリーミングされる Windows または Linux のデスクトップアプリケーションにアクセスすることができます。ビジネス上の理由から一刻も早い市場投入が必要だがアプリケーション改修の工数が取れない、そういったケースではこちらの方法が適しているかもしれません。

どのような移行のプランを選択すればよいかは、企業の状況によって様々です。今後のビジネスの成長戦略や市場の動向を鑑みて、慎重に検討していきましょう。ぜひ担当の AWS のソリューションアーキテクトにも相談してみてください。

AWS では、数多くのお客様の SaaS ソリューションが稼働しています。本連載で紹介してきたベストプラクティスや考え方は、これらの SaaS の開発 / 運用を支援する中で得られた知見がベースとなっています。実際の経験に基づくナレッジを活用することで、よくある課題や落とし穴を回避し、実装のコストを削減することができます。AWS が提供するマネージドサービスの活用もその一部です。

これらをうまく使って、継続的なユーザー体験の改善に注力できるスケーラブルな SaaS を構築してみましょう ! 本連載はこれで最終回となりますが、引き続き AWS ブログ 等で SaaS に関する情報をお届けしていきますのでお楽しみに !