エンジニアリングインフラとしての機能フラグ

デプロイは退屈であるべきだ

本番にコードを送り出すことと、機能をユーザーに露出することは別の決定だ。機能フラグは、爆風半径を制御しながら継続的にマージできるようにする。観測可能性と組み合わせると、リリースは二値イベントではなく可逆な実験になる。

これはフラグをインフラとして扱うときだけ機能する：明確に命名され、チームが所有し、安全にデフォルトされ、スケジュールで削除可能であること。

運用性のために設計する

すべてのフラグは、管理サービスが使えないときのデフォルトが要る。重要経路は意図的にフェイルクローズまたはフェイルオープンし、ランダムであってはならない。ターゲティング規則は、特にエンタープライズ顧客と規制ワークフローで、テスト可能かつ監査可能でなければならない。

無関係な振る舞いを一つのフラグで包むな。粗いフラグは絡まったクリーンアップを生む。細かいフラグは組合せテストコストを生む。ユーザーに見える能力でグループ化しろ。

• 誰がフラグを変え、なぜかを記録する
• フラグ作成時に削除日を設定する
• 可能ならタイトループからフラグ評価を外す
• 有効・無効の両経路をテストする

実験には衛生が要る

フラグが実験を支えるなら、ローンチ前に仮説・主要指標・終了基準を定義しろ。未完の実験を無限に走らせるな。分析を汚染し、認知負荷を増やす。

慎重にセグメントしろ。同じジャーニー上の重複実験は結論を無効化し、混乱したUXを生みうる。

クリーンアップはデリバリーの一部だ

機能が完全にリリースされた後も長く残るフラグは、死んだ設定と隠れた分岐になる。ローンチと同じ真剣さでクリーンアップを計画しろ。未使用パスを消し、コードベースが現実を反映するようにしろ。

成熟したチームがフラグで勝つのは、トグルが多いからではなく、安全にリリースし、その後システムをより単純にできるからだ。