『リクナビ』、「データの民主化」するってよ
この記事は リクルート プロダクトデザイン室 アドベントカレンダー 2022 23日目です。
はじめに-自己紹介-
新卒HR領域のプロダクトデザイングループに所属している町田と小峰です。学生向けの就活情報サイト『リクナビ』を担当しております。
この記事では私たちのグループで実施しているモニタリング環境構築プロジェクトの取り組みを紹介します。サービスやプロダクトに携わる方は様々な取り組みをされているかと思いますが、人材領域ならではの難しさや我々が目指しているビジョンなどもお伝えできればと思います。
『リクナビ』が目指す「データの民主化」とは？
「データの民主化」とは？
最近「データの民主化」という言葉をよく聞くようになりました。データという言葉を聞くと、一般的にはデータサイエンティスト等の専門職が担当する業務というイメージがあるかもしれません。
しかし、LookerやTableauなどのBIツールが開発された現在では、私たちプロダクトマネージャーが施策立案と共にデータ分析をすることが可能になっています。
「データの民主化」とは、上記のようなデータ分析を専門職としない人が自由自在にデータ分析をすることが可能になることを言います。
従来データ人材を通して、二次情報としてデータを見ていましたが、これにより一次情報として触れることができるようになります。そのため、意思決定のスピードが上がり、結果としてプロダクトのクオリティを上げることができるでしょう。
「データの民主化」がなぜ必要なのか？
もう少し「データの民主化」の必要性に関して考えてみましょう。
前章で述べたように、確かに「データの民主化」による利点はありますが、新たに「データの民主化」プロジェクトを始める判断まで至らないということは往々にしてあると思います。
例えば、「現状すでにExcelで数値の取りまとめはできているし、より詳細にデータを見たいという時には専門のチーム体制が整っている」という場合です。
上記の場合でも「データの民主化」を推進すべきと考える理由に関して大きく3つの観点から見ていこうと思います。
①情報流通の効率化の観点
「データの民主化」の意味合いの一つ目として、企業運営的にいうと、決裁者でも生のリアルなデータにアクセスしやすく、意思決定の精度やスピードが上がるという点があげられます。事業データは組織の決裁者になるほど見るべき範囲が広くなり、抽象的なものほど決裁者に共有されるというのが一般的だと思います。
そのため役員をはじめとする部長やマネージャーなどの管理者は、事業の大局を見て意思決定をしてそれを伝えますが、受け取った一般社員にはその意思決定の背景や理由が伝わりにくいということがあります。
そこで「データの民主化」を行うことによって、必要なデータを簡単に検索・アクセスができるようになり、一般社員と管理者の間に存在していたデータの格差を縮めることが可能になります。
結果として管理者から一般社員への意思疎通が容易になると予想されます。
②データのビジュアライズ化による意思決定時間の短縮の観点
二つ目の内容として、データをビジュアライズすることの利点を考えようと思います。データをビジュアライズするというのは、ただ単純にグラフに落とし込むこととして軽く見られがちな内容かもしれません。しかし、表を用いての事業数値の共有というのは見るべき箇所が非常に多くなりがちで、各チームの中においてでさえも、中々浸透するものではないものです。ましてや事業部内で共有するのはより一層厳しいと考えます。
近年のBIツールを使用すると、通常のExcelなどで手作業で頑張って実施していたグラフ化などを、ボタンの操作だけで行うことができます。簡単に、かつより直感的に理解できるようなグラフやチャートを作成することができるのです。
事業数値の大枠を各チームメンバー（あるいは事業部内のメンバー）それぞれが直感的に理解しているという状況は、各施策を実施する上で効率性を大きく向上させます。データの内容が暗黙の了解としてメンバー間で合意できていることで、企画内容のエビデンスの提出を省略することができ、意思決定時間の短縮につながると考えられます。
③データ集計にかかる工数の極小化と信頼性
３つ目のメリットとして、「データの民主化」を達成することで、データを利用するときの集計工数を削減できることとデータ信頼度が向上することが挙げられます。
例えば、データ集計を実施している事業部は、事業部内で各チームごとにデータの抽出フォーマットを作成することがあると思います。その際に、各チームごとに抽出定義が異なるということがあり得ると考えています。
各チームそれぞれで抽出定義を設定しているので起こりえることではありますが、横並びでデータ分析を行う場合、定義が異なるのでせっかく抽出したデータが使えず、最初からやり直しということになることもあり得ます。
「データの民主化」の観点でBIツールを利用することでデータ抽出定義が揃い、その状態のデータをさらに加工することで、信頼できるデータが担保できると同時に、すでに土台の集計がされているため工数削減に繋がります。
また、定常的にチーム全体が確認すべき数値に関しては自動で更新されるように設定すれば更新工数は０になります。
「データの民主化」を推進すべき理由のまとめ
上記のように「データの民主化」による利点は多く存在し、新たに人材や工数を確保して進めるべき理由は十分と言えると思います。
「データの民主化」により、データサイエンティストをはじめとするデータ人材以外でもある程度データ活用をできるようになれば、データ人材が本来稼働を割くべきである、より複雑なユーザーアクションを解析することが可能になると予想されます。
加えて普段データに触れていないメンバーが、よりデータに対する関心・興味を持つようになることは、データドリブンな事業を進めていく上で重要な要素になります。
上記の意味でも「データの民主化」がやはり必要になると考えています。
モニタリングプロジェクトとは？-KPIやそれに紐づく指標を一元化できるモニタリング環境の構築-
プロダクト改修フローに関して
『リクナビ』において私たちがプロダクトの改修を行う際には、学生の皆さんのトレンドや行動、社会的な情勢などを参考にプロジェクトを立案し、高速で実装します。
現状、図のようなフローで施策を実施してプロダクトを改修しています。どれも重要なフェーズであり、『リクナビ』においては多くのプランナー・ディレクター・デザイナー・エンジニアが関わり合いながら上記のフローで開発を進めています。
ある一つの施策を進行する中では、以下のような検討事項が存在します。
・どのような指標（KPIをはじめとする数値）が影響を受けるのか
・該当指標がどれだけ向上するのか
・該当指標は向上することができるが反対に減少する指標はないのか
・施策実施工数と指標から得られるリターンは釣り合っているのか
検討した内容と社会的な影響度合い・ユーザー体験を総合して、該当施策を実施するかどうかを決定します。
数値によって実施可否を決める文化があるリクルートでは、モニタリング数値は施策を実施するか見送るかを判断するという意味で大きな要因になります。
なぜやろうと思ったのか-サービス全体の課題-
前述した通り、施策の実施にあたっての検討フローは全社的に確立されています。
一方で施策実施にあたっての上流からの「サービスの健康状態の把握」⇒「課題指標の特定」の工程は、毎回施策立案者がデータをわざわざ取りに行かないといけない状況でした。
・グループ全体で共通認識を持ち施策の方向性を全員で決める
・データの抽出工数を減らして、施策立案に最大限時間を割けるようにする
この2つの目的を達成するために、サービスの健康状態を把握して、課題指標の特定を簡易にすることで、実務レベルで業務改善ができるように検討を開始しました。
BIツール（DataPortal）で指標を一元的に可視化
データ環境のGCP（Google Cloud Platform)への移行という別プロジェクトの潮流に沿って、今回はLooker（旧dataportal）というBIツールでチーム毎の重要指標を可視化することにしました。
最重要指標をまとめた「まとめワークスペース」を作り、その配下に個別にワークスペースを作成し、紐づく各画面のＵＵ数などの指標を格納することで、サービスの健康状態の把握から、どこの指標が落ちているのかの課題指標の特定までを一元的に管理できる構造に。
「どんな施策を打つべきか」という大枠の方針に対し、サービス全体で共通認識を持てる状況に持っていきました。
プロジェクト開始～実際の運用までを半年足らずで実施したのですが、ここに至るまでにはサービスを横断してとりまとめることが多く、いろいろな苦労がありました。
次章からはＢＩツール作成にあたっての苦労話ができればと思います。
各TのKPIや紐づく指標のを把握・優先順位付け
組織やプロダクトが大きくなると、縦割りの構造になりがちです。
『リクナビ』も例に漏れず、各チーム毎でのKPI構造の全容を把握できている人がおらず、モニタリングする上での指標や、優先順位をヒアリング・定義するところからスタートしました。
追いたい指標は世代や時期によって変動する可能性があるため、更新のしやすさを考慮しオンラインホワイトボードでKPI構造を整理。
上記の各指標の定義やデータのソース元をExcelでまとめ、データ連携に伴う最低限の準備が整いました。
データの連携方法を精査
一番シンプルな方法として、GCPから直接Lookerにデータを流し込むのが当初想定した方法でした。
しかし社内のデータ環境が完全にGCPに移行しているわけではないので、GCPから取得できないデータの連携方法を考える必要がありました。
まず初めに検討したのが、
スプレッドシートにデータを連携し、Lookerに流し込むという案です。
手動更新がメインになってしまいますが、一番ライトな案としては定期的に各データソースからデータを引っ張ってきてスプレッドシートを更新し、直接Lookerに食べさせる方法を検討しました。しかし、社内セキュリティの関係上NGでした。。
そこで検討したのが、
スプレッドシートに入れたデータをGCPに流し込み、Big Query経由でLookerに流し込む方法です。
いろいろ思案した結果、上記の形で実装を進めました。
短期的に見ると、Big Queryを挟むことで1工程連携箇所が増え煩雑に思えます。
しかし背景を説明すると、データ環境をGCPＧＣＰに移行することを進めており、中長期的にはBig Queryでクエリを叩いてデータを取得することを考えています。
つまりBig Queryでクエリを叩いてデータを取得することで、今後テーブルを更新するときに今取得しているクエリがそのまま「モニタリングＰＪの説明書」（どこのテーブルのカラムから取得しているか）になるため、最終的には保守性が担保されるという意味合いで代替案②の方法を選定しました。
最後に
以上、『リクナビ』における「データの民主化」の足がかりについて、なるべくわかりやすく解説してきましたが、いかがだったでしょうか？
「データの民主化」は様々なサービスの課題でもあり、伸びしろでもあると考えてます。
グロースハックやUIエンハンスなどプロダクトに関わるすべての施策はデータドリブン的な考えで進められることが多いため、今回のPJを足がかりにして、プロダクトマネージャーがより簡単にデータを取り扱えるような世界を作っていけたらと考えています。
まだ、「データの民主化」という意味では第一段階目だと思っています。これからも、より必要なタイミングで自由に一次情報としてデータを取得できるような環境づくりを整えていければと考えています。
この記事を通して、同じ課題を感じている方の成功を後押しできれば幸いです！
