プロダクト重要指標の管理・公開をシステムで 実現した話

2023/03/27_『アナリティクスエンジニア』のリアル～リクルートのデータマネジメント、試行錯誤の最前線～での、加藤の講演資料になります

Transcript

1. © Recruit Co., Ltd. All Rights Reserved プロダクト重要指標の管理・公開をシステムで 実現した話 1 データ推進室 データテクノロジーユニット D3M部 SaaS D3Mグループ 加藤　顕 2023/03/27
2. © Recruit Co., Ltd. All Rights Reserved アジェンダ 1. 自己紹介 2. データポータルの紹介とその目的 3. 運用の中で見えてきた課題 4. 課題をシステムでどう乗り越えたか 5. まとめ 6. 最後に 2
3. © Recruit Co., Ltd. All Rights Reserved Speaker 3 加藤　顕 （カトウ　ケン) 株式会社リクルート (2022/4新卒入社〜) • SaaS D3MG/DSG/DEG グループ所属 • 『Air レジ』などのAirプロダクトのデータ周りを担当 • 趣味: 旅、ゴルフ、ゲーム #recruitdata
4. © Recruit Co., Ltd. All Rights Reserved SaaS D3Mグループのビジョン紹介 SaaS D3Mグループのビジョンとは？ 4 #recruitdata
5. © Recruit Co., Ltd. All Rights Reserved SaaS D3Mグループ ビジョン 5 プロダクトに関わる人が 1秒で数値の確認、2分で原因の深堀り、30分で意思決定 できる状態の実現 事業の意思決定を正しく行うためのデータ品質に責任を持つ（データマネジメント/ガバナンス） データ環境の整備や教育によってデータ利用者が正しく分析を実行できる状態を実現する（セルフサービスBI） #recruitdata
6. © Recruit Co., Ltd. All Rights Reserved SaaS D3Mグループ ビジョン 6 プロダクトに関わる人が 1秒で数値の確認、2分で原因の深堀り、30分で意思決定 できる状態の実現 事業の意思決定を正しく行うためのデータ品質に責任を持つ（データマネジメント/ガバナンス） データ環境の整備や教育によってデータ利用者が正しく分析を実行できる状態を実現する（セルフサービスBI） #recruitdata
7. © Recruit Co., Ltd. All Rights Reserved プロダクト重要指標の管理 プロダクト重要指標の管理とは Airプロダクトでモニタリングしている重要指標の定義を把握し、 プロダクトとして見るべき指標の論理定義及び物理定義（SQL）の正解を決め、一元管理すること 最初は、各プロダクトの重要指標の管理をコンフルにより行っていましたが、 - ページや定義が乱立してしまう - SQLの差分管理が困難である など、問題点がいくつかありました。 そこで、新たにデータポータルというものを立ち上げ、コンフルから移行しました 7
8. © Recruit Co., Ltd. All Rights Reserved データポータルとは 8 データマネジメント活動の一貫としてD3MGでは正しい数値を出すための土台を整備するために作成、運用 しています #recruitdata
9. © Recruit Co., Ltd. All Rights Reserved データポータルの技術要素 9 データポータルでSphinxとGithub Pagesを使用しています - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術 #recruitdata GitHub Pages
10. © Recruit Co., Ltd. All Rights Reserved データポータルの技術要素 10 データポータルでSphinxとGithub Pagesを使用しています - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術 #recruitdata fig1. rstファイル fig2. 生成ページ
11. © Recruit Co., Ltd. All Rights Reserved データポータルの技術要素 11 データポータルでSphinxとGithub Pagesを使用しています - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術 #recruitdata GitHub Pages
12. © Recruit Co., Ltd. All Rights Reserved データポータルの技術要素 12 データポータルでSphinxとGithub Pagesを使用しています - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術 #recruitdata GitHub Pages
13. © Recruit Co., Ltd. All Rights Reserved 13 運用開始!! #recruitdata
14. © Recruit Co., Ltd. All Rights Reserved 運用中の声 14 これで解決だと思ってもなかなかうまく行きません #recruitdata レビュアーの手順が複雑で、特定の人 ばっかりレビューしてる この注意書きいい感じに描きたいんだけ ど 重要指標の定義が変わってるのにまだ 反映されていない
15. © Recruit Co., Ltd. All Rights Reserved 運用する中で見えてきた課題 15 データポータルを運用する中で大きく3つの課題が見えてきました 1. 差分管理が難しい 2. レビュアーの手間が大きく、複雑になっている 3.利用者の目線がかけている 順に見ていきます #recruitdata
16. © Recruit Co., Ltd. All Rights Reserved 1. 差分管理が難しい Sphinxはビルドを行うため、多くのファイル(css, htmlファイルなど)が生成される 16 #recruitdata
17. © Recruit Co., Ltd. All Rights Reserved 1. 差分管理が難しい それらの生成後のファイルをGithub上で管理することになり、 実際の変更点は数カ所でも、レビュー時は多くのファイル差分を見る必要があったり 17 #recruitdata
18. © Recruit Co., Ltd. All Rights Reserved 1. 差分管理が難しい 複数ブランチで変更すると生成ファイルが全てコンフリクトしてしまうなどの問題が発生した 18 #recruitdata
19. © Recruit Co., Ltd. All Rights Reserved 2. レビュアーの手間が大きく、複雑になっている 19 変更時は右図のようなフローで運用している 本フローだけを見るとシンプルなように見えるが実は、 変更時のフロー図 #recruitdata
20. © Recruit Co., Ltd. All Rights Reserved 2. レビュアーの手間が大きく、複雑になっている 20 変更時は右図のようなフローで運用している 本フローだけを見るとシンプルなように見えるが実は、 レビューのたびにレビュアーがブランチの切り替えやpull、ビルドなどを 実行しなければならず手間が大きい 結果、レビュアーの負担が大きく、定義の変更のハードルが 高くなってしまっていた レビュアー側で Pull レビュアー側でビルド 中身の確認 ブランチ切り替え 変更時のフロー図 #recruitdata
21. © Recruit Co., Ltd. All Rights Reserved 21 3. 利用者目線の欠如 データポータルを作成しても、使われていなければ意味がありません 使われるためには、どのような使い方があるのかそのためにはどうするのが良いのかが、 ポータルだけでは見えてきませんでした #recruitdata
22. © Recruit Co., Ltd. All Rights Reserved 長期運用に不安 3つの課題に直面 1. 差分管理が難しい 2. レビュアーの手間が大きく、複雑になっている 3. 利用者目線の欠如 課題を解決しなければ運用、更新が後回しとなり、情報が陳腐化し、重要指標の定義 が無駄になる →システムで解決しよう 22 #recruitdata
23. © Recruit Co., Ltd. All Rights Reserved 課題をシステムでどう乗り越えたか 3つの対策を実施 1. Github Actionsを利用し、ビルドをGithub上で実施 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 3. 利用ログの取得やインタビューの実施 23 #recruitdata
24. © Recruit Co., Ltd. All Rights Reserved 1. Github Actionsを利用し、ビルドをGithub上で実施 Github Actionsを利用し、SphinxのビルドをGithub上で実行するように 生成前ファイルのみを管理することで、管理するファイルを大幅に削減、差分を最小限にした 24 #recruitdata
25. © Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 本番リポジトリとは別にPreviewリポジトリを用意 その中で本番リポジトリのブランチごとにフォルダを管理 CI/CDを導入し、テストやSlack連携などを実施した 25 Previewリポジトリ デプロイ時のSlack通知 #recruitdata
26. © 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
27. © 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
28. © 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
29. © 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
30. © 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
31. © 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
32. © 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
33. © Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 33 これに合わせて、フローも変更し、依頼者やレビュアーがの作業を減らした #recruitdata
34. © Recruit Co., Ltd. All Rights Reserved 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 34 結果レビュアーの1PRに対するレビュー時間が 10 分以下 30 分 #recruitdata
35. © Recruit Co., Ltd. All Rights Reserved 3. 利用者のログの取得や声を聞く どれくらいの人に使われていて、何をみているのかがわからないためまずは、プロダクト環境に GA(Google Analytics)を埋め込みました 35 #recruitdata
36. © Recruit Co., Ltd. All Rights Reserved 3. 利用者のログの取得や声を聞く これによりよく利用されているページを拡充したり、 必要な機能を追加しました 追加機能例) - copy機能などのプラグインの追加 - SQLの中でよく利用するマートへのリンクを設置 - tipsなど情報を付与する際の強弱をつける - …etc 36 tips機能 コードのコピー機能 #recruitdata
37. © Recruit Co., Ltd. All Rights Reserved データポータルの導入　+ システム対応の結果 データポータルの導入とシステムによる対応の結果 課題であった - ページ、定義の乱立 - SQLの差分管理 に加え、データポータル導入時の課題であった - 差分管理が難しい - ビュアーの手間が大きく、複雑になっている - 利用者目線の欠如 を解決することができた 37
38. © Recruit Co., Ltd. All Rights Reserved システム改修の結果 課題に対してシステム改修を行い以下を実現 1. Github Actionsを利用し、ビルドをGit上で実施 →生成前ファイルのみを管理することができ、差分を最小限に 2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入 →Preview環境を用意しレビューにかかる工数を削減 3. Slack連携の利用やフローの見直し →初心者でも使いやすいシステムに 38 プロダクト重要指標の管理・公開をシステムで実現し、 長期運用でも継続できる環境を用意 →1秒で数値の確認ができる世界へ #recruitdata
39. © Recruit Co., Ltd. All Rights Reserved アナリティクスエンジニアの役割 データポータルというプロダクト重要指標のシステム作成を通して実感したのは - データを取りまとめることだけでは継続的な価値を創出できない - 価値を持続可能なものにするためにはシステムを最大限活用する必要がある 人が介在せずに価値を創出できるような仕組みを作ることが大事 そのためにはエンジニアリングにもデータにも精通した人材が重要であり 事業のデータ利活用を推進していく上でアナリティクスエンジニアが果たす役割は大きい 39 #recruitdata
40. © Recruit Co., Ltd. All Rights Reserved 次のセッション 40 講演資料などのハッシュタグ #recruitdata イベント終了後にアンケートのご案内もあ りますので、是非ご回答をお願いします！ #recruitdata 40
41. © 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
42. © Recruit Co., Ltd. All Rights Reserved 想定Q & A1 Q: いつ頃から運用して、今どれくらい経過しているか？ A: α,β版もあったが、GA版(公式版)としては運用し始めてから1年経過 Q システム導入の上で一番困ったことは何か？ A: 使いやすくしないと使われないので、管理者利用者両方の立場に立って利用すること Q: 指標の公開範囲や公開先はどのように決定していますか？ A: 社内において、指標の公開制限はしていない。ただし、実数値を出す際にはSQLを実行する必要があり、そのアク セスで制限はされている Q: 指標を共有することによるメリットはどんなものがありますか？ A: 乱立しがちなモニタリングや報告数値において、共通認識を作ることができ数値のずれや定義の違いを大幅に減 らせた。これにより認識齟齬をなくし、ビジョンである1秒で数値を確認することに大きく貢献している 42 #recruitdata
43. © Recruit Co., Ltd. All Rights Reserved 想定Q & A2 Q: 指標の更新頻度ってどれくらいですか？ A: プロダクトの方針にもよるが、毎月大きく変わるような指標はそもそも入れない。そのため、あってもプロダクト の中で半期に数回程度 Q: データの正確性や信頼性についてどのように保証していますか？ A: 変更の際には論理定義、物理定義が変わること、正しいことをプロダクトの責任者に確認をし、変更時には広報を 実施している。 Q: 指標の可視化方法について、どのような工夫をしているか？ A: 指標の可視化方法については今回触れていないが、ポータルで利用されている指標を利用することで、数値ずれ を防いでいる。可視化についてはモニタリングのノウハウを集めた資料を共有するなどして無駄なものは作らないこ とを念頭に置いている 43 #recruitdata