Bucket

多くのフラグツールは個々のユーザー単位で考える。Bucketはむしろ企業を中心にすべてを組み立てる。実際に支払い、更新するのはそのアカウントだ。顧客アカウント全体を1回の操作で切り替えられる。B2Bチームがたいてい望むのはこれだ。個人ではなくチームに売っているなら、手作業がかなり減る。

機能を対象のごく一部にリリースし、挙動を見てから露出を一歩ずつ増やせる。初日に全面リリースを約束する必要はない。段階的展開こそ、チームがフィーチャーフラグプラットフォームを導入する最大の理由だ。小さく始める。後で広げる。

機能を出荷しても、誰かが使っているかは分からない。Bucketは利用データを1つの画面にまとめるので、どの企業が新しい能力を取り入れ、どれが無視したかが見える。これが当て推量と確信の違いだ。ほとんどのチームは当て推量で進む。Bucketは違う。

古いフラグは積み上がり、コードを乱雑にする。Bucketは古くなったフラグをアーカイブし、それを参照していた不要なコードを自動で削除する。死んだフラグを1つずつ消して午後を丸ごと使い、その間プロダクトマネージャーが先週出荷されるはずだったデモビルドを待っていた経験のある人なら、これがどれほどの安堵か分かるはずだ。

SDKはReact、Vue、Next.js、Node.jsなどをカバーし、型安全性も組み込まれている。パッケージをインストールし、公開可能キーを渡し、フックやクライアントメソッドを呼んでフラグを確認する。設定は開発者が普段コードを書くやり方に近いままだ。新しい考え方を覚える必要はない。

エンジニアリング作業がすでにあるLinearからフラグを作成・管理でき、フラグの変更をSlackに流してチームに共有できる。フラグを引き起こした特定のissueに結びつければ、文脈が1か所にまとまる。チケット、コミットメッセージ、二度と検索されないSlackスレッドに散らばることはない。

BucketはModel Context Protocolに対応し、CursorやVS CodeなどのエディタのAIコーディングエージェントがフラグを直接読み、管理できる。チームがコードを書くのにAIツールを使うなら、そうして作られたフラグも追跡しレビューできる。こうしたチームのほとんどはすでにフラグを使っている。Bucketはモデルの狙いを人ではなくアカウントに向けるだけだ。顧客が企業であるとき、その違いが効いてくる。

オンとオフのフラグを超えて、設定値をリモートで配信し、新しいコードを出さずに挙動を変えられる。キルスイッチがあれば、壊れた瞬間に全ユーザー向けに何かを無効にするレバーが1本ある。深夜2時に何かがおかしくなったとき、そのレバーこそが本題だ。