Feature Flagを適切に分類することでA/Bテストの運用コストを下げる by Takeshi Ihara

主にコンテンツを提供するアプリの開発に携わっていると、新機能をリリースしてKPIが改善した際に、コンテンツによる影響なのか新機能による影響なのか区別が困難という問題があります。
そこで一般的によく用いられている手法として、A/Bテストと呼ばれる手法があります。
自分が開発に携わっているサービスのA/Bテストは、新機能の表示の切り替えでKPIの変化を検証しています。
その表示の切り替えを管理するのが、Feature FlagやFeature Toggleと呼ばれる機能の有効・無効をコード上で切り替えるテクニックです。

A/Bテストの実施数が増えるに従って、Feature Flagの数も増えていきます。
これにより、A/Bテストを未実施、実施中、検証済みなどのFeature Flagのステータスを管理するコストが増加していきます。
ステータスを正常に管理しないと、未実施のFeature Flagが本番に露出されたり、検証済みのFeature Flagのコード上での削除漏れという問題が発生します。

そこで、検証範囲や検証期間に合わせて、Feature FlagをRelease、Ops、Permission、Experimentという4分類で管理するようにしました。
これにより、それぞれのFeature Flagの役割が明確になり、また分類に合わせて挙動を変更することで、Feature Flagの管理コストを削減することができます。
今回のトークでは、実際のサービスでのFeature Flagの分類に従った運用方針を紹介します。