ひとことで言うと
機能フラグは、コードはすでにデプロイ済みでも、スイッチのオン・オフで特定の機能を見せる・隠すを切り替えられる仕組みです。
「デプロイ（コードを本番に配置する）」と「リリース（ユーザーに見せる）」を分離するための技術的な手段です。 フラグをオフにしたままデプロイしておき、準備が整ったタイミングでオンにするだけで公開できます。
たとえ話でもう少し詳しく
機能フラグは、照明のスイッチに近いです。
- 電気工事（開発・デプロイ）は終わっている
- でもスイッチを入れるまで電気はつかない
- 「開店準備が整ったら点灯する」という判断を、工事とは別に行える
Webサービスでも同じです。 新機能のコードを本番環境に配置しても、フラグがオフなら誰にも見えません。 キャンペーン開始日・承認が下りたとき・テストが通ったときなど、任意のタイミングでスイッチをオンにするだけで公開できます。 問題が起きればスイッチをオフに戻すだけで、コードのロールバックなしに即座に非表示にできます。
よく出る場面・使いどころ
- 大型連休やキャンペーン開始に合わせて、直前ではなく余裕をもってデプロイしておきたいとき
- 特定のユーザーだけに先行して新機能を試してもらいたいとき（ベータ機能）
- A/Bテストで、半数のユーザーには旧デザイン、残り半数には新デザインを見せたいとき
- 問題が起きたとき、コードを戻さずに機能だけ即座にオフにしたいとき
似た言葉との違い
- デプロイ
- コードを本番サーバーに配置する作業
- 機能フラグを使うと、デプロイ済みのコードの公開をあとからコントロールできる
- リリース
- ユーザーへ機能を正式に公開する行為
- 機能フラグを使えば、デプロイとリリースのタイミングを意図的にずらせる
- 環境変数
- サーバーの設定値を外から渡す仕組み
- シンプルな機能フラグは環境変数で実装されることもあるが、より高度な管理には専用のツールが使われる
実務で気にするポイント
- 古くなったフラグをそのまま放置すると、コードが複雑になるため定期的に整理する
- フラグのオン・オフが誰でも簡単に変更できる状態は危険なため、権限管理を整える
- 多数のフラグが絡み合うと「どの条件でどの機能が出るか」が追いにくくなる
- 専用のフィーチャーフラグ管理サービスを使うと、ユーザー属性・割合・地域などで細かく制御できる
注意: 機能フラグはとても便利ですが、「使い捨て」の意識がないと残骸が蓄積します。フラグは「いつ削除するか」をセットで決めて、役目を終えたらコードごと取り除く習慣を持つことが大切です。