Four KeysによるDataOps改善の第一歩

Slide 1

Slide 1 text

2023/10/06　石井正浩 Four KeysによるDataOps改善の第一歩 @marufeuille 【Timee × NewsPicks共同開催】【オンライン開催】 Four Keysで改善する開発生産性〜データ・モバイル・フロントエンド〜 - UB Tech Vol.12

Slide 2

Slide 2 text

DataOps改善の第一歩としての fourkeys導入から運用のお話

Slide 3

Slide 3 text

石井正浩 / @marufeuille 2022/8入社データ基盤の開発・運用やってます 2月に第2子生まれました 🎂 コーヒー☕とコーラ🍹が好きです

Slide 4

Slide 4 text

目次 ● タイミーのデータ基盤と現在の活用状況 ● タイミーの考えるDataOps ● fourkeys計測の実装例 ● 数ヶ月運用してみた考察と感想

Slide 5

Slide 5 text

1 タイミーのデータ基盤と現在の活用状況

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

現在のデータ基盤概要・・・収集活用営業施策 KPI 可視化 KPI 可視化 KPI 可視化マーケ施策 KPI 可視化レコメンデーション

Slide 9

Slide 9 text

利用状況参考数値 2022/8 … 社員数約350 2023/10/1 … 社員数約800 Looker上のダッシュボード数 BQ上のクエリの実行時間

Slide 10

Slide 10 text

2 タイミーの考えるDataOps

Slide 11

Slide 11 text

そもそもDataOpsとは？ https://www.gartner.com/en/information-technology/glossary/dataops

Slide 12

Slide 12 text

そもそもDataOpsとは？ https://www.gartner.com/en/information-technology/glossary/dataops 一気通貫でデータを使った施策を高速で回せることの追求 (と解釈)

Slide 13

Slide 13 text

タイミーのDataOps ・・・収集活用営業施策 KPI 可視化 KPI 可視化 KPI 可視化マーケ施策 KPI 可視化レコメンデーション究極的にはこの全体を DataOpsの生産性として捉えたい

Slide 14

Slide 14 text

例: 新しいデータを使って施策を回したい場合・・・収集活用営業施策 KPI 可視化 KPI 可視化 KPI 可視化マーケ施策 KPI 可視化レコメンデーション新しいデータ新しい施策

Slide 15

Slide 15 text

補足: データ基盤(ELT)の概念図データソース Extract Transform Load データの抽出データの取り込み変換処理 DataLake 生データ置き場 Staging 形式の統一や個人情報の処理等 DataWare House Dimensional Modeling後のデータ DataMart ※ Transform内の層の設計は弊社の場合です Lookerや各種ダッシュボード等それぞれに特化したデータ新しい施策

Slide 16

Slide 16 text

施策実行時のチームと守備範囲データソース Extract / Load DataLake Staging DataWareHouse DataMart DataEngineer (DRE) Analytics User ※ MLいれるとややこしくなりそうなので割愛します (実際に存在します) また、厳密ではないのでやることによって若干変わります各システム保持チーム Transform 新しい施策

Slide 17

Slide 17 text

Slide 18

Slide 18 text

3 fourkeys計測の実装例

Slide 19

Slide 19 text

データ基盤開発のプロセスイメージストーリーの作成外部依頼・ニーズリファインメント開発チームアサイン PR デプロイレビュー価値の創出開発が終わるまで繰り返す fourkeysのリードタイムの範囲チームのストーリーをこなすリードタイム

Slide 20

Slide 20 text

情報の出どころスループット安定性 pr, commitなどの履歴情報 pr, commitなどの履歴情報障害情報(ポストモーテム) スプリントのタスク、ストーリー

Slide 21

Slide 21 text

利用したベースの実装紹介 ※ 上記画像は以下より引用 https://github.com/dora-team/fourkeys 収集用のDeploy(GoogleCloud)や可視化の Dashboard(Grafana)が付属したパッケージ基本的にgithub eventをいい感じにしてくれるので、そこだけでも使う価値ある(無料だし) ベースとして、DORAチームの実装を利用しています

Slide 22

Slide 22 text

実際の構成 events_raw DORAの実装そのままポストモーテムプロダクトバックログスプリントバックログ加工

Slide 23

Slide 23 text

ダッシュボードまずはDORA相当となるように実装

Slide 24

Slide 24 text

4 数ヶ月運用してみた考察と感想

Slide 25

Slide 25 text

可視化してみたけれど...

Slide 26

Slide 26 text

可視化してみたけれど... ふーん？って感じしませんか？

Slide 27

Slide 27 text

可視化してみたけれど... https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance より引用デプロイ頻度は1日2回以上だからまあいいかなリードタイム2.47日だと悪いから改善しないとなぁ・・・とかいってもしゃーない感

Slide 28

Slide 28 text

個別に問題を追い込む必要がある https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance より引用 ① あるリポジトリだけリードタイムが異様に遅い (5,6日)から改善しないと！確認すると、兼任者のみで構成されたチームが主に作業していたリポジトリであり、ヒアリングの結果、他の業務の手が空いたときのみの対応になっていることがわかった → 組織としての問題は把握できたが、即効性のある対応は難しそう ② そもそもどうやればリードタイム短くできるんだっけ？変更行数が短くても必ずすぐにマージされるとは限らないが、長くて早くマージされるものはなかった → 基本的に抑える形で PR作っていこうという　コンセンサスを得られた一定以上行数が多くてリードタイム 1日以内は存在していなかった※

Slide 29

Slide 29 text

ダッシュボードの改善ある程度の期間眺めていると見方が少しわかってくる弊チームの場合 - リポジトリをまたいだ活動が多いので、デプロイ頻度は全体で見たほうが良さそう - リードタイムは個別

Slide 30

Slide 30 text

一歩進めた可視化ストーリーレベルのリードタイム究極系に近づけるべく、まずはチームのストーリーレベルのリードタイムの可視化を開始

Slide 31

Slide 31 text

fourkeysを利用した施策 https://tech.timee.co.jp/entry/2023/09/07/202714

Slide 32

Slide 32 text

データ基盤における安定性のいま当初想定 - 障害情報と紐づけて、問題の起こしたデプロイを特定し数値化すればなにか見えるはず結果 - うまく紐づくようなものがほぼなかった

Slide 33

Slide 33 text

データ基盤における安定性の今後データソース Extract Trans form Load ここまでが正しいことを前提条件として結果テーブル最終的なデータ品質が悪化しないことを担保このあたりの変更によって

Slide 34

Slide 34 text

最後に導入してみたまとめ ① fourkeys導入だけしてもそんなに意味はなさそう ② 必要な情報は得られつつあるので今後もやっていく ③ 生産性を向上させるための議論が深まるようになった

Slide 35

Slide 35 text

まだまだ道半ばなのでお力を貸してください！！！ https://hrmos.co/pages/timee/jobs/1682251404118319115 積極的に採用中です!!!