tldr

フィーチャーフラグを使用することにより、トランクベース開発が可能になりダークランチやベータリリースが可能になります。これにより、短いサイクルでの機能開発やA/Bテストによる効果測定を実現し、ユーザーへの価値提供をより高めていくことができます。

この記事は「サイバーエージェントのフィーチャーフラグを活用した高速開発」というタイトルの発表の内容が元になっています。発表はYoutubeで公開されています。

スライドはこちらから閲覧可能です。

フィーチャーフラグと開発の関係性について

フィーチャーフラグとは？

フィーチャーフラグとは簡単に言うと 静的または動的に機能のオンオフを切り替える手法です。例えばフィーチャーフラグがオンの場合はアプリである機能がオンになります。フィーチャーフラグがオフの場合はその機能がオフになってユーザーがに露出されないようになります。これがフィーチャーフラグの一番簡単な説明になります。

コードで書くとこんな感じになっています。

フラグの値はオン／オフである必要はありません。 例えば、カラーコードや文言です。

また、フラグの値は3パターン以上のときもあります。例えばa/b/cの3種類でも問題ありません。

ユースケース

フィーチャーフラグさまざまな場面で活躍します。

限定的なリリース

その1つが限定的なリリースです。例えばベータユーザーに対して、もしくは課金をしてくれているプレミアムユーザーに対してのみある機能をリリースすることが可能です。 またはある機能やアプリバージョンを段階的に1%から100%まで少しずつロールアウトさせていくといったことも可能です。ロールアウトで問題があればただちにロールバックして前のバージョンに戻すことも可能です。

トランクベース開発

従来の開発では開発ブランチで長い時間をかけて開発します。そのことによってマージコンフリクトが起きやすく、また一つのプルリクエストでコードの変更箇所が多いのでレビュアーとしてもレビューが大変になってストレスの溜まる開発になってしまいます。

トランクベース開発では開発中の機能はフィーチャーフラグを使いユーザーに露出しないようにしつつ開発をします。そして1日など短い時間でmaster(main)ブランチにマージするプルリクエストを送ります。そうすることによって長い間開発ブランチで開発しないのでコンフリクトが起きにくくレビュアーとしても変更箇所が少ないのでレビューしやすい開発ができるになります。動作確認をするときは開発者やチームメンバーのみ機能がオンになるようにフィーチャーフラグを設定しておきます。いざリリースする際には全ユーザーに対してフィーチャーフラグをオンにするだけでリリースが完了します。

A/Bテスト

上記の通り、フィーチャーフラグを使うことで アプリの挙動をユーザーごとに変えることが可能です。実際にアプリの挙動を変えた2つのユーザー群のコンバージョンなどを分析することによって実際のユーザーで施策の効果を確かめながら開発することができます。この分析プロセスのことをA/Bテストといいます。 A/Bテストの利点はリアルなユーザーのフィードバックを知ることが可能になります。

フィーチャーフラグのメリットとデメリット

メリット

フィーチャーフラグが実現する開発の本質は「デプロイとリリースを切り離す」ことです。 従来はデプロイした同時にリリースとなっていましたがフィーチャーフラグを使うことによって機能をオフにしたままデプロイが可能になります。そしてリリースしたいタイミングでフィーチャーフラグを動的にオンにすることによってユーザーに対してリリースすることが可能です。そうすることによってリスクを最小限に抑えながら高速な開発が可能になり、またA/Bテストにより本番環境でテストすることができます。 そしてストレスが少ない開発をすることでプルリクエストを投げる人にとってもレビューする側にとってもストレスが少ない開発ができるようになります。

デメリット

フィーチャーフラグの導入するときのデメリットとして以下があります。

• コード量の増加 AとBの機能を1つのアプリに含めるのでコード量が増加します。
• フラグの管理コスト フラグが利用有無、フラグ同士の依存など、フラグを増やすことによってフラグの管理コストが増えていきます。
• 学習／導入コスト フィーチャーフラグを自前で用意するにしても既存のプロダクトを導入するにしても 学習コストや導入コストがかかってきます。

フィーチャーフラグのよくある疑問

フィーチャーフラグを導入後、コードからどのタイミングで削除したらいいか？

該当のフィーチャーフラグがどのような用途に使われるかによって削除するタイミングは変わってきます。リリースのためだけに使う用途であれば、フィーチャーフラグを開発中オフにしておいき、リリース後に全く問題無ければその時点でそのフィーチャーフラグは役割を終えたということで削除されます。一方でリリースをした後にある程度時間が立ってから問題が起きた場合、その機能を落としたい際はリリースが終わったあともいつでもその機能をオフにできるように残しておく必要があります。

フィーチャーフラグの分類やそれぞれの違いについてはこちらがわかりやすいです。

DBの設計反映など不可逆の変更はフィーチャーフラグではどのように扱うのか？

DBの設定反映など、不可逆な変更はフィーチャーフラグを導入しても対応が難しい部分です。その場合は基本的にシステムのロールバックが難しくてもユーザーに影響がでる部分をロールバックするためにどうすればよいかを考えれば良いこともあります。たとえば、APIやUIの部分でユーザー側にはDBの設定変更がロールバックしているように見えるフィーチャーフラグの導入の方法を取ることでユーザーへの機能のロールバックが可能になります。

社内フィーチャーフラグ基盤

私は現在勤務しているサイバーエージェントという会社でBucketeer（バケティア）という名前の社内フィーチャーフラグ＆A/Bテスト基盤を開発しています。

この基盤プロダクトはフィーチャーフラグの基本的な機能に加え、

• フラグ値の即時反映
• ユーザー属性や様々なルールなどを使ったの細いターゲティング設定
• ベイズ統計学を使用したA/Bテスト分析機能
• エラーイベントを監視した自動フラグオフ機能
• GTMやSlackとのインテグレーション

など、社内の要望に答えながら開発が進められています。近い将来にOSS化するロードマップもありますので是非ご期待ください！