フィーチャーフラグの導入（1）どのような方法があるか？
ここまでの説明でフィーチャーフラグシステムのイメージは掴んでいただけたでしょうか？ 次はプロダクト開発へフィーチャーフラグを導入する場合に、どのような実現方法があるかについて説明します。フィーチャーフラグの仕組みの実現方法にも、簡易的なものから本格的なものまでさまざまなものがあります。
環境変数や設定ファイルによるフィーチャーフラグの管理
多くのプロダクトでは、アプリの設定を行うために環境変数や設定ファイルを使用しているかと思います。これらをアプリの起動時に読み込んで、振る舞いを切り替えたい箇所で参照することで、簡易的なフィーチャーフラグとして使用することができます。
この方法のメリットは、特別な仕組みを導入することなくすぐに使用できることです。注意点としては、フィーチャーフラグの値の変更にはアプリケーションの再起動が必要であることや、動的なフィーチャーフラグとして使用するのが難しいことが挙げられます。また、複数のクライアントアプリやマイクロサービスがある場合に、フィーチャーフラグの設定の一元管理もできません[注2]。
- [注2] Feature Toggles (aka Feature Flags)（Pete Hodgson）
フィーチャーフラグシステムを内製
システムを内製する場合にもいくつかの方法があります。
データベースによるフィーチャーフラグの管理
RDBやKVSなどのデータベースを使用してフィーチャーフラグを管理する方法です。フィーチャーフラグの設定を保存するデータベースに加え、フィーチャーフラグを編集するためのWebコンソール、アプリからフィーチャーフラグを取得するためのAPIを実装する必要があります。
この方法のメリットは、チーム内で必要な機能を柔軟に提供できることです。また、複数のクライアントアプリやマイクロサービスからフィーチャーフラグを使用する場合でも、フィーチャーフラグの設定はデータベースで一元管理することができます。注意点としては、簡易的なフィーチャーフラグシステムであれば比較的容易に実装・運用できますが、本格的なものを構築するためには考慮すべき事柄が多く難易度が高いという点です。また、システムの構築や運用のためのコストもかかります[注3]。
OSSの使用
データベースを使用して一からシステムを実装する代わりに、既存のOSSを使用する方法もあります。FF4Jのような単一プログラミング言語・プラットフォーム対応のもの、Unleashのような複数のプラットフォーム用のSDKを提供しているもの、また、機能が少ないものから高機能なものまでさまざまなものがあります。
この方法のメリットは、既存のOSSを使用するため、システムの実装が不要となることです。注意点としては、一般的なOSSの導入時と同様、必要な機能が提供されているか、アクティブに開発・保守されているかといった点を確認する必要があります。また、実装は不要となりますが、運用コストがかかる点も考慮すべきです[注3]。
社内共通システムとして構築
他の方法はチーム内でフィーチャーフラグシステムを構築して使用する場合の説明でしたが、こちらは社内の複数のシステムから使用する場合の方法です。巨大テック企業では、社内共通システムとしてフィーチャーフラグシステムやABテストシステムを構築していると前回の記事で説明しましたが、複数のチームで大規模にフィーチャーフラグを使用する場合は検討する価値があります。
この方法のメリットは、社内共通システムの使用する側のチームの時間や料金を削減できることや、社内データ基盤との連携といったサードパーティー製サービスでは実現が難しい機能を提供できる可能性があることです。注意点としては、フィーチャーフラグシステムの開発・運用のために専用のチームが必要になることなど、大規模な投資が必要になる点です。
- [注3] Feature Management Platform: Build or Buy?（LaunchDarkly）
サードパーティー製サービスを導入
最後にサードパーティー製サービスの導入について説明します。デモで説明したFirebase Remote ConfigやLaunchDarklyなど、こちらも機能が少ないものから高機能なものまで、また、月々の料金が比較的安いのものから高いものまでさまざまなものがあります。
この方法のメリットは、代表的なフィーチャーフラグシステムでは豊富な使用実績があるため安心して使用できることや、導入や運用にかかる時間的なコストが内製よりも少なくなることです。注意点としては、それなりの料金がかかる可能性がある点や、自社プロダクトのニーズに完璧に応えることができない可能性がある点が挙げられます。
