こんなフィーチャーフラグは気をつけろ！ - Secret Ninja Blog

機能リリースにあたって”フィーチャーフラグ”を使って、特定のユーザにのみリリースをしたりするやり方が一般的になってきたように思う。 また、launchdarklyのようなフィーチャーフラグに特化したサービスなども出てきている。 https://launchdarkly.com/ トレジャーデータでもフィーチャーフラグを利用して顧客にサービス提供を行なっているが、今まで経験してきた中で、こんなフィーチャーフラグを作ってしまうと後々困るから気をつけようね。って話をしてみる。 ちなみにここではオペレーションの観点からフィーチャーフラグの気をつけないといけない点を挙げる。 また、下記でいうところの"Experiment"または"Permission"に当たることが多い。 Feature Toggle Types | Unleash 1 - え、PMが機能リリース後にやめちゃった。 正確なデータがあ

[mezamashi0540]

一般化できない特定顧客向けは実装直後から負債化するので削除条件を設定しておきたい。実装するのは簡単だし、顧客・営業は気楽に言ってくれるけど、基本的にはNGかなあ。

[kiririmode]

feature flagプラクティス

[tettu0402]

めちゃくちゃわかる。なんなら設定した当人（私）も背景を忘れていることもある。これなんでこのpriortyなんだっけ？なんでこれ重複してるの？分からない……

[havanap]

ifdef地獄的な

[zorio]

組合せ爆発は怖いね。

[naopr]

涙なしには読めない話だ。自分も経験あるのでめっちゃわかる

[SWIMATH2]

良いまとめ、運用乗り始めたがそろそろ難しさも気になってきたところだったので参考になる

[asuka0801]

PMFで SaaS作った事あるなら分かると思うのだけどフィーチャーフラグは作りたくなくても産まれてしまう物なのでどう管理していくかが重要だと思う。

[rti7743]

更新を考えるならフィーチャーフラグはNGだと思う。手間が2倍になるわけだし。