見出し画像

機械学習・DeepLearningも怖くない!PdMが持つべき、データ活用の思考法

この記事は リクルート  プロダクトデザイン室  アドベントカレンダー 2022 10日目です。

こんにちは、リクルートプロダクトデザイン室の田中です。
私はもともとデータ組織でデータプランナーをしていたのですが、去年からプロデザ室のプロダクトマネージャー(以下PdM)を兼務し、『ゼクシィ』にデータ&PdMの両面で関わっています。
組織長がキャリアの方向性を一緒に考えてくれて柔軟な異動や兼務ができる上に、次々に新しいお題に取り組めるありがたい環境だなと感じています!

さて、今日はデータ組織にいた人間が企画側を兼務してみて、企画側として「データ組織とコミュニケーションを取る時にはこうした方がいいんじゃないかな〜」と思ったことをつらつらと書いていこうと思います。

企画とデータの密接性

「ビックデータ」が叫ばれて久しい昨今、機械学習やディープラーニング(以下DL)がかなり身近になってきているのではないかと思います。
弊社でも今や成果を出しているプロジェクトの多くが「データ×〇〇」になっていて、様々なデータが取り扱えるリクルートにおいて、データをいかに使いこなすかが重要なファクターになっています。
各事業に専属のデータ組織が存在しており、PdMもデータサイエンティストとのやり取りを日々行うことになります。

企画側にデータ組織とのコミュニケーションが追加されたことの苦労

企画者は多くの組織と関わり、全体の調整を行い案件を推進していきます。
今まではその多くが開発エンジニアやデザイナーとのやり取りでした。
長年やり取りしている中でお互いに注意ポイントや伝え方のコツが蓄積しているものなのですが、データ組織は比較的新しく、開発知識とは別のモノであるため、企画側で知見の蓄積・伝達が不足しがちなのではと感じています。

データ分析って何をやるのか?機械学習・DLとは何なのか、何ができるのか?
企画としてどうやって関われば良いのか??

「データを活用した企画」の可能性と関わることがなかった企画者が一様にぶち当たる困惑だと思います。

社内外のデータ活用事例をかき集めて、なんとなくできそうなことのイメージは掴めた気がするけど、自分の担当領域で同じようなことができるんだろうか?
実際にデータサイエンティストとどうやってコミュニケーションを取ればいいんだろうか?言ってることが理解できないんですが…。なんですかその横文字の単語?怖い!!!

こんな感じです。(オーバーかもです。)

私も元々データの素養はなく、どうにかデータ組織で生き延びて来た人間ですので、企画者の方が企画推進に苦労する様を「気持ち分かる分かる」と見てきました。
企画側の素養を備えたデータサイエンティストも多くなってきているので企画者としてのキャリアとしても、データ系の知識は不可欠になっていくでしょう。

じゃあどうすればいいの?

ここからは、私の思う、企画者がデータ系企画を推進するために持っておくべき思考法を書いていこうと思います。
普通に企画の基本じゃんということが多いですが、お付き合いください。
(特に技術的な話はありません。)

データ組織に依頼するタスクは大きく3つあると思います。

① スポット分析・シミュレーション
② 機械学習・DLを用いたロジックの開発
③ モニタリング・BIツールの開発

以下でそれぞれについて「こういう関わり方がいいと思う」というポイントを書いてみます。

■ 共通して大切なこと

①~③全てに共通して大切なことは、
・目的を明確に言語化して伝えること
・用途シーンをできるだけ具体化すること
です。

この2点が明確に伝われば、それに相応しい手法はデータサイエンティストが提示してくれます。
(目的と用途がイケている事を前提に話していますが、そこの磨き込みこそ最も注力するべきところだと思います。)

企画者は提示されたものに対して、「本当に目的を達成できるのか?」「想定している用途に使えるものなのか?」の観点で質疑し、パワーを割けばよいです。
逆にこの根本の部分がふわっとしてしまっているとアウトプットも同様にふわっとしてしまい、目的に合わないもの、使えないものが出てくることになります。
そんなの当たり前だよ〜と思うかもしれませんが、データ活用系の企画がうまく行かない時にはそもそもここの言語化・検討が甘かったということが多々あります。

■ 個別ポイント:① スポット分析・シミュレーション

企画する案件によって多種多様なので言い切れない内容ではありますが、関わり方のポイントとして以下3点が挙げられます。

・テーマに対し、企画者が積極的に仮説立てを行うこと
 例えば「CV(コンバージョン)に効く変数を見つけたい」といったお題の場合、手当たり次第にそれっぽい変数を探っていくことはできますが、企画者側でも事業特性を踏まえて「多分これじゃないかな?」という仮説を持っておくことで、検証する変数の抜け漏れを防いだり、結果の解釈に役立てることができます。

・アウトプットイメージをすり合わせること
分析作業に入る前にアウトプットイメージのすり合わせを行うことも大切です。
分析が出てみて「あれ?違うな」ということが意外と多く、時間と労力を無駄にしてしまいます。
アウトプットイメージが具体的に浮かばない場合、ラフで相手に伝え、良さそうなイメージ案を提示してもらう方法でも良いと思います。もしすり合わせなしに作業に入りそうになっていたら一旦立ち止まってイメージのすり合わせを入れてください。

・アウトプットが他施策や事業知見から違和感がないか確認する
分析は人が行うものなので、間違いもあります。
今まで企画者として培ってきた数値感、事業知見を総動員して分析アウトプットに違和感がないか確認してください。その齟齬が新たな発見につながったりします。

・結果によってどう動くかを予め決める
これは先に話した用途の明確化と少し被りますが、想定される結果によってアクションを予め決めておくことで、データサイエンティスト側の分析結果の見せ方が変わってきたり、深堀り分析をスムーズに行ってもらうことができます。
分析で手を動かすデータサイエンティストが、テーマや目的感、その後のネクストアクションを理解しているかが、アウトプットの品質に直結します。
品質を最大限高め切るためにも、具体的に言語化することがとても大事だと考えています。
「あれ?打ち手もないし、この分析はいらないかも?」みたいになって不要な分析を省いたり、よりシャープな分析になることもあります。

■ 個別ポイント:② 機械学習・DLを用いたロジックの開発

①の分析と行き来したりイコールになることも多いですが、切り離してちょっとだけ②についてもお話します。

知らない横文字の単語が出てきただけでちょっと怖くならないですか?(私は怖いです)
W2V?LGBM?クラスタリング??みたいな。(基本ですよ!←怖)

各ロジックの特性や、やっている事の理解は少し難しいかもしれませんが、ここでも基本としてざっくりおさえておいたほうが良いポイントが存在します。
共通点を押さえることが最重要&近道ですので、恐れず攻めましょう。

・インプットとアウトプットは絶対におさえること
横文字のロジックの中で何をしているのかは分からなくても、共通しているのは「何らかのデータをインプットとして、何らかのアウトプットをする」ということです。
「何を入れて何が出てくるのか」の定義に関しては力を入れて理解、関わるようにしましょう。
特に精度にはインプット(どのデータを使うのか)が最も影響します。
どのデータがインプットとして良さそうかは事業知見が必要になり、企画側が最も得意とするところなので積極的に関わりましょう。
アウトプットに関しては、ほぼ次に述べる精度の話と被るので割愛しますが、精度以外だと、最初に設定した目的・用途に適したものなのかの視点でチェックが必須です。

重要なのはインプットとアウトプット

・精度の定義=企画の目的を達成する状態となっているかを確認すること
ロジック・モデル作成において、KPIを何に設定するかは注意深く検討してください。
開発者は、設定された精度を最大限に高める努力をしてくれますが、その精度の定義が間違っていれば使えないものが作られてしまいます。
例えば、レコメンドロジックを作成する場合、
・予約率を上げたいのか?
・その先の成約率を上げたいのか?
・予約率や成約率の他にビジネス的な要求は存在するのか?
などを議論し切る必要があります。
これは企画側が社内調整を含めて明確にやらなければいけないことなので、後々ブレることのない設定をしてください。
(クラスタリングなど特に精度がないものもあるのでその場合はビジネス要件をどうするかが主題になります。)

■ 個別ポイント:③モニタリング・BIツール

こちらも個別にバリエーションがあるので、一概に言えないですが、冒頭の「用途」の部分をもう少し詳しく書くことにします。

・モニタリングを「使われるもの」にする
苦労してモニタリングダッシュボードなどを作成しても、あまり使われないというのはあるあるだと思います。
理由は大きく2つあり、1つは作ったものが利用者の目的達成に適した作りになっていないこと、2つめは新しいツールを今の業務に入れることの困難です。

モニタリングの設計は簡単そうに思われるかもしれませんが、「見ておいたほうが良さそうな指標を手当り次第並べる」ようなやり方では実際に見る時に何を見てどうすればいいのか分からず次第に使われなくなります。使えるツールにするためには誰がどんなシーンでそれを利用し、利用した先のゴールは何なのかそれに向けてデータで何を語りたいのかを考えて設計する必要があります。
例えば、『ゼクシィ』では営業がクライアントに報告するためのレポートをBIツールで提供していますが、作る時には営業部署と連携してトークシュミュレーションを何度も繰り返して項目や見せ方の磨き込みを行いました。内部モニタリングでも目的と利用シーンからかなり具体的に項目の磨き込みを行うことで業務フィットするツールを目指します。

また、内部で「便利ツール」のように提供する場合、いかに組織に新ツールとして浸透させるか使ってもらえるものにするかまで考えておく必要があります。
『ゼクシィ』だと社内ツールについて定期的にメルマガが送られており活用事例などが紹介されていたり、勉強会が開かれたりしています。

以上が私が仕事をしていて企画側としてこう行動した方が良いなと思うことでした。
サイトの進化のためにデータをいかに活用していくか、UXの視点で目的と用途を捉え、データ組織の能力を最大限発揮してもらえる推進を目指して行ければ良いなと思います。
偉そうに書きましたが不足も沢山あるでしょうし、できていない・不十分だったな〜と感じながら日々過ごしております。
また気づいた事があればアップデートして発信できればと思います!


この記事が参加している募集

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