Feature Flagの活⽤術

はじめに ・実運用におけるFeature Flagの活用についてお話します！ ・Feature Flagとは何か？ ・Feature Flagのメリット ・Feature Flagの利用事例 1~3 ・Feature Flagの失敗事例 1~2

Feature Flagとは ・機能の有効化・無効化をソースコードの修正や再デプロイ不要でできるようにする仕組 み（要するに、if文で表示・非表示を切り替えできる） 関数の実行時に true / falseが決まっている（例：環境変数、実行環境など）

Feature Flagのメリット 継続的デリバリの実現 ・機能をOFFの状態でリリースして、必要なタイミングでONにする ・→ リリース時期を待つことなくリリース可能に リリース時における不確実性の低減 ・ビックバンリリースの回避 ・一部のユーザーのみに公開できる ・A/Bテストの簡略化

開発中の新機能を隠す ・段階的にリリース（Feature FlagがOFFの状態なので顧客は利用できない） ・最低限、サイドメニューのリンクを隠すだけでもOK ・事前に複数顧客に触って欲しい場合などはこっちの方がいいかも ・絶対に利用されたくない場合は、ルーティングごと隠してアクセス無効に Feature Flagの活用事例①

一部の顧客でのテスト検証 ・課題を解決し得る機能かどうかを検証するために、一部の顧客のみに限定公開して一 定期間使ってもらう（結果次第ではボツ機能にすることも検討） Feature Flagの活用事例②

データベース移行時にも Feature Flagを活用できる！ 背景 ・開発初期はHerokuのPostgreSQL (DB1) を使用していたが、 AWS RDS (DB2) へ移行 Feature Flag を活用した段階的な移行 1. Feature Flagを使い、DB1 ⇔ DB2 を動的に切り替え可能にする 2. リポジトリを統一し、どちらの DBにも対応できる設計 3. テーブルごとにFeature Flagを作成し、影響範囲を最小限に抑える 段階的リリースでリスクを軽減 1. 最初はHeroku の DB1 を使用 2. 一部のテーブルを AWS RDS (DB2) に切り替えて動作確認 3. 問題なければ、他のテーブルも順次 DB2に移行 4. Feature Flagを削除し、完全移行完了！ 番外編：Feature Flagの活用事例③

Feature Flagの設定漏れ ・リリース後、本来は全ユーザーが利用できるはずの機能が、Feature Flagの設定ミス により一部のユーザーに対して非表示のままになっていた💦 → 最後いつ・誰が設定変更するかの考慮が漏れていた → 泥臭い方法ですが、Feature Flag設定時に記録を残して、いつ・誰が編集すべきか を明記していました（例：事前にタスクを切っておく、コメントアウト） Feature Flagの失敗例①

RTのテストケース作成時に... 既存機能に対して、Feature Flagで一部ユーザーに限定公開している場合、RTのテス トケース作成時の工数が肥大化する（Feature Flagがon/offの場合など） → ユーザーが利用している以上QAする必要がある！ → ただ、リソースが足りない場合は事前の期待値コントロールをした上で、offの場合は QA項目から除外するのもあり（ただし機能による） Feature Flagの失敗例②

まとめ Feature Flagを用いることで様々なメリットあり ・段階的にリリースをすることで、大規模な障害を避けられる ・全体リリース前に一部の顧客からFBをもらえる 一方でデメリットもあり ・事前に運用を決めておかないと設定漏れやリソースの圧迫が起こる → 機能ごとにチームで合意をとった上でFeature Flagを使用する体制が好ましい