Share
Embed
Slide 1
Slide 1 text
ふつうのFeature Flag実践入門
JJUG CCC 2026 Spring
@irof
Slide 2
Slide 2 text
自己紹介
● irof （いろふ）
● ふつうのプログラマ
● 個人事業主、技術顧問業
● 大阪在住、関西Javaエンジニアの会運営
● TDD, DDD, CI/CD, アジャイル, モデリング
Slide 3
Slide 3 text
本セッションの趣旨
● ありふれた悩み
○ リリース時期が未定なfeatureブランチの取り扱い
○ デプロイは影響の少ない深夜などに行う
○ リリース障害の対応が不安定で綱渡り
これらに使えるかもしれない道具や考え方を紹介します。
唯一絶対の万能解を示すものではありません。
Slide 4
Slide 4 text
対象者
Javaアプリケーション開発経験があり、Feature Flagとの関わり
方として以下のいずれかに当てはまる人
● Feature Flagを知らない人
● 使ったことがある人
● なんとなく使っている人
● 活用していくヒントを探している人
みんなじゃん？
Slide 5
Slide 5 text
今日の流れ
1. Feature Flagの目的と期待
2. Feature Flagの基本
3. 実装例
4. リリースと運用と落とし穴
5. まとめ
Slide 6
Slide 6 text
Feature Flagの目的と期待
Slide 7
Slide 7 text
Feature Flagとは
Slide 8
Slide 8 text
なにもの？
● コードを変更せず動作を変更する仕組み
● Feature Flag、フィーチャーフラグ
○ たまにフューチャーフラグと言われたり
○ 未来向いてて良いと思う
● フラグと言ったりトグルと言ったりする
○ 同じものだけど区別する派閥もある
● 再ビルドや再デプロイをしないのが基本
○ デプロイとリリースを切り離すのに使う
Slide 9
Slide 9 text
何が嬉しいの？
● リリースが「フラグを切り替える」だけになる
● リリースしないコードをマージできるようにする
● フラグを活用してリリースの選択肢を仕込める
○ 段階的ロールアウト
○ A/Bテスト
○ 緊急停止
○ ...
Slide 10
Slide 10 text
なぜいまこの話をするの？
● さまざまな技術の進歩で開発速度が上がりつづけている
● 開発速度が上がるとデプロイやリリースも早く回したくなる
● しかし、マージとデプロイとリリースが密結合な状態で高速回
転させるのは難しい
● 特にリリースは軽量に即座に安全に行いたい
● リリースに対する要求にFeature Flagが応えられる
Slide 11
Slide 11 text
参考: デプロイ/リリース分離パターン例
Slide 12
Slide 12 text
Feature Flagに対する期待
役割によって期待値は違うものです
Slide 13
Slide 13 text
ここで扱う役割
いろんな役割がありますが、本セッションでは「ビジネス」と「エン
ジニア」と置きます。
対立を助長する意図はありません。
Slide 14
Slide 14 text
ビジネスの期待
● リリースするかしないかのハンドルを握りたい
● リリースにエンジニアの都合を考慮したくない
● リリース後に何かあったらすぐ前の状態に戻したい
● ユーザーの反応を見ながら学びたい（少し応用）
Slide 15
Slide 15 text
エンジニアの期待
● 長命ブランチの面倒を見るのに疲れた
● コンフリクト解消にかかる労力を減らしたい
● リリースを待たずにマージしたい
● 深夜や休日などにリリース作業を行いたくない
● デプロイから不確実性を減らしたい
Slide 16
Slide 16 text
誰に何が嬉しいか
Slide 17
Slide 17 text
主に嬉しいのはビジネス側
● ビジネスがリリースのハンドルを握れる価値は大きい
○ （エンジニアに結構気を遣っているものでして……）
● エンジニアの嬉しさは、それを支える手段
Slide 18
Slide 18 text
それに対するエンジニアの役割
● ビジネスを支える技術を提供するのがエンジニアの役割
● エンジニアが技術を持ち込んで現場に適用する
○ 「これできるって聞いたよ」とか言われるとイラっとするよ
ね
○ いまだと「こんなのAIでやれるんでしょ？」とか……
● そもそもリリースの重量化は技術的な理由だったりする
○ 年月や世間によって常識として扱われたりするけど
○ 諦められてるのってなんか嫌じゃない？
Slide 19
Slide 19 text
Feature Flagの基本
Slide 20
Slide 20 text
動作原理
Slide 21
Slide 21 text
動作原理
● フラグを評価し、結果を受けて処理を分岐する
● フラグはハードコードしない
○ ハードコードしたら変更時に再ビルドとデプロイが必要に
なる
これだけ。とてもシンプル。
Slide 22
Slide 22 text
ぶっちゃけ、ただの分岐
Slide 23
Slide 23 text
評価タイミング
● なし（マージ時）
○ 変更したコードをマージしたら変わる
● ビルド時
○ ビルド時に評価する
● 起動時
○ 起動時に一度だけ評価する
● 実行時
○ 処理が実行されるたびにフラグを評価する
Slide 24
Slide 24 text
評価タイミングとフェーズの関係
Slide 25
Slide 25 text
評価タイミングとFeature Flag
● 実行時評価がいわゆるFeature Flag
● 起動時に一度評価するものは再起動が必要になる
○ そのためFeature Flagに含まないことが多い
○ けど本セッションではFeature Flagの枠で扱います
● マージ時はフラグ関係ないので違う
● ビルド時はめちゃ広げればだけど、流石にFeature Flagとは
違うなーって。おもった。
Slide 26
Slide 26 text
考えること
シンプルなものほど、考えることは多いもので
Slide 27
Slide 27 text
Feature Flagのテーマ
● 何を目的とするか
● フラグをいつ評価するか
● フラグをどう判定するか
● フラグをどのように管理するか
● 切り替え対象の処理をどう設計するか
Slide 28
Slide 28 text
何を目的とするか
● Feature Flag全体に対する目的や期待は前述の通り
● その上で、導入しようとしている特定のフラグの目的を考える
● 「汎用的で何にでも使えるもの」は往々にして使いづらかった
り限界があったりする
● 眼前にあるシステムに合いそうなものを考えます
Slide 29
Slide 29 text
フラグをいつ評価するか
● 先にあげた「評価タイミング」を選択する
● システムの性質を業務面と実装面で把握して考える
○ すでに採用している実装技術との兼ね合いもある
● 実行時評価は柔軟だが、唯一絶対の解ではない
○ たとえばパフォーマンスの問題
Slide 30
Slide 30 text
フラグをどう判定するか
● true / false の値だけなら単に if で分岐すればOK
● 三値以上持たせることも可能
○ フラグって名前やめろ
● 設定値以外（たとえばユーザーのロールなど）による分岐も
可能
● どういう判定をしたいかを目的と照らして考えます
● Feature Flagライブラリはここにフォーカスしている
● これも「柔軟な方がいい」ものでもない
Slide 31
Slide 31 text
フラグをどのように管理するか
● フラグの管理場所とかを考えます
○ 内包するか、外部に置くか、とか。
● システムの作りや評価タイミング、判定方法により管理の条
件が決まってくる
○ たとえば実行時判定なら実行環境から参照できる必要が
ある
Slide 32
Slide 32 text
切り替え対象の処理をどう設計するか
● 単に if で囲めばいいだけ？
● 切り替え後が if で前が else ？
● 切り替えの実現手段や撤去も踏まえて考えていく
Slide 33
Slide 33 text
補足: 柔軟性という毒
● 柔軟なのはいいこと
○ とは限らない
○ 柔軟性は不安定さにつながる
○ （Java言語使いなら伝わる？）
● 下手な柔軟性は期待に逆行する
● Feature Flagは安定して動いて欲しい
● 「Feature Flagのせいでトラブりました」←つらい
○ こういうのが起こりづらい設計をしたい
Slide 34
Slide 34 text
用途による種類の整理
認知度の高い話を押さえておく
Slide 35
Slide 35 text
種類の例
Slide 36
Slide 36 text
ここで挙げられているもの
● Release Toggles: リリースフラグ
● Experiment Toggles: 実験フラグ
● Ops Toggles: 運用フラグ
● Permission Toggles: 権限フラグ
出典: https://martinfowler.com/articles/feature-toggles.html
本セッションでは紹介に留めます。
Slide 37
Slide 37 text
注意: 「ぜんぶで4種類」ではない
● 前図はlongevity × dynamism の2軸で整理したもの
○ とうぜん、他の軸もありえる
● 境界は曲線かつ破線
○ 厳密な区切りではない、という意図的な表現
○ たぶん。知らんけど。
● 2軸は四象限図にしがちだが、四象限で描いてしまうと「4つ
ですべて」に見えるミスリードにつながる
Slide 38
Slide 38 text
注意: 「これらに対応すればいい」ではない
● カテゴライズは対象を理解するための切り口
● 「4種類に対応できるようにしよう！」は落とし穴
● いきなり全部はしくみも運用も半端になる
● 仕組みは負債になりやすい
○ 必要なところに必要なだけ持ち込む
Slide 39
Slide 39 text
「よく知られたモデル」の使い方
● 下敷きにしつつ、コンテキストに合わせて調整する
● そのまま適用しようとするとぎこちなくなりがち
○ たとえばデザインパターンとか
● とはいえ使わないのは勿体無い
● 先に挙げた「考えること」と合わせるとか有効
Slide 40
Slide 40 text
参考: モデリングのきほん
Slide 41
Slide 41 text
導入前のポイント
Slide 42
Slide 42 text
ON/OFFの認識を揃える
● ON=新処理、OFF=既存処理 とか
● フラグは「どっちがONだっけ？」の混乱が生じがち
○ Feature Flagに限った話ではない
Slide 43
Slide 43 text
導入時はデフォルトOFF
● 「ONにする」を意識的にやるのが良い
● 切り替えを分離できているかを実践で検証できる機会
● デフォルトONのまま一度も切り替えられないフラグがたまに
ある
○ それはFeature Flagではないかも
Slide 44
Slide 44 text
命名規則を考える
● 複数のフラグを同時に見ると規則がほしくなる
● 厳密さはシステムやチームなどコンテキスト依存
● 例としては「目的が分かる動詞+名詞」など
○ 例: enable-checkout-v2
○ enable とかはノイズな場合もある
● 期限付きの場合は日付を入れるとか
Slide 45
Slide 45 text
向き不向きもある
● Feature Flagはいつでも有効なものでもない
○ むしろ使用しなくて済むときは避けた方がいい
○ 必要悪に近い存在
● メリットが上回る時だけ採用するのが本筋
○ 一方でいきなりうまく使えるものでもない
○ チームで運用するものなのでチーム力が必要
Slide 46
Slide 46 text
Feature Flagが向かないもの
● 恒久的に残りそうな分岐
○ 汎用的な仕組みではなく特化した設計が合う
○ OpsやPermissionをどう捉えるかは検討課題
● 強い整合性が必要な複数システムの同時切り替え
○ Feature Flagの工夫で乗り越えるのは至難の業
○ 後ほど解決案を紹介します
● セキュリティ境界や権限制御の中核
○ 汎用的な仕組みでなく（以下略
● その他なにかしらの代替としての濫用
Slide 47
Slide 47 text
いい塩梅で使おう
● 対象を理解し、技術も理解し
○ 必要な時に、必要なだけ。
● できたら苦労しない
● 適切に使い分けるには知識と経験が要る
○ 経験を積まないと分からない難しさも多い
● やらないことはうまくならない
○ やれるところから少しずつやっていこう
○ 無理じゃない範囲で強引に使うのも一考
Slide 48
Slide 48 text
実装例
4段階の成長モデル（一例）
Slide 49
Slide 49 text
1st: PureJava
最小実装例
Slide 50
Slide 50 text
ただのif文
Slide 51
Slide 51 text
1st: コメント
● ここではフラグもハードコード
● 抽象ブランチをFeature Flagと組み合わせる第一歩
● マージやコンフリクトの「時間を置いたら増していくリスク」は
回避できる
● 「ここに分岐が増える」を評価する
Slide 52
Slide 52 text
導入: 長命ブランチをFeature Flagで扱う
● 長命ブランチを抽象ブランチとして取り込む
● 抽象ブランチの切り替えにFeature Flagを使用する
○ ドッグフーディングなど限定公開パターンを使う
Slide 53
Slide 53 text
参考: 抽象ブランチとは
● 変更を安全にmainブランチへ統合し続けるための手法
● コンフリクトやマージに伴うリスクを軽減する
● 既存コードと新コードの間に抽象レイヤーを挟むなどし、両
者を共存させる
● 万能解ではなく、以下の問題を持ち込む。
○ 同じ目的のコードが重複する
■ 静的解析に警告されることも
○ 変更が差分にならずdiffでレビューできない
Slide 54
Slide 54 text
2nd: Spring Bootの基本機能
Slide 55
Slide 55 text
やること
application.yml 等のプロパティファイルでフラグ値を管理
し、Environment や @Value、
@ConditionalOnProperty で参照する。
これにより2つの切り替えが実現できる。
1. 起動時にコンポーネントを差し換える
2. 実行時にフラグを参照して分岐する
ただしどちらも変更は再起動が必要
Slide 56
Slide 56 text
1. 起動時にコンポーネントを差し換える
● @ConditionalOnProperty などを使い、フラグによって
DIするコンポーネントを切り替える。
● @Profile はこれの特化実装
Slide 57
Slide 57 text
コンポーネント切り替えの実装例
Slide 58
Slide 58 text
2. 実行時にフラグを参照して分岐する
● 設定クラス（@ConfigurationProperties）などを通して
フラグを参照できるようにする
● 分岐側は設定されたインスタンスに問い合わせる
● この実装だとフラグは起動時に決まるが、分岐側は「起動時
に決まっている」から分離される
Slide 59
Slide 59 text
フラグ参照の実装例
Slide 60
Slide 60 text
2nd: コメント
● フラグの管理はSpring Bootプロパティの管理に従う
● 動的な変更への対応は難しい
○ 再起動が必要
○ 変更は環境変数や起動時引数などを触る
○ そのためデプロイとリリースが分離されない
● フラグ値以外での判定は未解決
○ やるとしたら独自ロジック
Slide 61
Slide 61 text
3rd: 2nd + OpenFeature
Slide 62
Slide 62 text
構造
Slide 63
Slide 63 text
OpenFeatureとは
● Feature Flag操作の標準仕様（CNCFプロジェクト）
● フラグ管理サービスのベンダーロックインを避け、共通のイン
ターフェースで操作可能
● 様々な言語のSDKがある
○ Java SDKはもちろんある
○ Spring Bootでの使用がドキュメントにある
Slide 64
Slide 64 text
導入ステップ
1. 依存関係の追加（OpenFeature SDK + Provider）
2. プロバイダーの設定（Bean定義）
3. コード内での評価
Slide 65
Slide 65 text
1. 依存関係の追加
Slide 66
Slide 66 text
2. プロバイダーの設定
Slide 67
Slide 67 text
3. コード内での利用
Slide 68
Slide 68 text
3rd: コメント
● 車輪の再発明でなくできた車輪を借りてこよう
● Java以外でも使うならOpenFeatureは有力
○ SDKが利用可能なことが条件
● Providerの公開実装があれば楽できるかもだけど、なくても
結構簡単に作れる
● Provider差し替えやフラグ以外の条件での評価と言った車輪
が実装されているので再発明を避けられる
● 本番で使用するなら何をBean定義するかとかちゃんと設計し
よう
Slide 69
Slide 69 text
4th: 3rd + Wrapper
Slide 70
Slide 70 text
構造のイメージ
Slide 71
Slide 71 text
OpenFeatureの直接使用を避けたい理由
● フラグキー（文字列）のハードコーディング
○ typoのリスクがある
○ 一覧化が別途必要になってくる
○ 使用箇所を探すのがgrep
● EvaluationContext の構築がノイジー
○ 本来やりたい仕事ではない
○ 分岐もそれなりにノイズなのに、より酷くなる
● プロダクトコードの外部依存を局所化したい
Slide 72
Slide 72 text
変更案: enum + ラッパー
● フラグをenumで一元管理する
● SDKを隠蔽するラッパーを作成する
Slide 73
Slide 73 text
1. フラグを一元管理するenum
Slide 74
Slide 74 text
2-1. SDKを隠蔽するラッパー
Slide 75
Slide 75 text
2-2. 高レベルAPIの追加（オプション）
Slide 76
Slide 76 text
3. Serviceでの利用
Slide 77
Slide 77 text
4th: コメント
● 独自レイヤーをOpenFeatureのような独立性を意識したコン
ポーネントにさらに被せるのは微妙と感じる気持ちもわから
なくはなくはなく……
Slide 78
Slide 78 text
4段階のまとめ
● プロダクトやチームのコンテキストにあったやり方を選択しよ
う
● この一本道でもない
○ FeatureGate的なのを導入してからOpenFeatureを導入す
るとかも有力
● 私は技術スタックを積むのには慎重派
○ 積む時も外しやすく設計する
○ なので3rdは採用するにしても限定的
Slide 79
Slide 79 text
Feature Flagとテスト
Slide 80
Slide 80 text
テストの考え方 1/2
● 分岐網羅はしておきたい
○ どちらも本番で動作するコード
○ 呼ばれないコードは壊れても気づけない
● テストの重複は許容する
○ むしろ自然なこと
● 廃止予定の処理も最後までテストを維持する
○ 切り替え後も切り戻し先として現役
Slide 81
Slide 81 text
テストの考え方 2/2
● 組み合わせ網羅はこだわらない
○ フラグが増えると指数で増えるが、運用される組み合わ
せは限定的なはず
○ フラグは直交するように設計する
● 使わないフラグは積極的に削除
○ テストごと消せて負債が減る
Slide 82
Slide 82 text
テストでのフラグ制御
● 実装方法ごとにテストでの制御方法を確立しておく
○ プロパティなら @TestPropertySource とか
○ OpenFeatureはClient／Providerのどこをどのフェーズで
テストするかとか
○ デプロイして本番での切り替え方法も検証しておく
● テストしやすさも実装方法の選択材料にする
Slide 83
Slide 83 text
設計Tips
Slide 84
Slide 84 text
フラグどうしを依存させない
● フラグ同士の依存は複雑化の原因
○ ぶっちゃけ制御不能
● どうしても必要なら設計を明示
○ 組み合わせた単一のフラグに置き換えた方が良いことも
Slide 85
Slide 85 text
判定を局所化する
● フラグ判定をコード内に分散させない
● 入口で分岐し、内部を単純に
● 1トランザクションでフラグは1度だけ評価する
○ 途中で変わる前提にすると難度が跳ね上がる
○ 外部プロバイダ評価はコストもある
■ ループ内で繰り返し引かない
Slide 86
Slide 86 text
NG例: 同じフラグの複数回参照
Slide 87
Slide 87 text
NGの理由
● Feature Flagに限った話でもない
○ パスが4つあるのがつらい
● Feature Flagの実装によっては異なる結果になることも当然
ある
● 1リクエスト内で変わってしまうと再現しにくい不具合になる
○ これが期待する動作であることはまずない
Slide 88
Slide 88 text
判定箇所と判定ロジックを分離する
● 呼び出し側は「ONか？」を問い合わせるだけ
● if (date > X && user.isBeta()) のような判定ロ
ジックを散らばらせない
● 判定ロジックは1箇所（ラッパー/ルーター）に集約する
● 高レベルAPIの実装箇所を用意しておくのが FeatureGate
の狙いの一つ
Slide 89
Slide 89 text
リリースと運用と落とし穴
Slide 90
Slide 90 text
リリースと運用
Slide 91
Slide 91 text
並行稼働
● 処理を切り替えるフラグではなく、追加処理を有効化するフラ
グとして導入
● ONにすると新しい処理 も 実行される
○ 今までの処理も実行される
● 結果の突き合わせなどを通して検証し、実績を持って切り替
える
Slide 92
Slide 92 text
参考: 並行稼働のじっくりステップ
● 現行処理のみ（新処理は動かない）
● 並行（現行結果を採用）
● 並行（新結果を採用）
● 新処理のみ（現行処理は動かないが切り戻し可能）
● フラグ廃止
Slide 93
Slide 93 text
ロールアウト戦略
● 現行処理と新処理をFeature Flagで切り替える場合に取りう
る選択
● すこしずつ対象を増やして影響を見る
● パフォーマンス対応を本番で低リスクに検証するなどの時に
採用する
Slide 94
Slide 94 text
Kill Switch
● すぐにOFFにできる状態にしてリリースする
● OFF -> ON がすぐ切り替えられるなら、ON -> OFFも 理屈
上は すぐできる
● データも含めると案外難しいことも多い
Slide 95
Slide 95 text
監視とメトリクス
● フラグ導入による影響の感度を上げる
○ エラーレートやレイテンシの変動など
○ 実行時評価は特に重要
○ 影響を与えたくないなら起動時評価を採用する
● フラグの変更とビジネスインパクトの関係を可視化（できたら
いいな）
Slide 96
Slide 96 text
ログと監査
● フラグの変更管理
○ 監査ログを保持
● フラグの評価記録
○ ログやメトリクスを検討
○ 数が多くなると「使われてるっけ？」とかがしばしば起こる
Slide 97
Slide 97 text
切り替えと切り戻しの落とし穴
Slide 98
Slide 98 text
ON/OFF混在を前提とできているか
● 複数サーバー、複数リクエストは当たり前
● ON/OFF混在で動作するものである
● 「ONにして以降はすべてON」と思い込まない
○ フラグ解決後に処理が滞留しているかもしれない
Slide 99
Slide 99 text
ONにする際の注意
● 無停止リリースでは混在は常にありえる
● 切り替えたときはONの処理とOFFの処理が同時に走る前提
で設計する
● Feature Flagに限らず無停止デプロイならバージョン混在は
避けられない問題
● どうしても無理な場合に備えて停止も視野に入れておく
○ 最後まで抵抗したい気持ちを持ちつつ
Slide 100
Slide 100 text
OFFにする際の注意
● 常に片道だけではなく戻しの切り替えも考慮する
○ データ・状態の整合が崩れないことを確認する
● 「ONで作ったデータがOFFでどう動くか」は検証漏れがち
Slide 101
Slide 101 text
DBマイグレーションとの兼ね合い
● DBマイグレーションとFeature Flagは衝突しがち
● これもFeature Flag固有の問題ではない
○ リリースは常に切り戻しを想定すべき
● Feature FlagはON/OFFが切り替わる前提
● 繰り返しになるが「ONで動くがOFFで動かない」は不可
● ずさんな移行が表面化しただけ
Slide 102
Slide 102 text
参考: Expand/Contract での安全な移行
破壊的変更を避け、各段で両方が動く
1. Expand: 新カラム追加（後方互換）
2. 両書き: 新旧両方に書く
3. 読み先を新カラムへ切替（Feature Flagで制御）
4. Contract: 旧カラム削除（撤去とセット）
各段を個別にデプロイして切り戻せる状態を維持しながら進む
Slide 103
Slide 103 text
分散環境の落とし穴
Slide 104
Slide 104 text
分散環境での設計スメル
● サービスを跨いで同じフラグを参照する
● 切り替え時に処理中のものがどうなるか不定
○ 分散トランザクションに似た問題につながる
● 複数のシステムが同じフラグに関心があるのは設計ミスの
気配がある
Slide 105
Slide 105 text
跨ぐなら入口で制御する
● A→Bのフローなら、フラグは上流（A）の入口でだけ評価
○ 下流（B）はフラグを直接参照せず、リクエストのされ方に
依存する
○ 非同期メッセージングも同様
● 各サービスが同じフラグを参照しにいく設計にしない
● 問題構造は先の1メソッド内で複数回参照と同じ
Slide 106
Slide 106 text
下流システムの設計
● B側はフラグで処理を分けるより、エントリーポイントを分ける
○ ストラングラーフィグパターン
● どうしてもフラグが必要なら上流システムで取得したフラグを
引き継ぐ
○ リクエストパラメタが増やせないならヘッダで渡すなど
Slide 107
Slide 107 text
フラグの撤去
Slide 108
Slide 108 text
フラグ撤去の運用
● 完了条件を決める
● 期限を設定しチケットに紐付ける
● 撤去タスクをリリース計画に含める
● 作業を割り当て、監査ログを残す
Slide 109
Slide 109 text
撤去を重視する
● 超重要
● 導入時より撤去時の作業・リスクを最小化する設計を優先す
る
○ 「現行処理をifブロックに書いてreturnする」とか
● 変更量が多いほど撤去の難度が上がる
○ 難度が上がると事故のリスクが増える
■ 撤去で事故を起こすと先が厳しくなる
Slide 110
Slide 110 text
撤去しやすさ全振り例
Slide 111
Slide 111 text
まとめ
Slide 112
Slide 112 text
話したつもりのこと
● Feature Flagは、デプロイとリリースを分ける実践的な道具
○ とはいえ一足飛びにそこに至るのは難しい
○ なので使いながらレベルをあげていく
● 実態はただの分岐なので雑に使うとすぐ負債になる
● 目的に合わせて選び、撤去まで見据えて導入する
● 価値の本丸は「リリースを扱いやすくすること」
○ リリースのハンドルをビジネスに渡すのを目指す
○ それを支える仕組みをあたりまえにする
Slide 113
Slide 113 text
次のアクション
Slide 114
Slide 114 text
初めて学ぶ人
● 前提
○ Feature Flag未使用、未検討
○ featureブランチで開発している
● まず1つのfeatureブランチを抽象ブランチで統合してみる
○ コードが統合できなければFeature Flagに至らない
● マージとリリースを切り離す選択肢を持つ
○ デプロイとリリースの分離はその先にある
Slide 115
Slide 115 text
なんとなく使っている人
● 前提
○ 使えてはいる
● 現在の実現手段とそれでできていること／できていないこと
を確認してみる
● 今後できるとよさそうなことを考えてみる
○ たとえば命名、期限、撤去などのルール作り
● 問題が起こりそうな設計になっていないかを確認する
Slide 116
Slide 116 text
活用していくヒントを探している人
● 前提
○ まちまち
● なんかあった？
○ 教えて？
Slide 117
Slide 117 text
FAQ
By Claude
Slide 118
Slide 118 text
Q1. 何から始めればいい？
Feature Flagを使い始めるなら何から手をつければいいです
か？
まず1機能をフラグOFFのままmainブランチにマージする、いわ
ゆる「抽象ブランチ」から始めるのがおすすめです。ライブラリは
後からでも導入できます。まずboolean enableNewFeature =
false;のような単純なif文でいい。動かしてみて困ったことが出て
きたタイミングでOpenFeatureなどを検討するので十分です。
Slide 119
Slide 119 text
Q2. 商用 vs 自前
商用サービスと自前実装はどう使い分ければよいですか？
Experiment flag（sticky bucketing）や複雑なターゲティングが必
要になった時点で商用サービスが現実的な選択肢になります。
Release flagやOps flagだけなら自前実装＋OpenFeatureで十分
なケースが多いです。最初から商用サービスを入れると「フラグ
を使う習慣」より「ツールの習熟」が先になりがちなので、規模や
用途を見極めてから導入を検討するのがよいと思います。
Slide 120
Slide 120 text
Q3. テストは全組み合わせ必要？
テストはフラグのON/OFFの組み合わせすべてを書く必要があり
ますか？
全組み合わせを網羅する必要はありません。同時に運用される
フラグは限られるので、実際に組み合わせて使うものだけをテス
トすれば十分です。それよりも「ONとOFFそれぞれ単独でテスト
が通ること」を守ることが重要です。呼ばれないコードは壊れても
気づけないので、両パスのテストを維持しましょう。
Slide 121
Slide 121 text
Q4. 撤去を習慣にするには？
フラグの撤去をチームに習慣づけるにはどうすればよいです
か？
「導入と同時に撤去チケットを切る」などプロセスに組み込むの
が効果的です。完了条件や期限をフラグ作成時に決めてしま
う。また定期的に（例えばスプリントレビューで）生きているフラグ
一覧を確認する習慣をチームに持たせると、放置が可視化され
てフラグ墓場になりにくくなります。
Slide 122
Slide 122 text
Q5. DBマイグレーションとの兼ね合い
DBマイグレーションとフラグを同時に扱う場合はどう考えればよ
いですか？
マイグレーションはON/OFFどちらでも常に耐えられるスキーマ
を保ちます。Feature Flagが問題を引き起こすのではなく、切り戻
しを想定していないマイグレーションが表面化するだけ。なので
切り戻しを真っ当に設計するのが根本的な対策です。DBリファク
タリングのテクニックが有用です。