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

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

Transcript

1. © Recruit Co., Ltd. All Rights Reserved
   プロダクト重要指標の管理・公開をシステムで
   実現した話
   1
   データ推進室 データテクノロジーユニット
   D3M部 SaaS D3Mグループ
   加藤　顕
   2023/03/27
   

   View Slide

2. © Recruit Co., Ltd. All Rights Reserved
   アジェンダ
   1. 自己紹介
   2. データポータルの紹介とその目的
   3. 運用の中で見えてきた課題
   4. 課題をシステムでどう乗り越えたか
   5. まとめ
   6. 最後に
   2
   

   View Slide

3. © Recruit Co., Ltd. All Rights Reserved
   Speaker
   3
   加藤　顕
   （カトウ　ケン)
   株式会社リクルート (2022/4新卒入社〜)
   ● SaaS D3MG/DSG/DEG グループ所属
   ● 『Air レジ』などのAirプロダクトのデータ周りを担当
   ● 趣味: 旅、ゴルフ、ゲーム
   #recruitdata
   

   View Slide

4. © Recruit Co., Ltd. All Rights Reserved
   SaaS D3Mグループのビジョン紹介
   SaaS D3Mグループのビジョンとは？
   4
   #recruitdata
   

   View Slide

5. © Recruit Co., Ltd. All Rights Reserved
   SaaS D3Mグループ ビジョン
   5
   プロダクトに関わる人が
   1秒で数値の確認、2分で原因の深堀り、30分で意思決定
   できる状態の実現
   事業の意思決定を正しく行うためのデータ品質に責任を持つ（データマネジメント/ガバナンス）
   データ環境の整備や教育によってデータ利用者が正しく分析を実行できる状態を実現する（セルフサービスBI）
   #recruitdata
   

   View Slide

6. © Recruit Co., Ltd. All Rights Reserved
   SaaS D3Mグループ ビジョン
   6
   プロダクトに関わる人が
   1秒で数値の確認、2分で原因の深堀り、30分で意思決定
   できる状態の実現
   事業の意思決定を正しく行うためのデータ品質に責任を持つ（データマネジメント/ガバナンス）
   データ環境の整備や教育によってデータ利用者が正しく分析を実行できる状態を実現する（セルフサービスBI）
   #recruitdata
   

   View Slide

7. © Recruit Co., Ltd. All Rights Reserved
   プロダクト重要指標の管理
   プロダクト重要指標の管理とは
   Airプロダクトでモニタリングしている重要指標の定義を把握し、
   プロダクトとして見るべき指標の論理定義及び物理定義（SQL）の正解を決め、一元管理すること
   最初は、各プロダクトの重要指標の管理をコンフルにより行っていましたが、
   - ページや定義が乱立してしまう
   - SQLの差分管理が困難である
   など、問題点がいくつかありました。
   そこで、新たにデータポータルというものを立ち上げ、コンフルから移行しました
   7
   

   View Slide

8. © Recruit Co., Ltd. All Rights Reserved
   データポータルとは
   8
   データマネジメント活動の一貫としてD3MGでは正しい数値を出すための土台を整備するために作成、運用
   しています
   #recruitdata
   

   View Slide

9. © Recruit Co., Ltd. All Rights Reserved
   データポータルの技術要素
   9
   データポータルでSphinxとGithub Pagesを使用しています
   - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ
   - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術
   #recruitdata
   GitHub Pages
   

   View Slide

10. © Recruit Co., Ltd. All Rights Reserved
    データポータルの技術要素
    10
    データポータルでSphinxとGithub Pagesを使用しています
    - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ
    - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術
    #recruitdata
    fig1. rstファイル
    fig2. 生成ページ
    

    View Slide

11. © Recruit Co., Ltd. All Rights Reserved
    データポータルの技術要素
    11
    データポータルでSphinxとGithub Pagesを使用しています
    - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ
    - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術
    #recruitdata
    GitHub Pages
    

    View Slide

12. © Recruit Co., Ltd. All Rights Reserved
    データポータルの技術要素
    12
    データポータルでSphinxとGithub Pagesを使用しています
    - Sphinxはドキュメント生成ツールでマークダウン形式からドキュメントを生成できるライブラリ
    - GitHub pagesはGitHub のリポジトリからファイル を取得し、ウェブサイトを公開できる技術
    #recruitdata
    GitHub Pages
    

    View Slide

13. © Recruit Co., Ltd. All Rights Reserved
    13
    運用開始!!
    #recruitdata
    

    View Slide

14. © Recruit Co., Ltd. All Rights Reserved
    運用中の声
    14
    これで解決だと思ってもなかなかうまく行きません
    #recruitdata
    レビュアーの手順が複雑で、特定の人
    ばっかりレビューしてる
    この注意書きいい感じに描きたいんだけ
    ど
    重要指標の定義が変わってるのにまだ
    反映されていない
    

    View Slide

15. © Recruit Co., Ltd. All Rights Reserved
    運用する中で見えてきた課題
    15
    データポータルを運用する中で大きく3つの課題が見えてきました
    1. 差分管理が難しい
    2. レビュアーの手間が大きく、複雑になっている
    3.利用者の目線がかけている
    順に見ていきます
    #recruitdata
    

    View Slide

16. © Recruit Co., Ltd. All Rights Reserved
    1. 差分管理が難しい
    Sphinxはビルドを行うため、多くのファイル(css, htmlファイルなど)が生成される
    16
    #recruitdata
    

    View Slide

17. © Recruit Co., Ltd. All Rights Reserved
    1. 差分管理が難しい
    それらの生成後のファイルをGithub上で管理することになり、
    実際の変更点は数カ所でも、レビュー時は多くのファイル差分を見る必要があったり
    17
    #recruitdata
    

    View Slide

18. © Recruit Co., Ltd. All Rights Reserved
    1. 差分管理が難しい
    複数ブランチで変更すると生成ファイルが全てコンフリクトしてしまうなどの問題が発生した
    18
    #recruitdata
    

    View Slide

19. © Recruit Co., Ltd. All Rights Reserved
    2. レビュアーの手間が大きく、複雑になっている
    19
    変更時は右図のようなフローで運用している
    本フローだけを見るとシンプルなように見えるが実は、
    変更時のフロー図
    #recruitdata
    

    View Slide

20. © Recruit Co., Ltd. All Rights Reserved
    2. レビュアーの手間が大きく、複雑になっている
    20
    変更時は右図のようなフローで運用している
    本フローだけを見るとシンプルなように見えるが実は、
    レビューのたびにレビュアーがブランチの切り替えやpull、ビルドなどを
    実行しなければならず手間が大きい
    結果、レビュアーの負担が大きく、定義の変更のハードルが
    高くなってしまっていた
    レビュアー側で Pull
    レビュアー側でビルド
    中身の確認
    ブランチ切り替え
    変更時のフロー図
    #recruitdata
    

    View Slide

21. © Recruit Co., Ltd. All Rights Reserved
    21
    3. 利用者目線の欠如
    データポータルを作成しても、使われていなければ意味がありません
    使われるためには、どのような使い方があるのかそのためにはどうするのが良いのかが、
    ポータルだけでは見えてきませんでした
    #recruitdata
    

    View Slide

22. © Recruit Co., Ltd. All Rights Reserved
    長期運用に不安
    3つの課題に直面
    1. 差分管理が難しい
    2. レビュアーの手間が大きく、複雑になっている
    3. 利用者目線の欠如
    課題を解決しなければ運用、更新が後回しとなり、情報が陳腐化し、重要指標の定義
    が無駄になる
    →システムで解決しよう
    22
    #recruitdata
    

    View Slide

23. © Recruit Co., Ltd. All Rights Reserved
    課題をシステムでどう乗り越えたか
    3つの対策を実施
    1. Github Actionsを利用し、ビルドをGithub上で実施
    2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入
    3. 利用ログの取得やインタビューの実施
    23
    #recruitdata
    

    View Slide

24. © Recruit Co., Ltd. All Rights Reserved
    1. Github Actionsを利用し、ビルドをGithub上で実施
    Github Actionsを利用し、SphinxのビルドをGithub上で実行するように
    生成前ファイルのみを管理することで、管理するファイルを大幅に削減、差分を最小限にした
    24
    #recruitdata
    

    View Slide

25. © Recruit Co., Ltd. All Rights Reserved
    2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入
    本番リポジトリとは別にPreviewリポジトリを用意
    その中で本番リポジトリのブランチごとにフォルダを管理
    CI/CDを導入し、テストやSlack連携などを実施した
    25
    Previewリポジトリ
    デプロイ時のSlack通知
    #recruitdata
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

33. © Recruit Co., Ltd. All Rights Reserved
    2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入
    33
    これに合わせて、フローも変更し、依頼者やレビュアーがの作業を減らした
    #recruitdata
    

    View Slide

34. © Recruit Co., Ltd. All Rights Reserved
    2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入
    34
    結果レビュアーの1PRに対するレビュー時間が
    10
    分以下
    30
    分
    #recruitdata
    

    View Slide

35. © Recruit Co., Ltd. All Rights Reserved
    3. 利用者のログの取得や声を聞く
    どれくらいの人に使われていて、何をみているのかがわからないためまずは、プロダクト環境に
    GA(Google Analytics)を埋め込みました
    35
    #recruitdata
    

    View Slide

36. © Recruit Co., Ltd. All Rights Reserved
    3. 利用者のログの取得や声を聞く
    これによりよく利用されているページを拡充したり、
    必要な機能を追加しました
    追加機能例)
    - copy機能などのプラグインの追加
    - SQLの中でよく利用するマートへのリンクを設置
    - tipsなど情報を付与する際の強弱をつける
    - …etc
    36
    tips機能
    コードのコピー機能
    #recruitdata
    

    View Slide

37. © Recruit Co., Ltd. All Rights Reserved
    データポータルの導入　+ システム対応の結果
    データポータルの導入とシステムによる対応の結果
    課題であった
    - ページ、定義の乱立
    - SQLの差分管理
    に加え、データポータル導入時の課題であった
    - 差分管理が難しい
    - ビュアーの手間が大きく、複雑になっている
    - 利用者目線の欠如
    を解決することができた
    37
    

    View Slide

38. © Recruit Co., Ltd. All Rights Reserved
    システム改修の結果
    課題に対してシステム改修を行い以下を実現
    1. Github Actionsを利用し、ビルドをGit上で実施
    →生成前ファイルのみを管理することができ、差分を最小限に
    2. 本番リポジトリとPreview用のリポジトリを作成し、CI/CDを導入
    →Preview環境を用意しレビューにかかる工数を削減
    3. Slack連携の利用やフローの見直し
    →初心者でも使いやすいシステムに
    38
    プロダクト重要指標の管理・公開をシステムで実現し、
    長期運用でも継続できる環境を用意
    →1秒で数値の確認ができる世界へ
    #recruitdata
    

    View Slide

39. © Recruit Co., Ltd. All Rights Reserved
    アナリティクスエンジニアの役割
    データポータルというプロダクト重要指標のシステム作成を通して実感したのは
    - データを取りまとめることだけでは継続的な価値を創出できない
    - 価値を持続可能なものにするためにはシステムを最大限活用する必要がある
    人が介在せずに価値を創出できるような仕組みを作ることが大事
    そのためにはエンジニアリングにもデータにも精通した人材が重要であり
    事業のデータ利活用を推進していく上でアナリティクスエンジニアが果たす役割は大きい
    39
    #recruitdata
    

    View Slide

40. © Recruit Co., Ltd. All Rights Reserved
    次のセッション
    40
    講演資料などのハッシュタグ
    #recruitdata
    イベント終了後にアンケートのご案内もあ
    りますので、是非ご回答をお願いします！
    #recruitdata
    40
    

    View Slide

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
    

    View Slide

42. © Recruit Co., Ltd. All Rights Reserved
    想定Q & A1
    Q: いつ頃から運用して、今どれくらい経過しているか？
    A: α,β版もあったが、GA版(公式版)としては運用し始めてから1年経過
    Q システム導入の上で一番困ったことは何か？
    A: 使いやすくしないと使われないので、管理者利用者両方の立場に立って利用すること
    Q: 指標の公開範囲や公開先はどのように決定していますか？
    A: 社内において、指標の公開制限はしていない。ただし、実数値を出す際にはSQLを実行する必要があり、そのアク
    セスで制限はされている
    Q: 指標を共有することによるメリットはどんなものがありますか？
    A: 乱立しがちなモニタリングや報告数値において、共通認識を作ることができ数値のずれや定義の違いを大幅に減
    らせた。これにより認識齟齬をなくし、ビジョンである1秒で数値を確認することに大きく貢献している
    42
    #recruitdata
    

    View Slide

43. © Recruit Co., Ltd. All Rights Reserved
    想定Q & A2
    Q: 指標の更新頻度ってどれくらいですか？
    A: プロダクトの方針にもよるが、毎月大きく変わるような指標はそもそも入れない。そのため、あってもプロダクト
    の中で半期に数回程度
    Q: データの正確性や信頼性についてどのように保証していますか？
    A: 変更の際には論理定義、物理定義が変わること、正しいことをプロダクトの責任者に確認をし、変更時には広報を
    実施している。
    Q: 指標の可視化方法について、どのような工夫をしているか？
    A: 指標の可視化方法については今回触れていないが、ポータルで利用されている指標を利用することで、数値ずれ
    を防いでいる。可視化についてはモニタリングのノウハウを集めた資料を共有するなどして無駄なものは作らないこ
    とを念頭に置いている
    43
    #recruitdata
    

    View Slide