Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロダクト重要指標の管理・公開をシステムで 実現した話
Search
Recruit
PRO
March 27, 2023
Business
1
1k
プロダクト重要指標の管理・公開をシステムで 実現した話
2023/03/27_『アナリティクスエンジニア』のリアル~リクルートのデータマネジメント、試行錯誤の最前線~での、加藤の講演資料になります
Recruit
PRO
March 27, 2023
Tweet
Share
More Decks by Recruit
See All by Recruit
SIerでの経験が活きた!『SUUMO』『ゼクシィ』担当PdMの企画プロセスを紐解く〜プロデザ!〜
recruitengineers
PRO
0
68
事業目的とのプロトコル変換
recruitengineers
PRO
4
96
Boosting Hotel Profits: The Power of Enhanced Cancellation Predictions
recruitengineers
PRO
3
670
ヘルススコアの改善の過程で起きた嬉しい変化
recruitengineers
PRO
4
720
スクラム開発導入による 他組織を巻き込んだ開発生産性向上の取り込み
recruitengineers
PRO
3
380
大公開!SUUMOの裏側 -データ組織の取り組みLT会-
recruitengineers
PRO
4
120
FIFOキューで実現する Spring Bootの非同期処理とその性能評価方法
recruitengineers
PRO
5
160
組合せ最適化による問題解決の実践的アプローチ
recruitengineers
PRO
8
1.4k
社内のAI活用事例と活用促進のための取り組みを大公開!
recruitengineers
PRO
4
710
Other Decks in Business
See All in Business
オレンジスピリッツ 会社説明資料/Introduction
orangespirits
0
13k
問題を明確にする方法 / How To Clarify The Problem
tbpgr
1
280
ラクスル株式会社 会社概要(IR)
raksulrecruiting
5
6.4k
WORKERS'BOX document ver5.2
himojimoji
0
100
新規プロダクトの立ち上げ~グロースへの移行をスムージングする一つの方法論
kubotaku
0
190
クラスメソッド_会社紹介資料_202407 / introduction to classmethod for engineers
classmethod_jinji
1
1.3k
PMにとってスキルより大事なもの
pakugoku
0
200
DevIO2024_16_9_OnlineSlide_template 0708登壇資料_yukoyagi
yukoyagi
0
330
インキュデータ会社紹介資料
okitsu
1
25k
(3枚)営業のためのマーケティングマネジメントの全体像(コスト検証)
nyattx
PRO
2
1.2k
20240712_CM_Odyssey
hideki_ojima
1
190
enechain company deck
enechain
PRO
4
79k
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
36
9.1k
Typedesign – Prime Four
hannesfritz
37
2.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.5k
How to name files
jennybc
67
96k
How GitHub (no longer) Works
holman
305
140k
A designer walks into a library…
pauljervisheath
201
24k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
228
16k
Leading Effective Engineering Teams 2024
addyosmani
3
300
Rails Girls Zürich Keynote
gr2m
93
13k
4 Signs Your Business is Dying
shpigford
178
21k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
325
21k
Debugging Ruby Performance
tmm1
71
11k
Transcript
© Recruit Co., Ltd. All Rights Reserved プロダクト重要指標の管理・公開をシステムで 実現した話 1
データ推進室 データテクノロジーユニット D3M部 SaaS D3Mグループ 加藤 顕 2023/03/27
© Recruit Co., Ltd. All Rights Reserved アジェンダ 1. 自己紹介
2. データポータルの紹介とその目的 3. 運用の中で見えてきた課題 4. 課題をシステムでどう乗り越えたか 5. まとめ 6. 最後に 2
© Recruit Co., Ltd. All Rights Reserved Speaker 3 加藤 顕
(カトウ ケン) 株式会社リクルート (2022/4新卒入社〜) • SaaS D3MG/DSG/DEG グループ所属 • 『Air レジ』などのAirプロダクトのデータ周りを担当 • 趣味: 旅、ゴルフ、ゲーム #recruitdata
© Recruit Co., Ltd. All Rights Reserved SaaS D3Mグループのビジョン紹介 SaaS
D3Mグループのビジョンとは? 4 #recruitdata
© Recruit Co., Ltd. All Rights Reserved SaaS D3Mグループ ビジョン
5 プロダクトに関わる人が 1秒で数値の確認、2分で原因の深堀り、30分で意思決定 できる状態の実現 事業の意思決定を正しく行うためのデータ品質に責任を持つ(データマネジメント/ガバナンス) データ環境の整備や教育によってデータ利用者が正しく分析を実行できる状態を実現する(セルフサービスBI) #recruitdata
© Recruit Co., Ltd. All Rights Reserved SaaS D3Mグループ ビジョン
6 プロダクトに関わる人が 1秒で数値の確認、2分で原因の深堀り、30分で意思決定 できる状態の実現 事業の意思決定を正しく行うためのデータ品質に責任を持つ(データマネジメント/ガバナンス) データ環境の整備や教育によってデータ利用者が正しく分析を実行できる状態を実現する(セルフサービスBI) #recruitdata
© Recruit Co., Ltd. All Rights Reserved プロダクト重要指標の管理 プロダクト重要指標の管理とは Airプロダクトでモニタリングしている重要指標の定義を把握し、
プロダクトとして見るべき指標の論理定義及び物理定義(SQL)の正解を決め、一元管理すること 最初は、各プロダクトの重要指標の管理をコンフルにより行っていましたが、 - ページや定義が乱立してしまう - SQLの差分管理が困難である など、問題点がいくつかありました。 そこで、新たにデータポータルというものを立ち上げ、コンフルから移行しました 7
© Recruit Co., Ltd. All Rights Reserved データポータルとは 8 データマネジメント活動の一貫としてD3MGでは正しい数値を出すための土台を整備するために作成、運用
しています #recruitdata
© Recruit Co., Ltd. All Rights Reserved データポータルの技術要素 9 データポータルでSphinxとGithub
Pagesを使用しています - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術 #recruitdata GitHub Pages
© Recruit Co., Ltd. All Rights Reserved データポータルの技術要素 10 データポータルでSphinxとGithub
Pagesを使用しています - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術 #recruitdata fig1. rstファイル fig2. 生成ページ
© Recruit Co., Ltd. All Rights Reserved データポータルの技術要素 11 データポータルでSphinxとGithub
Pagesを使用しています - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術 #recruitdata GitHub Pages
© Recruit Co., Ltd. All Rights Reserved データポータルの技術要素 12 データポータルでSphinxとGithub
Pagesを使用しています - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術 #recruitdata GitHub Pages
© Recruit Co., Ltd. All Rights Reserved 13 運用開始!! #recruitdata
© Recruit Co., Ltd. All Rights Reserved 運用中の声 14 これで解決だと思ってもなかなかうまく行きません
#recruitdata レビュアーの手順が複雑で、特定の人 ばっかりレビューしてる この注意書きいい感じに描きたいんだけ ど 重要指標の定義が変わってるのにまだ 反映されていない
© Recruit Co., Ltd. All Rights Reserved 運用する中で見えてきた課題 15 データポータルを運用する中で大きく3つの課題が見えてきました
1. 差分管理が難しい 2. レビュアーの手間が大きく、複雑になっている 3.利用者の目線がかけている 順に見ていきます #recruitdata
© Recruit Co., Ltd. All Rights Reserved 1. 差分管理が難しい Sphinxはビルドを行うため、多くのファイル(css,
htmlファイルなど)が生成される 16 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 1. 差分管理が難しい それらの生成後のファイルをGithub上で管理することになり、
実際の変更点は数カ所でも、レビュー時は多くのファイル差分を見る必要があったり 17 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 1. 差分管理が難しい 複数ブランチで変更すると生成ファイルが全てコンフリクトしてしまうなどの問題が発生した
18 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. レビュアーの手間が大きく、複雑になっている 19
変更時は右図のようなフローで運用している 本フローだけを見るとシンプルなように見えるが実は、 変更時のフロー図 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. レビュアーの手間が大きく、複雑になっている 20
変更時は右図のようなフローで運用している 本フローだけを見るとシンプルなように見えるが実は、 レビューのたびにレビュアーがブランチの切り替えやpull、ビルドなどを 実行しなければならず手間が大きい 結果、レビュアーの負担が大きく、定義の変更のハードルが 高くなってしまっていた レビュアー側で Pull レビュアー側でビルド 中身の確認 ブランチ切り替え 変更時のフロー図 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 21 3. 利用者目線の欠如
データポータルを作成しても、使われていなければ意味がありません 使われるためには、どのような使い方があるのかそのためにはどうするのが良いのかが、 ポータルだけでは見えてきませんでした #recruitdata
© Recruit Co., Ltd. All Rights Reserved 長期運用に不安 3つの課題に直面 1.
差分管理が難しい 2. レビュアーの手間が大きく、複雑になっている 3. 利用者目線の欠如 課題を解決しなければ運用、更新が後回しとなり、情報が陳腐化し、重要指標の定義 が無駄になる →システムで解決しよう 22 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 課題をシステムでどう乗り越えたか 3つの対策を実施 1.
Github Actionsを利用し、ビルドをGithub上で実施 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 3. 利用ログの取得やインタビューの実施 23 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 1. Github Actionsを利用し、ビルドをGithub上で実施
Github Actionsを利用し、SphinxのビルドをGithub上で実行するように 生成前ファイルのみを管理することで、管理するファイルを大幅に削減、差分を最小限にした 24 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 本番リポジトリとは別にPreviewリポジトリを用意
その中で本番リポジトリのブランチごとにフォルダを管理 CI/CDを導入し、テストやSlack連携などを実施した 25 Previewリポジトリ デプロイ時のSlack通知 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 全体としてみると下記のような構成になります。これにgithub
actionsを組み合わせました。具体的な動き としては 26 リポジトリ ブランチ名 内容 Github Pages 本番リポジトリ リリースブランチ mainブランチの生成ファイル ◯ mainブランチ ビルド前のファイル featureブランチ1 PR1のビルド前ファイル featureブランチ2 PR2のビルド前のファイル … … Previewリポジトリ Preivewブランチ 各PRの生成ファイル - featureブランチ1の生成ファイル - featureブランチ2の生成ファイル - … ◯ #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 PRが作られると内部でactionsが動き、CIを実行CIに通れば自動でPreview環境に反映されるように
27 リポジトリ ブランチ名 内容 Github Pages 本番リポジトリ リリースブランチ mainブランチの生成ファイル ◯ mainブランチ ビルド前のファイル featureブランチ1 PR1のビルド前ファイル featureブランチ2 PR2のビルド前のファイル featureブランチ3 NEW!! PR3のビルド前のファイル Previewリポジトリ Preivewブランチ 各PRの生成ファイル - featureブランチ1の生成ファイル - featureブランチ2の生成ファイル - featureブランチ3の生成ファイル ◯ #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 PRが作られると内部でactionsが動き、CIを実行CIに通れば自動でPreview環境に反映されるように
28 リポジトリ ブランチ名 内容 Github Pages 本番リポジトリ リリースブランチ mainブランチの生成ファイル ◯ mainブランチ ビルド前のファイル featureブランチ1 PR1のビルド前ファイル featureブランチ2 PR2のビルド前のファイル featureブランチ3 NEW!! PR3のビルド前のファイル Previewリポジトリ Preivewブランチ 各PRの生成ファイル - featureブランチ1の生成ファイル - featureブランチ2の生成ファイル - featureブランチ3の生成ファイル ◯ CI実行 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 レビュアーはPreview環境のGithub
Pagesを見れば良いようになった 29 リポジトリ ブランチ名 内容 Github Pages 本番リポジトリ リリースブランチ mainブランチの生成ファイル ◯ mainブランチ ビルド前のファイル featureブランチ1 PR1のビルド前ファイル featureブランチ2 PR2のビルド前のファイル featureブランチ3 NEW!! PR3のビルド前のファイル Previewリポジトリ Preivewブランチ 各PRの生成ファイル - featureブランチ1の生成ファイル - featureブランチ2の生成ファイル - featureブランチ3の生成ファイル ◯ レビュアー 確認 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 その後、承認、マージされるとfeatureブランチの内容がmainブランチに反映される
30 リポジトリ ブランチ名 内容/ディレクトリ構成 Github Pages 本番リポジトリ リリースブランチ mainブランチの生成ファイル ◯ mainブランチ ビルド前のファイル featureブランチ1 PR1のビルド前ファイル featureブランチ2 PR2のビルド前のファイル featureブランチ3 NEW!! PR3のビルド前のファイル Previewリポジトリ Preivewブランチ 各PRの生成ファイル - featureブランチ1の生成ファイル - featureブランチ2の生成ファイル - featureブランチ3の生成ファイル ◯ マージ #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 その後、承認、マージされるとfeatureブランチの内容がmainブランチに反映される
31 リポジトリ ブランチ名 内容/ディレクトリ構成 Github Pages 本番リポジトリ リリースブランチ mainブランチの生成ファイル ◯ mainブランチ ビルド前のファイル featureブランチ1 PR1のビルド前ファイル featureブランチ2 PR2のビルド前のファイル featureブランチ3 NEW!! PR3のビルド前のファイル Previewリポジトリ Preivewブランチ 各PRの生成ファイル - featureブランチ1の生成ファイル - featureブランチ2の生成ファイル - featureブランチ3の生成ファイル ◯ CD実行 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 mainブランチに変更があれば、CDが実行され自動的に本番環境のブランチへ反映、本番反映される
32 リポジトリ ブランチ名 内容/ディレクトリ構成 Github Pages 本番リポジトリ リリースブランチ NEW!! mainブランチの生成ファイル ◯ NEW!! mainブランチ ビルド前のファイル featureブランチ1 PR1のビルド前ファイル featureブランチ2 PR2のビルド前のファイル featureブランチ3 PR3のビルド前のファイル Previewリポジトリ Preivewブランチ 各PRの生成ファイル - featureブランチ1の生成ファイル - featureブランチ2の生成ファイル - featureブランチ3の生成ファイル ◯ #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 33
これに合わせて、フローも変更し、依頼者やレビュアーがの作業を減らした #recruitdata
© Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 34
結果レビュアーの1PRに対するレビュー時間が 10 分以下 30 分 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 3. 利用者のログの取得や声を聞く どれくらいの人に使われていて、何をみているのかがわからないためまずは、プロダクト環境に
GA(Google Analytics)を埋め込みました 35 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 3. 利用者のログの取得や声を聞く これによりよく利用されているページを拡充したり、
必要な機能を追加しました 追加機能例) - copy機能などのプラグインの追加 - SQLの中でよく利用するマートへのリンクを設置 - tipsなど情報を付与する際の強弱をつける - …etc 36 tips機能 コードのコピー機能 #recruitdata
© Recruit Co., Ltd. All Rights Reserved データポータルの導入 + システム対応の結果 データポータルの導入とシステムによる対応の結果
課題であった - ページ、定義の乱立 - SQLの差分管理 に加え、データポータル導入時の課題であった - 差分管理が難しい - ビュアーの手間が大きく、複雑になっている - 利用者目線の欠如 を解決することができた 37
© Recruit Co., Ltd. All Rights Reserved システム改修の結果 課題に対してシステム改修を行い以下を実現 1.
Github Actionsを利用し、ビルドをGit上で実施 →生成前ファイルのみを管理することができ、差分を最小限に 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 →Preview環境を用意しレビューにかかる工数を削減 3. Slack連携の利用やフローの見直し →初心者でも使いやすいシステムに 38 プロダクト重要指標の管理・公開をシステムで実現し、 長期運用でも継続できる環境を用意 →1秒で数値の確認ができる世界へ #recruitdata
© Recruit Co., Ltd. All Rights Reserved アナリティクスエンジニアの役割 データポータルというプロダクト重要指標のシステム作成を通して実感したのは -
データを取りまとめることだけでは継続的な価値を創出できない - 価値を持続可能なものにするためにはシステムを最大限活用する必要がある 人が介在せずに価値を創出できるような仕組みを作ることが大事 そのためにはエンジニアリングにもデータにも精通した人材が重要であり 事業のデータ利活用を推進していく上でアナリティクスエンジニアが果たす役割は大きい 39 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 次のセッション 40 講演資料などのハッシュタグ
#recruitdata イベント終了後にアンケートのご案内もあ りますので、是非ご回答をお願いします! #recruitdata 40
© Recruit Co., Ltd. All Rights Reserved 本番リポジトリ 付録1) 全体の構成
41 github pages用 branch Previewリポジトリ github pages (Preview) CI CD push github pages用の branch github pages (本番) Github actions #recruitdata
© Recruit Co., Ltd. All Rights Reserved 想定Q & A1
Q: いつ頃から運用して、今どれくらい経過しているか? A: α,β版もあったが、GA版(公式版)としては運用し始めてから1年経過 Q システム導入の上で一番困ったことは何か? A: 使いやすくしないと使われないので、管理者利用者両方の立場に立って利用すること Q: 指標の公開範囲や公開先はどのように決定していますか? A: 社内において、指標の公開制限はしていない。ただし、実数値を出す際にはSQLを実行する必要があり、そのアク セスで制限はされている Q: 指標を共有することによるメリットはどんなものがありますか? A: 乱立しがちなモニタリングや報告数値において、共通認識を作ることができ数値のずれや定義の違いを大幅に減 らせた。これにより認識齟齬をなくし、ビジョンである1秒で数値を確認することに大きく貢献している 42 #recruitdata
© Recruit Co., Ltd. All Rights Reserved 想定Q & A2
Q: 指標の更新頻度ってどれくらいですか? A: プロダクトの方針にもよるが、毎月大きく変わるような指標はそもそも入れない。そのため、あってもプロダクト の中で半期に数回程度 Q: データの正確性や信頼性についてどのように保証していますか? A: 変更の際には論理定義、物理定義が変わること、正しいことをプロダクトの責任者に確認をし、変更時には広報を 実施している。 Q: 指標の可視化方法について、どのような工夫をしているか? A: 指標の可視化方法については今回触れていないが、ポータルで利用されている指標を利用することで、数値ずれ を防いでいる。可視化についてはモニタリングのノウハウを集めた資料を共有するなどして無駄なものは作らないこ とを念頭に置いている 43 #recruitdata