こんにちは、プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow CTO の大谷旅人です。
今回は「Offers MGR(オファーズマネージャー) 」にフィーチャーフラグ（Feature Flag）機構を導入した際の選定視点含むアレコレについてお話していきます。
フィーチャーフラグ（Feature Flag）とは
この記事で紹介する Feature flag とは、機能のオンオフをコード変更やデプロイ不要で変更するための仕組みのことです。
より詳しくは、以下の URL を参照下さい。
導入の背景、目的
背景: As-Is から To-Be への転換
フィーチャーフラグ（Feature Flag）導入前の状態（As-Is）は、新機能のリリースが一斉に行われ、ビックバンリリースとなる傾向にありました。
これにより、個々の顧客や特定のセグメントユーザーに合わせたきめ細かなリリースができず、リリース後のトラブルシューティングが困難になるという問題も生じていました。
そこで目指すべき状態（To-Be）は、新機能を顧客毎やセグメントユーザーごとに出し分けリリースできる機構を整備し、コンポーネント制御を通じて、より精密なリリース管理を実現することとしました。
目的: 段階的かつ効率的なリリースの実現
上記の目指すべき状態（To-Be）だけでなく、導入により以下を達成することも目的としました。
-
新機能とPoC（Proof of Concept）の段階的リリース:
- 新機能や概念実証を段階的に展開し、対象セグメントの増減をスムーズに行いながら、デプロイなしで変更を即座に反映します。
-
スモールリリースの促進:
- 小さな変更を高頻度でリリースすることで、価値を迅速に顧客に届けることが可能になります。これは、顧客からのフィードバックを早期に集め、製品の改善につなげるためにも重要です。
-
開発粒度の最適化:
- 変更の頻度を小さく保つことで、レビューの効率を高め、コードの衝突を減少させます。また、小さな変更は問題の特定を容易にし、迅速な対応を可能にします。
これらの目的は、組織全体の開発プロセスとリリースサイクルを改善し、最終的には製品の品質向上と顧客満足度の向上を図ることに直結します。
新機能や PoC の段階的な導入によって、特定セグメントのニーズに応じた柔軟なデプロイメントが可能となり、ユーザーの反応に基づいて迅速に修正を加えることができます。
このアプローチは、顧客中心の開発を推進し、長期的な顧客関係を構築するための基盤となります。
総合すると、フィーチャーフラグの導入は、より戦略的でリスクを管理した形での新機能のリリースを可能にし、組織全体のアジリティを高めるための重要なステップです。これは、顧客にとって最も価値のある機能を迅速に提供し、開発チームの能力を最大限に活用するための基礎を築くことに寄与します。
ソリューションの選定
自前実装も一瞬頭をよぎりましたが、餅は餅屋ということで以下観点でソリューションを選定しました。
選定基準
- 機能&柔軟性
- セグメント指定やカスタム属性に基づくロールアウトリリースが可能か
- キルスイッチ、スケジュールリリースが可能か
- 初期不要
- シングルサインオン(SSO)や監査(Audit)といった運用時機能があるか
- ランニングコスト
- キルスイッチ、スケジュールリリースなどは初期不要なことから、必要な機能のみ最小の月額コストで使えるとベスト
- サービスの利用量、トランザクション量に応じた従量課金がどのように発生するか
- インテグレーション(アプリケーション)
- Rails/React との連携がスムーズに行えるか
- 別途管理画面を実装する必要がなく、フラグ管理のためにコードへ大幅な変更を加える必要がないこと
- 運用時のモニタリング
- フラグごとのアクティビティを管理・監視し、必要なデータを A/B テストなどの分析に利用できること
選定結果
LaunchDarklyがコスト面、機能サポート度合い、Lib & Integration豊富さなどから良い
上記選定基準でいくつかのソリューションを見比べた結果、LaunchDarkly を選定しました。
LaunchDarkly の魅力は、最小限の機能を使用する際に低コストでの導入が可能な点にあります。
スタートアップや小規模なプロジェクトにはこの点が特に魅力的でしょう。
スケール後に SSO やスケジュールリリースなどが必要になった際も、1 機能毎有効化する度に課金される形式となっており、正しく PLG してて好感持てます。
また、VSCodeのプラグイン あるなど Integration が豊富なの事も好ましい点です。
プロダクトへの導入
ソリューションを決めてしまえば、組み込み自体に難しいことは特にありません。
ドキュメント見て、組み込んでいくだけです。
ただし、マネジメント & 運用時にはいくつか注意点があります。
タスクマネジメント、設計
-
Flagの限定的使用:
- フラグ管理が自由に行えるようになると、すべてを動的に管理しようとする誘惑に駆られるかもしれません。しかし、これは避けるべきです。特に、バックエンドの処理分岐にフラグを使用すると、管理とテストが煩雑になるため、基本的には非推奨です。フラグは主に表示管理に留めるべきです。
-
リリース順序の共有:
- 特定の企業やユーザーに段階的に機能を公開する場合、リリース順序、適用範囲、適用条件、表示期間などに関するチーム内の共通認識が必要です。
運用
-
評価とフラグの管理:
- 予め決めた表示期間が経過した後は、機能の全体公開または部分公開を継続するかを適切に評価し、ジャッジを下す必要があります。全体公開となったフラグは削除を徹底することが重要です。
-
定期的なレビュー:
- 複数の分岐が存在する場合、どの機能がどのユーザーに提供されているかを認識することが困難になり、提供しているプロダクト像がメンバー間でぼやけるリスクが生じます。
- 公開タイミングを含め、定期的にフラグの棚卸しとリリースジャッジを行うことで、チーム全体が顧客に提供している内容を正確に把握できます。
- このリスクを軽減するため、一定以上のフラグが設定されないような制限を設けるか、期間が過ぎたフラグを検知できるようアラートやテストフローを導入することも有効です。
まとめ
リリースとデプロイメントは、実際には異なるプロセスです。
デプロイメントは技術的な実行を指し、リリースはその成果物がエンドユーザーに届けられる瞬間を指します。
この 2 つを明確に区別することで、開発のアジリティを高め、より顧客中心のアプローチを実現できます。フィーチャーフラグ（Feature Flag）の導入は、このアジャイルな開発プロセスをサポートし、開発組織が柔軟かつ迅速に顧客のニーズに応えるための有効な手段です。
今回紹介した選定から導入までの内容が、少しでも参考になれば幸いです。
副業転職の Offers 開発チームがお送りするテックブログです。【エンジニア積極採用中】カジュアル面談、副業からのトライアル etc 承っております💪 jobs.overflow.co.jp
Discussion