フィーチャーフラグのメリット（1）より早く、ストレスレスで開発できる
フィーチャーフラグのアイデア自体はアプリの振る舞いを動的な変更するシンプルな手法ですが、プロダクト開発を大きく変える可能性を持っています。ここからは、フィーチャーフラグのメリットについて見ていきます。
フィーチャーフラグはトランクベース開発や継続的デプロイメントを容易に実現します。これにより従来の開発プロセスの速度を向上させ、開発者のストレスが軽減できます。
トランクベース開発
トランクベース開発[注8]とはソースコードのリポジトリをシンプルに保つことで、ストレスレスで安全な開発フローを実現する手法です。簡単に説明すると、メインとなるブランチ（「トランク」とも呼ばれます）から数日以内でマージするフィーチャーブランチをチェックアウトして小さなコミットを作り、すぐにトランクにマージする作業を繰り返し行います。これにより以下のメリットが期待できます。
- レビューが楽になる：変更箇所は最小限に抑えることで、プルリクエストのレビューのストレスが軽減されます。
- バグが減る：変更箇所のスコープが狭くなることにより、バグが入り込むリスクを減らします。
- コンフリクトが起きなくなる：短期間でマージすることにより、マージする際のコンフリクトを減らします。
上記のメリットは、開発が進み、チームが大きくなるとともに複雑化する開発が、シンプルかつスケールすることを可能にします。
注釈
- [注8] Trunk Based Development（Paul Hammant）
フィーチャーフラグでトランクベース開発を実現するには
フィーチャーフラグを使用することにより、開発中で未完成の新しい機能をフラグでオフに設定しておき、次々とメインのブランチにコミットを積み上げることができます。最終的に機能が完成したタイミングでフラグをオンにすることでユーザーにその機能をリリースします。
同一バイナリで異なる振る舞いを管理する
また、すべての開発中の機能はメインのブランチにフラグがオフの状態で取り込まれています。もしQAチームが開発中の機能のテストを行いたい場合は、ユーザーにリリースしているのと同一のバイナリを使用して、QAチームのみフラグをオンにすることでテストが可能です。
並行QAの実現
さらに、従来の開発、QA、申請、リリースと順番に行っていたリリースフローを開発が終わった段階ですぐに申請へ進み、申請が承認されるまでの時間でQAを並行して行うことで開発サイクルを短縮できます。
継続的デプロイメント
継続的デプロイメントとはDevOpsの文脈でよく使用される用語であり、新しいコードが自動テストに合格すると、直ちにエンドユーザーにデプロイされる一連のリリースフローを指します。
ここで重要になるのはデプロイメントとリリースを分離する必要があるということです。継続的デプロイメントを採用した開発では新しいコードは次々とユーザーに届けられますが、実際に新しい機能をユーザーに使ってもらうタイミングはマーケティングやキャンペーンによって前後することもありますし、機能の一部が未完成のままの場合は完成を待って触ってもらいたいなど、開発プロセスとは異なるタイムラインで動いていることがあります。そこでデプロイは開発プロセスに合わせて逐次行うが、リリースは各プロジェクトの戦略に基づいて決定すると行った形で、デプロイとリリースの2つを分ける必然性が生まれます。
フィーチャーフラグで継続的デプロイメントを実現するには
継続的デプロイメントにフィーチャーフラグは不可欠な要素ではありません。しかし、フィーチャーフラグを利用することで、継続的デプロイメントが比較的容易に実現できます。
たとえば、リリース日が決まっている数カ月を要する大規模な施策があった場合、フィーチャーフラグで新機能をオフにした状態でコミットとデプロイのサイクルを回して機能を完成させ、十分なテストを実施しておきます。最終的にリリース日時にフラグをオンにすることで簡単にエンドユーザーにリリースが可能です。
加えて、従来リリース後にバグが見つかった場合、修正版をコミットしてリリースを実施するか、ロールバック作業が必要になります。
一方、フィーチャーフラグで新機能をラップしておけば、ボタンを押すだけで、ものの数秒で機能をオフにして被害を最小限に留めることが可能です。
フィーチャーフラグのメリット（2）本番環境でのテストが可能になる
フィーチャーフラグは本番環境でのテストを可能にします。モダンな開発では、スピード感をもってプロダクトを段階的に進化させていくとこで、エンドユーザーのニーズに素早く答えていくことが要求されます。フィーチャーフラグはそうしたユーザーのフィードバックを得るために、開発者に本物のユーザーでアプリをテスト、検証する機会を提供します。
前述したように、多くのフィーチャーフラグシステムには特定のユーザー群にのみ機能をオンにする機能や、任意の割合のユーザーのみ設定したフラグ値を返す機能が備わっています。こうした機能を使用すれば、リリースフローに本番環境でのテストを組み込むことができるようになります。ここからは、さまざまなリリース手法やテスト手法における、フィーチャーフラグの活用方法を見ていきましょう。
カナリアリリース
カナリアリリースとはアプリの新しいバージョンを少数のユーザー群にリリースし、問題がないか確認した後にすべてのユーザーにリリースする手法です。リリースにバグが含まれていた場合でも少数のユーザーのみに障害範囲を限定できます。
フィーチャーフラグでカナリアリリースを実現するには
フィーチャーフラグを使用してカナリアリリースを実施するには、新しい機能をフィーチャーフラグでラップし、少数のユーザー（例：全体の1％）のみフラグをオンにするなどしてモニタリングシステムなどで問題がないことを確認します。十分に確認をした後にすべてのユーザーにロールアウトします。
ベータリリース
ベータリリースとは一般提供（GA）を開始する前に一部のユーザーに新しい機能を試してもらい、バグ報告や実際に使った際のフィードバックを反映した後にすべてのユーザーに対してリリースを行う手法です。フィーチャーフラグを利用することで一定の条件を満たしたユーザーのみ機能をオンにすることが可能になります。
その他のリリース手法
その他に近い手法として、リリース前に（一般的に告知なく）一部ユーザーに新機能や異なるバージョンをリリースしてモニタリングするダークローンチ、社内ユーザーのみにリリースするドックフーディングといった手法があります。このようなリリース手法に関してもフィーチャーフラグは有効な手段になります。
ABテスト
ABテスト[注9]とはランダムに分割したユーザー群へ異なる施策を適用して、比較するという対照実験です。具体例として、従来のレコメンドアルゴリズムと改良版のアルゴリズムを異なるユーザー群に適用して、コンバージョン率を比較・分析し、より良い方をすべてのユーザーに採用するといった具合です。ABテストの大きなモチベーションの1つはデータドリブンで開発を推し進めていくことができる点です。社内で大きな期待をかけて開発した新機能もユーザーに使ってもらわなければ意味がありません。チーム内で改善を続けても開発者が気になる点が実際のユーザーが気になる点と異なる場合も考えられます。ABテストは「本当のユーザー」が何を求めているのかを教えてくれます。
注釈
- [注9] 『A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは』（Ron Kohavi、Diane Tang、Ya Xu著、 大杉直也訳、ドワンゴ、2021年3月23日）
フィーチャーフラグでABテストを実現するには
ABテストは異なる施策を異なるユーザー群に適用することから、フィーチャーフラグシステムと不可分であるといっても過言ではありません。異なる施策をフィーチャーフラグでランダムにクライアントへ割りあて、最終的なコンバージョンをモニタリングシステムで測定することによりABテストは完成します。本連載でこれから紹介するフィーチャーフラグシステムもABテストの機能をはじめから持っているものや、外部のモニタリングシステムとのインテグレーションによって比較的簡単にABテストを実施できるようにするものが多く存在します。
