※本記事は株式会社アンチパターン 「SaaS開発ガイド（基礎編・応用編）」をもとにした内容です
※なお、本参考書はAWS Summit 2024 一般配布物です
Contents
SaaSとは
「Software as a Service」の略称。
「サービスとしてのソフトウェア」を意味するクラウドサービスの一種。
※SaaSモデル
基礎用語
- テナント
SaaSを利用するユーザー（顧客組織）の契約単位。「テナント」の単位は会社単位、部署単位、チーム単位などと、企業規模や組織構成などによって異なる。
- マルチテナント構成
共通のサーバーやデータベース、アプリケーションを複数のテナントに提供する。
（既存資産やビジネス上の制約がない限り採用すべき構成）
[コスト]
インフラストラクチャリソースを共有することで最適化。
[スケーラビリティ]
テナント数増加に対応しやすい。
[運用性]
サーバー・ストレージなどの運用対象になるマシン数を削減。
[メンテナンス性]
プログラムのデプロイ先を1つにすることで、テナントごとの個別管理を削除。 - ノイジネイバー
テナント間でリソースを共有する構成の場合に発生する事象。
同居しているテナントがCPUやメモリ、ディスクI/Oなどの大量のコンピューティングリソースを消費した場合、他のテナントが十分にサービスを利用できなくなること。
特定のテナントで大量の処理が実行された場合、リソースを共有する他のテナントにまでその影響が及んでしまうトラブル。同居しているテナントが他のテナントにより不利益を被ることになる。
※曜日や日付、時間帯などでユースケースが定まっている場合は注意が必要。
（例：月末処理など）
※別のインフラストラクチャにあるテナントに移動させることで一時的な解決を図ることも可能
- テナントティア
顧客が利用できる機能やディスク容量、処理能力、セキュリティレベルなどに応じてプランを分ける。これらを各利用プランに分けることををいう。
ビジネスモデル
SaaSというビジネスモデルの特徴は、
- サービスを多くの顧客に提供することで大きな成長につながるビジネスである。
- SaaSは一つの事業者が複数の「テナント」にサービスを提供するモデル。
- SaaSは継続課金を行うサブスクリプションモデルが多い。
留意点：サービス性
利用価値を保つために常に領域内のベストプラクティスを、継続的に俊敏性を高くして提供続ける必要がある。
新機能リリースやアップデートまでに期間が開くと、世の中のトレンドや競合サービスに遅れを取ることになり、顧客損失につながる。
つまり、タイムリーなプロダクト新機能開発やアップデートが必要になってくる。
強みとしてスケーラビリティやアジリティを担保でき、コスト効率や運用効率を高めるために、共通的なアーキテクチャやインフラで多数のテナントに対してサービスを提供できる。
一方で共通の環境でサービスを提供すると（マルチテナント）、セキュリティや性能の担保が難しくなる。
○意識すべきポイント
【SaaSビジネス成長のデザイン】
- プロダクトの初期段階においては機能開発などやるべきことが多く、スケーラビリティを完璧に意識することは難しい。
- ある程度プロダクトが成功し、利用者数が増えてきたタイミングで早めにスケーラビリティを高めていくことを検討。
- 俊敏性の高いSaaSアーキテクチャを実現するために、テナントのオンボーディング（利用開始）プロセス自動化、テナントの需要に合わせたコンピューティングリソースの自動スケーリングなどを検討。
【すべての顧客は共通の環境を提供すること】
特定の顧客に向けたカスタマイズではなく、機能アップデートや管理、オプション、運用作業などはすべての顧客に対して行われるもの。
様々な顧客のニーズをモデル化し、テナントのユースケースを集約し、ベストプラクティスとして提供できるように機能設計を行うこと。
【ガバナンスとコンプライアンスを考慮】
- ガバナンス：どこのデータセンターにデータを格納するか
- コンプライアンス：個人情報を取り扱う際、国々によって関連する法令など
【開発したオプション機能の切り替え】
利用契約を行っているテナントに対してのみ、開発したオプション機能を提供する。
そのため、フィーチャーフラグをセットし、有効・無効により特定のテナントのみにスイッチングできるようにする。
※テナントティアに応じた切り替え対応も可能。
- フィーチャーフラグ
アプリケーション実行時に処理の有効・無効を動的に切り替えるためのフラグ。
SaaS開発に限らず利用される手法。
【処理の優先度を設定】
テナントティアに応じて処理の優先度を設けたいケースがある場合。
（テナントティアに応じたリクエスト数の割り当て変更など）
（より上位のプランに加入しているテナントにSLAとして処理件数や処理時間などを保証する）
- スロットリングポリシー
一定時間内に処理可能なリクエスト数を制限すること。
※APIの提供時や複数の利用者が共通のシステムを利用するケースに採用されがち。
留意点：セキュリティ
数多くの企業や消費者に共通のサービスを提供し、データを預かる。また、多数のユーザーからのリクエストを処理し、データを管理しなければならない。
故にSaaS提供事業者は、同時に複数テナントに関する対策も求められ、管理の難易度は高く、責任範囲は広い。
○意識すべきポイント
【テナントを意識した設計が必要】
まず、すべてのSaaSに適した設計は存在しない
SaaSビジネスとしての、「要求事項」、「セキュリティ」、「コンプライアンス要件」、「マーケットセグメント」などあらゆる要素がアーキテクチャに影響を与えることを考慮する。
テナントは基本、分離をしなくてはならない。
- データ漏洩
マルチテナント構成において、初期段階からテナント間のデータ漏洩防止を明確に設計しておかないと長期的に重大インシデントを引き起こしかねない。SaaSは機密性が重視され、アプリケーションとデータは完全に分離されている必要がある。
- クロステナントアクセス防止
テナント同士が相互にアクセスできないようにリソース間に境界を設定し分離させなくてはならない。（共有する場合は適切なアクセス制御が必要）
【すべてのテナントリソースを分解する】
堅牢なSaaSアーキテクチャを実現する。
すべてのレイヤーにおいて分離の手段を講じ、テナントのリソースにはそのテナントのみがアクセス可能となるような構造にする。
【リソースへテナントを識別するタグを付与する】
テナントごとのリソースを分離する一つの方法として、各リソースへＩＤタグを付与すること。
テナントIDにより識別することで、データの参照可否制御やクロスアクセスの防止につながる。
【（テナントへの）アクセス制御の実装】
ユーザー認証情報をもとにアクセス可能であるリソースや機能を制御する。
【プロダクトやフェーズに応じたセキュリティの考慮】
求められるセキュリティレベルは異なる。実際に機密情報が蓄積されていない状態でセキュリティを必要以上に考慮するのは、俊敏性・迅速なリリースを欠いており、効果的ではない。
市場踏襲前の段階ではセキュリティリスクは軽微であるため、トレードオフにてきちんとリスクを把握し、俊敏性を優先した開発が必要になる。
マルチテナントの場合、どのテナントに属しているのか、境界を跨ぎやしないかなどマルチテナントSaaS特有のセキュリティへの考慮が必要。
開発ステップ
| ①競合・市場調査 | 立ち上げ予定のSaaSアイディアが市場投入・実装に値するものであるか、確認をとる。市場調査は競合他社の動向把握にもつながる。 |
| ②顧客の課題を明確化 | 顧客の悩みや課題を理解し、これから開発を予定しているSaaSプロダクトが解決につながるか。 顧客の属性や抱える課題など具体的な顧客のペルソナを設定し、どのような機能提供で解決できるか。 |
| ③ビジネスモデル選定 | 課金モデルなどのビジネスモデル選定を実施。 課金モデルとしては、広告収入やサブスクリプション収入など様々な方法がある。 最初の1か月間無料トライアルやフリーミアムの期間としてSaaSプロダクトを提供する方法もある。 提供するSaaSがどのようなポイントを提供し、その対価がどのように支払われるべきか事前に設計すること。 |
| ④コア機能の定義 | プロダクトの開発は小さく、かつ素早く始めることが重要。 すべての要件を実現するのではなく、前述のようにいかに早くプロトタイプを提供できるかを意識する必要がある。 スピード優先で素早いリリース。様々な機能のラインナップの中から優先順位をつけて、優先度の高い機能に絞って集中的に開発を行うこと。 |
| ⑤プロダクト開発 ロードマップ策定 | ・事業計画の策定 ・将来から逆算して、現時点とのすり合わせを行い、方針があっているか ・ロードマップは開発プロセスの計画や進捗状況に合わせて見直すこと ※ロードマップは計画や進捗を把握するよりも策定する過程の方が重要。 ※ロードマップ自体、常に変化するものであるため、顧客への公開は慎重に行うべき。 |
| ⑥MVPの開発 (Minimum Viable Product) | リリースまでに多くの期間を要する場合、競合他社に抜かされてしまう可能性がある。そのため、最小限の機能に留め、短い開発サイクルで可能な限りスピーディーに市場に投下することが大切。 |
| ⑦フィードバック収集と検証を繰り返す | MVPは一回市場に投下して終わりではない。 リリース後は利用した顧客から得られるデータの収集・分析に努めること。 【フィードバック収集方法】 ・ユーザビリティテスト ・チャット ・アンケート ・メール問い合わせフォーム ・ソーシャルメディア ・顧客へのインタビュー ・Web分析ツール |
環境構築の流れ
- テナント情報の設定（オンボーディング）
テナント名称、契約プラン、フィーチャーフラグの設定やテナントのステータスなどの情報を整理。 - テナントオンボーディングテスト
テナントがSaaSを利用開始するオンボーディングの場面において不十分な体験を提供しないか確認。（サービスへの期待感や信頼感の維持）
オンボーディングにおいてもインフラを新規にプロビジョニングする場合は、そのフローが正しく実施されるか、また契約の急増にも耐えられるかといったポイントを確認する。
・スロットリングテスト
想定しているスロットリングが正しく動作しているか確認する。
・クロステナントインパクトテスト
特定のテナントがシステムに過度な負荷をかけてしまうノイジーネイバーへの対処シミュレーションとして、実際のシステムに負荷をかけてテストを行う。テナント分離テストテナントが適切に分離され、セキュリティが担保されているかテスト。
- ユーザーの設定
・テナント内には管理ユーザーと一般ユーザーが必要。
・アクセス制御や権限設定ができるようにユーザー管理方法を設定する。
・最低限テナント管理ユーザーを作成する。 - 請求方法の設定
請求方法（定額制など）、また請求システムと連携して請求できるようにテナントオンボーディン時に請求システム側への登録が必要。 - インフラ環境の構築
SaaS開発に必要な6つの視点
①テナントという概念の思慮
- 隔離用企業のデータのセキュリティ担保とリソースの効率性、運用効率性をバランスよく両立させることが重要。
- 適切なテナント設計。テナントの概念を考慮したアーキテクチャ設計が非常に重要。
【新たにサービスの利用を開始する場合はテナントのオンボードが必要】
顧客がSaaSを利用開始する際に実施。
- テナントオンボーディング
新しい「テナント」の契約が決まり、サービス利用を開始する再任、その「テナント」をシステム内に新しく構成するプロセスのこと。一般的なSaaSではテナント管理、ユーザー管理、請求管理のそれぞれについて新しい「テナント」がサービス利用するためのプロビジョニング（準備）が必要になる。
※スケーラビリティを意識したオンボーディングの自動化がポイント。
・スクリプトなどを実行して自動化
・セルフサービスなどによる自動化
| サイロ モデル | テナント毎に必要なリソースを準備する構成。 分離レベルが高く、セキュリティリスクや性能問題において、他のテナントの影響を受けにくく、情報漏洩のリスクに強い。金融業界などセンシティブな情報を取り扱う業界に最適。テナントの数が多い場合はインフラコストや運用効率の面で工夫が必要。 【メリット】 ①テナントが求めるセキュリティ・コンプライアンスへ対応できる ②ノイジーネイバー問題が発生しない ③影響範囲の最小化 【デメリット】 テナント間でインフラストラクチャを共有しないため、コスト効率は悪い。 テナント毎に環境を構築することから、利用されないコンピューティングリソースも増えがち。構成の変更やパッチあてなど、メンテナンスの作業負荷も高くなる。  |
| プール モデル | リソースを複数のテナントで共有する構成。共有度が高く、インフラコストや運用効率の面でとてもメリットが大きい。 顧客数の拡大は多くのSaaSにとって目指すべき姿であり、顧客拡大において、 インフラコストや運用効率においてメリットがあるもののノイジーネイバー対策やテナントの境界線を意識した分離が必要。 【メリット】 ①コスト効率を高めやすい リソースを共有するプールモデルはコスト効率を高めやすい。 待機リソースを減らすことができる。 ②スピード感を持った開発 テナント毎の個別開発や個別対応が最小化され、新機能のリリースなども迅速に行える。 ③運用の簡素化 オンボーディング時の作業量を減らせるほか、自動化もしやすい。 【デメリット】 ①ノイジーネイバーの問題 特定のテナントが大きな負荷をかけることで、他のテナントが適切に利用できなくなる可能性がある。 ②テナントのシステム利用状況を追跡しにくい テナント毎のリソース利用量を把握しにくくなる。  |
| ブリッジ モデル | アプリケーションの処理を実施するサーバー部分は共有しつつ、データを格納するデータベースはテナントごとに分離するなど、一部はサイロ、一部はプールを適用するモデル。 特定のデータベースの分離、共有に最適。 ・サイロモデルより分離レベルが下がり、プールモデルより分離レベルが上がる。 データベース分離によりリスクが低下し、リソースの共有によりコスト効率を上げ、セキュリティリスクが下がるバランス型。 【メリット】 サイロモデル、プールモデルのどちらかに近いかにより、それぞれのメリットを享受できる。ノイジネイバーの対策が可能。 【デメリット】 ①サイロモデル、プールモデルのどちらかに近いかにより、それぞれのデメリットもある。オンボーディング時の個別対応が必要になる。 ②サーバー部分を共有しているため、サーバー処理が極端に多いテナントが存在すると、ノイジーネイバー問題を起こす。  |
| ハイブリッド モデル | 共有レベルと分離レベルのバランスをとった構成。 ※サイロモデルとプールモデルが「テナント」によって混在する構成。 ※ブリッジモデルの課題をさらに解決させることを目的とした構成。 ➡効率とセキュリティのバランスを考えることのできるカスタム性のあるモデル。 【例】特別なセキュリティ要件を求められた場合 プールモデルを提供し、極度に大きい処理や堅牢なセキュリティが必要になるテナントは、専用リソースで提供する。ノイジーネイバーは対応できるが、サイロ構成が増えるため、運用効率に支障をきたすことがある。  |
| ティアベース分離 | 利用プラン（ティア）ごとに分離方法を切り替える方法。ティアに応じた差別化したサービス提供。上位プランではリソースやデータベースの占有ができる。マルチテナントに機密データをのせることができない場合にも有効。 【メリット】 各企業からの個別要望に応えざるを得ないケースに有効。 【デメリット】 個別環境が増えすぎると運用負荷が増加する。 |
【テナントの分離】
SaaS設計・開発の基本かつ必須要素。各テナントは他人同士であり、当然ながら相互にデータを参照できてはいけない。テナントを確実に分離することで、お客様のリソースに他のテナントがアクセスできない状態を担保する必要がある。また、インフラ間でのテナント移動発生する場合を考慮すること。
- データとユーザーの統合・分解
あるテナントが分解した場合、ドンのデータがどのテナントに属するか整理のうえ、新規テナントにデータを移行しなくてはいけない。ユーザーも同様である。
- テナント分離パターン
サービスを提供する際には、サービスを提供するのに必要なリソースを共有してどのリソースを共有して、どのリソースを分離するのか検討が必要。
一方で、SaaS提供事業者は複数の企業から大切なデータを預かっており、仮にリソースを共有することで、他のテナントの情報に間違ってアクセスできる状態になった場合、顧客への損害賠償ならびに解約数の増大に発展する。
【テナント分離のポイント】
| ①事業目標 ・今後もSaaSビジネスをスケールアップさせていくのか ・少数の利用者に対して高い価値を提供するのか。 |
| ②提供するサービスの性質 ・提供する機能がミッションクリティカルな業務に利用されるものか。 ・多少のシステムダウンが許されるのか。 |
| ③顧客のニーズ 企業の必要条件を実現できるようなSaaSサービスであるか。 |
| ④開発・運用エンジニアのリソース ・SaaSビジネスの立ち上げ時点や初期リリース時点では、十分なリソースを確保できないケースもある。その場合、開発・運用負荷を下げやすいテナント分離方法を採用すべき。 ・ビジネス拡大においてリソース不足がボトルネックとならないように、機能の共通化や運用面における自動化もポイントとなる。 |
【テナントの境界を意識することの重要性】
自社のアーキテクチャがどのようにテナントを分離しているか、意識すること。
データベースレベルで分離しているのか、行レベルで分離しているのかによって、テストの重要度や必要な工数、作業時の注意レベルは変わっていく。
【テナントのデータ移動】
データの抽出と別の環境への挿入作業が必要。（ダウンタイムの確保が論点となる）
テナントティアごとにＤＢの構造が異なり、複雑な構造であった場合、データ移行自体をあきらめるのも一つの手段。
- データパーティショニング（データの分離方法）
どのようなレベルでデータストアを分離するか、テナント同士のデータを明確に分離する。
セキュリティ要件、コスト、パフォーマンスなどを考慮して適切なデータパーティショニングが必要になる。サービスの特性に応じた設計が必要になる。
図の左に行くほどセキュリティリスクやノイジーネイバーのリスクは減っていく。その反面、効率は悪くなる。右に行くほど、セキュリティリスクやノイジーネイバーのリスクは高くなる。
【分離方法】
| データベース分離 テナント毎に個別にデータベースを構築する方法。 テナントのデータはほかのテナントから完全に分離され、テナント毎にスキーマを餅、管理や管理なども個別に行うことができる。 | 【メリット】 ①テナント間のクロスアクセス防止 ②テナントレベルのSLA ③テナント毎の要件への対応 【デメリット】 ・管理の煩雑さ オンボーディングのプロセスではテナント毎にデータベースの構築や設定を行う必要がある。そのため、運用時には多数のデータベースに対して監視を行う必要がある。 ・コスト増加 テナント間でのリソース調整が難しい。 |
| 行分離 共通のデータベース・スキーマにて、すべてのテナントのデータを扱う方法。 テナントを区別するカラムを用意するなど、行レベルでの制御が必要になる。 行レベルでの分離ではカラムにテナントのIDなどの識別子を設定し、行単位でテナントのデータを分離する。 | 【メリット】 ①アジリティの確保 各テナントのデータベース環境を共通化できるため、機能拡張や取り扱うデータの追加において、変更を迅速に反映できる。 ②モニタリングと管理のしやすさ 単一のストレージやデータベースを管理するだけで各消費量・利用状況などのモニタリングや運用管理がしやすい ③コスト最適化 【デメリット】 ①影響範囲を狭めるための対策が必要 共通のストレージ環境で複数のデータを取り扱うため、そのストレージがダウンした場合、すべてのテナントがサービスを利用できなくなる。 ②特定のテナントにおける占有的な利用 特定のテナントがデータベースへ多数アクセスした場合に、他のテナントが十分なパフォーマン氏でサービスを利用できなくなる。 |
| スキーマ分離 共通のデータベース内に、テナントごとにスキーマを構築する方法。 | 【メリット】 データベース分離と行分離を両方享受できる。 テナント毎にデータベースを構築しないため、オンボーディングプロセスなどを簡素化できる。 【デメリット】 データベース分離と行分離のデメリットをうける。ノイジーネイバーの可能性がある。 |
| ハイブリッド テナントのニーズに応じて、それぞれの分離手段を組み合わせる方法。 物理的なデータベースは分離しつつも、データアクセス方法を分離方法によらず共通化することが有効。 |
②迅速なサービス改善を実現するアーキテクチャの検討
- クラウドサービスの活用
いかに価値の高いものにフォーカスして開発を進めるかは重要な要素である。
外部サービスを活用して、開発のボリューム減らすことが可能であり、専門性の高いサービスに対して利用することでリスクヘッジをすることができる。
➡顧客のニーズに向き合い、柔軟で迅速なサービス改善を実現することで顧客のサービス継続率を高めることができる。
- マイクロサービスの活用
１つの大きなアプリケーションを細かい機能・サービスに分解し、各単位の機能・サービスを連携させながらシステムを動かす。サービスを柔軟にかつ迅速に変化させる有効な手段の一つ。
【メリット】
| ①俊敏性を高める CI/CD 俊敏性を高めるCI（継続的インテグレーション）・CD（継続的デリバリー）を実現。 コード更新など影響範囲が限定的であり、影響分析・修正対応が用意。新しいアイディアや機能を実験的に試しやすい。失敗したとしても、ロールバックが可能。 |
| ②小さなチーム単位による俊敏な対応力 複数のコンパクトな組織に分解することで、各組織の活動効率や対応スピードの向上が期待できる。 結果的に、俊敏な対応力を持った組織が作られ、開発サイクルの短縮および生産性の向上につながる。あくまで大人数を想定しており、10数名の場合はそもそも機能しない。 |
| ③必要な機能だけ柔軟にスケーリング マイクロサービスで機能を分割することで特定の機能に絞ったスケーリングが容易になる。 |
| ④一部機能の再利用 ソフトウェアを小さい機能に分けるマイクロサービスは機能を組み合わせることで再利用が可能。 マイクロサービスにおける各機能は特定の明確な役割をもった構成要素として働く。 一度作成した構成要素は別のソフトウェアを作成する際に活用できる。 開発者はいちから機能開発を行う必要がなく、俊敏性の向上につながる。 |
| ⑤サービス独立によるアプリケーションの耐障害性の向上 マイクロサービスでは耐障害性も向上する。全体への影響を最小限に抑えられる。 しかし、マイクロサービスはオーバースペックになる可能性がある。そのため、モジュラーモノリスを検討するようにすること。 ※モジュラーモノリスとは サービス分割はしないが、同一コードベース内でモジュールを分けてモジュール間の依存関係がない形で実装する |
③セキュリティの強化
一般的なWebアプリケーションに求められるOWASP（Open Web Application Security Project）が提唱するセキュリティリスクに向き合う必要がある。
加え、「QWASP Top10」（2021）が掲げるセキュリティリスクTop10は要確認。
- アクセス制御の不備
- 暗号化の失敗
- インジェクション
- 安全が家訓印されない不安な設計
- セキュリティの設定ミス
- 脆弱で古くなったコンポーネント
- 識別と認証の失敗
- ソフトウェアとデータの整合性の不具合
- セキュリティログとモニタリングの失敗
- サーバーサイドリクエストフォージェリ（SSRF）
④拡張性の担保
SaaSはソフトウェアに価値を乗せ続けることで無限にスケール可能。当然、スケールに伴う運用コストは極力増大させないこと。ソフトウェア内で自動的な処理が望まれる。
（顧客の増加に比例して契約、アカウント開設、請求などの人手作業が増えないようにすること）
既存ユーザーばかりに偏らず、新規ユーザーが提供するSaaSサービスに対して、比較的理解しやすいように拡張性を見直し、サービスの有用性を実感させること。
- ユーザーオンボーディング（新規契約者の活用促進ミーティング）
顧客にサービスの使用方法を理解してもらい、自ら利用できる状態になってもらうこと。
顧客が困っていることやわからないことに対して、「マンツーマン」、「説明会」、「動画学習」など状況に合わせて提供する。
※UIや機能を作る。処理の自動化など、ユーザー側に負担をかけないように設計・開発段階で考慮しておくと有効。
⑤料金プランの設計と請求方法の確立
ビジネスのフェーズや提供する業務の種類や顧客ターゲットなど、様々な要素を考慮して自社のサービスに適した設定が必要。
自社でシステムを構築する方法と、サードパーティ（ビリングプロバイダー）が提供するサービスを利用する方法がある。いづれの方法でも、支払処理をするコンポーネントはメインサービスから独立させるべき。
（処理の内容や目的が異なるため）
※定額料金でなく、従量課金であれば課金の指標となるデータを毎月計測して利用料を決定すること。
| 料金プランの作成 | ○ペルソナの定義 どんな価値を提供するか明確にし、その対価としてどんな料金プランを作成するか。 別々の価値を提供するには複数の料金プランを準備して、プランによって提供する機能を明確化し、価格設定も別々にする。 ➡柔軟な料金プランの設定により適切にビジネスを成長させること。 |
| 価格設定 | ①プロダクト開発に要したコスト、サービス運用に必要なコストから料金を設計 SaaS開発では開発要員の増減などコストが変動する要素が多く、サブスクリプションでは利益を得られないケースがある。 ②競合プロダクトベースに料金を設計する 競合他社と類似した金額だと、コスト面において差別化を図る子ことができなくなるため注意。 ③プロダクトが提供する価値から料金を設計する ・SaaSプロダクトのコストや機能、サービスなどの観点から顧客への付加価値を考慮し検討する。 継続的な機能やアップデートやサービス改善に伴い、料金を段階的に上げていくことができる。開発コストを一定に抑えることができれば、プロダクトの成長に伴って収益性を高めていける。 |
- メータリング
ユーザーがSaaSをどのように利用しているか評価する指標。情報をビリングで活用することを目的とする。料金プランの設計後はメータリングで取得するデータによって料金が決定する。
SaaSは課金形態や料金プランによって、利用できる機能に上限があるため指標が必要になる。
メータリングの指標となるプランごとの料金を設定出来たら、ビリングユニットと組み合わせて使用状況を把握する仕組みを用意する。
※ビリングユニット：料金プランを設計するうえでベースとなるデータの組み合わせ
※SaaSの利用状況やサービス、機能の利用をイベントとして記録するために、メータリング用のAPIなどを用意するとよい。
- ビリング
SaaSの課金形態や料金プランに応じて、テナントに対して利用料金を請求する仕組み。
メータリングで得られた情報（利用料・アクティビティなど）を利用プランに紐づけ、課金額を算出する。ビリングの方法やメータリングで評価する対象の設計が必要。
※サードパーティを利用することでビジネスを加速させられる。
取り扱うデータの量が増加すれば、負荷が上がる。また請求額に直結するためミスの許容ができない。また、料金プランと合わせて従量課金がお客様の価値につながるか、本当にメータリングが必要なポイントがどこか、見極めた設計が必要。
⑥データの活用
顧客増加に伴い、すべての顧客の多種多様なアクティビティデータをSaaS提供事業者が保有できることが大きな特徴。（すべての顧客の行動データを把握）
テナントアクティビティのデータなどを使って、「どのプランにどの程度のコストが発生しているか」、「各プランの値付けが妥当であるかどうか」テナント別のコスト効率を把握すること。
そのために、システム内部の状態や統計データを観測可能な状態にし、SaaS利用者の体験向上につなげられるように分析すること。新しいナレッジや継続的な機能改善、ユーザー体験向上につなげる。
※リリース後も顧客のアクティビティデータやプロダクト稼働状況を様々な観点で監視・把握する必要がある。
【取得すべきデータ】
- テナントの活動状況の把握
→アクセス頻度、ログイン時間、テナントティアごとのアクティブなテナント数
→サービスを利用する期間、時間帯 - 処理パフォーマンス状況の把握
→テナントごとの処理の実施時間
→テナント毎の処理結果ログ - コスト、収益性の把握
→テナントティアごとのＣＰＵなどのリソース
→テナントティアごとのストレージ利用量など
- 可観測性
システムのアウトプット及ぼす影響をシステム内部の情報からいかに推測できるかの尺度。
下記ポイント３種を組み合わせることでタイムリーな検知・対処を実現。顧客のアクティビティデータやプロダクト稼働状況から得られる結果をもとに、新たな改善へとつなげていく継続的な活動はSaaSビジネスの成功に必要不可欠。
【可観測性の重要なポイント】
各テナントの活動状況を把握するためには、ツールの導入し、ログやメトリクスを収集。
※テナントに紐づけた形でログの出力やメトリクスの取得が必要（テナントIDで区別）
※考慮すべきポイントは「活動データの取得」「集計・可視化」
➡収集したデータはダッシュボードで表示
●メトリクス
システムのパフォーマンスや稼働状況の基準となる指標。
●ログ
運用していく中で不測の事態が起こった際などに、ログをたどることで不具合が発生している箇所、日時、ユーザー、端末などの詳細情報を把握できる。
●トレース
複数のシステムや機能をまたいで全体的にシステムの動作状況を追跡する考え方。
「システム全体として稼働状況に問題がないか」、「特定の箇所がボトルネックになっていないか」などを検知できる。
※これらのデータは膨大であるためデータレイクのようなプラクティスを活用し、必要なデータ加工（ETL処理）BIツールなどを用いて可視化できるようにするとよい。
【テナントのアクティビティデータを収集】
各テナントを区分したうえで、テナントが利用しているリソースを把握できるようにする。
テナントごとのシステム利用状況の把握は、SaaSビジネスとしてコスト算定や価格決めなどの根拠情報として活用できる。
- これらデータは管理ビュー上にて確認できるようにする。
- 運用業務として各テナントへの個別対応作業が想定される。
- 運用面を考慮して、各テナントのアクティビティやワークロードを確認できるビューが必要。
【テナントごとの消費リソースの監視と制御】
テナントティアを区別したサービスを提供するうえでリソース状況の確認。
※テナントがプランの制限量を超えてストレージを利用しようとした場合、利用にストップをかけるか、アップグレードを促すなどの対応が必要である。
【テナントの活動を把握】
アプリケーションにテナントを区別するためのコードを挿入し、テナントの活動を区別できるようにする。これらの情報をログファイルとして出力し、データウェアハウスなどを活用して分析。
【テナントの活動状況を可視化】
特定のテナントを抽出してデータを表示できるような環境を用意し、テナント別の傾向やシステム利用状況などをインサイトとして確認できるようにする。
※これらの情報を定期的に確認することで、システムの障害や停止を未然に防げる。
プロダクト開発手法
●BizDevOps
ビジネス部門、開発部門、運用部門の3者が一体となった密に連携した組織運営が重要であり、プロジェクトを推進するが概念や考え方。3者同一のゴールを設定し、目的達成のために各ロールが協調的に働く。結果が3者の効率、生産性を円滑なものとなるようにする。
- 各部門がデータを共有して定期的・定量的な視点からデータ分析できる。
- 共通のKPIやコミュニケーション方法を決めて生産性を高める工夫が必要。
【例】柔軟な機能追加と安定したシステムを導入するための自動化ツールの作成・導入
頻繁に機能の変更など改修を行う場合は、問題が発生しないように製品の信頼性を高める。
それにより、商品の販促にもつながる
【うまく機能しない場合】
①開発業務を外部の開発会社へ丸投げした場合
- 納品義務だけを背負っているため、仮説と検証を繰り返して成長させることができない
- 一括請負の場合は、システムの明確な完成基準が定められない
- 改修が一回で反映されないケースが多いと思われる
②ビジネス部門と開発部門が分断している場合
部門間のコミュニケーション不足や、要件のすり合わせ認識に齟齬が発生する
●MVP/プロトタイプ
※MVP(Minimum Viable Product)
最小単位で動くプロダクトを開発し、スピーディーにリリースすることでユーザーに体験を与え、早々にフィードバックを得ることができる。
- 仮説検証を行える価値のある最小のプロダクトをいかに素早くリリースできるか。最小プロダクトを早期にリリースしてユーザーからフィードバックを受けることが重要。
- アジリティの高い開発を実現するためには、ビジネス部門・開発部門・運用部門のシームレスな連携や協力が不可欠。
開発後
| 立ち上げ期 | ・潜在顧客のニーズ調査、ビジネスプランの立案、プロトタイプの準備 ※素早いプロトタイプの作成、展開により市場の反応を直接検証すること ・サービス利用者増加後はユーザー体験（UX）を調査する。 ・調査結果を製品に反映させて、ユーザー目線に立った、製品のニーズを理解する。 その後ユーザーの継続率を参照する。 ・ターゲットユーザの明確化 ・ユーザー満足度やユーザー継続率の把握 |
| 運用期 | ※顧客数がある程度増加していることが前提 ▲運用コストが増加させないこと SaaSの特徴としてスケーリングに柔軟性があるため、コスト効率性がわるくなる。 ➡運用コスト効率化のためには顧客数増加に伴う対応を自動化できるようにすること 【例】ユーザー自らログインできる、スケーリング機能など つまり顧客増大による運用コストを増大させないための自動化検討 |
| 成長期 | ※大幅に顧客数が増加していることが前提 各顧客との接点の確立が難しくなっていく状態。 ・顧客のアクティビティデータを収集・分析し、機能改善につなげていく継続的な取り組みが必要。 ・ユーザーの数が膨大であるときは要望が与えるビジネスインパクトに優先順位をつけて改善を進めていく。 |
オフボード
顧客がサービスの契約を終了した場合に必要な対応。
【オフボード処理】
- ステータスフラグで利用状況確認
- お客様に利用停止の連絡、通知。
【考慮事項】
- テナント内のデータにアクセスできる期限を検討。
- 法的な要件を考慮すべき
※契約書や注文書といった帳簿・書類や社会保険、雇用に関する書類などは法令上保管期間が定められている。 - 一定期間は再契約を見越してデータを保管するか、相手方に保持・削除を選択させるか。
【再オンボード時の対応】
ステータスフラグを変更する。テナントデータがあれば、ユーザー登録の手間が省ける。
No responses yet