シンプルなフィーチャーフラグでは不十分なとき：中央集権型プラットフォームへの移行

チームが成長しました。小さなグループが設定ファイルにいくつかのフィーチャーフラグを書いていた頃から、今では5つのプロダクトチームが同じ環境にデプロイし、ほぼ毎日機能をリリースしています。かつてのフラグ管理方法が、負担になり始めています。

忍び寄る問題

最初は、各チームが自分たちのフラグを管理していました。ここに設定ファイル、あそこに環境変数、もしかしたらもう退職した誰かが作った簡易的な内部ダッシュボード。全員がお互いのやっていることを把握しているうちは、それでうまくいっていました。

しかし今、可視性は失われています。どのフラグが有効で、誰が作成し、どの機能を制御しているのかを一元的に確認できる場所がありません。一時的なはずだったフラグが、何ヶ月も本番環境に残っています。誰も削除したがりません。なぜなら、何かがそれに依存しているかどうか、誰にもわからないからです。

実際には、次のような状態になりがちです。

# config/flags.yaml
flags:
  new_checkout: true
  dark_mode: false
  payment_v2: true
  search_autocomplete: true
  beta_onboarding: false
  legacy_report: true
  # 所有者なし、説明なし、作成日なし
  # 'legacy_report'が何をするのか、もう誰も知らない

アクセス制御も頭痛の種になります。小さなチームでは、全員がお互いを信頼していました。今では、誰もが本番環境のフラグを切り替えられるべきではありません。おそらく、リードエンジニアかプロダクトマネージャーだけがその権限を持つべきです。しかし、フラグが設定ファイルや共有ダッシュボードにある場合、アクセス権を持つ誰でも変更できてしまいます。ミスが発生します。

そして、監査の問題もあります。何か問題が発生したとき、誰がいつ何を変更したのかを知る必要があります。適切な監査証跡がなければ、インシデント調査は推測の域を出ません。結局、チャットで「昨日、誰かペイメントフラグを触った？」と聞き回ることになります。

中央集権型プラットフォームが提供するもの

ここで、専用のフィーチャーフラグプラットフォームの出番です。LaunchDarkly、Split、あるいはUnleashやFlagsmithのようなオープンソースのツールは、すべてのフラグを一元管理する場所を提供します。

すべてのフラグには、名前、説明、所有者、変更履歴が付与されます。いつ作成され、いつ有効になり、いつ最後に変更されたかがわかります。これだけでクリーンアップが容易になります。何ヶ月も触られていないフラグを検索し、自信を持って削除できます。

ロールベースのアクセス制御（RBAC）は、権限の問題を解決します。開発者はフラグを作成し、ステージングでテストできますが、本番環境で有効にできるのはテクニカルリードだけです。プロダクトマネージャーは、開発者がコードをデプロイすることなく、ロールアウト率を調整できます。これにより、本番環境での意図しない変更のリスクが軽減されます。

監査ログはすべての変更を記録します。誰が、いつ、どの値からどの値に変更したか。フラグが有効になった後にエラーが急増した場合、誰が変更したかをすぐに確認し、連絡を取ることができます。これは、機能変更が適切な承認を経たことを証明する必要があるコンプライアンス要件にも役立ちます。

よりリッチなターゲティングルール

チームが段階的ロールアウトをより頻繁に採用するにつれて、より洗練されたターゲティングが必要になります。単純なパーセンテージベースのロールアウトは基本的なシナリオには有効ですが、特定の地域のユーザーだけに機能をロールアウトしたい場合はどうでしょうか？ プレミアムサブスクライバーだけに？ 特定のデバイスタイプのユーザーだけに？

プラットフォームのフィーチャーフラグを使用すると、ユーザーID、地域、サブスクリプションプラン、アプリバージョン、デバイスタイプ、カスタム属性に基づいてターゲティングルールを定義できます。これらはすべて、コードに触れることなくダッシュボードから設定できます。コードベースを分岐させたり、複数のデプロイパスを維持したりすることなく、複雑な実験を実行できます。

いつ移行すべきか

厳格なルールはありませんが、チームが中央集権型プラットフォームを必要としている兆候を以下に示します。

  • 誰かがチームに知らせずにフラグを変更したインシデントが発生した。
  • コードベースに明確な所有者のいないフラグが蓄積されている。
  • 「現在本番環境で有効なフラグはどれか？」という質問に簡単に答えられない。
  • 異なるチームがお互いのフラグに干渉している。
  • 機能変更が適切なレビューを経たことを監査人やコンプライアンス部門に証明する必要がある。

チームがまだ十分に小さく、全員がすべてのフラグを覚えていて、変更する人がごく少数であれば、プラットフォームはまだ必要ないかもしれません。しかし、これらの条件が満たされなくなったら、選択肢を評価する価値があります。

実践的なクイックチェックリスト

フィーチャーフラグプラットフォームを導入する前に、以下を確認してください。

  • 現在のフラグを棚卸しする。 いくつあるか？ まだ有効なものはいくつか？ それぞれの所有者は誰か？
  • アクセス制御のニーズを特定する。 誰がフラグを作成できるべきか？ 誰が本番環境で有効にできるか？ 誰がロールアウト率を調整できるか？
  • 監査要件を定義する。 すべての変更を追跡する必要があるか？ コンプライアンスのために承認ワークフローを証明する必要があるか？
  • ターゲティングのニーズを評価する。 単純なパーセンテージロールアウトで十分か、それともユーザー属性、地域、デバイスタイプに基づくルールが必要か？
  • チームの規模と成長を考慮する。 さらにチームが増えているか？ 環境が増えているか？ リリース頻度が上がっているか？

次に来るもの

中央集権型のフィーチャーフラグプラットフォームは、大規模なフラグ管理における運用上の問題を解決します。しかし、それはより大きな疑問も提起します。すべての機能がフラグで制御されるべきではなく、すべてのリリースに段階的ロールアウトが必要なわけでもありません。プラットフォームはツールを提供しますが、それらをいつ、どのように使うかは、依然としてあなたが決める必要があります。

フィーチャーフラグプラットフォームの真の価値は、ダッシュボードや監査ログではありません。デプロイとリリースを分離し、本番環境で安全にテストし、プロダクトチームが恐れることなく頻繁にリリースできる自信を与える能力です。それが、あなたが実際に構築しているケイパビリティなのです。