フィーチャーフラグは安全な公開に役立ちますが、公開完了後も残すと分岐とテストケースが増え続けます。
削除前
- 対象利用者が新機能へ移行済みか
- ロールバック期間が終わったか
- 古い経路へ戻す予定がないか
- 他のフラグが依存していないか
- 分析やサポートがフラグ名を使っていないか
削除手順
- フラグ値を新しい側へ固定する
- 古い分岐と関連コードを削除する
- 設定、環境変数、管理画面から削除する
- 古い側だけのテストを削除する
- 新しい通常経路のテストを残す
- ドキュメントを更新する
一変更で整理する
新機能追加とフラグ削除を同じ差分へ混ぜると、問題時に戻しにくくなります。片付けだけの変更としてレビューします。
次に読む記事
ケーススタディ：新しい検索画面を全利用者へ固定する
新検索画面のフラグが一か月間100パーセント有効で、旧画面を削除する場面を考えます。管理画面の割合だけを見て消すのは早計です。社内利用者、特定地域、テスト環境、障害時の強制無効設定など、別の評価規則が残っている可能性があります。まずフラグの定義、既定値、上書き条件、評価ログを確認し、「全利用者」がどの母集団を指すかを明確にします。
判断手順では、旧分岐へ入った件数が業務周期を通じてゼロか、主要指標とエラー率が新経路で安定しているか、ロールバック手段をフラグ以外に確保できるかを確認します。旧検索が外部API、新検索が自前索引を使うなら、画面差分だけでなくタイムアウト、検索結果件数、更新反映の遅延も比較します。フラグ削除後に問題が出た場合は通常のデプロイを戻すため、その所要時間とデータ互換性も判断材料です。
悪い例は、条件式だけを true に置き換え、フラグSDK、設定、旧コンポーネント、旧APIクライアントを残す変更です。挙動は同じでも、次の開発者はどれが現行か判断できません。反対に一度に旧索引まで削除すると、切り戻し不能になります。良い例は、まずコード上の分岐と旧画面を削除して新経路を通常コードにし、関連テストを整理します。旧データ基盤の廃止は保持期間と復旧計画を確認した別作業にします。
清掃を中止する失敗条件は、旧分岐の利用が一件でも説明できない、指標にフラグ値が付かず比較不能、データ形式が新旧で非互換、障害対応責任者が切り戻し方法を承認していない場合です。完了後は、フラグ名の全文検索が移行記録以外でゼロ、設定サービスから定義が消えた、両分岐用テストが現行仕様のテストへ統合された、監視がフラグなしでも新経路を識別できることを観測します。
まとめ
フィーチャーフラグ整理の中心は、公開を終えた分岐・設定・test・計測を通常経路へ固定して消すことです。期待と実際を分け、条件を固定し、小さな仮説を同じ手順で検証します。成果は修正だけでなく、なぜその修正でよいと判断できたかという確認可能な根拠です。
参考リソース
関連記事
ケース：新検索画面を通常経路にする
配信率が一か月100%でも、社内account、地域rule、障害時override、評価失敗時defaultが旧画面を返していないかlogで確認します。「全利用者」にmobile旧versionが含まれるかも定義します。
旧検索が外部API、新検索が自前indexならtimeout、結果件数、更新遅延、data形式を比較します。flag削除後はdeploy rollbackになるため所要時間とdata互換性を確認します。flagだけが復旧手段なら代替準備前に消しません。
条件をtrueへしてSDK、設定、旧componentを残すと現行経路が不明です。一方、旧indexのdataまで同じPRで消すとrollback不能です。code分岐の清掃とdata基盤廃止を分けます。完了時はflag名検索が移行記録以外0、設定削除済み、現行testが残る、監視がflagなしで新経路を識別でき、評価errorが増えていないことを確認します。
フラグ廃止の関係者と判断表
関係者は機能開発者だけではありません。release責任者は切り戻し、supportは利用者案内、data担当はflag別指標、mobile担当は古いclient、platform担当は設定定義を持ちます。
| 確認項目 | 廃止可能 | 廃止を止める状態 |
|---|---|---|
| evaluation log | 旧variantが業務周期で0 | 母集団や期間が不明 |
| client version | 対応版へ移行済み | 古いappが評価する |
| data | 新旧互換または移行済み | rollbackで読めない |
| dependency | 他flagから参照なし | 組合せ条件が残る |
| rollback | deployで戻せる | flagだけが復旧手段 |
配信率100%は、例外rule、地域rule、強制overrideまで新variantとは限りません。 default値、targeting、環境別設定、評価失敗時の値を確認します。
清掃後の動作確認
flag名をcode、test、環境変数、管理画面、dashboard、runbookで検索します。旧分岐専用testを消した後、現行経路の振る舞いを通常testとして残します。SDK自体を消すのは他flag利用がない場合だけです。新機能追加や旧data基盤の物理削除は別変更にして、清掃差分を戻せるようにします。
完了時は設定サービスから定義が消え、評価errorが増えず、新経路の主要指標とalertが継続し、rollback手順がflagなしで実行可能か確認します。フラグ廃止は条件式をtrueへ固定する作業ではなく、暫定的な運用契約を閉じる作業です。
フラグ種別で廃止時期を変える
release flagは公開後に消す候補ですが、permission flagは恒久的な認可規則です。experiment flagは分析確定とdata保持、ops flagは代替の障害対応手段を確認します。同じflagでも寿命と所有者が違います。
owner、purpose、作成日、廃止予定日をmetadataへ持たせます。期限超過でも自動削除せず利用と依存を確認します。serverとclientの両方で評価する場合、API field、analytics property、cache keyにもvariantが入り得ます。SDK関数だけでなくflag文字列、variant名、metric dimensionを検索します。
release後はunknown flag評価を確認します。古いclientが削除keyを評価するとdefaultへ落ちます。設定を先に消すか最後にするかはSDK defaultとdeploy順で決めます。
flagをcache keyに含めていた場合、削除後のkey変更でcache missが急増する可能性があります。移行中のkey互換と容量を確認します。analyticsからdimensionを消す場合もdashboard queryを先に更新し、欠損を障害と誤認しないようにします。
型定義やgenerated clientにflag keyがあるならsource schemaから消して再生成します。手編集だけでは次回生成で復活します。document、sample config、local development seedも更新し、新参加者が削除済みflagを設定しない状態にします。
← 一覧に戻る
