フィーチャーフラグの導入（2）どの方法を選ぶか？
ここまでで、フィーチャーフラグの導入方法とそれぞれのメリットや注意点を説明しました。次は、実際に導入する際の参考となるように、各方法の比較やよくあるパターンの説明をします。
各方法の比較
各方法について、3つの観点から比較します。このような観点を踏まえ、現在求める要件や将来的に変化しそうな要件に照らし合わせて、フィーチャーフラグの導入戦略を決定する必要があります。
チームの規模
数人程度の少人数で開発している場合は、実現したい要件にマッチしている限り、環境変数や設定ファイルの使用で十分な場合も多いです。チームの規模が大きくなってくると、フィーチャーフラグの管理が難しくなったり、要件が増えたりすることで、データベースやOSSによるフィーチャーフラグシステムの構築や、サードパーティー製サービスの導入の検討が必要となります。さらに、複数のチームで大規模にフィーチャーフラグを使用する場合は、時間や料金といったコストの削減や独自機能の提供を目的として、社内共通システムとして構築を検討する価値があります。
実現したい要件
ThoughtWorks社のTechnology Radarでも言われているように[注4][注5]、例えば実現したい要件がトランクベース開発による開発フローの改善のみの場合に、高機能なフィーチャーフラグシステムは必要ありません。このような場合は、環境変数や設定ファイルの使用、シンプルなフィーチャーフラグシステムの構築、シンプルなサードパーティー製サービスの導入などで十分だと考えられます。一方で、ABテストやカナリアリリースなどを実現したい場合は、フィーチャーフラグシステムの一般的な機能を一通り備えたシステムが必要になります。さらに、社内データ基盤との連携といったサードパーティー製サービスでは実現が難しい機能が必要な場合には、社内共通システムとして構築を検討する必要があります。
導入のためのコスト
フィーチャーフラグシステムの構築や運用に人や時間を投資することが難しい場合は、サードパーティー製サービスの導入によって、導入までの時間的なコストを削減することができます。また、OSSを使用することでシステムの運用コストはかかりますが、実装コストは削減できるため、何らかの理由でサードパーティー製サービスの導入が難しい場合は検討する価値があります。
各方法ごとに使用状況に応じて料金も変わってくるため、料金についても事前によく検討する必要があります。一般的には、使用規模が小さいうちはサードパーティー製サービスの方が料金が安くなりやすく、使用規模が大規模になると内製の方が料金が安くなりやすいと考えられます。
- [注4] Technology Radar Vol.22（ThoughtWorks）
- [注5] デジタル企業ではすでに常識！100%自動化したソフトウェアデリバリー 【世界のエンジニアに学ぶ】（日本CTO協会）
よくあるパターン
プロダクト開発チームがフィーチャーフラグシステムを導入する際、次のような流れを辿ることが多いと言われています[注6]。
- 初めは、環境変数や設定ファイルを使用した簡易的なフィーチャーフラグの仕組みを導入します。
- チームの規模の拡大や実現したい要件の増加に伴い、データベースを使用したフィーチャーフラグシステムを構築します。
- チームや会社でのフィーチャーフラグの重要性が高まると、サードパーティー製サービスを導入する、もしくは社内共通システムとして構築するといったことが行われます。
もちろん2を飛ばして1から3に移行するケースなどもありますが、筆者の経験からもよくある流れだと感じます。フィーチャーフラグをチームで試してみたい場合は、まず1から始めてみると良いかもしれません。
- [注6] 『Effective Feature Management』（John Kodumal、O'Reilly Media, Inc.、February 2019）
