見出し画像
Photo by sanaearts

datatech-jp Casual Talks #3 レポート

よしむら＠データマネジメント担当

datatech-jp Casual Talks #3 レポート

#2は自分も発表してちょっと疲れたので、#3は気軽に聞いてレポートを書いてみたいな感じ。
今日のコンセプトはハイパー速報レポートを出そうと思って書いている。

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

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

データエンジニアを採用するための試行錯誤

発表者

syou6162　（モノタロウ）

発表資料

概要

データエンジニアの人員足りてますか？
モノタロウの採用に関する活動を振り返り、グループ独自に採用活動を始めた背景を紹介します。

GCPとかLookerとかを雑多に管理下板が、DMBOKをベースに管理することを決めた。

DMBOKの領域広すぎて、全然人足りないじゃんみたいな話になって採用活動を頑張ることに。

データ管理の人材獲得が難しい理由

  • データ管理人材は無くてもサービス存続に困らないため、あまり存在しない

  • エンジニアのキャリアプラン上にデータ管理がなかなか入ってこない

  • 地味なので魅力が伝わりづらい

採用活動をやって良かったこと４つ

口を開けて待っていただけでは余裕があったらやるタスクになりがちだが、グループ目標に組み込むことで、採用を熱意をもって取り組むことができた

Job Descriptionを書くことによって、データ管理について共通認識を持てるようになった。自分の仕事に納得感が持てるようになった。

「個人で」採用活動している形になってしまってチームで取り組んでいることを伝えられなかったので、会社の公式のなかチームで取り組むことができた。

採用のファネルはこんな感じ。「認知→カジュアル面談→応募」
アウトプットを増やすことで、認知の改善を行った。そのことでカジュアル面談の数がかなり増えた。が、応募は０件だった。
面談終了時のpushが足りない、クロージングの問題ではないかという話になった。pushも改善したら、応募も増えてメンバーも増えた。
採用もデータドリブンに取り組むことで改善できた！やったー！

採用活動だけを頑張るのではなく、普段の活動の言語化することで得ることと相互作用で頑張っていくと継続して続けることができる。

データエンジニア増やしていきましょう！

感想

データマネジメントする人の希少性は高い。おそらくデータマネジメント単品で取り組んでいる人というよりは、３つのうちどれかのパターンの人材がいそう。
データエンジニアはデータに対して真摯に向き合った経験があるので、データマネジメントに目覚めるためある程度いそう。
コンサルタントも最近データマネジメントで食いに来ているので、少しはいそう。
ビジネスは妖精さんが整えた後の数字を見ているので、少なそう。
自分はビジネス×データマネジメントやっている超レアキャラだと思っている。

  • データエンジニア×データマネジメント

  • コンサルタント×データマネジメント

  • ビジネス×データマネジメント

社外にアウトプットするのは勉強のためにも大事だと思うが、自分は怠惰な人間なので、意識的にやらないとやめちゃうので、めっちゃ意識している。

エンジニアとどう協業して分析を加速させるか

発表者

rerost/hazumirr　（Wantedly）

発表資料

概要

分析を取り巻く背景

ユーザーのデータがBigQueryに入ってLookerで分析する形。

問題とその根源は何か

プロダクトチームがデータの設計をするのだけど、プロダクト開発が進むにつれ分析の効率が悪くなってきている。

プロダクト開発と分析の担当者が属人的になってきて、ナレッジがたまらないのが課題。

どう取り組みか

分析の課題を実装上の問題にする。

分析上の課題：テーブルとかカラムの説明がない。
アプリケーション上の課題：RDB上のテーブルの説明がない

説明を同期する仕組みを作れば、実装の課題を解決すると分析の課題も解決される。

バックエンドエンジニアがバックエンドのコードに書いて、それをBigQueryのDescriptionに書かれるような形にすることで解決できた。

歴史を振り返り、新しいものを利用する。
データを加工するレイヤーでいいものがない。

歴史をふりかえると課題が明るみになる。そして現在を見ると昔はなかったが新しいものは課題を解決できるようなソリューションが出ている。

まとめ

２つの取り組みはよかった。

  1. 分析の課題を実装上の問題にする。

  2. 歴史を振り返り、新しいものを利用する。

Tips

３つのTIPS

  1. 既存ツールの社内向け速習会を再度行う

  2. Slackで「data_problem」スタンプをつけると問題が集まるように

  3. 分析を分析できるようにする

感想

プロダクトを作っている人と、データ基盤作っている人が一緒の人、もしくは近い人だからこそ、うまく回っているところがありそう。

歴史をふりかえりというのがあるが、自分もプロジェクトとかプロダクトとかで一定期間がたったら、未来の自分か後任の人かへのお土産として、課題をまとめておいておくことを意識している。

データ業界はドッグイヤーの世界の中でも早い業界なので、少し前では今のソリューションでは課題が解決できなかったものが、数か月後には解決できるソリューションが出てくる世界であることを意識しておくのは重要そう。

BigQueryの監査ログの使い倒し方

発表者

hiza　（メルカリ）
Analytics Infra：アナリストに近い立場で分析環境の整備を行うチーム

発表資料

概要

BigQueryが基盤で、利用者は９００名/月、データセットは１５００くらい。データ分析、ＭＬ、マーケティング、カスタマーサポートなどで使っている。

月間900名もBigQuery使っているのは、いいようなBIが作れてない課題というような感じに思っている。

監査ログとはこちら
・INGORMATUIN_SCHEMA.JOBS_BY
・AUDIT_LOG

頻繁に使われているテーブルを調べるのに、AUDIT_LOGが役に立つ。
どのテーブルからメタデータを着手するとかに便利。

AUDIT_LOGを集計すると、テーブルごとに利用者数を集計できる。
ユーザーのうち1割以上が使ったテーブルは1500のうち40ほどだった。

変更の影響を調べる。
カラムに変更を行いたい場合、そのカラムを参照するクエリは影響を受ける。BigQuery上にあるデータセットは慎重な変更が求められる。

変更するカラムを何人がどんな頻度で使っているか集計できる。
また、変更するカラムを使ったことがある人のアカウントが特定できる。
影響範囲の特定ができたね、やったー！

人事DBをleft joinすることで組織ごとにアクセスを分析できる。
そうするとより詳しい

使ったものが使われているのか調べる
中間テーブルの利用者を分析すると、利用者が増えている中間テーブルと、利用者が増えていない、もしくは使われていないことがわかる。

データの利用についてよくあらわれる傾向は、データは大量にあっても重要なのは全体の中の一部。
重要なデータを特定して、集中的にメンテナンス・改善を行うのが効率的。

感想

今日の話でいくつか出てきているけど、データチームの取り組みもデータドリブンでやっているのが良いね！基本的に取り組みは全て、KPI定めてデータドリブンで取り組んだほうがいいと思う。

改善するためには、数値でふりかえるというのが重要で、別の発表で歴史をふりかえるという話が合ったけど、ふりかえるときは定性的な意見を聞いてふりかえるのも重要だし、定量的に最初に狙ったKPIに対してどうだったかということをふりかえるのも重要。

今のチームは運用周りは、なぁなぁでやること決めがちなので、ちゃんと数値をとって方針決めに行くことを方針づけたほうがいいなと思った。

データ基盤チームのスクラム運用と生産性計測

発表者

Tsuchikawa　（Timee）

発表資料

概要

Timeeは隙間時間のバイトマッチングサービス。

データ統括部は、BIチーム、DSチーム、DREチームの３チーム構成。
DREチームの取り組みについて紹介。

DREチームはデータ基盤周り全般をやっている。
Notionでのチーム管理をして、スプリントもNotionでやっている。

スクラムイベントはスクラムで定められた４つのセレモニーを遵守してやっている。

チーム改善から生まれたよさそうな施策

４つくらいよさそうな施策が生まれた。

  • 不確実性ラベルの運用

  • ペアプロ

  • 一日開発デー

  • インセプションデッキの実施

不確実性が高いアイテムはできるだけ細かくアイテムを切り、見積もりを再度行うことでよくなった。

インセプションデッキ＝プロジェクトの全体像をまとめたドキュメント。

感想

人間呼ばれると答えたくなるので、どこの開発チームもほっとくと割り込みだらけになっているケースがよくあるので、割り込みタスクのふりかえりとかできているのがよさげ。
そして実際に1割に抑えられているというのはかなりすごい。

不確実性ラベルの運用はなるほどなと思って、不確実というのは塊が大きい、内容を理解できていないという事を理解しているので、解決手段が細かく分割することというのが理にかなっている。

インセプションデッキという単語を初めて聞いた。内容調べると、こういう当たり前だと思われていることを言語化するのはものすごい大事で、やはり効果があるということ。

dbt で DWH を構築してみて得た知見を共有したい

発表者

K(Komura Takayuki)

概要

Dimensional Modelingをやってみた。

  • これからdbtでDWHを構築される予定の方

  • dbtでDimensional Modelingを採用する予定の方

  • （書ききれなかった３つ目）

こちらをベースに説明

感想

データモデリングは勉強しないとなーと思いつつ、データエンジニア領域で専門家いるしなーと思って手を付けてない領域。

モデリング手法はいくつかあるけど、どういうときにどういう手法を使ったらいいのかさっぱりわからない。誰か教えてください！

おわりに

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

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

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

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

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

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

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

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

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


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