プロダクトマネージャーが身につけるべきデータ分析スキル 実践編〜プロデザ！BYリクルートvol.11に参加してきた

recruit-event.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下のトピックについてディスカッションすることで、プロダクトマネージャーがデータ分析をどのように行っているのかの話を聞くことができる会です。

【トピック1】社内に埋もれたデータを活用し、営業活動を支援する「サロンの集客課題を定量的に判断できるWebレポートサービス」を開発したtoB向け取り組み紹介

【トピック2】 カスタマー向けのレコメンド機能に対し、基礎的な定量データの分析から、定性的な仮説を策定、改善施策のPDCAを回すことで、レコメンド効果を改善したtoCの取り組み紹介（『SUUMO』）

【トピック3】データサイエンティストからPdMに転身してわかった、プロダクトマネージャーがデータ分析をするためのポイントや思考法

会の様子

事例1 : 商談前の準備にかける時間の削減

最初の事例として、商談前の現場を観察した結果、商談前の準備に業務の10%以上をかけていることに気が付き、その時間を削減した事例の説明がありました。

特に、不足情報を追加する作業と様々なデータを出力して解釈する部分に時間がかかっていたそうで、その2点を解決する課題として設定したそうです。

課題を解決する際には、

• 自分の足で一次情報を取りにいくこと
• 必要最低限の情報まで削ぐこと
• 未経験の自分が営業できる状態になるまでプロダクトを磨くこと

の3点を意識したそうです。
こうして徹底的に現場に立ったプロダクト開発を心がけ、自分が自信を持ちきれるくらいにプロダクトを磨くようにしたというお話がありました。

事例2 : SUUMOのカスタマー向けレコメンド機能の改善

続いて、toC向けの事例としてSUUMOのレコメンド機能を改善した事例の紹介がありました。

レコメンド機能の分析は、レコメンド物件の価格分布という定量データやモデルにInputしている特徴量の重要度のモデル分析をしていたそうですが、最初はどちらかというとHOWの改善に勤しみ過ぎたせいで失敗してしまったということです。(発表者の南さんはデータサイエンティストとして働いていたこともあり、自分自身の強みを活かそうとしすぎてしまった)

そこで、ユーザー課題起点の思考に転換することを心がけたそうで、仮説を持つ&仮説を疑うことを前提に、基礎分析を繰り返したそうです。
基礎分析を繰り返していく過程では、お気に入り物件のCVRが類似物件と比較すると高いことに気がつくとともに、残りのユーザーがCVしない理由の読み取りをし始めたそうで、そこで興味の減退をモデルに組み込んだ結果レコメンドCV数が改善したということでした。

事例3 : データサイエンティストからPdMへの転身

最後に、データサイエンティストからPdMへ転身した話から、PdMとデータサイエンティストが協業していく上でのポイントに関するお話がありました。

最初に、データサイエンティストとPdMの協業事例としては、ML・DLを用いたロジック開発やモニタリング・BIツールの開発やスポット分析・シュミレーションの3つに種類分けされるという話からスタートし、以降はそれぞれの種類で意識すべきポイントの話に移っていきました。*1

ML・DLを用いたロジック開発

こちらは、「何を入れて何が出てくるのか」の定義(データと結果の定義)が重要だというお話がありました。

モニタリング・BIツールの開発

こちらは、営業のシュミレーション会を繰り返し実施して営業トークの型とセットになったレポートを完成させた事例の話がありました。

Q&A

事例紹介の後はQ&Aセッションがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

ペルソナは一つに決めきるのか？ペルソナを作っていくための過程をもう一度詳しく知りたい(事例1)

ペルソナに正解を追い求めるのではなく、チームメンバーの共通理解や納得感の醸成を重要視した。

ペルソナ設定の切り口は？(事例1)

勤続年数をはじめ、どういう営業の人か？を意識して切り口を設定した。

商談同行がなければ発見できなかったインサイトはあったのか？(事例1)

「これがほしい」と言われたけれど全然使ってないじゃん、というものやその逆のポイントは商談に同行したことで見つかった。

営業について歩くというのはオンライン時代も可能だと考えるか？(事例1)

前提として今日の事例はコロナ前の話ではあった。オンライン化したことで営業がしやすくなった側面もあると思う。

営業は自分のやり方をオープンにしてくれないということはあったか？(事例1)

リクルートの営業のすごさなのか、やり方を透明にしない人は誰もいなかった。平時から、積極的に自分自身が持っているナレッジを共有する文化がある。

基礎分析の項目はどのように決めたのか？(事例2)

ユーザー理解のデータであるという捉え方をして、Input/Outputのイメージを持つことを大切にした。

オフライン検証とは具体的にどのようにやったのか？(事例2)

「レコメンド オフライン評価」でググると一般的な話は出てくる。SUUMOは、過去のレコメンドデータと既存のレコメンドデータを比較してオフラインのスコアを測定するようにしている。

前提条件などオフライン検証をやる上で気をつけたポイントは？(事例2)

前提条件をできるだけ揃えるというのは気をつけた。(スマホアプリだけで比較するなど)

データサイエンティストでなくてもリクルートではPdMとして働けるか？(事例3)

データサイエンティストでなくても働ける。自分の強みやバックグラウンドを意識して仕事をする人が多い。

データ分析から品質同士のトレードオフ関係ができることもあると思うが、QAとコラボして品質改善をしていくことがあるのか？(事例3)

周りではない。大規模開発とかだとあるのかもしれない。

見せても何もアクションできないデータについてクライアントのレベル感次第だと見せることに価値がある場合もあると思うが、そういう時にどうデータの取り扱いをしているのか？(事例3)

そんなにはない。御用聞きみたいなのは良しとしないので、提案とセットになることが多い。

会全体を通した感想

toB, toCそれぞれを始め、異なる観点でデータ分析やデータ活用の事例を聞くことができてよかったです。

データ分析といっても、まずはユーザーの徹底的な観察が重要だという話は特に印象的でした。

*1:前提として、データ分析はPdM自身ができることがベストだと考えているが、その際は目的と用途シーンの明確化が重要