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
JavaScript研修 (2024)
recruitengineers
PRO
5
2.7k
TypeScript入門 2024
recruitengineers
PRO
19
12k
React 研修 (2024)
recruitengineers
PRO
33
11k
Next.js 研修 2024
recruitengineers
PRO
11
1.7k
App Router入門 Next.js App Router@Recruit bootcamp2024
recruitengineers
PRO
11
970
『実践オブジェクト指向設計』および『実践データベース設計』事前課題
recruitengineers
PRO
1
1.8k
実践オブジェクト指向設計 〜Javaで学ぶオブジェクト指向(応⽤)〜
recruitengineers
PRO
1
840
実践オブジェクト指向設計サブ資料:①オブジェクト指向の基礎
recruitengineers
PRO
1
400
実践オブジェクト指向設計サブ資料:➁データモデル中心設計
recruitengineers
PRO
1
330
Other Decks in Business
See All in Business
CompanyDeck_v5.0.pdf
xid
2
15k
インキュデータ会社紹介資料
okitsu
1
26k
株式会社タンプ 会社紹介資料 / TANP Inc. Company Profile
gracia
2
290
エスキュービズム 会社紹介資料
human_resources
1
5.7k
株式会社レイン_ピッチ資料
maiko1989
0
510
FeaSion 紹介資料
feasion
0
210
自己解決を支える検索技術と改善サイクル
akiroom
1
430
のぞみ整形外科理学療法士採用ピッチ資料2024年版
nozomi6000
0
140
デジタル証券準備・Company Deck
dts
2
1.9k
merpay-Overview
mercari_inc
5
140k
plex-recruiting-pitch
plex
1
290k
ゾンビスクラム先生が語る過ちと教訓!俺みたいになるな!
kuroppe1819
3
170
Featured
See All Featured
The Language of Interfaces
destraynor
151
23k
Building Effective Engineering Teams - LeadDev
addyosmani
56
2.3k
Optimising Largest Contentful Paint
csswizardry
27
2.7k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
26
7.2k
Into the Great Unknown - MozCon
thekraken
28
1.3k
Making Projects Easy
brettharned
111
5.7k
GraphQLの誤解/rethinking-graphql
sonatard
64
9.7k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
26
8.8k
What's new in Ruby 2.0
geeforr
339
31k
Side Projects
sachag
451
42k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
277
13k
Principles of Awesome APIs and How to Build Them.
keavy
124
16k
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