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
1.1k
プロダクト重要指標の管理・公開をシステムで 実現した話
2023/03/27_『アナリティクスエンジニア』のリアル~リクルートのデータマネジメント、試行錯誤の最前線~での、加藤の講演資料になります
Recruit
PRO
March 27, 2023
Tweet
Share
More Decks by Recruit
See All by Recruit
分散型と集中型で切り開くクラウドコスト最適化: リクルート横断プロダクトCroisのFinOps実践
recruitengineers
PRO
1
32
毎晩の 負荷試験自動実行による効果
recruitengineers
PRO
5
230
Transformerを用いたアイテム間の 相互影響を考慮したレコメンドリスト生成
recruitengineers
PRO
2
610
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
170
問題解決に役立つ数理工学
recruitengineers
PRO
13
2.8k
Curiosity & Persistence
recruitengineers
PRO
2
200
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
450
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
220
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
400
Other Decks in Business
See All in Business
インキュデータ会社紹介資料
okitsu
3
42k
HENNGE会社紹介資料/company_introduction
hennge
3
170k
LW_brochure_engineer
lincwellhr
0
34k
【DearOne】Dear Newest Member
hrm
2
11k
アウトカムファーストな専門技術組織の構築と運用のための取り組み / Efforts to Build and Operate an Outcome-First Technical Expertise Organization
lycorptech_jp
PRO
5
490
Feedback in Action
lycorptech_jp
PRO
1
340
株式会社ジグザグ_新規投資家向け資料_2025年7月.pdf
zig_zag
0
1.8k
ラクスパートナーズ採用ピッチ資料_エンジニア部門.pdf
rakuspartners_recruit
0
24k
Top 07 Ways to connect QuickBooks Payroll Support Number
qbpayroll1
0
200
CC採用候補者向けピッチ資料
crosscommunication
2
52k
フルリモートで社内にどうやって自分の居場所を作るのか?
satoshi256kbyte
12
18k
エレコム株式会社 中途採用説明資料
elecom_hr
0
730
Featured
See All Featured
The Invisible Side of Design
smashingmag
301
51k
Building an army of robots
kneath
306
45k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
The World Runs on Bad Software
bkeepers
PRO
70
11k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
A better future with KSS
kneath
238
17k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
The Cult of Friendly URLs
andyhume
79
6.5k
Producing Creativity
orderedlist
PRO
346
40k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
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