PMのためのフィーチャーフラグ概要。定性的フィードバックの取得とリリース管理

PMにとって、フィーチャーフラグは定性的なフィードバックを提供し、ベータ版を管理し、実験を行うのに適しています。詳細はこちらをご覧ください。

多くのフィーチャーフラグについてのブログと同様、このブログも「フィーチャーフラグといえばXを思い浮かべる人が多いと思いますが、今日はYについてお話しします」と始まります。エンジニアリングのユースケースを取り上げることが多いので、今回はプロダクトマネジメントにおけるフィーチャーフラグの使い方について見ていきたいと思います。

技術的なレベルでは、そして機能の開発ライフサイクルの多くでは、Feature Flagsは主にエンジニアリングのためのツールです。しかし、開発プロセスの後半では、PMが主なユーザーとなることがあります。その理由と方法について見てみましょう。

エンジニアリングとプロダクトマネジメントの比較

フィーチャーフラグの最も強力な点は、フラグというシンプルで単一の述語だけで、多くの利害関係者に貢献できることです。

エンジニアにとっては、フラグが提供する価値は以下の通りです。

• テストとデバッグを簡単に行う方法。
• 高度な変更管理。
• キルスイッチやオペレーショントグルで重要な操作性を確保。

しかし、同じフラグでも、アカウント担当者にとっては顧客の体験をコントロールする能力となります。また、プロダクト管理にもさまざまな利便性を提供します。PMにとって、フィーチャーフラグは外の世界に関するもの全てです。次のような価値があります。

• 顧客と一緒に物事をテストし、定性的なフィードバックを得るための簡単な方法。
• 経験の検証。
• 学び、対応する機会。

これは、実はエンジニアに提供する価値と同じで、エンジニアリングやパフォーマンスではなく、プロダクト検証の側にあるとも言えます。

ベータ版の管理

フィーチャーフラグが価値を発揮しやすいのは、新機能のベータ版や早期試用版のキュレーションです。ベータ版リストとその特別な入口の構築は、完全に社内で行うと、非常に高価で、技術的な負債を抱え、管理も不十分なプロセスになりかねません。フィーチャーフラグを使えば、これを別のツールに抽象化することができ、より技術力の低い関係者に焦点を当てた、より優れたUIを実現することができます。また、より軽量で、より再利用性の高いエンジニアリング実装となります。

フィーチャーフラグを使用すれば、PM（またはアカウントチームやサポートチーム）は、顧客と直接やり取りすることができます。エンジニアリングの関与やリリースの調整を必要とせず、ベータ機能にそれらを追加することができます。

さらに、フィーチャーフラグを使うことで、どの顧客がどの状態にあるかを非常に簡単に確認することができます。例えば、ある機能がSuper Big社にとってオンなのかオフなのか？フィーチャーフラグは、これを分かりやすいUIで表示します。

定性的なフィードバックを得る 

新機能を顧客に提供するためにエンジニアリングやリリースプロセスに依存する必要がなくなれば、プロダクトチームは顧客主導の方法で作業する方がはるかに速いことに気付くでしょう。

新しい機能を顧客の前に出すのが早ければ早いほど、イテレーションも早くなります。誰もが知っていることですが、フィーチャーフラグは、その意図した行動の周りに筋肉をつけるためのちょっとした超能力なのです。

ここで重要なのは、定性的なフィードバックを得るためには、その機能が完全に動作する必要はないということです。UIの初期部分についてのフィードバックを得たり、エンドツーエンドのワークフローが完成する前に重要な統合経路をテストしたりします。フィーチャーフラグを利用することで、ソフトウェア開発プロセスに顧客を安全に取り込むことができ、開発プロセスとともに検証してもらうことができます。

もし何かが壊れて、顧客のエクスペリエンスに影響を与えるようなことがあれば、組織内の誰でも即座にそれをオフにすることができ、エンジニアリングチームには何の影響も与えません。フィーチャーフラグは、プロセスの早い段階で定性的なフィードバックを得たいという普遍的な欲求を、コストをかけずに簡単に実現することができます。

実験

フィーチャーフラグにまつわる要望で多いのが、「実験」です。実験には様々な意味があります。パフォーマンスに関するエンジニアリングの実験、顧客からのフィードバックを得るための実験、統計的なユーザー行動に焦点を当てた実験などです。

チームがよく求めるのは後者ですが、このあたりの言い回しは様々です。実験と呼ばれることもあれば、A/Bテスト、コホートテスト、ユーザーセグメンテーションと呼ばれることもあります。また、コンバージョン最適化の枠組みの中で行われることもあります。

これらのユースケースは全て、ユーザーにさまざまな体験を提供し、彼らが何をしたかについてある程度のデータを報告し、それらの行動を比較し、提供されテストされた体験の中から「勝者」を選ぶことを含んでいます。

これは、プロダクトマネジメントとデザインの両方、および成長（またはプロダクト主導の成長）チームの世界において、よくあるニーズです。以前は、このような能力は、しばしば直接フィーチャーフラグと混同されていました。現在では、これらの機能それぞれに最善のツールを使用しつつ、それらを簡単に連携させるというのが、最新のアプローチとされています。

これは何を意味するかというと、フィーチャーフラグのソリューションは、フィーチャーフラグが得意とする変更管理とリスク軽減にまつわるコアなユースケースに焦点を当てた場合に最も効果を発揮する傾向があるということです。データサイエンスや実験ツールの発展し続ける世界では、学習ループ、行動追跡、分析に焦点を当てて成果を出しています。どのようなフラグシステムも、優れたデータプラットフォームほどユーザーの行動分析に優れているわけではありませんし、ユーザーの行動に焦点を当てたベンダーも、フラグシステムの根本的な変更管理の可能性に優れているわけではありません。

むしろ、この種のユーザー行動テストのための適切なツールにデータを取り込むための手段として、フィーチャーフラグを検討されることをお勧めします。フィーチャーフラグは、複数の状態を提供し、データを簡単に報告し、セグメントやその他のイベントタイプを各状態から任意のデータベンダーに送信することができます。

リリースとデプロイの切り分け

フィーチャーフラグを使った作業で可能になる主なメンタルモデル、それはリリースとデプロイメントを分離することです。

プロダクト管理にとって、これはリリースを完全に自分の管轄にできることを意味します。プレスリリースの発表が予定された瞬間に、エンジニアリングがオンラインでボタンを押せるかどうかを確認したり、ローンチ当日に必死で慌ただしく活動したりする必要はもうありません。

フィーチャーフラグは、ローンチを退屈なものにします。なぜなら、リリースは、PMやマーケティング部門が望むときにいつでも行えるからです。エンジニアは既に作業を終えて、次の作業に移っています。もし問題があれば、その機能は簡単に停止させることができますが、願わくば、PMが前もってフラグを広範囲に適用しておき、より少数のユーザー集団でテストを行い、より大規模な立ち上げのリスクを回避できるようにして欲しいものです。

フィーチャーフラグを使えば、機能のローンチは最も混沌とした仕事ではなく、よりシンプルな仕事になります。発表のスケジュールを決め、準備ができたらフラグを立てます。ローンチ日がローンチ分へと短縮されるのです。  

まとめ

ここで紹介されていること以外にも、PMが学ぶべきことはたくさんあります。ベータプログラムの最適な方法、質的フィードバックの質を高める方法、フィーチャーフラグに関するエンジニアとの日常的な作業プロセスなどです。組織がフィーチャーフラグを採用して強化する中で、全てのプロダクトマネージャーが学び続けることを私たちは推奨します。

しかし、その前に、フィーチャーフラグで何ができるかを知っておくことが大切です。これにより、リリースを管理し、顧客との検証をより早く、より頻繁に行い、エンジニアリングチームへの依存を減らすことができます。その効果は絶大です。

プロダクトを作り出す多くの組織が、権限を与えられたプロダクトチームという理想を実現しようとしている中で、フィーチャーフラグは、現代のソフトウェアデリバリーチームが目指す、自律性と顧客中心主義のための重要な道筋となります。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。