見出し画像

プロデザ!byリクルート vol13「PdMが身につけるべきデータ分析スキル【Q&Aセッション】」

リクルートのプロダクト制作におけるナレッジをシェアするウェビナー「プロデザ!byリクルート」。第13回目となる今回のテーマは「PdMが身につけるべきデータ分析スキル【Q&Aセッション】」。

  「プロダクトマネージャー×データ」シリーズの第三弾となる今回のイベント。データ分析の業務プロセスや、プロダクトマネージャー(以下、PdM)が最低限持っておくべきデータ分析スキル、考え方など「PdMとデータ分析」にまつわる視聴者からの質問に回答していくことで、ナレッジを共有するのが狙いだ。  

登壇者は、『SUUMO』のUI・UX改善とチームリーダーを担う南大智。『ゼクシィ』のPdMとデータ組織を兼務する田中水彩。モデレーターはプロダクトマネジメント組織でグループマネージャーを務める永石陽祐。いずれもプロダクトデザイン室のPdM3名によるパネルディスカッション形式で行われた。  

※2023年7月25日に開催したオンラインイベント「プロデザ BY RECRUIT VOL.13 PdMが身につけるべきデータ分析スキル【Q&Aセッション】」から内容の一部を抜粋・編集しています。  

【登壇者PROFILE】

南 大智
株式会社リクルート プロダクトデザイン室 販促領域プロダクトデザインユニット(プロダクトマネージャー)。2018年にリクルート住まいカンパニー(現リクルート)に入社。データサイエンティストとして『SUUMO』のtoC向けデータ施策の分析/開発を担当。2021年よりPdM組織に異動し、現在は『SUUMO』のUI・UX改善及びチームリーダーを担当。
 

田中水彩
株式会社リクルート プロダクトデザイン室 販促領域プロダクトデザインユニット(プロダクトマネージャー)。2018年にリクルートテクノロジーズ(現リクルート)に入社。機械学習・DeepLearning周りのソリューション装着を担当。2019年より旅行領域のデータ分析・施策業務を担当。 現在は『ゼクシィ』でPdMとデータ組織を兼務。
 

永石 陽祐(モデレーター)
株式会社リクルート プロダクトデザイン室 グループマネージャー(プロダクトマネージャー)。名古屋大学大学院情報科学研究科修士課程修了後、外資系通信機器メーカーにてネットワークエンジニアとして通信事業者向けに移動体ネットワークの設計/検証に従事。2014年にリクルートテクノロジーズ(現リクルート)入社。グループ共通システムの企画や導入推進、運用改善業務を経て、『リクルートエージェント』等のサービス企画開発業務に従事。カスタマー接点のオンライン化を推進し全社表彰を受賞。
 
 

Q.データの裏にあるユーザー行動をどう想像する?


 
永石:それではパネルディスカッションを始めます。ご視聴のみなさんからお送りいただいたご質問に対して、私たち3名より回答させていただきます。
 

永石:最初のご質問です。「データの裏にあるユーザー行動はどうやって想像していますか? どのタイミングで現地調査に行ったり、追加でアンケートを取ったりしますか?」ということですが……南さん、いかがでしょう?
 
南:僕の場合はまず「ユーザーになりきる」ところから始めることが多いです。それが最も簡単な方法なので。僕が担当している『SUUMO』のアプリをユーザーになりきって使用して。じつは、そのまま実際に家を買ってしまいました(笑)。
 
ただ、それだけだと自分一人の感覚でしかないため、客観的な意見を知るためにカスタマーインタビューをしたり、チャットツールでユーザーの声を聞いたりといったこともしていますね。
 
永石:主観と客観、両方の視点を行ったりきたりしながらユーザー行動の理解を進めているという感じですかね。ちなみに、インタビューを取りに行ったり、チャットツールでファクトを追加したりするのって、どういうタイミングですか?
 
南:僕の場合は、自分の中で何かしらの仮説を持てたタイミングでインタビューなどを行うことが多いですね。
 
永石:なるほど。多少荒かったとしても、仮説を立てた状態でファクトに向き合うわけですね。田中さんの場合はどうですか? 施策を考えるにあたり、ユーザー行動を想像するためのプロセスみたいなものはありますか?
 
田中:私も基本的には南さんと同じやり方です。それに加えて、私の場合はチームのメンバーとディスカッションすることが多いですね。まだそこまで考えがまとまっていない段階でもとりあえず集まって「こういうタイプがいそうだよね」と意見交換しながら、ユーザー行動についての仮説の精度を高めています。
 
 

Q.納得感のあるペルソナの作り方は?

永石:次のご質問です。「納得感があるペルソナを作るにはどうしたらいいですか? 対象セグメント(属性)はどう決めている?」ということです。こちらも南さんからお願いします。
 
南:ペルソナ作りについては、自分が関わっているプロダクトではあまり力を入れてやったことがなくて。それよりも、ユーザーインタビューなどを通して、実際のユーザーがどんな課題をどれくらい抱えているのかといったリアルなところを特定していくことのほうが多いですね。
 
ただ、ペルソナを作る目的ではないんですが、実際にそうした調査の分析を進めるなかでユーザー像が明らかになっていくことは多いです。たとえば『SUUMO』でスマホアプリとスマホサイトで同じような施策をやったとします。そこで、違う検証結果が出ることで、アプリとサイト、双方のユーザーの違いが見えてきたりするので。
 
永石:田中さんの場合はどうですか? 施策を検討するうえで、ペルソナを作ったり、それを活用したりした事例などはありますか?
 
田中:正直、私もそこまで詳しいペルソナ像を作ることはないですかね。作ったとしても簡易的なものです。私がやっているのはエンハンスの施策が中心なので、新規事業を作るときほどしっかりとしたペルソナは必要ないと思っていて。ただ、
行動ログなどから「たとえば、このページに来ているカスタマーはどういう人なのかな?」と想像していくようなことはわりとやっていますね。
 
永石:なるほど。南さんの『SUUMO』も、田中さんの『ゼクシィ』も歴史と実績があるプロダクトなので、過去のアクセスログなどのデータや過去の施策に基づくファクトが蓄積されている。だから、イチからペルソナを作るよりも、そうした蓄積のなかから想像したほうが、より実態に即したユーザー像をイメージできるのかなと。ただ、立ち上げたばかりのプロダクトの場合はそうした蓄積がないため、やはりペルソナを立てるなどしてユーザー像をしっかり固めていくことは大事だと思います。
 

Q.立てた仮説が適切なのか、確かめる方法は?


永石:次のご質問です。「自分の仮説&対応が合っていたかどうかは、どうやって検証しますか? レコメンドのロジックに変更を加えても、良い新規物件が登場したなど、他の要因でも結果は変わると思います。切り分けるポイントがあれば教えてください」ということです。「物件」とあるので、『SUUMO』を想定したご質問かと思います。南さん、いかがですか?
 
南:前提として、レコメンドの改善にあたってはまずABテストで仮説検証をするのですが、『SUUMO』は大規模なサービスなので、基本的に一部のユーザーや物件の影響をあまり考慮せずに分析できます。とはいえ、たまに外れ値みたいなユーザーに影響を受けることがあって、そういうときはそれらの影響を取り除いた集計で検証結果を判断しています。
 
永石:そこは外部要因が混ざらないように注視したうえで、施策を検討していくという感じですかね。これは振り返りの設計などに近いのかなと思いますが、施策を考える段階である程度、「外的要因をどれくらい受けるか?」というのはしっかり考えておくものですよね。
 
南:そうですね。企画の内容にもよりますが。もちろん、ある程度はあらかじめ想定しておくことが望ましいですよね。とはいえ、実際には外的要因って、事前に想定できないものが多いのかなと思います。ですから、そういう場合の切り分けのポイントでいうと、日ごとのCVRをチェックしたときに「どこか跳ねている日はないか?」だったり、「一部のユーザーや物件に対して、大量に反響がきていないか?」といった部分を注視して切り分けを行うことはありますね。
 
永石:そこはマーケットの基礎分析や数字などを見れば、それが異常な値かどうかを判断できますよね。そこで違和感があったときには何かしらの外的要因の影響を考慮して、検証を行うということですかね。
 
南:そうですね。補足すると、そうした一部のユーザーや物件を除外する場合には、それが恣意的な判断にならないように注意する必要があるかなと思います。結果だけを見て、「ここがヘンだから取り除きたい」ということだと、恣意的に検証の結果を変えることができてしまいますので。そこは、あらかじめ除外の基準を設ける必要があります。たとえばCV数が50件以上とか、100件以上の場合は一律で除外しますとか、そういう基準を決めておくと恣意的な判断にならずに済むのかなと思います。
 
永石:そこは大事なポイントですね。田中さんはどうですか? 自分の仮説が合っているかどうかの検証みたいなことは、何かされていますか?
 
田中:私もABテストが中心ですね。ただ、ものによってはわざわざ工数をかけてABテストを実施できないケースもあるので、その場合は要素だけを抜き出して、行動ログから証明できることは証明していく。そのうえで、どこを検証すべきかを割り出して小さく検証していく、みたいなことをやっています。
 
永石:ありがとうございます。それもすごく分かります。施策のなかで、ここの部分は過去のデータで一定の検証ができるけど、ここはやってみないと分からないみたいなことってありますよね。そこを見極めるというか、複合的な判断が必要なのかなと思います。
 

Q.データ分析の切り口を増やすために、日頃から意識すべきことは?


永石:次の質問にいきましょう。「データ分析をする上でいろんな切り口が大事だと思いますが、データ分析の観点を増やす上で普段からどのように業務に取り組まれていますか?」ということです。田中さんは、データ分析の観点を増やすために取り組まれていることはありますか?
 
田中:リクルートの場合は社内でのナレッジの共有が盛んで、成功した施策だけでなく失敗した施策の要因みたいなところまでデータベース化されていて、気軽にチェックできます。そういった過去の事例が切り口のヒントになることは多いですね。
 
永石:『ゼクシィ』とはあまり関係ない事業の施策でも参考になりますか?
 
田中:そうですね。まるで異なる事業であっても、サイトの構成だったり、カスタマーの仮説やその動きみたいなところが似ていることもあるので、そのまま横展開できるケースも多いです。
 
南:僕も社内のナレッジ集は参考にしています。過去の事例が膨大にまとまっているので、自分の引き出しを増やすためにもよく見ていますね。それ以外だと、自由研究みたいな感覚で、自分が個人的に興味を持っていることを分析することはあります。最近は『SUUMO』アプリのAndroid版とiOS版のユーザー数の比率の推移を調べてみました。スタートは単なる好奇心なんですけど、いつか何かしらの役に立つかもしれないと思って。
 
永石:結局のところ、うまい切り口を考えられる人って、引き出しが多いんですよね。前回のPdM×データのイベントでも「適切な好奇心」というキーワードがありましたけど、南さんのように普段から好奇心を持ってサービスに向き合うことって、すごく大事なんじゃないかと。すぐに役立つか分からないけど、日頃からいろいろなことを調べておく。すると、周辺の知識が増えて、結果的にデータ分析の観点を増やすことにつながるのではないかと思います。
 
あとは僕が思うに「抽象化する」「構造的にとらえる」みたいなことも大事なのかなと。たとえば、社内のナレッジ集から過去の施策をいくつか見た時に「これとこれは同じ構造だな」とか「要はこういうことだな」みたいなことを捉えられる人は、切り口を立てるのもうまい印象があります。要は、具体的な事例をいったん抽象化して、別のプロダクトに転用できないか考えてみる。それを繰り返していけば、切り口の引き出しも増えていくのかなと思います。
 

Q.PdMはデータ分析の専門知識をどこまで理解すべき?

永石:次の質問です。「PdMはデータ分析のテクニカルな内容をどこまで理解すべきでしょうか? 使っている分析ツールは?」。田中さん、南さんともに「データ分析に長けたPdM」という印象がありますが、このあたりはいかがでしょうか?
 
田中:「どこまで理解すべきか」というと難しいのですが、たとえばレコメンドでいえば、詳しいロジックまで理解する必要はないのかなと思います。あとは、データを入れた時に出てくる、横文字のやたら難しそうな処理についても、ざっくりとした理解でいいのかなと。
 
ただ、データ分析のインプットとアウトプット、つまり「どんなデータを入れて、どんな結果が出てくるか」の定義は、しっかり押さえておく必要があります。特にインプットですね。たとえば、とあるユーザーの行動をもとに、式場のレコメンドロジックを考えるとします。見ている式場や頻度など、いろいろな要素があるなかで、どんな変数を入れるべきか。仮説を立てて適切なインプットをするためには、それなりの経験や知見がいるんじゃないでしょうか。
 


永石:南さんはどうでしょう。PdMはデータ分析のテクニカルな内容をどこまで理解すべきだと思いますか? 
 
南:僕も、必ずしも全てを理解しなくていいと思っています。僕自身はもともとデータサイエンティストとして仕事をしていたこともあり、理解できているほうだと思いますが、知識があるからといって、それが成果や事業への貢献に直接つながるわけではありませんから。ただ、知っていたほうが便利なことは確かで、施策のスピードは上がると思います。
 
永石:ありがとうございます。僕個人の意見も言わせてもらうと、ある程度のことは知っておいたほうがいいと思っています。田中さんや南さんの場合は、もともとそれなりに知識があるので自覚されていないかもしれませんが、実際はかなりの武器になっているんじゃないかと思います。仮説の精度も高まりますし、関係者との対話の論点がシャープになり、明らかにスピードが上がる印象があるんですよね。
 
とはいえ、知識さえあれば適切な企画を立てられるかというと、そういうわけでもなくて。PDMに求められるのは、先ほど田中さんがおっしゃったような「インプット・アウトプットの定義」を明確にし、データ分析の精度を高めること。まずは、そこにフォーカスするといいんじゃないかと思います。
 
田中:そうですね。ちなみに、質問に「使っている分析ツールは?」とありましたが、これは事業によって様々です。私の場合は、「Tableau(タブロー)」「Adobe Analytics」「BigQuery」などを使うことが多いですね。
 
 



Q.データサイエンティストと協業する際に注意する点は?


永石:次が、最後の質問です。「データサイエンティストの立場で、PdMと協業する時に意識するのはどんなことでしょうか」。まず、田中さんはいかがですか?
 
田中:データサイエンティスト、PdMの双方が、それぞれの立場にどれくらい寄り添えるか、みたいなところはすごく重要かなと思います。先ほどのインプット・アウトプットもそうですけど、それをやる目的などを含めてしっかり目線合わせして、不明な点があればしっかりコミュニケーションをとって潰しておく。また、データサイエンティストが困らないように、目的を明確に言語化して伝えたり、用途シーンをできるだけ具体化したりといったことも大事ですね。
 


永石:南さんはどうですか?
 
南:僕がデータサイエンティスト時代、PdMからデータ分析を依頼された時によくあったのは、目的や背景などを伝えられず、ただ「この数字を出してください」みたいなことを言われるケースです。そうした場合は、僕のほうから質問をして、目的や背景を深掘りするようにしていました。そうでないと、いくらその数字を出しても、もともと達成したかった目的に繋がらないことがありますから。
 
目的を聞き取りした結果、その数字を出しても成果に繋がらないと判断した場合は、別の集計の方法や、そもそも「やらない」という選択肢を提示することもありました。ですから、そこはPdM側がある程度、依頼の際に「何のためのデータ分析なのか」をしっかり伝える必要があると思います。
 
永石:それはめちゃくちゃ大事ですね。他職種とうまく連携できるPdMって、やっぱり説明がうまいですよね。言語化だったり、文脈を正しく分かりやすく伝えたりする能力に長けている。聞き手の目線で、相手が気になるであろうポイントを理解したうえで、ストーリー化して物事を伝えられるようなスキルは、データサイエンティストに限らず、さまざまなステークホルダーとコミュニケーションをとりながら施策を進めていくPdMに欠かせないと思います。
 
 


次回のプロデザ!のお知らせ


7月に開催し大好評だった「新規プロダクトのPMFまでの道のり大公開!〜プロデザ!BYリクルートvol.12〜」後編として「新規プロダクトの市場と事業の価値観をFITさせるプロセス大公開~プロデザ!BYリクルートvol.16」
を2023/11/14(火)19:00 〜 20:00に開催します!

ご興味のある方はぜひご参加ください!
お申し込みはこちらから



お知らせ|プロデザ室は仲間を募集しています

プロダクトデザイン室の募集情報は〈こちら〉のサイトからご確認いただけます。ぜひご一読ください☆
https://blog.recruit-productdesign.jp/

お願い|noteのフォローをお願いします!

こちらのnoteアカウントをまだフォローしていない方!ぜひフォローしてくださいね。皆さんのキャリアやお仕事に役立つ記事を発信していますので、絶対損させませんよ!!!

お願い|できればX(旧twitter)もフォローをお願いします

プロダクトデザイン室の公式X(旧twitter)ではイベントの見どころやオリジナルコンテンツを更新しています。ぜひフォローしてください。
https://twitter.com/Recruit_PD_PR


みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!

プロダクトデザイン室では、一緒に働く仲間を募集しています。