Operate：利用者視点でのサービス改善を前提に運用する【第11回】

ミニ演習2

状況 ：あるプロダクトの新機能を開発したのでリリースを試したい。どのようにリリースすれば効果的だろうか。

選択肢 ：
アクションa ：同じプロジェクトの内部の人に評価してもらう
アクションb ：情報漏洩につながるため、新機能のリリースは部分的であっても止めるべきだ
アクションc ：実際の利用者の一部に先行してリリースし、反応を見る

　特にリリース済みのサービスにおいては、アクションcが有力である。不具合の確認だけではなく、サービスとしての反応を一部分だけに閉じて確認できる。この手法は「Dark Launching（ダークローンチ：ひっそりと公開するという意味）」と呼ばれる。「Canary Release（カナリアリリース）」と呼ばれることもある。

　ダークローンチを導入し、サービスを段階的にリリース（ここでのリリースはバージョンアップの意）することで、大きく失敗することを未然に防げる。

　また入念にテストしたとしても、不具合がゼロになったことの証明はできない。動作上の不具合だけではなく、顧客体験（UX：User Experience)上の課題を洗い出すことも運用中のサービスにおいてはとても重要だ。例えば、新機能に利用者がリーチしにくいという根本原因の探求などである。こうした少しの不満が多くの利用者を逃してしまうことにもつながる。

段階的なリリースのための手法

　「ミニ演習2」でみたように、サービスの新機能の提供では、段階的なリリースが有効だ。段階的リリースのための手法の１つに「分岐」がある。

分岐1 ：通信ごとにランダムに分ける

　ロードバランサーのようなトラフィックの振り分け機構を用意し、一定量の通信を新しい機能の搭載しているサーバーに振り分ける。ネットワークのエラーや利用状況を確認し、通信量を徐々に増やしながら機能をテストする。

分岐2 ：特定の条件で分ける

　指定したユーザーIDにだけ新機能を開放する。例えばユーザーIDが「整数」であれば、「奇数／偶数のどちらか」や「モジュロ演算により任意の数nで割り切れるユーザーIDのみ」「居住エリア」などで分ける。

　あるいは、サービスの「設定」メニューから利用者自身に先行機能を体験するかどうかを選ばせることもできる。そうしたオプションを用意するサービスは実在する。

　こうした機能を出し分けできる仕組みを用意できれば「機能トグル（feature toggle）」と呼ぶ機能を実現できる。機能トグルのON／OFFを切り替えることで、特定機能の有効／無効を切り替える。A／Bテストのための環境にも通じるものがある。

　機能トグルの付加的な効果として、開発中の新しい機能が万が一、ソースコードに入っていたとしても、機能トグルをOFFに（実行経路をOFFに）しておけば安全なリリースが可能になる。機能トグルは、GmailやFacebookなどにも垣間見ることができる。

リリースの後のKPIと改善

　実際にリリースしたアプリケーションは、アプリ内に埋め込んだユーザー行動ログを分析し、利用状況を定量的に可視化する。実証実験において、その規模が大きい場合は、利用者ごとではなく、ある程度セグメント化された利用者単位で行動パターンを追えるほうがフィードバックを得やすい。

　改善のためのKPIを取得する際は、必ずしも1つのツールだけから得られるものではないことに注意する（図3）。

図3：モバイルアプリの認知から利用開始までのステップ

　例えば、モバイルアプリの場合、アプリストアからのダウンロード／起動などは、各種プラットフォームのデータを利用する必要がある。利用者数の定義は、各システムにより異なっている。ユニークユーザー（UU：Unique User）であったり、アクティブユーザー（AU：Active User）であったりする。各システムの取得方法をきちんと確認することが重要だ。

　またアプリの特性によっても異なるが、特にB2C（企業対個人）用途で一定期間、利用者に自由に触ってもらうようなアプリの場合は、利用者が画面ごとに離脱しているかどうかを追う。徐々にユーザー数が絞られるため「ファネル（漏斗）」と表現されることが多い。

　B2E（企業対従業員）のアプリなどでは、利用者である従業員は、そのアプリを使うことが、業務上ある程度の前提になっているため、ファネルで追うことには、あまり意味がないかもしれない。