新機能を少しずつ公開する「機能フラグ」とは？

アプリへ新しいコードを配布しても、すべての利用者が同時に使い始める必要はありません。機能の有効・無効を切り替える機能フラグを使うと、公開範囲を分けられます。段階的な公開の考え方と、切り戻しで戻せないものを説明します。

コードの配布と、機能の公開を分ける

新しい検索画面を作ったとします。コードを本番環境へ配布したあと、最初は社内の確認担当者だけが使い、次に一部の利用者へ広げる。こうした切り替えを支えるのが機能フラグです。

Unleashの公式ガイドは、機能フラグを、コードのデプロイと機能のリリースを分ける方法として説明しています。デプロイはコードを動かす環境へ配置すること、リリースは利用者がその機能を使えるようにすることです。

冒頭の検索画面は仮例です。フラグを追加しただけで、既存の画面と新しい画面の両方が正しく動くわけではありません。切り替え先を含めた実装と確認が必要です。

段階公開では、対象の選び方が利用体験を左右します。同じ人がページを開くたびに新旧の画面を行き来すると、操作に迷うかもしれません。

Unleashの段階公開の解説では、割合や利用者の情報に基づく公開方法が示されています。同じ利用者に一貫した結果を返す仕組みは、stickinessと呼ばれます。安定した利用者IDなどを使う設定と、呼び出すたびにランダムに選ぶ設定では、同じ動作にはなりません。

社内向けの共同作業ツールなら、人単位で分けるより、チーム単位で同じ画面を使うほうが説明しやすい場合もあります。誰を一組として扱うかは、製品の使われ方から決める点です。

また、公開割合を増やす前に、何を見て判断するかも必要になります。新しい検索画面なら、検索が失敗していないか、待ち時間が増えていないか、目的の情報へ進めるかなどが確認の候補です。単に利用者が増えたことを、成功の証拠にはしません。

機能を無効にすれば、以後の処理を以前の経路へ戻せる設計は可能です。しかし、すでに行った処理まで取り消されるとは限りません。

たとえば、新機能がデータの保存形式を変えた場合、旧画面がそのデータを読めるかを確認する必要があります。送信済みの通知や、外部サービスへ渡した情報も、スイッチを戻すだけではなかったことになりません。

次は、段階公開を検討するときの確認例です。特定の製品が自動的に保証する機能の一覧ではありません。

表が見切れる場合は横にスクロールできます

機能フラグは、復元の仕組みそのものではありません。データを戻す必要がある変更では、バックアップと復元の基本も別に考える必要があります。

新旧両方の処理を残すと、それぞれを保守し、組み合わせを確かめる負担が続きます。前掲のUnleashの公式ガイドも、段階公開を終えたフラグと不要な旧経路を片付ける方針を示しています。

作成時に、何のためのフラグか、誰が管理するか、いつ役目を見直すかを残しておくと、後から判断しやすくなります。障害時の停止に使う長期的なスイッチと、新機能の公開のためだけの一時的なフラグは、目的を分けて扱います。

機能フラグは、コードを配るタイミングと、利用者へ機能を開くタイミングを分ける手段です。対象の選び方、停止の条件、データへの影響、役目を終えたあとの整理まで考えることで、段階公開の手順を具体化できます。