月別アーカイブ: 2020年2月

Builder’s Playbook – Measurement 101

/ kosuket / 1件のコメント

ついに1週間空いてしまいましたが、第6弾です。

前回はエンジニアチームとどのようにプロダクトを作っていくかについて書いたので、今回はできたプロダクトが実際にどのくらいのインパクトを生んでいるのか、逆にマイナスに働いていることはないかを計測する方法について書いてみます！

Measurement 101

前回までのプロセスを踏んで作ってきたプロダクトですが、実際にインパクトはどうやって計測したらいいんでしょう？

一番単純に思いつきそうな方法は、プロダクトをリリースした前後で計りたいメトリックが変わったかを計測する、ですかね？
実は結構これがトリッキーで、この方法だと必ずしもそのプロダクトのインパクトを正確に計測できるとも限らないんですね。

ちょっと前になってしまいますが、前々回で使用した航空会社の例を使ってみてみましょう。

前々回で、航空会社の「飛行機遅延によって顧客が離れてしまう(churn)」という問題に対して、仮に「アプリの通知機能を使って遅延時のゲート、荷物到着情報を搭乗者に伝える」という機能を作って解決されるかみてみるというのを例に挙げてみました。

この例の場合ですと、仮説が正しい場合、「通知機能をリリースすることで飛行機遅延によって離れてしまう顧客の数が減る」はずです。

なので、実際にプロダクトをリリースして、飛行機遅延後に離れてしまう顧客の数(カスタマーチャーン)が減ったかを測ったとします。測った結果先月と比べてカスタマーチャーンが5%減っていました。

これを見ると「おぉ、この機能はカスタマーチャーンに効果があったんだ」と思ってしまいそうですが、本当にそうでしょうか？

もしかしたら先月は年末で、そもそも普段利用しない顧客がたくさん利用していて、結果そういった顧客は戻って来ず、今月は普通の月なのでビジネスユーザーの比率が高く、そういった顧客はそもそも利用頻度が高く、同じ航空会社を使いがちなのかもしれません。その結果今月のカスタマーチャーンがたまたま先月に比べて低かっただけかもしれません。

また、もしかしたらマーケティングチームが今月割引キャンペーンを行なっていて、たまたま今月多くの顧客が戻ってきただけかもしれませんし、たまたま、今月はライバル会社が先月の年末商戦との調整で価格を大幅に上げたので、相対的に両方の会社を利用しているユーザーが自分の会社に来ただけかもしれません。

こんな風に、世の中に起きていることを全て完璧に把握して、「そういったことが全く起きていないので、この5%は確実にプロダクトをリリースしたことによる効果です」と言えればいいのですが、多くの場合世の中に起きていることの全てを把握することなんてできません。

仮に実は何もしなければ先月に比べてカスタマーチャーンが30%減っていたのにプロダクトを出したせいで5%しか減らなかったとなっていた場合、「このプロダクトをリリースしたおかげで5%チャーンが改善したんだー！よし、もっとアグレッシブにこのプロダクトをロールアウトしていこう」なんてしてしまうと、気づかないうちにどんどん状況を悪くしていってしまいます。

こんなことにならないように、プロダクトのインパクトを正確に測る手法の一つが実験です。
そして、その実験の中で一番一般的なのはA/Bテストです。

広義のA/Bテストはインターネットマーケティングにおける施策の良否を判断するために、二つの施策同士を比較検討する行為全般を指す。

Wikipedia (Japanese) – A/Bテスト

なんかWikipediaの解説は結構広義な意味の解説をしているっぽくて、そのまま鵜呑みにしてやると上記のリリースの前後測定同様間違った結果が出てしまうことがあるので、(プロダクト、マーケティング含めた)ソフトウェア業界での文脈でちょっと書いてみます。

Experimentation 101 – A/B Testing

Overview – Treatment & Control

ソフトウェア業界では、基本的にA/B Testingというと、ユーザーを2つのグループに分け、1つを現状維持のグループ(コントロール)、もう1つを新たな施策を試すグループ(トリートメント)として一定期間片側にだけ新たな施策を試し、コントロールとのメトリックの違いをその施策のインパクトとする、という実験のことを指します。

Randomization

A/B Testingで一番大事なことは、このコントロール、トリートメントのグループ分けです。

上記の航空会社の例でもあったように、世の中に起きていたかもしれないいろんな事象を全て把握するのは不可能ですし、仮に把握できたとしてもそれら全てを計算要素に入れてプロダクトのメトリックへのインパクトを計算するのも大変です。

A/B Testingは、コントロール、トリートメントのグルーピングをランダムに行うことでこの問題を解決しようとしています。世の中で自分の関知しない事象があったとしても、ユーザーをランダムにコントロールグループ、トリートメントグループに分けていくことで、その事象に関与しているユーザーの割合がコントロールとトリートメントで一緒になります。なので、コントロールグループとトリートメントグループ全体でみると、その事象による影響はキャンセルされて、コントロールグループとトリートメントグループでの違いが、この実験で試したかった施策(航空会社の例でいうと通知機能の有無)だけになり、コントロールグループとトリートメントグループで計測されたメトリックの違いは全てその施策が原因であると言えるようになる。という感じです。

Statistical Significance & Sample Size

上記で解説したようにコントロールグループとトリートメントグループをランダムにアサインすることで、インパクトを計測したいもの以外の効果を無効化できるのですが、本当に無効化するためにはもう一つ条件があります。それが、コントロールグループとトリートメントグループにそれぞれたくさんのユーザーがいることです。

コインを投げて表が出る確率が1/2でも実際投げてみると3回連続で表が出ることがあるように、ランダムにアサインしても偶然特定の要素を持つユーザーが一方のグループにいっぱい入ってしまうことがあります。

数が少なければ少ないほど1回の偶然が起こすインパクトは大きく、逆に数が多くなれば1回の偶然が起こすインパクトは小さくなります。(表が出る確率が1/2のコインは3回投げて全部面になることはたまにありますが、100万回投げたら大体表と裏の出た回数が一緒になるというのと同じ感覚です)

ここで行うのがサンプルサイズの計算です。簡単に言うとコントロール/トリートメント間の違いが偶然によるものでないというために必要なユーザーの最低人数が何人なのかを計算し、実験に必要なサイズを決定します。

そしてこの「コントロール/トリートメント間の違いが偶然によるものでない」ということを統計的有意性(Statistical Significance)と言います。現実的には100%の確率で絶対に「コントロール/トリートメント間の違いが偶然によるものでない」ということを言い切るのはとっても難しいので、実務的にはこの「コントロール/トリートメント間の違いが偶然によるものでない」確率が何%だったら安心/満足できるかを決めます。多くの場合90%〜95%以上の確率で「コントロール/トリートメント間の違いが偶然によるものでない」と出るのであれば、きっとそうなんでしょうというのがソフトウェア業界での一般的な統計的有意性のスレッショルドです。(もちろんテストしたいものや実験の文脈によってこの値をいくつに設定するのかは変わります)

そしてこの%をいくつにするかで必要になってくるサンプルサイズも大きく変わります。プロダクトマネージャーはできるだけインパクトを正確に計測したいのですが、それに必要なサンプルサイズが大きすぎると計測が終わるまでに時間がかかりすぎ、機敏にプロダクト開発ができなくなってしまうので、この二つのバランスを取って実験のスペックを決めます。

実際のサンプルサイズの計算方法は、「A/B Test Sample Size Calculator」等でググると大体便利なウェブ計算機が出てくるので、割愛します 笑

Wrap Up

実験やメトリックの計測は、UX(ユーザーエクスペリエンス)とならんでザ・シリコンバレーなプロダクト開発の核となる部分です。特に(あくまで個人的な主観ですが)ウーバーはMetrics Obsessionと言われるくらいデータ、メトリックス、実験に、会社として強みを持っていて、いかに速く正確にインパクトを計測してそれを元にプロダクトを改善していくかについて、結構他では得られないような学びを得られた気がします。その点についても今回でカバーしたかったのですが、長くなってしまったので一旦切って、次回その辺の僕なりの学びについて紹介してみようかなーと思います！

Builder’s Playbook – Let Builder’s Build

/ kosuket / 2件のコメント

さて、第5弾です。

前回でUXデザインとPRDについてお話したので、今回はエンジニアリングのチームとの実装についてです。

Working with Engineers

Product Managerの面接ではよく、エンジニアとうまく働けるかがよく問われます。会社によりますが、Product Managerにもエンジニアが受ける技術的な部分の面接を課すところも多いです。こういった背景があるので、よくProdutct Managerにはテックバックグラウンドが必要だと言われます。僕自身もMBAに入る前はエンジニアをしていたのですが、実際にProduct Managerとして働いてみて、この仕事に必要とされる「テックバックグラウンド」って多くの人が思い浮かべるような「コードが書ける」とか「エンジニアにコードのアドバイスをする」みたいなところとは若干違うことに気づいたので、その辺を紹介してみます。

What & How

PMシリーズの一番初めの回でも書きましたが、Product Managerの仕事はWhatを定義することです。何を解決するべきか、解決策は何であるべきかをAnalytics、デザインと一緒に定義していきます。何を解決するべきで、その解決策は何であるべきかがわかったら、エンジニアの出番です。エンジニアはテクノロジーに関してのHowの専門家で、定義された解決策を実現するために必要なテクノロジーのスペックを定義し、実装していきます。

僕も含めてProduct Managerのいない組織でのエンジニアからProduct Managerにスイッチした人の多くはエンジニアに渡す際、Productの定義領域がHowにまで及んでしまうことがよくあります。これ、僕にとっては結構な学びだったのですが、チームのエンジニアがジュニアな人しかいないときはこういうガイダンスも必要ですが、ある程度シニアなエンジニアになるとProduct Managerが先にテクニカルなスペックを出してくるのを嫌います。

Let builders build
(作る者たちの邪魔をしてはいけない)

Uber’s original cultural values

Product Managerは実装方針に関しては基本的にはサポート役であるべきなので、プロダクトスペック(解決されるべき問題とそれを実現するための機能群をユーザー視点から定義したもの)を定義してエンジニアに渡した後は、エンジニアが模索して持ってきたテクニカルスペックをレビューして、プロダクトの観点からの懸念点(このプロダクトはこういう風に進化させていきたいのでこのアーキテクチャだとこのタイミングでガタがくるとか、そのフレームワークだとこのエッジケースがカバーされないとか、ユーザーがこんな風に増える予定なのでそのQPS (query per second)だとやばいとか)をフィードバックするにとどまります。テクニカルなProduct Managerだと、例えばデータベースの選定や、具体的なロジックに関してのフィードバックも行いますが、フィードバックはあくまでもプロダクト視点でのフィードバックで、実装方針はあくまでもエンジニア主導で決定していきます。

Involve Early

エンジニアと働く中で学んだもう一つの大事なことは、彼らをいかに早い段階からプロジェクトに関わってもらうか、です。

これは二つの点から大事です。

まず一つは問題の解決策としてエンジニアしか思いつかないようなことも結構あるということ。エンジニアに解決しようとしている問題を投げかけてみるとUXデザイナーやProduct Managerでは思いもつかなかったようなテクニカルなアイディアが飛び出してくることがあります。それだけでユーザーエクスペリエンスの全部が解決されることは稀ですが、そのテクニカルなアイディアをコアにしてユーザーエクスペリエンスをデザインしていくということはよくあります。

もう一つはデザインのフィージビリティチェックです。ある程度のデザインのフレームワークができたら、まずはそれをエンジニアに見せ、早い段階でエンジニアの観点からフィードバックをもらうことで、エンジニア的に無理そうなところや実装にめちゃくちゃコストがかかりそうなところがわかります。それを知った上でデザインをすることで、よりリーズナブルなデザインになり、デザイン→エンジニアの受け渡しをスムーズにすることができ、エンジニアの実装速度をアップさせることができます。

Agile

二つほど心得的なことを書いたので 笑
一つだけ、戦術的なところのことも書いてみます。笑

アジャイルは、MBAのインターン時代にも書いたことがありますが、(Summer Internship -Practice 参照)おさらいという感じで。

アジャイルは簡単にいうと、開発時のチェックサイクルを短くすることで、チームとして進捗を管理しやすくして、進捗具合やプロダクトの学びを元に方向修正をしやすくするための手法です。

基本的には1週間から4週間で一つのサイクル(スプリント)として、そのスプリント内の自分の持ち時間から実行可能なタスクを決めて実行していきます。
スプリント内ではスタンドアップと言われる進捗確認をとても短い間隔(毎日とか隔日とか)で行います。これによってチーム間での情報共有や、進捗をブロックしているものを共有して解決できる人に助けてもらいやすくします。
各スプリントの最後には大体デモとレトロ(レトロスペクティブ)というものを行います。
デモはそのスプリントで達成したものをみんなで見るという感じです。どちらかというとレビューというよりは、みんなにできたものを見せて褒めあってモチベーションを高めるとか同じチームのメンバーがどういうものを作ってるのか知るというのが目的な気がします。(レビューは、デモとは別に各プロジェクトで独立して行います。)
レトロは、スプリントの最後に、そのスプリントでうまくいったこと、うまくいかなかったことをチームメンバー全員で出し合って、オープンに話し合う場です。その中で話し合ったものの中で、次のステップを取るべきものはリストアップしてチームの中で誰がオーナーになるかを決めてトラックします。

おおまかにいうとこんな感じでしょうか。チームによって違いますが、スプリントは結構エンジニア主導なところが多い気がします。

Product ManagerのAgileへの関わり方は、

  • Agileのタスク用にProductのユーザーストーリーを作る
  • スタンドアップ、その他でエンジニアのブロッカーになっているものを取り除く
  • デモでちゃんとエンジニアを褒める

とかでしょうか。

Productが定義されたら、機能を元にユーザーストーリーを作ります。ユーザーストーリーはユーザーがその機能を使って出来る一つのシナリオで、「〜が〜することができる」みたいな感じで書くのが一般的です。そして、何をもってそれをできたと見なすかというExit Criteriaを定義して、一つのまとまりとしてエンジニアに渡し、それを元にエンジニアが必要に応じて実装手順ごとにサブストーリー/サブタスクを書いていきます。

スタンドアップの話はそのままなので省略するとして、その次のデモでちゃんとエンジニアを褒めるをもう少し書いてみます。これ、Product Managerとして結構大事です。これもまたPMシリーズの一番最初に書きましたが、Product Managerは製品開発チームの心臓であるべきなので、その製品を作って世に出したいと一番思っている人なはずです。そういう人なので、その製品に関するデモは、それがどんなに些細なことでも、どんなにテクニカルなことでも強い興味を示すべきで、そのタスクが完了したことを喜ぶできです。プロダクトリーダーシップという点で、エンジニアにこういう姿勢が見せれるかというのもProduct Managerの大事な職務の一つです。

Wrap Up

外から見るとProduct Managerってエンジニアと密に仕事をしていて、エンジニアのプロジェクトマネジメントをいかに回すかが主な仕事と思われがちですが、実際はそんなこともなかったりします 笑

ただ、エンジニアとプロダクトは基本的には組織的に独立しているので、特別な権限のない中でいかにエンジニアの士気を高めて効率的に製品開発を回すかであったり、その製品が提供できる価値をいかに低コストで早く世に出せるかというのはProduct Managerの大事な資質なので、そういった観点から、Product Managerとしてのエンジニアとの関わり方を書いてみました！