Lookerの導入効果をレビューでご紹介(glassmonkey-BASE株式会社)

参考になった

レビュー投稿日の情報になります

BASE株式会社 / glassmonkey

チームリーダー / フロントエンドエンジニア / 従業員規模: 101名〜300名

最終更新日2024/06/20投稿日2023/11/10

利用プラン	ツールの利用規模	ツールの利用開始時期
非公開	101名〜300名	2021年12月

利用プラン	非公開
ツールの利用規模	101名〜300名
ツールの利用開始時期	2021年12月

導入の背景・解決したかった問題

導入背景

Redashを基盤として使っていたが、誰が管理していくのかが明確に決まっておらず、メンテナンスされていないクエリがあったり、インスタンスの負荷があったりしていた。
データ分析観点とは別で基盤リプレース企画の話が出ており、ショップをサポートするチームで実施したいことを担保できる仕組みに変更しようとしていた。

比較検討したサービス

Redash（継続利用）
Salesforce Marketing Cloud
Aimstar
b→dash
Tableau

選定理由

※全社的にLookerを導入するという決断は全社横断のデータプラットフォームチームが主導

Redash（継続利用するか）との比較

データ分析がSQLをかける人に限られてしまい、属人的になってしまっていた
当初の目的として、ショップをサポートするチームのやりたいことを実現できるのがLookerだった

導入時の苦労・悩み

苦労したこと
- データ分析にあたってエンジニアとエンジニアではない人で職能の垣根がないチームを理想として目指していた。一方で、Redashで作っていたデータ基盤のテーブル構造は実装を優先したものであり、分析観点では使いづらく、そのままLookerで実装するのは難しかった。そのため、SQLがかける方の視点では、Looker へ移行をするよりもSQLを書いた方が良いのではないか、という意見も存在していた
- データ基盤ではどういうデータ構造なら扱いやすいかを考え、ETLではなくELTにすることで分析しやすいようなデータ構造を1つ1つ作りアウトプットを共有しながら進めた
導入初期
- データ属人化への対応
  - Redash利用時の反省を活かし、管理者不在の状態をなくすために、組織ごとにデータの責任者をおいた。それぞれの責任者がデータマートを作り、自チームのデータの定義を決めて運用を始めた。
- Looker独自の用語のキャッチアップ
  - Looker単体の固有名詞も多かったため新しい用語のキャッチアップをした
- Lookerのベストプラクティスがあまりなかった
  - 他社の事例やどのようなExploreを作ると良いか、ファイル構造のベストプラクティスなどがあまりなく手探りで進めていた

導入に向けた社内への説明

上長・チームへの説明

上記に記載したどのような組織を作っていこうとしているか、また背景に記載してあるRedashが無法地帯になってしまっていることを伝えた

活用方法

よく使う機能

各チームによって見ている画面は異なるが、BASE BANKチームの場合は毎朝メインのKPIダッシュボードを使い、昨日の動きや事業KPIを確認している。それにより今の数値がビハインドしているかをみることができ、エンジニアでも事業数値としてどうかをみることができる。

Explore
- 恒久的なものはダッシュボードを使うが、単発的にグラフを作る、ビジュアライゼーションを作るというのをよくやるため。
通知機能
- 大きな変化があったときだけ、通知するということができるため重宝している。エンジニアとしては便利な機能であり、事前に閾値を決めたものだけの通知ではなく、グラフが大きく変動している場合（異常値がある場合など）に自動的に通知を飛ばすということができる。
派生テーブル機能
- Lookerの中にテーブル定義を準備せずとも、SQLで定義をすることで、Looker内にテーブルがあるかのように動かすことができ、分析しやすいようにデータを整形することができる。

ツールの良い点

日時をシームレスに切り替えられる
- 日毎にサービスのトラクションを取れる状態にしておくと、Looker上でSQLから指定をしなくても週・月単位の表示に切り替えることができる。SQLで表現しようとするとそれぞれのSQLを書かないといけないため、コスト削減につながっている。また、KPIとして手軽に参照しやすい点。
簡単にダッシュボードの作成ができる
- Explore機能だが、簡単に誰でも探索的にデータにアクセスすることができる。サービスやデータ構造を知らずとも、データに触れることができ、サービス理解や事業理解につながる。
エンジニアの工数削減と全員でデータに向き合う文化醸成
- エンジニアへのコードのレビューやダッシュボードの作成依頼が必要ではなく、エンジニアの工数削減になっている。また、今ではPMMがキャンペーン（施策）後にLookerでダッシュボードを作るのが当たり前になっているほど、データの当事者意識を作ることができ、エンジニアだけではなく全員でデータに向き合う文化を作ることができている。

ツールの課題点

ツールそのものへの気になる点はない。

プラクティスの共有
- 公式からのベストプラクティスの共有のアナウンスが欲しい。なかなか知見が世に出回らず、導入自体に苦労したため。Looker MeetupとSlack チャネルもあって動いているが、ナレッジの共有という観点だとまだまだ足りていないと感じている。

その他

BASEでは複数のサービスを展開していますが、まずはBASE BANKチームがファーストペンギンとしてデータの責任者を立て、データの定義を実施して運用し始めたことでうまくいったため、いきなり全社への導入をするのではなく、まずは一つのサービスから導入するなど、小さく初めていくことをおすすめします。また、Lookerの導入は単純にツールの導入にとどまらず、データを全員で扱えるようになったことにも繋がっており、文化醸成にも貢献しています。

ツールを検討されている方へ

他のどのBIツールを導入するにせよ、メンテナーは事業部を跨いだ横断チームだけではなく、データマートごと（事業部ごと）においておいた方が良いでしょう。事業部側から見たいタイミングでみることができること、また、全社横断チームに任せてしまうと、オーナーシップが薄れてしまいます。メンテナーに向いているのは、アナリストやSQL（分析クエリ）がある程度書ける人が良いと考えています。

まだまだLookerに関しての事例が足りないので、Looker コミュニティへの参加もお待ちしております！

https://looker-japan-user-group.connpass.com/

BASE株式会社 / glassmonkey

チームリーダー / フロントエンドエンジニア / 従業員規模: 101名〜300名

2020年5月に入社。現在は資金調達サービス「YELL BANK」のEPM（Engineering Program Manager）を担当。