フィーチャーフラグ — 消し忘れたスイッチが、本番を壊す

What — デプロイと公開を分ける

フィーチャーフラグは、コードの中の分岐を、デプロイせずに外から切り替えられるようにする仕組みです。

if (flags.isEnabled("member_rank_discount", user)) {
  price = applyRankDiscount(price, user);
}

これで、2つの操作を分けられます。

• デプロイ — 新しいコードを本番に置く。フラグは OFF なので、利用者には何も変わらない
• 公開 — フラグを ON にする。コードは変わらず、利用者に機能が見える

分けることで、公開を少しずつ行えます。社内だけ、1%だけ、特定の地域だけ。問題があれば、デプロイし直さずにフラグを切るだけで戻せます。

フィーチャーフラグ

コードの分岐を、デプロイせずに外から切り替える仕組み。フィーチャートグルとも呼ぶ。

段階的リリース

新しい機能を、利用者の一部から順に広げて公開すること。

キルスイッチ

問題が起きたときに、機能をすぐ止めるためのフラグ。長く残す前提で作る。

割り当ての固定

同じ利用者には、判定のたびに同じ結果を返すこと。利用者 ID から計算する。

フラグは、目的によって寿命が違う

「フラグ」とひとまとめにされがちですが、目的が違えば、いつ消すべきかがまったく違います。

new_checkout_flow

Why — なぜフラグが事故を生むのか

フラグの価値は、デプロイと公開を分けることでした。分けたということは、「本番にあるコード」と「本番で動いているコード」が一致しなくなったということです。

冒頭の事故は、この食い違いが3つ重なっています。

• 消さなかった。 公開の終わった分岐が3年残り、名前が「使われていない」ように見えた
• 名前を再利用した。 同じ名前が、コードの版によって別の意味を持った
• デプロイの失敗に気づかなかった。 古い版の1台では、名前が古い意味のままだった

どれか1つでも無ければ、起きませんでした。

割り当ては、利用者で固定する

段階的に公開するとき、判定のたびにランダムに決めると、同じ利用者が画面を開くたびに新旧が入れ替わります。カートに入れたときは新しい画面、決済のときは古い画面、ということが起きます。

割り当ては利用者 ID から計算して固定します。

bucket = hash("new_checkout" + userId) % 100
bucket < 10 なら新しい画面（10% に公開）

同じ利用者は常に同じ側に入り、公開の割合を 10% から 50% に広げたときは、すでに新しい画面を見ていた 10% の人はそのままで、残りの一部が加わります。フラグの名前を式に含めるのは、別のフラグで同じ人ばかりが先行公開の対象にならないようにするためです。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。