データ民主化を進めてデータを資産に、Unipos社がLookerを導入した経緯
この記事はUnipos advent calendar 19日目の記事です。
この記事では、僕が所属するプロダクト戦略室で3Qに取り組んでいたLookerの導入の経緯と、Lookerに対して感じたことを書いていきたいと思います。
データ基盤、分析、SQL、という言葉にピンとくる人に興味を持っていただける記事になっています。
この記事で言いたいこと
- Unipos社ではLookerを導入しました
- LookerはノーコードBIツールではない
- Lookerはアナリストを正しい方向に頑張らせてくれる
- 本番はこれからだ
Unipos社ではLookerを導入しました
Lookerとは
ものすごく雑に言うとBIツールです(後ほど単なるBIツールではないと言うのですが)。
Lookerを初めて聞いたよという方は、BQなどのデータベースにあるデータを可視化したりできるものなんだな、という理解で次に進んでもらえればと思います。
Unipos社で直面していた問題
- データマートをBQに作ってもSQLの習熟度によっては欲しいデータの取得に時間がかかっていた
- 分析依頼が分析チームに集中するとここがボトルネックになってしまうことがあった
- 言葉の定義と数式がチームによって違うことがあった
- 「投稿率」の式が(投稿をした人)/(有効メンバー)の場合と、(投稿をした人) / (有効メンバー + 招待メンバー) の場合など
- 分析用のクエリを一応ドキュメントとして残していたが、残すかどうかは個人の主観によっていたし、メンテナンスもされていなかった
- データガバナンスが整っていなかった
- この人はこのカラムを見ていい、見てはいけないってのが仕組みとして整備しきれていなかった(後回しにされがちだった)
Lookerでは上記の問題達がズバッと解決できそうだ！と感じて導入するに至りました。
その中でも特に感動したことをピックアップして書いていきます。
LookerはノーコードBIツールではない
BIツールというとTableauが想起されると思うのですが、Tableauとはターゲットが違うなと思っています。
実はUnipos社でもTableauは導入されているのですが、あまり上手く活用しきれていないというのが正直な感想です...
僕が思うTableauと(ついでにPythonを使った分析も併せて)の比較表は下記の通りです。
Unipos社では、Tableauがピッタリ当てはまるユーザーがいないので、あまり上手に活用できていなと感じています。
今のUnipos社にとってはLookerがすごくピッタリハマるなというのを感じています。
いろんな人が気軽にデータにアクセスできて定義のブレがなくなる
- Lookerでは分析に使う指標をあらかじめLookMLという形式で定義する必要があります
- このLookMLでは「投稿率をどう定義するか」、「利用率をどう定義するか」などを予め定義します
- 上の比較表でLookerを使う人の分析リテラシーは高くないことを想定していると書きましたが、LookMLを構築する人は分析リテラシーと、SQLの知識を必要とします
- こうして定義された指標を使ってもらうことで、チーム間での定義のブレをなくすことができます
- ただし逆に、定義されていない指標は使うことができないので、その点は注意が必要です
アナリストとLookMLと使う人の関係
Lookerはデータ基盤である
Lookerはデータベースのデータを簡単に引っ張ってきて、簡単に可視化できるようにするツールではありません。むしろデータベースに接続した後にLookMLの整備を行わなきゃいけないという点では、煩わしさを感じる方もいるかもしれません。
しかしLookerはデータリテラシーがそれほど高くない人が何気なく使っても、定義がしっかり揃うという強みがあります。ここを意識してLookMLを整備していくのがたまらなく楽しくなってきます。
そういう意味で、BIツールというよりも基盤という捉え方の方が個人的にしっくりきています。
Lookerはアナリストを正しい方向に頑張らせてくれる
LookMLを作る時は実際に使う人の声が宝になる
データ基盤として、ものすごく使いやすいと思えるデータベースを作ったけれど、結局その使いやすさを享受しているのはアナリストだけだったという経験がありませんか？僕にはあります。
これはアナリストは、ビジネスロジックが噛ませてあるデータよりも、最小の構成要素から分析する方がいろんな用途に使えるからです。
余計な処理はしないでもらったほうが使いやすく感じるアナリスト
一方、データリテラシーがそれほど高くない人や、分析に多くの時間を使って入られない人たちは、ある程度ビジネスロジックが噛ませてあるデータや、理解しやすい粒度になっているデータをもとに自分の仕事を遂行していく方が使いやすいと感じてくれます。
そのような方のために、最小の構成要素を渡しても歯痒く感じられてしまうはずです。
Lookerでは予め、どのような指標を可視化できるようにするかLookMLで定義する必要があります。 これはアナリストの頭の中で完結することではなく、使ってくれるユーザーが普段どのような指標を見ているかをヒアリングして、実装していく必要があります。
Lookerはアナリストが、使う人と向き合うことを強いてくるのです。
分析のためのSQLを資産にしていく
僕がLookerを使っていて一番感動しているところです!!!
分析のクエリって、分析後どのように管理していますか？
Unipos社では「これは他の人も使うかも」という個人の裁量でNotionに保存しているのですが、フローとして整っているわけではないし、メンテも特段されていません。
クエリを使い捨てることも少なくないというのが正直なところです。
Lookerを使うとLookMLによって、見たい指標のためのクエリ(のようなもの)が積み上がっていきます。僕はこれを 「クエリが資産化されていく」 と表現しています。
資産化されていると感じるし、LookMLは個人ごとに管理されているわけではないので共通化されています。
またLookMLの編集はGitHubで管理されているのでプルリクエストベースで管理することができます。
Lookerはアナリストに、クエリの管理を強いてくるのです。
この他にも
- データガバナンスが強力
- slackへのポストがすごく簡単
- ダッシュボード同士のリンクを作ることが簡単
- Gitベースで開発できる
- などなど...
アナリストが欲しいと思うところをピンポイントでついてくれて、アナリストを適切な方向に勝手に頑張らせてくれます。
(もっともっと書きたいことがたくさん！)
本番はこれからだ
まだまだUnipos社はLookerの導入を決めたばかりです。
POC期間を通じて、すでに各セクションで使い始められてはいるものの、LookMLの整備が追いついていないところは多いし、LookMLの設計も至らないところがあります。
何より、Lookerを真の意味で使いこなすとは 組織をデータドリブンな組織に持っていくこと にあると思います。
色んな人がデータにアクセスできて、知りたいことを適切に判断するために適切に加工でき、データを正しく理解出来るようにし、アクションにつながっている。そんな組織を作ることがLookerを使う意味なんだと思っています。
テンションと勢いで書いた記事ですが、Lookerの導入を考えている企業の一助になれれば幸いです。
LookerのPOC期間中にテンションを上げてくれた記事達
Discussion