🧢 はじめに
Rehab for JAPAN フロントエンドエンジニアの @tara_is_ok です！🧢
弊社では、仮説検証を行える環境を用意しデータドリブンで機能を迅速にアップデートさせていく環境を構築するために Feature Flag の活用を検討しています。
しかし、適切に運用しなければ技術的負債が増大するリスクがあります。
今回は、Martin Fowlerが提唱する 4 種類の Feature Flag を解説し、プロジェクトに最適な Feature Flag の適用基準を明確にするチェックリストを考えてみたので共有していきます 🥷
🏁 Feature Flag（Feature Toggle）とは
Feature Flag とは、コードをデプロイしたまま、特定の機能を有効/無効に切り替える仕組みです。これにより、以下のようなメリットが得られます。
- リリースの柔軟性向上: 未完成の機能を本番環境にデプロイしつつリリースの制御可能
- A/B テストの実施: 機能の効果を測定しながら提供範囲を調整
- 障害対応の迅速化: 問題が発生した場合に即座に機能を無効化
- ユーザーごとの機能制御: 権限レベルに応じた機能の有効化
🧤 4 種類の Feature Flag
Feature Flag には、生存期間、変更頻度(デプロイごと、リクエストごと他)などを整理すると 4 種類に分けることが出来ます。
| Feature Flag | 用途 | 生存期間 | 状態 | 備考 |
|---|---|---|---|---|
| Release Toggles | - トランクベース開発を可能にするために使用 - 機能のリリースとコードのデプロイを分離する |
1 ~ 2 週間 | 静的 | - 長期間残ると条件分岐が増えるので管理が複雑になる - 未完成コードの隠し場所としてはいけない |
| Ops Toggles | - システム動作の運用面の制御を行うために使用 - パフォーマンスへの影響が不明確な新機能をロールアウトする際に導入し、必要に応じてその機能を即座に無効化する |
比較的短め | 動的 | - リリースを伴わずに即座に設定変更できる必要がある - Kill Switch としてシステムが高負荷となる時に、非重要な機能を無効化するために長期間残ることもある |
| Permission Toggles | - 特定ユーザーに対して異なる機能やプロダクト体験を提供する - 既に完成されている機能の限定公開として使用 |
長期間 | 動的 | ユーザー(またはユーザーグループ)ごとに機能の有効・無効が決まる |
| Experiment Toggles | - A/B テストやカナリアリリースを行う - 未完成の機能の検証として使用 |
2 週間以上 ~ 長期間 | 動的 | - 生存期間は Permission Toggles よりは短い - ユーザー(またはユーザーグループ)ごとに機能の有効・無効が決まるためフラグは動的となる |
この 4 つの Flag を図で表すと以下のようになります
出典: https://martinfowler.com/articles/feature-toggles.html
✅ チェックリスト
Feature Flag の実装を検討する際に、どのタイプの Feature Flag がどんなシナリオで活用できるかを整理してみました。
プロジェクトの要件に合わせて、以下の項目に対して 3 つ以上当てはまる場合は 該当する種類の Feature Flag の導入を検討してみてはいかがでしょうか？？
### Release Toggles
- [ ] 未完成の機能を本番環境にデプロイし、必要に応じて有効化 / 無効化したい
- [ ] マーケティング戦略などと同期させるために新機能リリースのタイミングを調整したい
- [ ] 新機能を段階的にデプロイし、開発完了時に全ユーザー向けにリリースしたい
- [ ] 複数の独立した機能を管理しながら、1 つのバージョンとしてリリースしたい
- [ ] 新機能のリリース以前に本番環境で動作確認を行いリスクを減らしたい
### Experiment Toggles
- [ ] A/B テストや多変量テストを実施し、ユーザーデータをもとにプロダクトを改善したい
- [ ] 特定の UI やフローの変更がコンバージョン率に与える影響を測定したい
- [ ] ユーザー(またはユーザーグループ)ごとに異なるバージョンの機能を分岐させ、統計的に有意な結果を得たい
- [ ] 一定期間に一定のトラフィックでデータを収集したい
- [ ] データ分析の仕組みがあり(今後できる)、計測できる環境が整っている
### Ops Toggles
- [ ] 障害発生時に特定機能を即時停止できるようにしたい
- [ ] API や DB が高負荷時に動的に一部機能を制限し負荷を下げたい
- [ ] 特定機能が外部サービスや API に依存していて、障害時に無効化したい
- [ ] 運用の担当者がアプリのデプロイを行わずに機能を調整したい
- [ ] Kill Switch を用いて手動で機能を停止出来るようにしたい
### Permission Toggles
- [ ] 特定のユーザー(ユーザーグループ)に対してアクセス制限を行いたい
- [ ] 特定の企業やユーザーに半永久的に限定機能を制御したい
- [ ] 管理者だけが使える機能を提供したい
- [ ] サブスクリプションプランに応じて機能の ON/OFF を制御したい
- [ ] ユーザーなどの権限を動的に変更したい
👮♀️ 注意点
Feature Flag の導入と運用には、以下の点に注意が必要です。
- 不要になったフラグは定期的に削除する: 長期間放置するとコードの可読性が低下し、技術的負債につながる。
- フラグの数を適切に管理する: 不要なフラグが増えると設定管理が煩雑になり、意図しない挙動を引き起こす可能性がある。
- パフォーマンスへの影響を考慮する: フラグのチェック回数が増えるとレスポンス遅延につながるため、キャッシュの活用などを検討する。
- セキュリティリスクに注意する: 不適切なフラグ設定により、本来アクセスできない機能が有効化される可能性があるため、適切な認証・認可を実施する。
💪 最後に
Feature Flag は適切に管理を行えば、リリースの柔軟性を向上させ、システムの安定性を保つのに有効です。
ただ、無計画にひたすらフラグを増やしていくとコードの複雑性が増すため、適用基準を明確にし、管理ルールを徹底することが大事になってくるなと思います。
適切な Feature Flag の活用により、開発プロセスを効率的にしていけるよう引き続き頑張ります 🧖♂️
Discussion