2023/03/27_『アナリティクスエンジニア』のリアル~リクルートのデータマネジメント、試行錯誤の最前線~での、加藤の講演資料になります
© Recruit Co., Ltd. All Rights Reservedプロダクト重要指標の管理・公開をシステムで実現した話1データ推進室 データテクノロジーユニットD3M部 SaaS D3Mグループ加藤 顕2023/03/27
View Slide
© Recruit Co., Ltd. All Rights Reservedアジェンダ1. 自己紹介2. データポータルの紹介とその目的3. 運用の中で見えてきた課題4. 課題をシステムでどう乗り越えたか5. まとめ6. 最後に2
© Recruit Co., Ltd. All Rights ReservedSpeaker3加藤 顕(カトウ ケン)株式会社リクルート (2022/4新卒入社〜)● SaaS D3MG/DSG/DEG グループ所属● 『Air レジ』などのAirプロダクトのデータ周りを担当● 趣味: 旅、ゴルフ、ゲーム#recruitdata
© Recruit Co., Ltd. All Rights ReservedSaaS D3Mグループのビジョン紹介SaaS D3Mグループのビジョンとは?4#recruitdata
© Recruit Co., Ltd. All Rights ReservedSaaS D3Mグループ ビジョン5プロダクトに関わる人が1秒で数値の確認、2分で原因の深堀り、30分で意思決定できる状態の実現事業の意思決定を正しく行うためのデータ品質に責任を持つ(データマネジメント/ガバナンス)データ環境の整備や教育によってデータ利用者が正しく分析を実行できる状態を実現する(セルフサービスBI)#recruitdata
© Recruit Co., Ltd. All Rights ReservedSaaS 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 のリポジトリからファイル を取得し、ウェブサイトを公開できる技術#recruitdataGitHub Pages
© Recruit Co., Ltd. All Rights Reservedデータポータルの技術要素10データポータルでSphinxとGithub Pagesを使用しています- Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ- GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術#recruitdatafig1. rstファイルfig2. 生成ページ
© Recruit Co., Ltd. All Rights Reservedデータポータルの技術要素11データポータルでSphinxとGithub Pagesを使用しています- Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ- GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術#recruitdataGitHub Pages
© Recruit Co., Ltd. All Rights Reservedデータポータルの技術要素12データポータルでSphinxとGithub Pagesを使用しています- Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ- GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術#recruitdataGitHub Pages
© Recruit Co., Ltd. All Rights Reserved13運用開始!!#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 Reserved1. 差分管理が難しいSphinxはビルドを行うため、多くのファイル(css, htmlファイルなど)が生成される16#recruitdata
© Recruit Co., Ltd. All Rights Reserved1. 差分管理が難しいそれらの生成後のファイルをGithub上で管理することになり、実際の変更点は数カ所でも、レビュー時は多くのファイル差分を見る必要があったり17#recruitdata
© Recruit Co., Ltd. All Rights Reserved1. 差分管理が難しい複数ブランチで変更すると生成ファイルが全てコンフリクトしてしまうなどの問題が発生した18#recruitdata
© Recruit Co., Ltd. All Rights Reserved2. レビュアーの手間が大きく、複雑になっている19変更時は右図のようなフローで運用している本フローだけを見るとシンプルなように見えるが実は、変更時のフロー図#recruitdata
© Recruit Co., Ltd. All Rights Reserved2. レビュアーの手間が大きく、複雑になっている20変更時は右図のようなフローで運用している本フローだけを見るとシンプルなように見えるが実は、レビューのたびにレビュアーがブランチの切り替えやpull、ビルドなどを実行しなければならず手間が大きい結果、レビュアーの負担が大きく、定義の変更のハードルが高くなってしまっていたレビュアー側で Pullレビュアー側でビルド中身の確認ブランチ切り替え変更時のフロー図#recruitdata
© Recruit Co., Ltd. All Rights Reserved213. 利用者目線の欠如データポータルを作成しても、使われていなければ意味がありません使われるためには、どのような使い方があるのかそのためにはどうするのが良いのかが、ポータルだけでは見えてきませんでした#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 Reserved1. Github Actionsを利用し、ビルドをGithub上で実施Github Actionsを利用し、SphinxのビルドをGithub上で実行するように生成前ファイルのみを管理することで、管理するファイルを大幅に削減、差分を最小限にした24#recruitdata
© Recruit Co., Ltd. All Rights Reserved2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入本番リポジトリとは別にPreviewリポジトリを用意その中で本番リポジトリのブランチごとにフォルダを管理CI/CDを導入し、テストやSlack連携などを実施した25Previewリポジトリデプロイ時のSlack通知#recruitdata
© Recruit Co., Ltd. All Rights Reserved2. 本番リポジトリと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 Reserved2. 本番リポジトリと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 Reserved2. 本番リポジトリと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 Reserved2. 本番リポジトリと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 Reserved2. 本番リポジトリと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 Reserved2. 本番リポジトリと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 Reserved2. 本番リポジトリと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 Reserved2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入33これに合わせて、フローも変更し、依頼者やレビュアーがの作業を減らした#recruitdata
© Recruit Co., Ltd. All Rights Reserved2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入34結果レビュアーの1PRに対するレビュー時間が10分以下30分#recruitdata
© Recruit Co., Ltd. All Rights Reserved3. 利用者のログの取得や声を聞くどれくらいの人に使われていて、何をみているのかがわからないためまずは、プロダクト環境にGA(Google Analytics)を埋め込みました35#recruitdata
© Recruit Co., Ltd. All Rights Reserved3. 利用者のログの取得や声を聞くこれによりよく利用されているページを拡充したり、必要な機能を追加しました追加機能例)- copy機能などのプラグインの追加- SQLの中でよく利用するマートへのリンクを設置- tipsなど情報を付与する際の強弱をつける- …etc36tips機能コードのコピー機能#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イベント終了後にアンケートのご案内もありますので、是非ご回答をお願いします!#recruitdata40
© Recruit Co., Ltd. All Rights Reserved本番リポジトリ付録1) 全体の構成41github pages用branchPreviewリポジトリgithub pages(Preview)CI CDpushgithubpages用のbranchgithub pages(本番)Github actions#recruitdata
© Recruit Co., Ltd. All Rights Reserved想定Q & A1Q: いつ頃から運用して、今どれくらい経過しているか?A: α,β版もあったが、GA版(公式版)としては運用し始めてから1年経過Q システム導入の上で一番困ったことは何か?A: 使いやすくしないと使われないので、管理者利用者両方の立場に立って利用することQ: 指標の公開範囲や公開先はどのように決定していますか?A: 社内において、指標の公開制限はしていない。ただし、実数値を出す際にはSQLを実行する必要があり、そのアクセスで制限はされているQ: 指標を共有することによるメリットはどんなものがありますか?A: 乱立しがちなモニタリングや報告数値において、共通認識を作ることができ数値のずれや定義の違いを大幅に減らせた。これにより認識齟齬をなくし、ビジョンである1秒で数値を確認することに大きく貢献している42#recruitdata
© Recruit Co., Ltd. All Rights Reserved想定Q & A2Q: 指標の更新頻度ってどれくらいですか?A: プロダクトの方針にもよるが、毎月大きく変わるような指標はそもそも入れない。そのため、あってもプロダクトの中で半期に数回程度Q: データの正確性や信頼性についてどのように保証していますか?A: 変更の際には論理定義、物理定義が変わること、正しいことをプロダクトの責任者に確認をし、変更時には広報を実施している。Q: 指標の可視化方法について、どのような工夫をしているか?A: 指標の可視化方法については今回触れていないが、ポータルで利用されている指標を利用することで、数値ずれを防いでいる。可視化についてはモニタリングのノウハウを集めた資料を共有するなどして無駄なものは作らないことを念頭に置いている43#recruitdata