アーカイブ動画

アナリティクスエンジニア組織の立ち上げとこれから

株式会社リクルート　データ推進室　
データテクノロジーユニット　D3M 部　部長　山邉哲生氏

最初に登壇した山邉氏は、まなび領域のデータ活用責任者を務めるほか、D3M部の部長を兼任している。D3Mとは、Data Driven Decision Makingの略で、データマネジメントを通して経営資源としてのデータ価値を引き出し、意思決定の速度と精度を最大化するための組織として位置づけられている。

データ推進室がアナリティクスエンジニア組織を立ち上げた背景にあったのは、「データの利活用推進に伴って、データ分析基盤の要求が変化したこと」（山邉氏）だ。下図を見ればわかるように、青く塗られているところはすべてデータ推進室の管轄である。

要求の大きな変化としては、まず「要求元の分散化」が挙げられる。データの民主化が進み、経営・プロダクト・マーケ・営業など、様々な部署から依頼が来るようになったことである。

次に「難易度の高度化」だ。多角的・系列的・横断的な分析要件に耐えうるデータを提供することが増えてきたのだ。「スピード感のある意思決定のために、即時的な提供を求められることも多くなってきた」と、山邉氏は言う。

3つ目に「データマネジメントライフサイクルの長期化」である。新規機能や新規プロダクトの立ち上げが始まり、中長期での継続的なデータの品質担保が重要になってきたことが挙げられる。

システム面においてもETLからELTにアーキテクチャが移行していく中で利活用に近いレイヤーで確保するべき品質や対象となるデータ、あるいはアウトプットも増大の一途をたどっており、データ基盤の運用としてデータエンジニアだけ対応するのが難しくなってきていた。

「そこでModern Data Stack/Modern Data Teamの潮流も受け、ビジネスレイヤーに近接した領域でデータ利活用推進・およびデータマネジメントの装着を行うアナリティクスエンジニアのポジションを新設しました」（山邉氏）

アナリティクスエンジニアの役割は、要求元の分散化に対応して、よりステークホルダーに近いレイヤーでの要求整理、要件定義の実施、SSOT（Single Source of Truth）、再利用性を意識した継続的なデータモデリング手法を実施することだ。

難易度の高度化に対しては、構造的なロジックやメタデータの管理、CI/CDや自動テストなど、ソフトウェア開発手法を使ってDataOpsの実現を通して開発・運用の効率化を改善していくこと。データマネジメントサイクルの長期化に対しては、「Data as a Product」を念頭に、各種アウトプットの利用状況を定期的に確認しながら、データ環境のPDCAを回しつつ、注力すべき個所を特定していく。

「全てのデータを見ていくのは難しいので、要所を見定めながら重点的にケアしていくことも大事。その辺の優先順位をつけるという考え方も積極的に導入していきたい」（山邉氏）

狭義のアナリティクスエンジニアのメインとなる役割は、dbtやDataformを使って分析的な観点でのデータモデリングの実施、SQL を使ったデータ変換処理実装と定義されることが多いが、より上流で意思決定に寄与するための要求整理や要件定義が求められることも増えている。

また、BIダッシュボードの成果物管理やData as a Productとしてのデータマネジメントを実現するためには、意思決定者やデータ利用者の目線に立ったアウトカムを出すことも求められる。

「今、リクルートの中でアナリティクスエンジニアに求められるレイヤーは、一般的にデータアナリストやBIエンジニアとして定義される役割も包含した位置づけになっています」（山邉氏）

カーセンサーにおけるデータ活用の課題とは

株式会社リクルート　データ推進室
データテクノロジーユニット　D3M部　
マリッジ＆ファミリー・自動車・旅行 D3M グループ　森田順也氏

続いて登壇した森田氏は、『カーセンサー』のアナリティクスエンジニアとして分析基盤の開発に従事している。

近年の『カーセンサー』は単なる中古車情報サイトではなく、自動車業界の変革を受けて、車の利用シーンを包括的に支援するプラットフォームへと進化。それに伴い、ミッションも「あらゆる業務をデータで牽引すること」となっている。

このミッションを達成するには、各業務における様々なニーズに対応できる柔軟なデータ基盤が必要になる。そこで構築したのが、以下図のような分析基盤である。

「基本的にはELTのプロセスでデータを抽出・ロード・変換するというもの。dbt（Data Build Tool）によるデータ変換処理を軸とし、必要な人にデータを品質良く届けるための処理をいくつかの工夫を伴って実装。品質も高く、拡張性にも優れた基盤になっています」（森田氏）

もちろん、このような基盤は一夜にしてならずで、ビジネスと共に進化してきた。どのように進化してきたのか、森田氏は前・中・後期の3つに分けて解説した。

前期の開発テーマはディメンショナルモデリングとSSoT。このデータ分析基盤を構築する前は、サイロ化した分析基盤がいくつかあり、分析ツールも乱立していた。そのためクエリが重複し、見ている部署によって数値の定義がずれていたという。それらの分析基盤を全て統合すれば効率化・高品質化できるが、全基盤のマイグレーションは難しい。

「汎化できる部分のみSSoT化し、集中的に保守をするといったアプローチをとりました」（森田氏）

既存の分析基盤を残しつつ、共通化できる処理を見つけ出してdbt上で、単一のディメンショナルモデルを作成する。それを基に、KPIモニタリングや営業提案ツールなどのマートを構築していくというアプローチである。

保守するテーブルが限定されることで、その下流にあるテーブルは単純な集計処理になり、品質や生産性がどんどん向上していくという基本的なアプローチにはなっているが、「実際はそんなにうまくいかないところも多数あった」と森田氏は振り返る。

例えばスタースキーマを作るために、多数のサブシステムからテーブルを連携して揃えるのは、かなりの設計コストがかかるので非現実的である。そこで今あるデータから将来書くクエリを最小化できるという観点で、SSoTを作った。そのヒントは既存ツールのクエリにあり、半年に渡り既存ツールのデバッグ・改修を並行しながら解析し、SSoTを導出した。

「作業としては非常に泥臭いものですが、作ったテーブルは非常に便利で生産性の効率につながったと思います」（森田氏）

だが、これも長期的に使えるものではなかった。そこで中期に行ったのが、アドホックレイヤーの導入だ。森田氏の言うアドホックレイヤーとは、サイクルの速い分析要件に合わせた、生成されるモデルが全てviewであり、更新情報を使うjobが不要でレイヤーを無視することができ、開発フローから完全に切り出してリリースできるというレイヤーである。「ある意味、SSoTとは対局の位置づけをする考え方」と森田氏は説明する。

アドホックレイヤーを導入するメリットは、開発フローをかなりショートカットできること。だが無秩序なクエリができてしまうので、テストとドキュメンテーションとレビューだけはプロセスに組み込み、それ以外は省略している。

リリースまでの工程が短縮されるが、当然ガバナンスが落ちる。そこで泥臭く、アドホックレイヤーの運用ルールを定めたのである。運用ルールは複数あるが、一番のポイントは、アドホックで作ったテーブルを長期で運用する場合は、リファクタリングすることだ。

後期は、「データを武器にビジネスへ」という観点での改善である。つまり、データで価値を創出するために、データ中心にビジネスを変えるということである。一方で、データ中心へ移行していくには、業務変更がどうしても発生してしまう。

そこで必要になるのが、業務影響を最小限に生きたデータをすぐ分析できるよう、既存の手入力データを分析基盤に取り込めるような仕組みである。業務変更を小さくするため、既存のGoogle スプレッドシートやExcelを前提にクラウドストレージ経由やCloud Functions経由でBigQueryに取り込むようにした。

「企画してから約6カ月で運用開始できるのがこの基盤のいいところです」（森田氏）

もちろん、泥臭いことも行っている。例えば入ってきたデータの桁数が違ったり、文字化けしてしまったりということも多数発生する。そういった部分はツールとパイプラインの両方でテストを仕込み、不具合を検知・アラートを鳴らすような仕組みを作り、品質チェックしている。

カーセンサーに携わるアナリティクスエンジニアリングの価値の源泉は、変更に対する強さがあることだと、森田氏は言い切っている。

プロダクト重要指標の管理・公開をシステムで実現

株式会社リクルート　データ推進室
データテクノロジーユニット　D3M 部　SaaS D3M グループ　加藤顕氏

3番目に登壇した加藤氏は、『Airレジ』をはじめとするAirプロダクトのデータ周りを担当している。加藤氏が所属するSaaS D3Mグループのビジョンは、「プロダクトに関わる人が1秒で数値の確認、2分で原因の深堀り、30分で意思決定できる状態の実現」。その状態を実現するためには2つのことが重要になってくる。

1つ目は事業の意思決定を正しく行うためのデータ品質に責任を持つこと。2つ目が、データ環境の整備や教育によってデータ利用者が正しく分析を実行できる状態を実現することである。

具体的な取り組みとしては、まずプロダクト重要指標の管理だ。プロダクト重要指標の管理とは、Airプロダクトでモニタリングしている重要指標の定義を把握し、プロダクトとして見るべき指標の論理定義および物理定義（SQL）の正解を決めて一元管理することである。

これまではこの管理をコンフルで行っていたが、「ページや定義がコピーされたりして乱立してしまう」「SQLの差分管理が困難」などの問題点があった。そこで新たにデータポータルを立ち上げて、コンフルから移行することとなった。

データポータルとは、正しい数値を出すために論理定義と物理定義を一対一で対応させ、一元管理するためのもの。データポータルの技術要素は、SphinxとGitHub Pagesの2つ。Sphinxはドキュメント生成ツールで、マークダウン形式からドキュメントを生成できるライブラリ。もう一つのGitHub Pagesは。GitHubのリポジトリからファイルを取得してWebサイトを公開できる技術である。

この2つの技術によりデータポータルを作成し、昨年より本格的な運用開始。だが「これで問題が解決したわけではなく、3つの課題が見えてきた」と加藤氏は明かす。

1つは差分管理が難しいこと。Sphinxはビルドを行うため、多くのファイルが生成される。それらをGitHub上で管理するため、実際の変更点は数カ所でも、レビュー時は多くのファイル差分を見る必要があった。

2つ目にレビュアーの手間が大きく、複雑になっていること。データポータルを運用するにあたって次のようなフローを採用したが、レビューのたびにレビュアーがブランチの切り替えやpull、ビルドなどを実行するなど、手間がかかる。結果、レビュアーの負担が大きく、定義の変更のハードルが高くなってしまったという。

3つ目は利用者目線の欠如である。データポータルは使われなければ意味がない。使われ方や、求められる情報を整理する必要があるが、ポータルだけでは見えてこなかったのだ。

この3つの課題を解決するため、次の対策を実施した。まずはGitHub Actionsの一つの機能を利用し、SphinxのビルドをGitHub上で実施することを行った。生成前ファイルのみを管理するだけになったので、管理するファイルを大幅に削減、差分は最小限になった。

2つ目の対策は、本番リポジトリとプレビュー用のリポジトリを作成し、CI/CDを導入したこと。本番リポジトリとは別にプレビューリポジトリを用意し、さらにその中で本番リポジトリのブランチごとにフォルダを管理したのである。デプロイを押すと、プレビュー環境に行き、その変更点が反映されたページが見られる設計にし、CI/CDを導入してテストやSlack連携などを実施した。

構成としては以下図のように、水色の部分が本番リポジトリで緑色がプレビューリポジトリ。ブランチはそれぞれ管理されていており、本番リポジトリはfeatureブランチという、プルリクエストを作るたびに作るブランチやmainブランチ、リリースブランチを用意した。

プレビューリポジトリのブランチは1つだが、Directoryをブランチと一対一対応させている。何か一つ変更する場合は、featureブランチを作成し、CIを実行する。

CIに通ればプレビューブランチの方に変更が反映され、レビュアーはプレビュー環境のGitHub Pagesを確認。承認されればマージされ、featureブランチの内容がmainブランチに反映される。mainブランチの変更はCDが実行され、自動的に本番環境のブランチに反映、そして、本番反映される仕掛けとなっている。

これに合わせてフローも変更した。その結果、レビュアーの1プルリクエストに対するレビューは30分から10分以下でできるようになったという。

第3の対策は、利用者のログの取得や声を聞くこと。プロダクト環境にGoogle Analyticsを埋め込み、部署の人にヒアリングを行い、よく利用されているページを拡充したり、必要な機能を追加していった。

「データポータルの導入とシステム対応したことで、運用時の課題を解決することができた」と加藤氏。課題を解決したことで、プロダクト重要指標の管理・公開をシステムで実現し、長期運用でも継続できる環境が用意できた。

「データポータルというプロダクト事業指標のシステムを支え、事業のデータ利活用を推進していく上で、アナリティクスエンジニアが果たす役割は重要です」（加藤氏）

Lookerの捉え方は5年間でどう変わったのか

株式会社リクルート　データ推進室
データテクノロジーユニット D3M 部　まなび D3M グループ　近藤慧氏

最後に登壇した近藤氏は、まずまなび領域の変化について語った。領域内のデータ組織が拡大し、DWHもBigQueryで統合されて1つになっている。注目したいのは、「Lookerのユーザー数が、5年間で約5倍に増えている」点である。領域の拡大、専門のための分業化が進んでおり、2022年度よりアナリティクスエンジニア職も増えている。

Lookerの特徴は複数あるが、今回振り返るのは3つのテーマ。まずはLookMLですべてを記述できること。Lookerは、画面の表示や項目のラベル、ロジックを一つのファイルに定義していくことができる。

「2018年の導入当時は、BIとしては革新的なことであり、エンジニアとしては、これだけでLookerを入れるモチベーションになりました。現在も定義ファイルを1カ所にまとめておけるというメリットから、使い続けている理由の1つです」（近藤氏）

定義のキャッチアップや調査の際に一つずつダウンロードして、ファイルを開いて、コメントとロジックから定義を拾う必要がない。増えすぎた成果物を管理したり、時間が経ってレガシー化したものをリファクタリングする際は特に便利である。

「ファイルの分割や抽象化、テスト定義についても、負債を増やさないようデータ品質の担保にLookerを活用しています」（近藤氏）

GitHub連携ができることも、「当時は革新的だった」と近藤氏は振り返る。セルフサービスのBIツールは個人のファイル管理としては使いやすいが、レビューがやりにくく、バージョン管理ができないというデメリットもあった。それがLookerを導入するモチベーションになった。現在のGit管理はLooker上ですべて完結できるため、「一般的なGitのフローに基づいてレビューができて重宝している」と近藤氏は語っている。

アナリティクスエンジニア目線では、CI/CDやLinterを取り入れて、開発体験やレビュー体験をよりよくできないかを考えているという。なぜなら、徐々に負債は積み重なってしまうので、できる限り作るときの負債を減らしたいが、それは人間がレビューで指摘する際の心理的負荷を減らしたいという思いからだ。

「こうしたことを検討できるのも、アナリティクスエンジニアというポジションができたおかげです」（近藤氏）

その他にもアナリティクスエンジニアの役割として、セマンテックレイヤーの導入がある。事業全体の拡大に伴い、ガバナンスが効いたデータ提供の必要性が高まっており、SSOTなどのガバナンスがトレードオフにならないようにするためだ。

今の流行ではdbtやCubeの採用だが、LookerはGoogle SpreadsheetやLooker Studioからアクセスできるため、徐々にセマンテックレイヤーとしてのポジションが強くなってきている。そこで今あるLookerで検証しつつ、ユースケースがないか確認しようと、プロジェクトを進めている。

もう一つ、個人的に重要だと思っているテーマは、データ障害を未然に防ぐ取り組みである。そのためにも、データそのものの品質の担保や障害が起きる前に検知する仕組みづくりについても取り組んでいるという。

具体的にはBigQuery上にデータをテストする仕組みを作っている。2021年度にメタデータ基盤を構築。2022年度はそこの情報をdbtに直接連携して自動でテストするための基盤をデータエンジニアと共に構築した。今後はダッシュボード自体のオブザーバビリティを上げるための観測基盤の構築を検討している。

「Looker自体はAPIやファイルベースなので、そういったことがやりやすい。海外にはLookerとBigQueryを繋いだ内部のオブザーバビリティやイメージを可視化するツールもあるようなので、今後はこの辺を整備していこうと思っています」（近藤氏）

アナリティクスエンジニアを置いている組織は、「データアナリストにとっても良い組織と個人的には考えている」と近藤氏。アナリティクスエンジニアはアナリストからなるキャリアもあれば、ソフトウェアエンジニアやSREのノウハウを持ったエンジニアからなるキャリアもある。今のツールが機能を発揮し、アナリティクスエンジニアとしてキャリアをスタートさせる未来がくるかもしれない。

最後は充実の「Q&Aタイム」で盛り上がる

4人によるセッション後は、Q&Aタイムが始まった。たくさんの質問が寄せられ、最後まで盛り上がりをみせたイベントとなった。

Q．データのレイヤーによって「品質」の定義を変えているのか？

加藤：データポータルで追いかけている重要指標になんでも突っ込むと、すべての指標を追いかけることができません。会議で決め手を整理した上で、品質保証を行っています。また定義を変える場合についても、会議で共有しています。

森田：様々なレイヤーがありますが、レイヤーを振る舞いと内部処理に分けたときに、リファクタリングするときの振る舞いを変えずに、内部処理を変えるという考え方に近いと思います。 私たちの持っているデータパイプラインでは、最後の変換処理のテーブル群をレポーティング層と呼んでいます。例えばTableauやLookerから直接参照されるBigQueryは、レポーティング層で、振る舞いを定義して期待されるデータが返ってくるかを見るべきだと考えます。

一方、内部処理はディメンショナルモデリングデータもそうですし、その前のマスタデータも振る舞いに近い。そこは参照されるものを前提にリレーションが正しくできているかなどを見るため、内部処理としてテストする必要があります。振る舞いなのか内部処理なのかでテスト観点を分けてみることが重要だと考えています。

Q．全SaaSの全社共通の指標管理のページとしてSSOT化できているのか。指標1つとってもサイロ化することが多くあるなか、どう落とし込んだのか。

加藤：各プロダクトで持つ指標については、共通化しています。サイロ化するのは事業領域が多く、プロマネや営業などの役割によって見たい数字の定義が違うなどの背景があります。定義の共通化をすることで、サイロ化を防ぐことになると思います。営業を例に取ると、論理定義を決めるために共通認識を言語化し、その指標をもとに営業が追いかける定義を提案し、それ以外は自由にしてもらっています。最低限の定義を統一するという共通認識を持って進めるようにしました。

Q．ガバナンスのモニタリングは、どのように行なっているか

森田：明らかな違反（Lintルールの違反など）は、CIでチェックを行っています。モデリングの違反については、 dbt-project-evaluatorなどのパッケージも使えますが、ガバナンス自体を見るよりは、開発生産性や障害振り返り、KPTといった、DevOpsに課題が生じていないかを定性的ではありますがモニタリングしています。

ガバナンスを守る必要はありますが、アナリティクスエンジニアの価値は、「ビジネスにどれだけ貢献できるか」「品質の高いデータを出すことで事業をどれだけドライブできたか」です。プログラムをチェックしてアラートを挙げることよりも、先にテーブルを作って分析結果を出して、生産性が下がっているかどうかを確認し、課題があるなら次のアプローチを打つというプロセスが健全だと思います。

株式会社リクルート
https://www.recruit.co.jp/

株式会社リクルートの採用情報（アナリティクスエンジニア）
https://www.saiyo-dr.jp/recruit/Entry/select_job.do?to=job_view&jobId=1479