はじめに
本連載はフィーチャーフラグについての連載です。最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグに焦点をあて、フィーチャーフラグとは何なのか、どういった機能を提供するのか。フィーチャーフラグのメリット・デメリットを、具体例を使って詳細に説明します。また、導入前に考慮すべきことや、フィーチャーフラグの実装、サービスの選定の際の注意点、効率よく、かつ継続的に使用していくためのベストプラクティスも併せて解説します。さらにはサードパーティー製のフィーチャーフラグサービスの比較を行い導入検討に役立つ視座を提供します。
想定する読者
本連載が想定する読者はソフトウェアプロダクト開発に関わるすべての方です。とくに、信頼性を高めつつ開発速度を向上させたいと考えているソフトウェア開発者、プロダクトをグロースさせたいプロダクトマネジャー、プロジェクトを成功へと導くために日々努力を重ねているプロジェクトマネージャー、プロダクトの品質を守るQAエンジニアの方々には是非とも読んでいただきたいです。
背景
本連載を書く背景は、フィーチャーフラグの重要性を多くの方々に知ってもらい、より良い開発体験が広まってほしいという思いからです。
筆者が所属するサイバーエージェントでアンケートを実施した結果、フィーチャーフラグを導入しているプロジェクトは全体の2割にも満たしていませんでした。開発者はある程度フィーチャーフラグに関する知識を有しているものの、「メリットがイメージできていない」「既存のサービスについて調査ができていない」「導入コストに比べてメリットが少ない」などの理由で導入を見送っているプロジェクトが多くありました。この結果からフィーチャーフラグの認知が足りておらず、プロダクト開発において過小評価されているのではないかと感じました。弊社以外でもこうした理由でフィーチャーフラグの導入を踏みとどまっているプロジェクトは少なくないと考えています。
そこで本連載を通じて、フィーチャーフラグのメリットを読者に広く知ってもらい、導入検討のきっかけとなってもらいたいと願っています。
本連載の流れ
本連載は3つの記事で構成されています。
第1回となる本記事では、フィーチャーフラグとはなにか、どのようにしてプロダクト開発を変えていくのか、そのメリットと導入の際の懸念点を説明します。
第2回では、実際にフィーチャーフラグを導入する際のベストプラクティスを説明します。また、導入は自前で実装するのか、サードパーティー製サービスを使うのか。双方のメリット・デメリットを詳細に解説します。
第3回では、市場に存在するサードパーティー製サービスの比較を行い、実際に導入を検討しているプロジェクトの参考になるような情報を提供します。
フィーチャーフラグとはなにか？
フィーチャーフラグ（Feature Flag）は一言でいうと「コードを書き換えることなく動的にシステムの振る舞いを変更できる」開発手法です[注1]。
同じ意味の単語でフィーチャートグル[注1]や機能フラグ[注2]がありますが、本連載では「フィーチャーフラグ」で統一します。
フィーチャーフラグはソフトウェア開発にとって当たり前になっている
現在、フィーチャーフラグはDevOpsの文脈で当たり前の開発手法として認識されており[注3]、世界的な巨大テック企業も自社のプロダクト開発に導入しています。
Facebookは自前の「Gatekeeper」と呼ばれるシステムを構築していますし[注4]、GoogleもGmailといった主要プロダクトでフィーチャーフラグを活用しています[注5]。
その他にもNetflix[注6]やFlickr[注7]を始めとする多くの企業がすでに何年も前から開発にとって必要不可欠なプロセスのひとつとしてフィーチャーフラグを利用しています。
注釈
- [注1] Feature Toggles (aka Feature Flags)（Pete Hodgson）
- [注2] 機能フラグ（Microsoft）
- [注3] 『The DevOps ハンドブック 理論・原則・実践のすべて』 ジーン・キム、ジェズ・ハンブル、パトリック・ボア、ジョン・ウィリス著、榊原彰監修、長尾高弘訳、日経BP、2017年6月22日
- [注4] The Billion Versions of Facebook You've Never Seen
- [注5] Developing Gmail's new lookg（Mark Striebeck、Google Inc.）
- [注6] Preparing the Netflix API for Deployment（Netflix Technology Blog）
- [注7] Flipping Out（Ross Harmes）
フィーチャーフラグのもっとも簡単な実装
もっとも簡単なフィーチャーフラグの実装はif文を使用した以下のようなコードです。
if （featureFlag） {
// 機能がオン
} else {
// 機能がオフ
}
この例のfeatureFlagという変数がブーリアン型のフィーチャーフラグであり、もしこのフラグが真の場合は機能がオンになり、偽の場合は機能がオフになります。アプリがこのフラグ値を動的に取得できるようにすることで、コードに変更を加えずにブロック内から呼び出される機能のオン・オフを切り替えることが可能になります。
その他の簡単なサンプル
その他にも、フィーチャーフラグを利用することでアプリのさまざまな振る舞いを変更できます。
例1. UI
たとえば、フラグ値を文字列型にして16進数のカラーコードにすると、任意のUIコンポーネントの色を変更することが可能になります。
<font color={featureFlag}>ここの色が変わる<font>
一方、フラグに文言を渡せばユーザーが読むメッセージを変更できます。
<font>{featureFlag}<font>
例2. エンドポイント
その他のユースケースとしてはサーバーのバージョンアップや古いDBから新しいDBへのマイグレーションの際、フラグ値にエンドポイントを渡すことで動的にアクセス先を切り替えることができます。
例3. 限定的なリリース
さらにフィーチャーフラグの重要な機能の1つとして、特定のユーザー群やある割合のユーザーにのみ任意のフラグ値を返すことができます。たとえば、アプリの新しいバージョンをユーザー全体の1％のみにリリースを行い、様子を見ながら徐々に割合をあげるといったリリース方法が可能になります。
上記の例はフィーチャーフラグが可能にすることのほんの一部ですが、フィーチャーフラグを使うことでどのように振る舞いを動的に変更できるのかがイメージできたかと思います。
