※この記事はLooker Advent Calendar 2020の12/13の記事です。
はじめに
弊社もLookerの導入から1年が経ち、「そろそろ登壇でも…？」と機会をいただきましたので
12/7に開催されたYear End Looker Meetup 2020で登壇してきました。
発表の内容は資料を見てもらえればと思いますが、これをまとめるにあたって考えたことと、
発表して＆交流会に参加して思ったことを書いてみようと思います。
現状の振り返り
すっかり発表資料に入れ込み忘れていたのですが定量的な部分で言うと、
一年で約40のダッシュボードを作成し約150名のユーザーがそれを閲覧しています。
Slackのチャンネルにも配信しているので、可視化された数字は
もう少し多くのメンバーが見ている数字をLookerで管理・運用しているということになります。
1年間という時間で、かなり少数のメンバーで構築を進めてきたという意味では
なかなか良い状態までたどり着けているんじゃないかなと思っています。
Lookerをデータ基盤として捉え直す
今回のYear End Looker Meetup 2020では、登壇のテーマが「Looker運用の創意工夫」でした。
私は全社横断の分析組織に所属しており、
動きとしてはデータ整備人〜データアナリスト/BIエンジニアの領域を広く触っていることもあるため、
せっかくならLookerの位置づけを広く捉え直しつつこの1年間で試行錯誤してきたことをまとめてみようと思いました。
Lookerはデータガバナンスと集計定義のコード管理（Git管理）が強力なツールです。
データガバナンスと使いやすさを両輪で考えることは、もはやデータ基盤全体の構成を考えることと同義であり、Lookerの運用はBIツール運用として考えるよりデータ基盤の運用そのものと考えた方が整理しやすいと感じました。
広範囲におよぶ考慮すべき点を、以下に例を思いついた限り挙げてみます。
- 何を優先して可視化すべきかを判断するためのビジネスモデル理解
- どう集計結果を共有することが最も日々の意思決定につなげやすいか判断するための業務フロー理解
- 示唆を得るために必要十分で、かつ一人歩きしてもミスリードを引き起こさないデータ可視化
- 上記可視化を組み合わせ、さらに深い示唆を得るためのダッシュボード構築
- 上記可視化を動的に制御するためのフィルタ設計
- データ抽出とVisualization描画のリードタイム短縮に向けた取り組み
- Project/Model/Explore/Dashboard/Look/Folder × Userの権限という超多階層でのデータ閲覧権限管理（DWH側でも権限設定できることを考えたら選択肢は無限大）
- APIを活用したSlack等他ツールへの配信
- APIを活用したHubspot等他ツールからのデータ抽出
- 他部署含む複数名でサイロ化を起こさず集計定義を管理するためのルール
- 今後ユーザーを増やしていくためにわかりやすいフィールド命名規則
- 今後ユーザーを増やしていくためのわかりやすいメタデータ管理
アドベントカレンダーに間に合わせるために笑、限られた時間でざっと思いついただけでもこんなところでしょうか。
やったこととやらなかったこと（とできなかったこと）
そのため、「創意工夫」というテーマでお話しするとしてもまとまりがなくなりそうだと感じ、今回は
"創意工夫 to ビジネスユーザー/開発者 × やったこと/やらなかったこと/できなかったこと"
というフレームで整理してみました。
ガバナンスと使いやすさの両立を目指すにあたり敢えて使わないと決めた機能もあったため、
この整理は比較的理にかなっていたのかなと思っています。
いただけた反応
やったこととやらなかったことについての反応ももちろん嬉しかったのですが、
できなかったことに挙げた
- Exploreユーザーの育成ができなかった
- イケてるModel/Explore/View構成ができなかった
の二点も共感してもらえたようで、やはり皆様悩んでらっしゃるポイントなんだな〜と思いました。
相談会のような形で交流会でもこの点が話題に上ったのですが、各社試行錯誤はしつつもまだベストプラクティスという感触はなさそうな雰囲気でした。
一方で、微妙に相談内容と回答の噛み合わなさを感じた瞬間もあり、今振り返って考えると何がベストかはLooker管理組織の体制とミッションに依る部分が大きいからではないかなと思っています。
例えば我々の部署だとデータエンジニアがいるため、データレイクからデータマートへのETL部分はそれほど大きくボトルネックになっている感覚はありません。また、私のようなデータアナリストでもLookerのみでなくAirflowにコミットしているような体制になっているため、Lookerでデータマート管理を完結する必要がなく（むしろリスクだと捉え）定常的に利用するテーブルについてはデータマート側に吸収させています。
ただ、ここでデータエンジニアがおらずデータレイクから直接Lookerに繋ぎ込んで分析をしている組織だとデータマート機能がLookerの中にできることになり、"イケてるModel構成"の意味合いが全く変わってくるのではないでしょうか。
今後に向けて
登壇という良い機会をいただいたことで、原理的な部分と各社の個性に向いたベストプラクティスは切り分けて整理すべきという気づきがありました。この辺りはもうすこし思考を煮詰めて整理しなおしたいところ。
弊社でも可能な範囲で試行錯誤した結果を情報公開していければと思っておりますので、
是非皆様の試行錯誤が詰まったLookMLも見せていただけることを期待しております！
最後に
今回のユーザー会を取りまとめくださった @hase-ryo さん、本当にありがとうございました。
また、光栄にも弊社をData Evangelistとして選出いただいたLookerの皆様本当にありがとうございました。
引き続き、何卒よろしくお願いいたします。