見出し画像

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

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

アナリティクスエンジニアがデータマネジメントついて話すという内容だったので、他社はどんなデータマネジメント活動をしているのかと思って参加してみました。

データマネジメント セミナーレポート

データマネジメント関連のセミナーに興味ある人はこちらからどうぞ。

著者の他のコンテンツとして、DMBOKについてまとめているのでどうぞ。

dbt Coalesce 2022に見るアナリティクスエンジニアへの期待とその可能性

発表者

山邉 哲夫

発表資料

概要

リクルートのデータ組織について

リクルートはマトリクス型組織で、データ系の部門は横断組織としてサービスを担当している。

その一つの職種として、アナリティクスエンジニアというJDを定義して募集している。データアナリストとデータエンジニアの懸け橋となる存在。

dbt Coalesce 2022とは

dbtが主催しているアナリティクスエンジニアのカンファレンス

Semantic Layer:散らかりがちな重要指標をdbt内で一元管理して、API越しに呼び出すことが可能になる機能。

Headless BI:BI内にビジネスロジックを持たずにセマンティックレイヤーで集計済みのメトリクスを使うことで集計が異なることを防ぐ。
ダッシュボードをコードで管理することでバージョン管理が容易になりました。

dbt Python サポート:SQLに加えてPythonでモデルを記述することができるようになった。SQLと連携して処理すくことが可能で、SQLで抽出したものをPythonで加工するようなことも可能。

モダンデータチーム組成論:変化が多いデータ環境に対応できる組織を作る。dbtのようなツールの出現によりデータエンジニアからデータアナリストへ対応が変わってきた。

アナリティクスエンジニアのキャリアパス:データアナリスト、データサイエンティストに求められるものを専門的に提供できることが強み。また、アナリティクスエンジニアがサイエンス領域へ進出していくことも可能。

セマンティックレイヤーに代表される、メトリクス設計・管理・活用推進がアナリティクスエンジニアの主業務と定義づけられた。
アナリティクスエンジニアはELTのT以降の専門家としてデータ管理を追求。
深いドメイン理解を基にデータエンジニアとビジネスのハブになるだけではなく、サイロ化を防ぐためにアナリスト&サイエンティストとのハブとしても機能する。

感想

アナリティクスエンジニアという職種が出てきたというのは、データ活用も成熟してきて、専門家が必要になってきたというのが背景なのではないかと思った。

実際自社にもアナリティクスエンジニアの領域をやっている人がいるので、職種はアナリティクスエンジニアではないにしろその領域が重要なのは納得がいく。

自社のアナリティクスエンジニアの役割を行っている人にdbtを使ってもらいたかったので、自分の感性は間違っていなかったというのがわかった。

色々生まれてきたデータ系職種の中でもアナリティクスエンジニアはデータマネジメントの理解度が高い必要があるなと思った。

プロダクト意思決定の質×スピードを上げる、”いつも”使われるモニタリング開発のアプローチ

発表者

白子 佳孝

発表資料

概要

リクルートはもともとのビジネスをAirビジネスツールを通して一体化する。

ビジョン

プロダクトに係る人が1秒で数値の確認、2分で原因の深掘り、30分で意思決定できる状態の実現

そのためには、データ基盤とデータ品質=データマネジメントが重要になってくる。

事例紹介

Saas領域でもユニットという単位で分割されており、AirSHIFTの事例。
サービス立ち上げ時にスピードを優先して、データ活用を優先しなかった。
その結果、同じ指標でも違う集計をしてしまい、データを活用した意思決定の質とスピードが低くなってしまった。

最初はそれでも問題なかったが、グロースのフェーズになったときには、データ品質に課題が見えてきた。

ただ、データマネジメントの温度感はなかなか上がらない。なぜならば質が低いながらも業務上は問題が顕著化されていないから。

温度感を上げるために、プロダクトサイドとの関係構築とデータマネジメント活動の両軸を推進してきた。

プロダクトサイドとの関係構築は、意思決定者と週次定例を行い、プロダクトにどうデータを使ってビジネスに活かすのかという目線合わせを行った。また、プロダクト戦略を検討する会議体へ参加した、このようにビジネスサイドと協業することで、データ組織の信頼残高を高める。

データマネジメント活動は、重要指標について、定義を洗い出し正解を定めてGitHub+SPHINXを使って一元管理することを行った。その定義を正しくかつ容易に出せるようにデータマートを作った。品質強度を高めるための取り組み、SQLコーディングルール、カラム名の命名規則、データの品質チェックを行い、プロダクトサイドへフィードバックした。

  • モニタリング設計はとても難しいので、丁寧にすり合わせる(モック、プロトタイプ、正式版)

  • 誰の意思決定に影響しないモニタリングは負債と考える。

  • 作って終わりではなく、作った後の運用も考える

モニタリングするためのダッシュボードにはデザインが非常に重要。そのためにデザイナーに協力を要請した。

実現できたこととしては、作ったダッシュボードを意思決定者がいる会議の場で意思決定できるようになった。いつも確認されていた定義の確認が無くなった。

重要な指標についてはモニタリングする仕組みができたので、セルフサービスBIの推進を行った。

データに誰よりも詳しい存在だからこそ頼られる存在として意思決定支援ができていると実感している。

感想

もともとデータマネジメントをやっていたと話していただけあって、データマネジメントでやるべしと書かれていることを愚直に進めている。

データマネジメントはデータマネジメントを目的とすると上手くいかないというのは自分も認識しているので、いかにうまくビジネスサイドを巻き込んでビジネスに効果があるものであると認めてもらう必要があるので、うまく巻き込んだ事例が語られており参考になった。

モニタリングに使われていないダッシュボードは負債であるという考え方も賛成で、データマネジメント組織もビジネス成果をKPIして運用コストだけかかるものはまさに負債なので、そこら辺の意識を感じてよかった。

『SUUMO』における行動履歴ログの品質担保の取り組み

発表者

新堀 秀和

発表資料

概要

「SUUMO」は不動産クライアントとカスタマーをつなぐメディア。

データの活用事例としては、Webサイト/アプリから取得できるユーザーの行動履歴ログを使って、機械学習やモニタリングを行っている。

フロント開発が埋め込んでいるログをどうやって、機械学習に活用されているのか把握しておらず、意図せず改変してしまい障害が発生してしまうケースがあった。

という課題があったため、アナリティクスエンジニアがフロントエンジニアと連携して品質担保する方法を紹介します。

フロントエンジニアは高頻度のUI改善を行う必要があり、連携が必要となるとデータ観点のテストを行うと阻害要因になってしまう。

自動テストを組んで、連携の必要をなくして品質を担保できるようにした。
具体的にはE2Eテストフレームワークを使って、Webビーコン型の行動履歴ログが仕様通りの内容か自動でテストした。そこで起きたいくつかの問題と解決法を紹介する。

仕様書が更新されない問題:テストが通らないとリリースできないようにした
テストコードのメンテナンスコスト:ログ仕様をDBに登録するだけで、テストコードを自動生成するようにした。副産物的にテストコードを書けない人もテストコードを生成することができるようになった。

その結果、狙った通りアジリティを損なうことなく、ログ収集の品質担保できるようになった。

感想

この手の話は、フロントエンドとデータもそうだけど、バックエンドとビジネスサイドもそうで、お互いが遠い関係性であると何のために必要なのか認識されてなくてうっかり障害を起こしてしまうというのはよくある話。

その課題の対応方法として、定例会やりましょうという事ではなく、システム的に対応したのが参考にできるところで、よくあるのはコミュニケーション強化しましょう、定例会やりましょうと言って、定例会だらけになって身動き取れなくなるのはありがち。

自動的に品質担保できる仕組みは最初立ち上げるのは時間がかかるにせよ、誰もが幸せになれる取り組みなのでよい事例ですね。

LookerやDataformなど、ModernDataStachを用いてデータ活用の負を改善する(していく)話

発表者

林田 祐輝

発表資料

概要

スタディサプリとは下は小学生から上は社会人まで学ぶ人を支援するサービス。

データを使って意思決定を行っている。

チームのビジョン

データ活用ユーザーに、意思決定に必要なデータ分析環境をサービスとして提供する。

現状ステークホルダーにデータの依頼を受けており対応しているが、最終的には自動販売機のように好きなものをいつでも取り出せるようにしたい。

チームは提供価値を上げる×生産性を上げるを目指して活動している。

データ基盤については以前紹介したものを参考にしてください。


Dataform

BigQueryの保守業務の難しさが課題となり導入
スケジュールのクエリ、アドホックのクエリ、バッチクエリなどのSQLが散在していた。
テーブル間の依存関係が負えないため、ロジック変更の補足が困難だった。

アナリストが実装することができるようになり、実装面の効率化ができるようになった。
また、テーブル内容、データリネージなどデータマネジメントにも貢献できた。

DataCatalog

DataCatalogにビジネスメタデータとオペレーショナルメタデータを登録していった。詳しくは以下を参照ください。

LookerとTableau

それぞれメリット、デメリットがあるためステークホルダーに合わせて使い分けている。

と思いきや、指標名が同じだけど集計方法が違うことで数字が違うなどの課題が出てきていた。

BI毎にロジックを作るのではなくて、共通のデータマートを作ることで一元管理できるようになった。今後はLookMLで一元管理したものをTableauで参照するようにしてガバナンスをかけていきたい。

感想

このセッションの話も課題となってきたのはデータマネジメントされていない文脈で、データ活用の初期段階はまあ見れればいいかなと言われていたのがあるタイミングから急に温度感高くなる現象はあるので、先を見据えて対応していくのが自身のためにも良い。

データ関連のツールはいつの間にか良いものがどんどん出るので、このようなセミナーでキャッチアップをしてよいものを取り入れる必要があると思っている。

ツールを使えばできたものを無駄なコストを割いて行うことになるので、そのような事の無いようににしたい。

おわりに

自分の知識をまとめるためと今後誰かがデータマネジメントをやってみたいと思った時のきっかけとなるためにnoteを書くことにしました。
モチベーションのために役にたったという人はぜひ、フォロー&スキをお願いします。

ツイッターでもデータマネジメントに係る情報をつぶやいてますので、よろしくお願いします。

データマネジメントを学ぶ人が抑えておきたい本

今すぐわかるデータマネジメントの進め方
著者のDMBOKを用いてCDO室を立ち上げデータマネジメントを推進した経験を基にデータマネジメントの進め方をまとめたkindle本を執筆しました。

DXを成功に導くデータマネジメント
DXを成し遂げるために必要なデータをどうマネジメントしていけばよいかが書かれている。
データ環境より、セキュリティの観点であったり、プライバシーの観点であったりといった非技術者向けの内容が多く書かれている。
データマネージメントに興味を持った人はまずは読んでみるとデータマネジメントでなすべき概要が理解できる。

実践的データ基盤への処方箋
データ利活用を行うために必要なデータ基盤の考え方と、利活用するためにはデータをどのようにマネジメントしていけば良いかを具体的な例を用いて説明されている。
技術が中心になるので現在データ技術に係る人がデータマネージメントに興味を持った時には、まず手に取ることをおすすめする。

個人データ戦略活用 ステップでわかる改正個人情報保護法実務ガイドブック
個人情報保護法を順守するための基本的な考え方が実務ベースで書かれている。2022年4月に施工される改正個人情報保護法で新たに追加される概念も同様に記載されている。
政府の出しているガイドラインよりも俯瞰的に読めるためデータプライバシーにかかわる人、データを使ったビジネスを推進する人は読んでおくとスムーズに業務が進められる。

データマネジメント知識体系ガイド(DMBOK)
自分も要約・解説記事を書いているDMBOK。データマネジメントに興味を持った人がまず手に取ると挫折することは間違いないほどのボリュームがある。
読めば読むほど味が出てくるので、データマネジメントを進めようとしている人は各家庭に1冊は是非買っておきたい。

データマネジメントが30分でわかる本
著者もDMBOKを読むためには非常にボリュームが多く読み解くには苦労するので、かみ砕いた解説書をまとめたと書いてある通り、DMBOKを独自解釈してわかりやすく書かれている。
DMBOKを技術者目線で読み解いた内容になっているので、実践的データ基盤への処方箋と同様データ技術に係る人におすすめする。


この記事が気に入ったらサポートをしてみませんか?