Secret Ninja Blog

プロダクトマネージャーしてます

こんなフィーチャーフラグは気をつけろ!

機能リリースにあたって”フィーチャーフラグ”を使って、特定のユーザにのみリリースをしたりするやり方が一般的になってきたように思う。 また、launchdarklyのようなフィーチャーフラグに特化したサービスなども出てきている。

トレジャーデータでもフィーチャーフラグを利用して顧客にサービス提供を行なっているが、今まで経験してきた中で、こんなフィーチャーフラグを作ってしまうと後々困るから気をつけようね。って話をしてみる。 ちなみにここではオペレーションの観点からフィーチャーフラグの気をつけないといけない点を挙げる。 また、下記でいうところの"Experiment"または"Permission"に当たることが多い。

Feature Toggle Types | Unleash

1 - え、PMが機能リリース後にやめちゃった。

正確なデータがあるわけではないですが、USの人は2-3年くらいで転職していく印象があります。 これはプロダクトマネージャーも然りで、担当するリリースが終わったらサッとやめちゃうケースなどがあります。 USの離職通知は二週間前とかでいいし、当然十分な引き継ぎとかも行われません。 その結果、会社として大々的な機能でない場合に、担当者が曖昧になって、リリースしたのはいいけれど、リリース後の戦略が不十分でどうするのこれ?っていう機能が出てくるケースがあります。

その結果何が起きるかというと、顧客への宣伝が十分に行われず、数社だけが実は使っている機能が生まれます。当然フィーチャーフラグも永久に残り続けます。メンテができる人がいなくなったあとに不具合報告がでて、どのチームが直すのこれ・・・?みたいになるケースがががが・・・

ある程度汎用的な機能な場合には、誰もがその機能を忘れ去ったころに、もういい加減これは全員にリリースしてよくない??しちゃうね!!っていう決断をする必要が出てきます。

こうしよう

フィーチャーフラグを作るときには、その機能がどんな条件で有効化できて、いつまでに全員にリリースするのかを決める。

一部のユーザ限定であるならば、誰がどのような条件でその”一部”の定義を更新できるのかを確認する。これをしないと、以前からいる顧客にしか適用ができず、新規の利用が増えないのでいずれ廃れる。

2 - いつまであるのこのフィーチャーフラグ?

頑張って作っていろんな顧客につかってもらった機能! だけれども、一部の顧客からは微妙というフィードバックで機能を無効化しないといけなかった・・・。その後1年が経ち、2年が経ち、いつまでもその一部の顧客に有効化ができず、ずっとフィーチャーフラグが残り続ける。毎回新規の顧客にはデフォルトで有効化するために毎回有効化フラグをチェックしないといけない。 いつまで一部の顧客のために機能有効化作業を新規顧客のために続けるのだろう、こんなこともありがち。

こうしよう

一定期間の間に集中してUX改善をするためのリソースを用意しよう。その間にちゃんとフィードバックをもらって、問題を修正しよう。

その修正でも改善できない場合は、あとは決断するだけだ。自分自身が信じる良い機能を全員に有効化しよう。常にネガティブなフィードバックは存在し続けるので、あとはPMが決断をするだけだ。

3 - フィーチャーフラグの組み合わせ爆発!!

新機能開発がどんどん進んで機能Aがついにリリースだ!さらに、機能Aの追加機能である機能A+もリリースだ!どちらも別々なフィーチャーフラグで管理できる! あ、機能Aの追加機能の機能A++と機能A+の追加機能のA+Bもリリースして、全部別々なフィーチャーフラグで管理できるぞ!

さて、機能A+Bが欲しい顧客にはどのフィーチャーフラグを有効化したらいいかな?

こうしよう

我々は賢くないので、フィーチャーフラグの依存関係を全て理解してオペレーションできる人はそんなにいない。 プログラミングと同じでネストするような条件分岐は極力さけよう。文章で説明されても人間には理解が難しすぎる。

あとは、フィーチャーフラグの有効化をするツール側で極力バリデーションを入れるようにしたいところだが、結局追加実装が増えるだけなので、基本はシンプルにしよう。

4 - 混ぜるな危険。顧客向けフラグとサービスリリース向けフラグ

ある日、オペレーション用の管理画面に見たことがないにフィーチャーフラグが増えていた、これは一体何かなーと思いエンジニアに聞いてみると、 それは顧客には関連がない社内向けのフィーチャーフラグだった。 フィーチャーフラグが増えるごとに、オペレーション上気にするところが増えていく!どれが顧客に影響があって、どれがないの?っていうのを確認するコストもかかる。

こうしよう

下記でいうところの恒久的なフラグと段階的リリースなどに使われる一時的なフラグは、オペレーション上は完全に分けて管理できるようにしよう。

Feature Toggle Types | Unleash

おわりに

お酒を飲みながらあんまり深く考えず書いているので、ツッコミどころが多いのは異論がない。

フィーチャーフラグって手軽にやりがちだけれども、リリースした後のコミュニケーションやプロダクトのパッケージング戦略も踏まえてちゃんと考えて設定しないといけないと思うのですよね。