2023年時点でLookerでやっていること、いないこと

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© Recruit Co., Ltd. All Rights Reserved 当時何を語っていたか & 今一度Lookerとはエンジニアの LOVE が詰まった BI、それが Looker 1. 外部の DWH・DB を使うことを前提にしている 2. LookML で全てを記述できる 3. BI ツールなのに GitHub 連携ができる 4. ほとんどの操作を API 経由で実行できる 5. 見られている・見られていない指標がすぐわかる 6. カスタマー LOVE の溢れるサポートがついてくる 9 引用) https://blog.studysapuri.jp/entry/2018/06/04/08000 0

Slide 10

Slide 10 text

© Recruit Co., Ltd. All Rights Reserved 今日の内容エンジニアの LOVE が詰まった BI、それが Looker 1. 外部の DWH・DB を使うことを前提にしている 2. LookML で全てを記述できる 3. BI ツールなのに GitHub 連携ができる 4. ほとんどの操作を API 経由で実行できる 5. 見られている・見られていない指標がすぐわかる 6. カスタマー LOVE の溢れるサポートがついてくる 10 振り返りテーマその他テーマ

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© Recruit Co., Ltd. All Rights Reserved 「LookML で全てを記述できる」の振り返り 2018 ● measure や dimension といった項目の定義まで LookML という YAML ベースの書式で記述することが可能 ○ SQLでのロジック ○ ラベル ○ PKといっためた情報 ○ 数値フォーマットなど ● 可読性や検索性が向上 14 2023 ● 定義をファイルに、かつ一ヶ所にそのファイルをまとめておいておけるだけで保守性が高い BI・アナリスト業務定義のキャッチアップや調査の際に一つずつダウンロードして、ファイルを開いて、コメントとロジックから定義を拾って...をやらないで良い。特に5年立って開発されたものが増え、新規メンバーも来て、という時に辛さが少ない。

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© Recruit Co., Ltd. All Rights Reserved 「LookML で全てを記述できる」の振り返り 2018 ● measure や dimension といった項目の定義まで LookML という YAML ベースの書式で記述することが可能 ○ SQLでのロジック ○ ラベル ○ PKといっためた情報 ○ 数値フォーマットなど ● 可読性や検索性が向上 16 2023 ● 定義をファイルに、かつ一ヶ所にそのファイルをまとめておいておけるだけで保守性が高い ● ファイルの分割や抽象化、テスト定義を一部実施中。(コードやデータの品質担保) AE テーマ増えすぎた成果物を管理できるようにしたり、時間が経ってレガシー化したものをリファクタリングする際に特に使うようになった。 BI・アナリストだとどうしても事業貢献に引っ張られ、負債を積み上げて苦しむところを、 AEポジションがやっていく。

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© Recruit Co., Ltd. All Rights Reserved 「BI ツールなのに GitHub 連携ができる」の振り返り 2018 ● Looker はモデルやビューの定義の変更を自動的に GitHub をはじめとした Git リポジトリに同期 ● 履歴を追って復元 ● ブランチでプルリクエストを送ってレビューを経てマージ 20 2023 ● (強制フローにしてあるので当たり前だが)みんなブランチを切って、プルリク出してをやっている BI・アナリスト業務「事業レポート_v1.0_3月最新版」とかに苦しめられないし、デグレしたり消してしまった時に、誰のローカルが一番stableだったけ、、、とかに苦しまないだけ、幸せと言ってももはやポカンとされる。

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© Recruit Co., Ltd. All Rights Reserved 「BI ツールなのに GitHub 連携ができる」の振り返り 2018 ● Looker はモデルやビューの定義の変更を自動的に GitHub をはじめとした Git リポジトリに同期 ● 履歴を追って復元 ● ブランチでプルリクエストを送ってレビューを経てマージ 22 2023 ● (強制フローにしてあるので当たり前だが)みんなブランチを切って、プルリク出してをやっている ● CI/CDでLinterなどを取り入れて、より開発体験やレビュー体験をよりよくできないか、などは検討中 AE テーマ積み重なった負債で苦しんだ経験から、作る時の負債を少しでも減らしたいが、それを人間がレビューで指摘する時の心理負荷を減少したいという動機がかなりある。これもまた、AEというポジションができたおかげで、検討する余裕ができた。何より、DevOpsなどの考えを取り入れようとする時に「なんで ?」と言われないだけで正直動きやすい。。。

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© Recruit Co., Ltd. All Rights Reserved 「ほとんどの操作を API 経由で実行できる」の振り返り 2018 ● ダッシュボードの更新、ユーザの管理に到るまでかなりのことが API を通して実行可能 26 2023 ● あまり使っていない ○ 業務量が少ないため、手動対応で一旦どうにかなっているため ○ APIを定期的にキックする仕組みや、その運用に習熟しているわけではないというものある BI・アナリスト業務

Slide 27

Slide 27 text

© Recruit Co., Ltd. All Rights Reserved 「ほとんどの操作を API 経由で実行できる」の振り返り 2018 ● ダッシュボードの更新、ユーザの管理に到るまでかなりのことが API を通して実行可能 27 2023 ● あまり使っていない ○ 業務量が少ないため、手動対応で一旦どうにかなっているため ○ APIを定期的にキックする仕組みや、その運用に習熟しているわけではないというものある BI・アナリスト業務アナリスト兼務のAdminが、APIを用いて、 GoogleSpreadsheetなどに出力したり、ユーザーの削除などを実施している。ただ、アナリストからは、「自分たちとは遠い業務」に感じがちで、こういう所から AEの分業化の必要性が高まってきていた。

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© Recruit Co., Ltd. All Rights Reserved 「ほとんどの操作を API 経由で実行できる」の振り返り 2018 ● ダッシュボードの更新、ユーザの管理に到るまでかなりのことが API を通して実行可能 29 2023 ● あまり使っていない ● 業務標準化のため、ユーザ管理/ パーミッション管理などを YAML+SDK+APIでできないか検討中 AE テーマ手動でアナリストが設定して、パーミッションが上手くいってない、などがあった。 BI・アナリスト側でここを綺麗にするのは難しいので、 AEポジションから、Terraformなどで、管理できないかなどを検討中

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© Recruit Co., Ltd. All Rights Reserved セマンティックレイヤー:まなびデータソリューション部だけでなく、事業全体の拡大に伴い、よりガバナンスが効いたデータ提供の必要性が高まる。データの利用者数の増加と、SSOTなどのガバナンスがトレードオフにならないように、セマンティックレイヤーはどうあるべきかを、検討中 31 データ定義 (Looker) Dashboard (Looker) slack Google Spreadshe et csv Looker? DBT? データ利用者 AE テーマ詳細な分析探索/モニタリングモニタリングポスト出力連携セマンティックレイヤーからの連携組織拡大に伴い、バックグラウンド（データへの慣れ、使うツール）や目的、分析対象の多様化が進む

Slide 32

Slide 32 text

© Recruit Co., Ltd. All Rights Reserved データ障害を未然に防ぐ取り組み:運用するデータ/ダッシュボードの増加に伴い、Looker前の Transformation部分での情報共有/品質担保/異常検知の仕組み化の必要性あり。データエンジニアと共同し、複数のツール+自前実装で対応中。 32 メタデータ基盤 (Google Data Plex) Dashboard 基盤(Looker) テスト/監視基盤 (DBT) 2021 実現 BigQuery Transformatio n基盤(Airflow) 2022 実現 Dashboard の観測基盤今後のAE テーマメタデータを DBTのテストに変換 schema定義のテスト内容のanomaly detection transform modeling visualization 定義情報の連携 observation

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© Recruit Co., Ltd. All Rights Reserved まとめ ①【Lookerの振り返り】アナリストとしてはもちろん、 AEっぽいことをやる場合でも、Lookerの機能は使えるので、5年経ってもまだまだ使い倒せそうという振り返り。 ➔ というか、5年たち、色々あったからこそ使い倒さないと辛いことがわかってきているのかも。(正直DBTとかが出てきてくれたから、比較して、ひとまずLookerのこの機能でまずやってみるか、みたいな進め方も多い) ②【AE業務】アナリストで辛かったことに他の人が将来苦しまないための打ち手を、AEとしてやっている感じ。 ➔ AEが必須の職能、とまではまだ言えないけれど、「AEがいる・認められている」組織は、これからくる辛さなどをどうにかしようと思ってくれているということだから、BI・アナリストにとっても良い組織になりそうだな、という所感。 34

Slide 35

Slide 35 text

© Recruit Co., Ltd. All Rights Reserved 最後に振り返ってみると、近年では、アナリストたちが草の根でやっていたことの重要度が認識され、AEという名前で呼ばれ始めてる。（弊社は必要性を認識し、ロールとして定義し、増やそうとしてます。） ● アナリスト->AE : なりやすそう ● SWE,SRE -> AE: これから増えそう ● AEスタート:そんなキャリアもありかも、、、え、もういます? 35 実は、あなたも既にAEかも?

Slide 36

Slide 36 text