リクルートが考える「意思決定に効くデータマネジメント」とは ──アナリティクスエンジニア組織の立ち上げと事例紹介

アーカイブ動画

D3M部で活躍するアナリティクスエンジニアとは

最初に登壇したのは、山邉哲生氏。2015年に株式会社リクルートマーケティングパートナーズ（現リクルート）に入社。『スタディサプリ』のデータ分析基盤開発、Quipper社への出向などを経て、2021年よりデータの専門組織であるデータ推進部に参加。2022年4月に新設されたD3M部の部長に就任した。

リクルートのデータ組織はマトリックス型となっており、以下の図のように縦軸が各事業領域に対応したデータソリューションユニット、それを専門性で束ねた横軸がデータテクノロジーユニットである。

「データテクノロジーユニットは、データサイエンス部、データエンジニアリング部、D3M部の3つの専門性で組織運営しています。D3M部は、データマネジメントを通して経営資源としてのデータの価値を引き出し、意思決定の速度と精度を最大化するための組織です」（山邉氏）

具体的にはメトリクスの設計・定義、データマート・集計フローの構築、ダッシュボード・モニタリング環境の構築、データ品質の担保など、幅広い業務に携わることになる。

アナリティクスエンジニアは一般的に「分析にすぐ使えるクリーンなデータ環境を提供するために、ソフトウェアの開発手法を活用して生産性の高いデータ管理を実現する、データアナリストとデータエンジニアの架け橋となる存在」として定義されている。

アナリティクスエンジニアの期待と可能性は、dbt Labs社が開催するアナリティクスエンジニアのカンファレンス「dbt Coalesce 2022」でも語られた。

dbt Coalesceはさまざまな国の人が参加しており、アナリティクスエンジニアをはじめ、データエンジニアやデータサイエンティストなど、いろいろな人の関心を集めている。

10月に開催されたカンファレンスは米ニューオーリンズだけではなく、オンラインでの質疑応答やアーカイブ視聴もできるハイブリッド開催の形態をとっている。今回現地を訪れた山邉氏は、リアルタイムでセッションの感想をハッシュタグ「#dbtCoalesce」をつけて、Twitterで投稿している。

山邉氏はdbt Coalesceに関する5つのトピックスを紹介。まずは「dbt Semantic Layer」。散らかりがちな売り上げや会員数などの重要指標をdbt内で定義・一元管理し、API越しに呼び出しを可能にする機能である。

2つ目は「Headless BI」。セマンティックレイヤーで定義した集計済みのメトリクスを使うことで、ブラックボックス化を防ぎ数値の正確性を改善する。さらに、例えばApache Supersetの商用クラウド版であるPresetでは、ダッシュボードをコード管理できるようにすることで、「バージョン管理やローカル開発を可能にする流れもあった」と山邉氏。

3つ目は「dbt Python サポート」。従来のSQLに加え、Pythonでモデルを記述することが可能になり、豊富なライブラリが活用できるだけではなく、データサイエンティストとの親和性も向上。

「Pythonを主戦場にする人たちも活用できるようになった」と山邉氏が言う一方で、SQLモデルを参照することもできるので、SQLによるデータ抽出・変換とPythonによる複雑な前処理の連携も可能となった。

4つ目のトピックスは「モダンデータチーム組織論」。ビジネスドメインごとのオーナーシップの形成、変換処理や分析業務の民主化、プロダクトとしてのデータ提供など、データメッシュに代表されるような環境の変化を意識するトーンが強い。

「エンジニア視点で語る話が多いと思っていたが、アナリストがdbtのツールを学んで活用していくという視点が多かった」（山邉氏）

5つ目のトピックスは「アナリティクスエンジニアのキャリアパス」。「アナリストやデータサイエンティストに求められるものは何か、またその習得にはどういう選択肢があるのかというのを明示し、啓蒙するセッションが多かった」と山邉氏。アナリティクスエンジニアも、Pythonサポートも相まって機械学習パイプラインなど幅広い活用シーンを探求する様子が見えたと語った。

その所感をまとめたものが、次の図のようになる。

「セマンティックレイヤーに代表されるように、Single Source of Truthを実現するためのメトリクス設計・管理・活用推進がアナリティクスエンジニアの主業務の一つとして位置付けられてきたと感じた」と山邉氏。

アナリティクスエンジニアのパスも、アナリスト側からそのスキルを獲得していくというパスだけではなく、Pythonサポートによってより複雑な加工処理をサポートしていくパスも見られるようになってきた。

「価値あるデータ活用のあり方が問われている今、アナリティクスエンジニアへの期待は膨らんでおり、重要性も高まっている。今後のデータ組織にはアナリティクスエンジニアは欠かせない存在になる」と山邉氏は言い切る。

だからこそ、リクルートでもデータ活用を加速させるために、22年6月からアナリティクスエンジニアの採用を開始。課題も山積しているが、新しい取り組みを始めている。

意思決定のスピードを上げるモニタリング開発のアプローチ

続いて登壇したのは、白子佳孝氏。2017年にリクルートに入社。2021年より、SaaS領域におけるデータマネジメントグループのマネージャーを務めている。

リクルートではHR支援、販促支援に加え、現在は業務・経営支援に力を入れている。それを実現するため、『Airレジ』、『Airペイ』など「Air ビジネスツールズ」と呼ばれるプロダクトを提供している。

SaaS D3Mグループのビジョンは、「プロダクトに関わる人が1秒で数値の確認、2分で原因の深掘り、30分で意思決定できる状態の実現」である。

リクルートでは基本的に、30分の会議が多いためだと語る。つまり、「30分の会議の中で意思決定まで持っていくために、こうしたビジョンを設定している」と白子氏は言う。

そこで事業の意思決定を正しく行うための、データ品質に責任を持つ「データマネジメント/ガバナンス」と、データ環境の整備や教育に寄ってデータ利用者が正しく分析を実行できる状態を実現する「セルフサービスBI」の実現に取り組んでいる。

ではプロダクトの意思決定の質を上げるために、どのような取り組みをしているのか。

例えば『Airシフト』や『シフトボード』など、Labor事業の領域のプロダクトでは、サービス立ち上げ時のスピードを優先し、プロダクトサイドでデータ業務を実施していた。

だが、立ち上げ当初はモニタリングダッシュボードの数字が雑然としており、どのデータを事業として正しいものとして扱うのか、明確になっていなかった。デリバリーを優先し、個々にデータ活用を進めたことで、KGI/KPIの算出定義や使用するデータが統一されていなかったためである。

そのため、データ活用を活用した「意思決定の質×スピード」が低下してした。しかし、サービスが拡大期に入るにつれて、正しい数字をプロダクトメンバー全員が確認できる状態は重要になる。

「データマネジメントを推進すべきタイミングだと判断しました」（白子氏）

データマネジメントを推進するにあたり、データマネジメント活動に対する事業部内の温度感が低いという大きな壁もあった。「数値は見ることができるし、モニタリングもできているのに、やる必要があるのか」といった声もあったという。

そこで、データ利活用者、特に意思決定者との協働が不可欠であることを理解してもらうための施策を起こす。プロダクトサイドとの関係構築とデータマネジメント活動である。

プロダクトサイドとの関係構築では、意思決定者との週次定例を設けた。そこでは、目指すデータ利活用像に関して目線合わせを行い、各プロダクトの状況を踏まえた上で、今後起こりうるリスクを説明。データ組織の信頼残高を高めることに努めた。

またプロダクト戦略を検討する会議にも積極的に参加した。プロダクト戦略を検討する会議ではどのような議論・意見が交わされているのか、どの指標が特に注目されているかを把握し、一次情報を獲得するためだ。

もう一つのデータマネジメント活動では、モニタリング環境の前に正しい数値を出すための土台を整備することを目標とした。そのためにまずは重要指標の管理を実施。論理定義及び物理定義の正解を決め、GitHubとSPHINXを使って一元管理を行った。

次に、SSOT（Single Source of Truth）データマートの開発に取り組んだ。重要指標の数値が正しくかつ簡単に算出できるようにするためである。

品質の管理強度を高める取り組みも進めた。SQLコーディングルールを作成したのもその一つ。マートのカラム名ルールを整備し、PKの重複等が検知できるようにデータマート品質チェックも強化した。

これらの取り組みにより、プロダクトサイドがデータマネジメント活動結果を通じて重要性を理解し、支援するという状態を作ることができた。データマネジメント活動に対する温度感を上げることに成功したのである。

だが、ここまではあくまでもデータマネジメントを推進するための土台。本題は「1秒、2分、30分」の実現である。

「モニタリング設計は重要ですが、非常に難しい。週次の定例の中でモニタリング設計を段階的に開発していき、要件要望を都度ヒアリングしつつ進めていくスタイルを採用しました」（白子氏）

α版（プロトタイプ）に対する要望を追加し、正式版でリリース。また、「モニタリングにおいてUIは非常に重要」と白子氏は指摘する。そこでデザイナーと相談しながら、カラーコードの定義や見せ方の工夫をしたという。

こうしてプロダクトの意思決定者がいるモニタリング会議の場で、作成したダッシュボードが採用され、数値を見ながら意思決定に関わる議論ができるようになった。プロダクトに関わる人が、1秒で数値の確認、2分で原因の深堀り、30分で意思決定できる状態が実現できたのだ。

さらに、セルフサービスBIの推進も可能になった。SQLが苦手な人も業務に関する分析仮説を立て、データを抽出して仮説検証する新しい学習プログラムである。

日々の活動を通じて、担当事業のデータのことに誰よりも詳しくなることで、事業責任者から頼られる存在として意思決定支援ができる。だが、白子氏は、アナリティクスエンジニアの専門性を活かしてプロダクトグロースを成し遂げるためには、まだまだ白地はあると語っている。

「アナリティクスエンジニアとして、SaaS領域のデータ利活用をドライブさせるため、『1秒2分30分』の世界観をより当たり前にする活動を続けていきたいと思います」（白子氏）

サービス開発におけるデータマネジメントの課題と取り組み例

続いて新堀氏のセッションでは、不動産クライアントとカスタマーを繋ぐメディア「SUUMO」の事例について語られた。

SUUMOでは、メディアから取得できる行動履歴ログ（Webビーコン型のログ）を使って、機械学習を用いたリコメンドサービスやモニタリングなどに利活用し、物件の問い合わせや現地の見学や商談のマッチングを提供している。

アナリティクスエンジニアの活動領域は、以下のように加工・蓄積とモニタリングである。

マッチング向上は、サイトやメディアなどサイト開発でも取り組んでいる。『SUUMO』のUI/UX改善を高頻度、かつ継続的に実施。データ開発でも行動履歴ログを使って、リコメンドやモニタリングなどを通じてマッチング精度向上を目指している。

だが、その高頻度のUI/UX改善がリコメンドやモニタリングの障害原因となっていたと、新堀氏は明かす。障害が発生したのは、フロント開発側が、ログレコードの使用状況が把握しきれなかったことが原因となっていたのである。

「十分なテストが実施できず、意図せずして行動履歴ログが改変され、後続のデータサービス障害が発生していました。アナリティクスエンジニアが、フロントエンジニアと連携して行動履歴ログの品質担保をすることにしました」（新堀氏）

行動履歴ログの品質担保方法としては、ログ仕様を用意したテストが考えられる。だが、高頻度かつ継続的にUI/UX開発をしているため、アナリティクスエンジニアがテストを実施すると改善スピードが阻害される。そこで自動テストで解決できるように、フロント開発で使えるE2E自動テストを組み、行動履歴ログの品質担保を実施した。

実際の取り組みとしては、E2Eテストフレームワークを使い、サイト・アプリの生成するWebビーコン型の行動履歴ログに対して、自動テストを実施した。一般的なE2E自動テストは仕様書を用意し、それに対してテストを実行。その結果を突合する仕組みとなっている。

一つ課題となったのは、仕様書が更新されないこと。そのため、仕様を更新しないとテストが通らないプロセスとした。サイト改修のたびにエンハンスが必要になるため、テストコードのメンテナンス工数が上がらないように仕様自体をDBに登録。E2Eのテストコードを自動生成するようにした。

こうしてテストコードの作成を不要にし、メンテナンスコストを抑制することができたのである。一連のフローをまとめたものが以下となる。

「ログ仕様をDBに登録するだけでテストを実行できるフローにしたことで、テストコードを書かずに、行動履歴ログが取得できるようになりました。UI/UX改善スピードをほぼ損なうことなく、データサービスの障害も0件を実現しています」（新堀氏）

データ開発とフロント開発、いずれもマッチング向上という目的は同じ。アナリティクスエンジニアがフロントエンジニアと連携することで、両者が望む行動履歴ログの品質担保が実現できた事例と言える。

LookerやDataformなど、Modern Data Stackを用いて、データ活用の負を改善

最後に登壇した林田氏がグループマネージャーを務めるまなびD3Mグループのポリシーは「提供価値を上げる」「生産性を上げる」ことだ。

「提供価値を上げる」ためには、必要なタイミングで必要なデータがすぐに手に入る「当たり前品質」が必要だと林田氏は語る。つまり、使う時にそれが定義通りに正しいこと、使いたいときに使えること、データの内容が理解できることである。

さらに「生産性を上げる」ために、当たり前品質を担保しつつ、ステークホルダーからのデータ活用要望に応えていくためにデータ環境を整備している。

「D3Mグループは、GoogleのBigQueryから各種モニタリングツールに提供し、データマート開発やモニタリング環境構築をメイン業務として担当しています」（林田氏）

まなび領域のデータスタックは6種類あるが、今回紹介するのは、トランスフォーメーションツール「Dataform」、ガバナンスツール「Data Catalog」、BIツールの「Looker」と「Tableau」である。

Dataformの導入背景にあったのは、保守業務の難しさ。スケジュールクエリ、バッチクエリ、アドホッククエリなどのSQLが散在しており、テーブル間の依存関係が追えないため、ロジック変更の補足が困難だったからだ。少人数のチームのため、新規開発のスピード低下が懸念されており、新規参入者向けのナレッジシェアが難しかったという。

「開発効率を上げるため、dbtも検討しましたたが、データアナリストがIDEを効率よく使えること、コスト面での優位性が高いこと、さらにGCPのエコシステムに注力していることなどからDataformを採用しました」（林田氏）

Dataform導入で得られたのは、実装面で効率化が得られたこと。アナリストの開発効率を高めるために、ディレクトリ構成をBigQueryのdataset/table構造と統一、開発環境を用意し、本番環境と開発環境を分離。デフォルトを開発環境にし、CI/CDで環境変数を渡すようにした。

ガバナンス面では、テーブル内容やカラムレベルの概要を実装し、データリネージ機能で依存関係を調査できるようにした。また品質面でも、Assertionクエリによるテーブルのヘルスチェックが可能になるなど、効果が得られている。

一方で、「ガバナンスや品質の部分も、クエリも充足率が低い。抽象度が高いものはsqlxファイルが冗長になるといった課題も残っている」と林田氏は補足した。

続いて、Data Catalogの導入事例が紹介された。導入背景にあったのは、管理しているデータ資産（データマート）の把握。属人的なデータマート開発が進んでおり、特定ロジックはチーム内でシェアされていなかったことである。

もう一つの背景が、新規参入者へのオンボーディングである。「ソースコードを見るよりも理解しやすい形にしたかった」と林田氏は語る。そこでData Catalogを導入し、一元管理することにした。

実装部分はデータエンジニアリンググループが実施し、D3Mでは内容の登録を担当したという。「RECRUIT TECH MEET UP#3」でも紹介したが、2種類のメタデータをData Catalogに連携し、データマネジメントを強化。2つのメタデータとは、チーム（ビジネス）メタデータとオペレーショナルメタデータである。

Data Catalogをより活用するための課題は大きく2つ。一つはツール連携だ。現状のメタデータ登録は、GitHub上で登録する作業が必要だが、SQLでのデータマート開発やDataformから切り離されていた。開発とは別のプロセスで2重で登録業務を行っていたため、シームレスに連携したいと考えていた。

もう一つは品質情報の課題。要件や結果など各テーブルのAssertion情報をData Catalogに記述したいと考えているという。

「テストの仕様をメタデータに登録することで、各カラムの役割を持を残すことができるようになると考えています」（林田氏）

最後の事例はLookerとTableauの導入について。林田氏のグループでは、それぞれステークホルダーに合わせて使い分けている。

例えばプロダクトチーム向けには、ビジネスドメインを複数持っていることから、一元管理した開発を行いやすいLookerを提供している。一方、Tableauはデザイン要件が必要なケースで採用していた。
これらのBIツールの開発導入は、独立したチームで行っていたため、どちらも同じプロダクトを対象にしているにも関わらず、見ている指標が統一されていないことが課題であった。

こうした課題を解消するため、共通データマートを用意。リファクタリングを行い、ビジネスロジックを共通化した。

「将来的にはセマンテックレイヤーにLookMLを配置し、それぞれの要件に応じて、TableauやLookerを活用するような形にしていきたい」（林田氏）

【Q＆A】多くの質問が寄せられたセッション

セッション終了後のQ&Aタイムでは山邉氏がファシリテータとなり、参加者からの質問に回答した。いくつか抜粋して紹介する。

Q．「人手をかけずにデータの信頼を高める」ための具体的な打ち手とは？

白子：2段階で対応しています。1つはマートのPKが重複していないかを自動的にチェックする仕組みをつくること。これはTableauのアラート機能で通知。品質管理は人手をかけずに検知させています。SQLのレビューの自動化も行っています。

もう1つはステークホルダーが多いため、何を管理するのかスコープを絞り、何を重要視・管理するのかを整理。直接関わるデータを管理・棲み分けさせて、なるべく対応するものを減らしています。

Q．意思決定者を定例に呼ぶためにどのような勧誘・説得をしたのか

白子：データマネジメントおよび施策、事業として求めていることのすり合わせを行っています。SaaSのデータ組織としては、事業のKPIの分析、分析支援とセルフBIの推進、モデルの開発をするには、データマネジメントは必須だと端的に伝えて、必要性を語りました。

Q．データエンジニアとアナリティクスエンジニアの業務の棲み分けについて

新堀：データサイエンティストは機械学習を中心として、クライアントに価値を提供します。データを活用して社会貢献をしていく。アナリティクスエンジニアは、その前のデータを整備すること。データを見たい人に対して、データを整備して提供していきます。

アナリティクスエンジニアは図書館司書で、データエンジニアは図書館の運営を合理的にする開発者というイメージで業務を分担しています。

Q．ダッシュボード作成をアナリティクスエンジニアに担わせるメリットは？

白子：意思決定に関わる者はデータを正しく見る必要があるので、データマートや指標の管理が必要になります。アナリティクスエンジニアは、その裏側も整備した上で、ダッシュボードの開発を担っています。

Q．データの統一やフォーマットの統一で一番困ったことは？

林田：サービスの環境に合わせるところでしょうか。システム改修時はサービス側の改修の影響など、データ側にコメントをもらうようにしています。柔軟性を持って行うことが大切だと思います。

株式会社リクルート 中途採用ホームページ
アナリティクスエンジニア募集要項
https://www.saiyo-dr.jp/recruit/Entry/select_job.do?to=job_view&jobId=1479

＜関連記事＞
ブログ記事「アナリティクスエンジニアの募集を始めました」
社員インタビュー「アナリティクスエンジニア」
インタビュー記事「ビジネスとエンジニアリングをつなぐ「アナリティクスエンジニア」とは」