SaaS開発ガイド【基礎編】
BtoB SaaSがカスタム開発の要望と向き合うには
BtoB SaaS企業にとって、顧客からの開発要望をヒアリングし、適切に機能として提供することは、ビジネスの成功に欠かせません。しかし、特定顧客の要望だけを叶えるようなカスタム開発には多くの問題が伴い、プロダクトのメンテナンスや将来的なアップグレードにも影響を与える可能性があります。本記事では、1つのコードベースを保ちつつ、フィーチャーフラグを導入することで、適切に顧客からの要望に対応する方法について説明します。
BtoB SaaSにおけるプロダクトマネジメントの難しいポイント
BtoB SaaSにおいて顧客をティア(層)ごとに適切に扱うことは大変重要です。BtoB SaaSはある意味で飛行機のようなもので、一つのプロダクトを様々なテナント(≒契約企業)が相乗りをしながら価値を享受するモデルになっています。
当然、ファーストクラスのテナントもいれば、エコノミークラスのテナントもいます。これらを適切に分離しながら、それぞれのティア(クラス)に応じたサービスを提供をしつつも、十分にテストされ一定の品質が担保されたサービスを提供していくことになるわけです。
ここで重要なのは、より上位のティアのテナントが収益性の源泉となっているという構造そのものです。
つまり、如何にして上位のティアにより多くのテナントが移行できるか、また、上位のティアのテナントが解約せずにSaaSを利用し続けてもらえるかがビジネスの成長に大きく関わってきます。
ここでプロダクトマネジメントとして難しいのが「上位ティアの顧客からのカスタム要望をどこまで叶えていくか」という点です。
当然、収益性の高いテナントからの要望ですので、叶えて収益が確保されるなら取り組むべきであると考えがちですが、果たして本当にそのようにすべきでしょうか。一度立ち止まって検討を重ねる必要があります。
SaaSが1つのコードベースを保つべき理由
前提として、SaaSは1つのコードベースを保つべきであるとされています。それには様々な理由があります。
1.コスト削減
複数のコードベースにすることは、開発コストやメンテナンスコストがかかります。1つのコードベースを保持することで、開発チームやメンテナンスチームのコストを削減することができます。
2.一貫性の維持
複数のコードベースにすることで、バージョン管理が複雑になり、バグの発生原因を特定することが困難になる場合があります。1つのコードベースを保持することによって、一貫性のあるプロダクトを維持することができます。
3.迅速なリリース
複数のコードベースにすることで、バグ修正や新機能のリリースに時間がかかる場合があります。1つのコードベースを保有することによって、迅速なリリースを実現することができます。
4.セキュリティの強化
複数のコードベースを保有することは、セキュリティ管理が複雑になる場合があります。1つのコードベースを保有することによって、セキュリティ管理の強化にも繋がります。
5.スケーラビリティの向上
複数のコードベースを保有することは、場合によって環境ごとに別コードベースを適応する必要が出てくるなど、インフラストラクチャの複雑性を高め、スケーラビリティの問題を引き起こす場合があります。1つのコードベースを保有することによって、スケーラビリティを向上することができます。
以上のように、SaaSが1つのコードベースを保つことによって、コスト削減、一貫性の維持、迅速なリリース、セキュリティの強化、スケーラビリティの向上などのメリットがあります。
加えて、SaaSはいわばベストプラクティスの集約であり、様々な顧客の業務をソフトウェアによって効率化したり変革するようなモデルであるため、特定の顧客だけの機能を提供すべきではないという思想的な面も考慮すべきでしょう。
SaaS企業として成功を収めているといえば、やはり有名なのはセールスフォースでしょう。そのセールスフォースは当初から1つのコードベースを保つことを重要視しており、米国の計算機学会として知られるACMが主催したクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」において、”CRMのSaaSをシングルコードで提供し、成功してきた。”としています。(出典：https://www.publickey1.jp/blog/10/post_116.html)
解決策としてのフィーチャーフラグとは
特定のテナントからの要望が他のテナントにも有用であるかは要件をしっかりとヒアリングを重ね、慎重に検討すべきです。
しかしながら、その要望を叶える機能開発が仮説検証のためであったり、どうしても叶えないとビジネス上問題になる場合、どう対応すれば良いのでしょうか。
1つのコードベースを保ちながら特定のテナントもしくはテナント群にのみ機能を提供するとなった場合には、フィーチャーフラグの導入を検討するのが良いでしょう。
フィーチャーフラグとは、プロダクトの機能を有効にしたり無効にしたりするために使用するフラグのことです。例えば、特定のテナントが必要とするカスタマイズ機能が、あるメニュー項目の表示／非表示である場合、メニュー項目を管理するフラグを導入することでそのメニューの出し分けを制御することができるようになります。
フィーチャーフラグは、テナントティアごとの機能の出し分けだけでなく、実験の機能、運用のための機能、リリースタイミングの調整などにも活用できます。
参考：https://martinfowler.com/articles/feature-toggles.html
フィーチャーフラグを導入するにあたっての注意点
フィーチャーフラグのテストを実施する
フィーチャーフラグを導入する場合、それをテストする必要があります。特定のテナントの要望に応じてフラグを切り替えることによって、プロダクトが適切に動作することを確認するため、テストを実施する必要があります。テストを実施することによって、フィーチャーフラグの設定ミスやプロダクトの品質低下を防ぐことができます。
フィーチャーフラグを適切にドキュメント化する
フィーチャーフラグを適切にドキュメント化することによって、プロダクトの品質を維持することができます。特定のテナントの要望に応じてフラグを切り替えることによって、プロダクトの機能が増えるため、それらの機能がどのように機能するかをドキュメント化する必要があります。また、フラグを誤って設定することによって、プロダクトの品質が低下する可能性があるため、適切にドキュメント化することが必要です。
フィーチャーフラグを管理する
フィーチャーフラグを適切に管理することによって、プロダクトの品質を維持することができます。フラグの追加や削除を行う場合には、適切な承認プロセスを導入し、適切に管理することが必要です。また、フラグの設定ミスによってプロダクトの品質が低下する可能性があるため、適切な管理を行うことが重要です。
フィーチャーフラグSaaSの紹介
フィーチャーフラグは自身で実装することもできますが、それ自体をSaaSで実装することもできます。以下は代表的なフィーチャーフラグSaaSです。
- ・LaunchDarkly(https://launchdarkly.com/)
- ・Split(https://www.split.io/)
- ・Optimizely Experimentation(https://www.optimizely.com/products/experiment/feature-experimentation/)
フィーチャーフラグ以外の方法
機能をメタデータ化し、ユーザ自身が変更可能にすることによって、ユーザが自らニアカスタマイズが出来るようになるようにアプリケーションを作ることによって、同等の効果を得ることもできます。この方法は機能開発が必要になりますので、コストや効果を見合わせながら検討をしましょう。
【結論】
BtoB SaaS企業が顧客からのカスタム開発の要望と向き合うためには、適切なプロダクトマネジメントが必要です。その上で、1つのコードベースを保ちつつ、フィーチャーフラグを導入することで様々なシチュエーションに対応ができます。フィーチャーフラグを適切に運用することによって、顧客の属性などに合わせて適切に機能を提供することができるようになります。しかし、フィーチャーフラグを導入・運用するにあたっては、適切なテストやドキュメント化、管理が必要となりますので、その点は注意しましょう。
E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。
SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。
Spread the word:
