採択 2020/09/21 17:15〜 Track A LT(5分)

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

13
nonchalant0303 Takeshi Ihara nonchalant0303
主にコンテンツを提供するアプリの開発に携わっていると、新機能をリリースして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の分類に従った運用方針を紹介します。
2019 スポンサー 2019〆切後 資料請求
オンライン対応未決定 削除予定 オンライン対応検討中 要ロゴ 要PR 要支払 パンフ未確認
仮採択 採択しない スピーカー採択 ニッチ重複 チケット発券確認 原稿 スポンサー LT
仮採択(原稿) 採択済 採択しない 仮採択 要審議 ニッチ企画? LT向き加点 日程調整中 原稿 スポンサー