SaaSにおけるフィーチャーフラグ活用とその考え方

こんにちは、小笹です。
SaaSus Platform(https://saasus.io/)についてお客様とお話をさせていただきますと、「うちはお客様ごとにカスタマイズをしているのでSaaSにしていくのは難しい」というお声をいただくことがあります。

その際にプロダクトマネジメントのお話やフィーチャーフラグのお話をさせていただくのですが、その場その場でお話しする形になってしまうので、振り返りやすいコンテンツとして本ブログを執筆することにいたしました。

なお、本記事は「BtoB SaaSがカスタム開発の要望と向き合うには(https://saasus.io/blog/how-btob-saas-can-stand-up-to-the-demands-of-custom-development)」という拙作と合わせて参照いただくとより理解が進むかと思います。

Twelve Factor Appについて

まず、コードベースを一つに保つということについてです。
これはTwelve Factor Appというものでもその重要性が説かれています。
Twelve Factor Appは、Herokuプラットフォーム上で開発・運用・スケールした何百何千ものアプリケーションから得られた知見をモダンなWebアプリケーション(SaaS)としてあるべき姿として、12のベストプラクティスにまとめた方法論として提唱されたものです。提唱されたのは2012年ですが、いまだに色々な場面で引用されるある種古典的な考え方になっています。

その1番最初に来るのが、コードベース「バージョン管理されている1つのコードベースと複数のデプロイ」です。

もし複数のコードベースがある場合、それはアプリケーションではない – それは分散システムである。
という表現がなされているくらいその重要性が説かれています。

では、コードベースを一つに保つとして、顧客セグメントごとに機能を出し分けたい時にどうするか、その際に考えられるのがフィーチャーフラグの活用です。

フィーチャーフラグについて

まずはフィーチャーフラグについて理解を深めましょう。
Pete HodgsonさんというThoughtWorksの方が書かれたFeature Toggles(https://martinfowler.com/articles/feature-toggles.html)という記事が有名です。(最近はトグルでなく、フラグと表現することが多いようです。)
こちらも2017年頃で少し古いものですが、古典的な価値を帯びています。

簡単にフィーチャーフラグを表現すると、「チームがコードを変更することなくシステムの振る舞いを変更することができるもの」です。これによりカナリアリリースやABテストなどをスムーズに実現することができるようになります。

詳細は翻訳記事(https://qiita.com/TsuyoshiUshio@github/items/51c6662cd45bded95389)もありますのでご参照いただくのが良いかと思いますが、フラグのカテゴリをご紹介します。

フラグのカテゴリ

リリーストグルズ

これらは新しい機能のリリースを管理するために使用されます。リリーストグルは、機能が完成してもすぐにはユーザーに公開せず、タイミングを選んで展開するのに役立ちます。

実験トグルズ

これらはA/Bテストや実験的な機能のテストに用いられます。特定のユーザーグループに対して新しい機能を試験的に展開し、フィードバックやパフォーマンスデータを収集するために使用されます。

Ops トグル

運用上の問題に対応するために使われるトグルです。例えば、システムのパフォーマンスが低下したときに特定の機能を無効にするなど、運用上の柔軟性を提供します。

パーミッショントグル

機能のアクセス権を制御するために使用されます。これにより、特定のユーザーやユーザーグループにのみ特定の機能を提供することができます。

ユースケースについて

こういったものによって様々なユースケースに対応することができます。
フィーチャーフラグSaaSであるLaunchDarklyが様々なケースを紹介しています。
https://github.com/launchdarkly/featureflags/blob/main/2 - Uses.md

実装のイメージについて

また、実装のイメージを沸かせたい方は下記の記事を参照するのが良いでしょう。
https://zenn.dev/ascend/articles/feature-flag
https://logmi.jp/tech/articles/329505

SaaSにおける活用

前提となる知識を得たとして、SaaSにおいてこれらをどのように活用すれば良いでしょうか？
当然、4種類あるカテゴリは全て活用することができますが、特に活用するのはパーミッショントグルになるでしょう。

SaaSにおいてはティアという考え方があります。プレミアティアやスタンダードティアなど、顧客の層を指した表現になります。通常はプランと紐づいて収益構造を成しているものです。

ティアによって提供する価値を変えるために、ティアごとに提供機能が異なることは一般に起こり得るものかと思います。

もしくは、オプション機能なども考えられます。これはオプション契約テナントにのみ機能を提供するものです。これもイメージしやすいかと思います。

そして、特定顧客への提供です。所謂カスタマイズに近い部分ですが、ここは限界まで排除するように検討を進めていくことが重要です。顧客ごとにカスタマイズが必要なのであれば、その部分のみカスタマイズがある程度可能なコンポーネントを提供するような、顧客がカスタマイズできる機能を提供するよう努める必要があります。(イメージはKintoneなどのようなものでしょうが、開発するのはコストがかかります)

ティア、オプション、カスタマイズ、どれについても検討を進めるに当たっては、ビジネスプランとプロダクトマネジメントを一致させていくことが重要になります。

SaaSはビジネスとソフトウェアが絡み合ったビジネスモデルです。ビジネスのことを考慮せずにソフトウェアを複雑化することは避けねばなりませんし、逆も然りです。
フィーチャーフラグを活用するとコードベースを一つに保ちながら、確かにプロダクトを柔軟に提供することができるようになりますが、乱用は避けねばなりませんし、無限に拡張することは現実的でありません。
フィーチャーフラグに関してドキュメンテーションをしたり、適切な管理を実施しないと、むしろ運用を煩雑にしてしまうリスクを抱えることになります。

機能の廃棄について

そこで重要なのは機能を廃棄することです。

模範的な例として、Salesforceは定期的に機能を廃棄する方針を示しています。(https://help.salesforce.com/s/articleView?id=000387126&type=1)

Salesforce は、製品の使用状況の分析を含む広範なプロセスを用い、お客様との直接的な対話はもちろん、IdeaExchange を通じて寄せられたお客様の声にも耳を傾けた上で、廃止する機能を決定しています。Salesforce の目標は、お客様に最大の価値をもたらす分野にリソースを投じることです。ゆえに、多くのリソースを消費する割に実現される価値が小さい機能や、ごく限られたお客様のみに価値が限定される機能などは廃止もやむを得ないという判断が下されることがあります。機能が廃止されれば、一部のお客様には一時的な混乱が及ぶことは承知しております。ただし、長期的に見れば、最も優先順位が高い分野にリソースを注力していくことが、お客様やパートナーコミュニティに最大の利益をもたらすことになると確信しています。

素晴らしいですね。

これが実現可能なのは、機能ごとに利用状況やビジネスへの貢献度を可視化しているからでしょう。
利用状況分析などは顧客価値を最大化する上で、非常に重要なアクションになります。

ここで注意が必要なことは、SaaSは単なる機能の提供ではなく色々な企業のワークロードを把握しているからこそ可能な「ベストプラクティスの提供」であるという点です。
つまり、仮に利用率が低くても顧客への貢献度が高いのであれば、その機能を顧客に啓蒙していくなどのアクションが必要になってきます。

以上です。
SaaSって奥が深くて楽しいですね！