さて、前回まで結構間が空いていたのに、突然またブログを書き始めたのには理由がありまして。。。

この半年の間で今働いている会社(Uber)の職場環境も結構変わってきました。2月、3月のコロナ本格化に伴う株価の暴落であったり、フルリモートであったり、それに伴う会社全体規模でのレイオフであったり、その後のリカバリーであったり、ロンドン、カリフォルニア のレギュレーションの解決であったり。

そんな感じでアップダウンの激しい一年だったので、一緒に長く働いていた人の中にもレイオフの対象になって望まずとも会社を辞めなくてはならなかった人たちがいたり、新しいキャリアを選ぶ人たちがいたりしました。

こういうことを経験していく中で、シリコンバレーのすごい人達と働けていることを当たり前のことと思っちゃいけないんだなーという思いが強くなってきたので、シリコンバレーで働いているすごい人ってどういう人たちなのかっていうのをログにしてシェアしてみようかなーと思うようになりました。

シリコンバレーの中でも世界規模でずば抜けてすごい人達(TeslaのイーロンマスクとかFacebookのマークザッカーバーグとか)になると、いろんなインタビューを受けていたり記事が出ていたりと、情報も結構あると思うので調べれば結構わかると思うんですけど、シリコンバレーの名の知れた企業に入って一緒に働くことがあるレベルでの現場にいるすごい人の「レベル感」とか「すごさの軸感」とかって、特に日本語での情報がなかなかないんじゃないかなーと思ってます。

幸い僕はプロダクトマネージャーという職業柄、いろんなファンクションの人と関わるので、それぞれのファンクションで「この人はすげぇなー」と思った人の特徴とかを書ける範囲で書いていこうかなーと思っています！

実はMBAのインターン時代にも似たようなコンセプトで、インターン時代に一緒に働いていた人たち紹介みたいなログを書いていたので、これからどんな感じのこと書くのか気になってくれた方はぜひそのログを見ていただきたいんですけど、シリコンバレーの「人」に関して今もその時も感じていることがありまして、今回はプロローグなのでお茶濁し的にその辺のことを書いてみます 笑

Whales and Migration in Silicon Valley

アメリカにいる人たちって、日本とは違って終身雇用という感覚があんまりありません。シリコンバレーももちろん例外ではなく、大体一つの企業に4年くらいいたら「結構長いこといるねー」って感じです。ただ、シリコンバレーっていうのは地理的にも結構狭い中にアツい会社がいっぱいあるところなので、多くの人はこの限定された地域の中で数年単位でいろんな会社を回ってキャリアを築いていきます。

超優秀な人もこのパターンを辿ることが多いのですが、この、超優秀な人が新しい会社に移るときに、周りの優秀な人たちも「この人が移るんだったら僕も/私もそっちに移ろっかなー」としばらくしてからその会社に人が流れていくことが起きます。といってもカリスマ社長が退任して新しい会社を作るとかじゃない限りこれが何百人単位で起こることはあんまりないのですが、現場レベルの超優秀な人だと、ポジションにもよりますが数人から十数人のレベルでこの現象が起こります。事実、2020年現在の僕の今の上司も、上司の上司とその前の会社、その前の前の会社で一緒に働いていました。

これを僕は勝手にクジラの回遊って呼んでるんですけど 笑
このクジラの回遊によって、その超優秀な人の周りのコミュニティが新しい会社で新たなインパクトのある仕事をして、またそこで出会った優秀な人たちがその人たちに惹かれていき、数年後その超優秀な人がその次の会社に移るときに、その前の会社からついてきた人の一部と新しく出会った人の一部がまたその人について次の会社に行く。これを繰り返していくうちにその超優秀な人もキャリアを積んでいくのでその回遊の規模が少しずつ大きくなっていく、という感じです。

僕もまだシリコンバレーに来てまだ数年ですけど、肌感覚的にはこの辺が日本(もしくはアメリカの他の地域)での典型的なキャリアの積み方と大きく異なる点かなーと思います。
自分のスキルアップというのは大前提で大事ですけど、それと同じかそれ以上に、いかにシリコンバレーのクジラたちと巡り合ってそのコミュニティの優秀な人たちと切磋琢磨するか、その中で自分を信頼してくれるような同僚に巡り合って自分もクジラとして成長していけるか、というのがポイントな気がしています。

と、ここまで書くとどうしてもなんでそれがシリコンバレーで起きているかの仕組みについて自分なりの考察を書きたくなってしまうのですが、それも含めて一つのログにしてしまうと、もっともっと長くなって読みにくくなりそうなので、今回はこの辺にしておきます 笑

この辺のことはシリーズ的に何本か書いてみようかなーと思っているので、面白いなと思っていただけたら定期的にチェックしてみてください！

さて、半年以上空いてしまいました 笑
前回からの間にコロナの流行とかいろいろありまして、忙しく過ごしていました。最近になって、またBuilder’s Playbookシリーズを書いた後に書きたいものを思いついたので 笑 気を取り直して続きを書いていきたいと思います！

前回は世に出したプロダクトが実際にどのくらいのインパクトを生んでいるのか、逆にマイナスに働いていることはないかを計測する方法の基礎的な部分について書きました。今回はそれを踏まえて実際に現場で学んだMeasurementのノウハウを紹介してみたいと思います！

Measurement Acceleration

前回でカバーしたような実験/A/Bテストを行う場合、発生条件が極端に低い事象(例えば事故などの100万回に1回程度の頻度で起きる事象)を扱うプロダクトでは統計的有意性のある結果を得るまでに相当な時間がかかってしまいます。計測ー改善のサイクルを速くまわすためには、このデータ収集がボトルネックになりがちです。僕は今のチームの特性上そういう系のプロダクトを結構作ってきたので、そこで学んだいくつかのタクティクスを紹介します。

Cycle Time Measurement

Problem

例えば、Eコマースのサイトでユーザーがある商品を買ってから次にサイトに戻ってくるまでの時間を短縮するような機能を作ったとします。(例えばユーザーに送るレシートの下に「それを購入されたならこんなものも必要じゃないですか？」みたいなレコメンデーションを添付する機能とか)
この機能が実際に効果があるのかを確認するためには、A/Bテストで「ユーザーが戻ってくるのにかかる時間」に差があるか測定すると思うんですが、

例えば今のユーザーが戻ってくるのにかかる時間の平均が2週間だった場合、測定にものすごく時間がかかります。

平均2週間ということは1日で戻ってくる人もいれば、2ヶ月後に戻ってくる人もいるわけで、戻るべきユーザーが全て戻ってきてからでないと平均の計算ができないからです。

この場合ユーザーが戻る平均時間は2週間でも、99%のユーザーが戻るのにかかる時間は3ヶ月かもしれません。

ということは、この機能をリリースしてから、

1. まず必要な数のユーザーにこのリコメンデーション付きのレシートが送付されるのを待つ
2. 平均を計算するためには全部のユーザーが帰ってくるまで待たなければいけないので、実験期間の最後のレシートが送付されてからさらに3ヶ月待つ

というステップを踏まなくてはいけないので、めっちゃ時間がかかります。

Solution

こういう場合によく使われるメトリックが「ある一定期間の間に戻ってきたユーザーの割合」です。「平均」を使うと最後に戻ってくる数人のユーザーが数値に与える影響はとっても大きいので、最後の最後まで待たなければいけないのですが、「ある一定期間の間に戻ってきたユーザーの割合」をメトリックにすれば、その設定した期間だけ待つだけでメトリックが計測できます。

上記の例の場合、「2週間で何%のユーザーが戻ってきたか」という形で効果を測ることによって、待たなければいけない期間が「平均」を使った場合の3ヶ月から2週間に短縮できます！

とっても便利なメトリックなのですが、測定のスピード短縮の大きなメリットが得られる分、使用に注意しなければいけない点もあります。

「設定した期間までの効果しか測定しない」という点です。

上記のレコメンデーション付きレシートの例で言うと、「このレシートを見なくても2週間以内にサイトに戻ってきたであろうユーザーがレシートを見ることによってどれだけ速く戻ってくるか」は測定できるのですが「このレシートを見ないと戻ってくるの2週間以上かかっていたユーザーがこのレシートを見ることで不快に思って戻ってくるのにより時間がかかるようになった」という事象が起きていないことは測定できません。

こういうネガティブなインパクトが起きている可能性がある場合は「2週間で何%のユーザーが戻ってきたか」を実験のメインのメトリックにして、このメトリックに効果があった場合はこの機能を全ユーザーにリリースするという決断をしておいて、1ヶ月後、2ヶ月後に「このレシートを見ないと戻ってくるの2週間以上かかっていたユーザーがこのレシートを見ることでどうなっているか」を確認しながら、実験で確認された効果を上回るネガティブな効果が観察されたらリリースを巻き戻す、というような措置も必要になってきます。

Metric Decomposition

Problem

上記で使った例の続きで説明してみます。
上記のレコメンデーション付きレシートは、実験の結果「2週間で戻ってくるユーザーの割合」が6%増えるというポジティブな効果ありという結論になり、全ユーザーにリリースされたとしましょう。ただ、このメールで送っているレシートの開封率は60%で、チームとしては、もっと多くのユーザーにレシートを見てもらうことで「2週間で戻ってくるユーザーの割合」がさらに増えるだろうと考えているとします。

もっと多くのユーザーに見てもらうアイディアとして、メールだけじゃなく、アプリの通知でレシートの確認を促そうというのを思いつきました。

この場合もゴールは前回と同様「2週間で戻ってくるユーザーの割合」を増やすことなので、これを指標にしたいと考えています。

ただ、これまでの他の機能の実験結果からアプリの通知で期待できる開封率の増加はEメールの10%程度とアナリティクスのチームから報告がありました。ということは期待できる「2週間で戻ってくるユーザーの割合」に対する効果は「レシートにレコメンデーションをつける」という機能の10%程度ということになります。

前回よりも小さな効果を測定しなければいけないので同じメトリックを使うのであれば、統計的に有意な結果を測るのに必要なユーザー数が増えるので、結果として必要なユーザーにアプリの通知を送る期間が増えてしまいます。特に厄介なのが、「統計的に有意な結果を測るのに必要なユーザー数」は「測定したい効果」が小さくなるにつれ指数的に増えるので、今回のケースのように測定したい効果が10分の1の場合、必要なユーザーは数10倍から数100倍になってしまいます。

Solution

ここでよく使うのは、「メトリックの分解」です。

レシートレコメンデーションがどのように「2週間で戻ってくるユーザーの割合」に影響を与えているかを考えてみると

レシートを見るユーザーの数 ✖️レシートを見ることによって2週間以内に戻ってくる割合の増加率＝2週間で戻ってくるユーザーの割合

という図式で表せます。

上記のアプリ通知は、この図式の中だとProblem Sectionでも書いた通り「レシートを見るユーザーの数 」を増やす役割を担っていると思います。同様にアプリ通知機能は単純にレシート機能へのトラフィックを増やすだけでレシートのデザインには一切関与していないので、「レシートを見ることによって2週間以内に戻ってくる割合の増加率」には理論上一切の影響を与えないはずです。

であれば、「2週間で戻ってくるユーザーの割合」を直接測るのと、「レシートを見るユーザーの数 」の増加率を測って「レシートを見ることによって2週間以内に戻ってくる割合の増加率」に影響がないことを測ることが同じことを証明できていると言えます。

このように最終的に測りたいメトリックを分解して、代わりに各要素を測ることで計測を早めることができるんです！

理論的な説明だけだとあまりピンと来ないかもしれないので、実際に数字を当てはめてみたいと思います。

上記のProblem Sectionで、レシートのレコメンデーション機能が60%のユーザーに利用されていて「2週間で戻ってくるユーザーの割合」を10%程度増やしたことが判明しました。

これを上記の図式に当てはめると

レシートを見るユーザーの数(60%) ✖️レシートを見ることによって2週間以内に戻ってくる割合の増加率＝2週間で戻ってくるユーザーの割合の増加率(6%)

なので「レシートを見ることによって2週間以内に戻ってくる割合の増加率」は10%となります。

ここで、アナリティクスの予測通り、アプリ通知機能をリリースすることで「レシートを見るユーザーの数」が10%増え、「レシートを見ることによって2週間以内に戻ってくる割合の増加率」が変わらないとすると

レシートを見るユーザーの数の増加率(10%) ✖️レシートを見ることによって2週間以内に戻ってくる割合の増加率(10%) ＝2週間で戻ってくるユーザーの割合の増加率(1%)

となり、「2週間で戻ってくるユーザーの割合」にあたえる影響は1%となってしまい、その1%の違いを測るためのサンプルサイズが必要になります。

前述のようにMetrics Decompositionを使うと、「2週間で戻ってくるユーザーの割合(1%)」の代わりに「レシートを見るユーザーの数の増加率(10%)」を測ることになるので検出しなければいけない違いが10%になり、必要なサンプルサイズが大幅に減ります。

Summary

このように実験の基本を踏まえた上で小さなテクニックを使うことで、実験のサイクルを大幅に加速させることができます。今回紹介したのはどちらも簡単に使えるテクニックだと思うので、実際にA/Bテストを現場で使用している方は使ってみてもいいかもしれません。

Switchback

実験サイクルの加速に加えてもう一個、僕個人的にはあんまり学問的に勉強しなかったけども現場で学んで「おぉ」と思ったコンセプトにswitchbackがあります。

上記のMeasurement Accelerationで示したような、機能が直接単一のユーザーに影響するものであれば、単純なA/Bテストで十分有効なのですが、Facebookや、Amazon、Uberなどのマーケットプレイス的なプラットフォームプロダクト(需要サイドと供給サイドがあるプロダクト)でマーケットプレイス全体へのインパクトを与えるような機能は単純なA/Bテストで正確なインパクトを測ることが難しいです。

例えばUberでいうところのサージプライス。
サージプライスというのは、Uberを利用するときに、その利用する時間と場所における需要の多さに応じて追加料金をとるという機能です。ラッシュアワーのオフィス街などで、需要が多すぎて利用可能なドライバーが全て利用されてしまっていて本当に利用したいユーザーが利用できないという状況を改善できるように開発されました。

サージプライスが設定されると値段が上がるので、利用したいユーザーの数は減り、もらえるお金が増えるので利用したいドライバーが逆に増えます。この効果を利用して需要と供給のバランスをとるのですが、こういった機能(例えばサージプライスのアルゴリズムAとアルゴリズムBを比べる)の場合、同じ時間にユーザーをA/B、ドライバーをA/B に分けてAグループのユーザーとAグループのドライバーを、BグループのユーザーとBグループのドライバーをマッチするという方法をとってしまうと、そもそものマッチされるユーザー、ドライバーの全体数が実際のユーザー、ドライバーよりも小さくなってしまい、サージの効果を正確に計測することができません。(マーケットプレイスは、参加するユーザーの数によって市場の効率性に大きな差が出ます。)

これを解決するためにswtichbackを使います。

Switchbackは、同じ期間にユーザーをA/Bに振り分けるのではなく、一定期間を複数個のグループに分け、その各時間にAを使用するかBを使用するか切り替えるというコンセプトです。

ここで重要なのはこの期間のグループ分けで、一定期間の間になるべく多くのグループがあった方がいいのですが、各グループの長さもその機能の効果を測るのに十分な長さがなくてはいけません。

一番単純な例だと、1週間を基本期間として24時間単位のグループを7個作り、1週目の1、3、5、7日目はAのアルゴリズム、2、4、6日目はBのアルゴリズムを使い、2週目の1、3、5、7日目はBのアルゴリズム、2、4、6日目はAのアルゴリズムを使うという感じです。

一定期間を分けるグループ数を奇数個にし、偶数期間と奇数期間でアサインされる機能が交互になるようにすることで、シーズナリティを軽減することができます。

実際には分けるグループはもう少し細かくて、例えば、1週間を一個160分のグループ63個に分け、機能AとBを交互に160分ずつ使用する(そうすると1週間でそれぞれの機能が交互に21回、22回ずつ使用されることになります)

Switchbackをサポートするためにはマーケットプレイス自体にサポートするための機能をつけなくてはいけないので初めて行う時のハードルは結構高いのですが、プラットフォーム企業ではこういった機能が市場の効率性やその他のメトリックに大きな影響を及ぼすため、しっかり投資して正確に効果を測っている会社が多いです。

After-thoughts

ということで、僕個人的に現場で学んできたノウハウを書き留めてみましたが、いかがでしたでしょうか？笑
書いてて、内容がなんか当たり前すぎるような気もしつつ、でも逆にマニアックすぎるような気もしつつなので、正直どこまで需要があるのかはわかりませんが 笑

とりあえず、自分用の備忘録としては書きたかったことを書けたんじゃないかなと思います 笑

 

ついに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と言われるくらいデータ、メトリックス、実験に、会社として強みを持っていて、いかに速く正確にインパクトを計測してそれを元にプロダクトを改善していくかについて、結構他では得られないような学びを得られた気がします。その点についても今回でカバーしたかったのですが、長くなってしまったので一旦切って、次回その辺の僕なりの学びについて紹介してみようかなーと思います！