© 2023 SaaS Engineering Meetup #SaaSEM SaaSにおける フィーチャーフラグ活用とそ 考え方 本セッション 「BtoB SaaSがカスタム開発 要望と向き合うに (https://saasus.io/blog/how-btob-saas-can-stand-up-to-the-demands-of-custom-development)」とい う拙作と合わせて参照いただくと、より理解が進むかと思います。

© 2023 SaaS Engineering Meetup #SaaSEM コードベースを一つに保つことについて Twelve Factor App Twelve Factor App 、モダンなWebアプ リケーション(SaaS)としてあるべき姿とし て、12 ベストプラクティスにまとめた方法 論として提唱されたも 下記 ようなSaaS ため 方法論 ● セットアップ自動化 ために 宣言的な フォーマット を使い、プロジェクトに新しく加わった開発者が要 する時間とコストを最小化する。 ● 下層 OSへ 依存関係を明確化 し、実行環境 間で 移植性を最大化 する。 ● モダンな クラウドプラットフォーム 上へ デプロイ に適しており、サーバー管理やシステム管理を不 要なも にする。 ● 開発環境と本番環境 差異を最小限 にし、アジリ ティを最大化する 継続的デプロイ を可能にする。 ● ツール、アーキテクチャ、開発プラクティスを大幅に 変更することなく スケールアップ できる。

© 2023 SaaS Engineering Meetup #SaaSEM コードベースを一つに保つことについて コードベースを一つに保つ もし複数 コードベースがある場合、それ アプリケーションで ない – それ 分散 システムである。

© 2023 SaaS Engineering Meetup #SaaSEM コードベースを一つに保つことについて メリットと成功事例 コードベースを一つに保つメリット ● コスト削減 ● 一貫性 維持 ● 迅速なリリース ● セキュリティ 強化 ● スケーラビリティ 向上 CRM SaaSをシングルコードで提供し、 成功してきた。 (出典：https://www.publickey1.jp/blog/10/post_116.html) で 、コードベースを一つに保つとして、 顧客セグメントごとに機能を出し分けたい時にどうするか？

© 2023 SaaS Engineering Meetup #SaaSEM フィーチャーフラグについて 古典的な記事があります Pete HodgsonさんというThoughtWorks 方が書かれた Feature Toggles(https://martinfowler.com/articles/feature-toggles.html) という記事が有名 フィーチャーフラグ 、 「チームがコードを変更することなくシステム 振る舞いを変更することができるも 」です。

© 2023 SaaS Engineering Meetup #SaaSEM フィーチャーフラグについて どれぐらい動的にトグル（変更）決定がなされるか？ どれぐらい長く フィーチャートグルが 生存するか

© 2023 SaaS Engineering Meetup #SaaSEM フィーチャーフラグについて リリーストグルズ これら 新しい機能 リリースを管理するために使用されます。リリー ストグル 、機能が完成してもすぐに ユーザーに公開せず、タイミン グを選んで展開する に役立ちます。 実験トグルズ これら A/Bテストや実験的な機能 テストに用いられます。特定 ユーザーグループに対して新しい機能を試験的に展開し、フィードバッ クやパフォーマンスデータを収集するために使用されます。 Ops トグル 運用上 問題に対応するために使われるトグルです。例え 、システ ム パフォーマンスが低下したときに特定 機能を無効にするなど、運 用上 柔軟性を提供します。 パーミッショントグル 機能 アクセス権を制御するために使用されます。これにより、特定 ユーザーやユーザーグループに み特定 機能を提供することができ ます。

© 2023 SaaS Engineering Meetup #SaaSEM SaaSにおける活用について プロダクトマネジメントを行い、プロダクト 価値を定義 パーミッショントグルを活用しコードベースを一つに保ちながら柔軟性を発揮する ベース機能 基本機能群 オプション機能 アドバンスド 機能群 エンタープラ イズ機能群 オプション② オプション③ オブション① C社 個社機能 B社 A社 D社 E社 SaaS標準 アドオン機能 カスタマイズ機能 顧客セグメント毎 要件 、機能群を準備して、別々 プラ ンで、別々 プライシングで提供する 共通的にどんな企業でもカスタマイズが必要な項目 、「カ スタマイズ機能」を提供する 一部 企業で必要となるが他社でも使える可能性がある機 能 、「オプション機能」として提供する 他 顧客で 絶対に使われない特殊な要件について 、 「アドオン機能」でカスタマイズ提供するが可能な限り最小化 する 検 討 順 序 要件 違い 実装方針

© 2023 SaaS Engineering Meetup #SaaSEM で 、何故これが可能な か？ SaaSにおける活用について フィーチャーフラグがあれ 安心というわけで ありません。 複雑性を排除する動きを常に取り続けなくて なりません。 Salesforce 、製品 使用状況 分析を含む広範なプロセスを用い、お客様と 直接的な対話 もちろん、 IdeaExchange を通じて寄せられたお客様 声にも耳 を傾けた上で、廃止する機能を決定しています。 Salesforce 目標 、お客様に 最大 価値をもたらす分野にリソースを投じること です。ゆえに、多く リソースを 消費する割に実現される価値が小さい機能や、ごく限られたお客様 みに価値が 限定される機能など 廃止もやむを得ない という判断が下されることがあります。 機能が廃止されれ 、一部 お客様に 一時的な混乱が及ぶこと 承知しており ます。ただし、長期的に見れ 、 最も優先順位が高い分野にリソースを注力してい くことが、お客様やパートナーコミュニティに最大 利益をもたらすことになると確 信しています。 https://help.salesforce.com/s/articleView?id=000387126&type=1

© 2023 SaaS Engineering Meetup #SaaSEM SaaSにおける活用について 機能ごとに利用状況を分析しビジネスへ 貢献度を可視化 ex) ● テナントティアごと 利用率 ● テナントごと 利用率 ● 日次ごと 利用率 ex) ● テナントごと MRR ● チャーンレート ビジネスとソフトウェアが一体になったビジネスモデルがSaaSです