STORESのプロダクトマネージャー
西岡大揮氏：よろしくお願いします。僕の自己紹介をすると、2012年に楽天に入って、楽天市場のWebディレクターをやっていました。データ分析チームは別でありましたが、AdobeのSiteCatalystを使っていて、そこではSQLを書くことはありませんでした。
そのあと転職をして、クックパッド買物情報事業部に入りました。今ではロコガイドという会社になっている事業部でしたが、そこではデータ分析チームはなく、プロダクトマネージャーやエンジニアも一緒にSQLを書いていく環境でした。
3年弱くらい前にheyに入りました。最初はSTORES.jpのプロダクトマネージャーをやって、直近去年の12月くらいからSTORES予約に異動して、プロダクトマネージャーをやっています。
直近ではデータ分析チームは4人、5人くらいいますが、僕が入社した時は分析チームはなく、SQLを自分で書いたり、ダッシュボードを作ったりする環境でした。
プロダクトマネージャーがデータを見る2つの目的
プロダクトマネージャーがデータを見る目的を整理すると、2つに分けられると思っていて。事業の健康状態を把握するためと、あとは、もう少し具体的な施策に関する意思決定を行うため。イシューの測定や、要件定義のときの意思決定に使えるものじゃないかと思っています。
データは意思決定を早く正しく行うためにいいツールですが、使い方を間違えると、データが暴走しないかな？ というところで。僕自身もけっこう失敗したことがあったので、気をつけているところを話したいと思っています。
“データの暴走”とSTORESの開発対策
“データの暴走”がどういうことかと言うと、データの結論から、ぜんぜん違う文脈で使われたり。同じデータを見ていたとしても、人それぞれ解釈がぜんぜん違うため、議論が噛み合わないところがけっこうあったりしました。
データの暴走を防ぐために、1つ目は必要なデータを見極めることをけっこう意識してやっています。ある機能をリリースして、計測して、数値が上がって。いい結果が出ましたが「これって本当かな？」と。
必要なデータが漏れなく計測できているか。ほかにも「数値が10パーセント上がっているけれど、それって本当に成功なのか」のような目線が自分と上長で整っていなかったり、現場のチームで合っていなかったりはけっこうありました。
これを防ぐため、今のSTORESの開発では、基本的には事前の見立てや、チーム内レビューをしています。具体的には、事前の見立てをドキュメント化して、成功のイメージ、「どういう状態になると成功なんだろう」と話をして。定性的な情報から、その定性を定義できる定量的な数値を考えていくようなところのテンプレートがあったり。
あとは、チーム内レビューでプロダクトマネージャーだけでなく、施策に関わっているエンジニア、デザイナーを含めて「こういう数値を上げていきたい」「こうなれば成功」という目線を、事前にしっかりデータを見極めるところが大事かと思っています。
データを“正しく”疑う
2つ目、データを正しく疑う。クレジットカードを使う使わないはオーナーさんのストアによりますが、例えば、使っているストアと、使っていないストアの登録後1年間の累計売り上げが、使っているストアのほうが増えているデータがあったとします。
そうなると、クレカ利用を申請する、クレカを使ってもらうストアを増やしましょうという施策になり得ます。しかし、「それって相関関係であって、因果関係ではないよね？」とか。「ほかに変数があるんじゃないか？」とか。「そもそもサンプル数が足りていないんじゃないか？」のように、本当にその数値が正しいかどうかを疑っていく必要があるのではないかと思っています。
「データ」に向き合うプロダクトマネージャー
簡単にまとめると、SQLを書いて、ゴリゴリデータを抽出することもすごく大事です。しかし、データの暴走などに振り回されないように、特にステークホルダーが多いプロダクトマネージャーなので、関係者と同じ目線をもって、正しく早い意思決定をして事業を前に進めることを意識しています。
まとめると、必要なデータを見極めて、データを正しく疑って、データを抽出できることがプロダクトマネージャーとして重要ではないかと思っています。以上です。
