Looker ノススメ

やんごとなき事情で↓に引っ越しました :bow:
https://fisherman.hatenablog.com/entry/2019/12/05/232922
（内容は特に変わっていません）

---
# はじめに

[Looker Advent Calendar 2019](https://qiita.com/advent-calendar/2019/looker) 1日目の記事です。

こんばんは、[🔺YAMAP](https://yamap.com/) 分析チームの松本あおいです。好きな山は赤岳（八ヶ岳）です。
YAMAP は 2019-11 から、次世代 BI ツール [Looker](https://ja.looker.com/) を導入しました。

この記事では、YAMAP で導入前に感じていた課題とその解決方法を中心に、Looker の素晴らしさを紹介したいと思います。

## 参考までに、YAMAP の概況

Looker をはじめ、 BI ツール導入を検討している方の参考になればと思い、会社の規模などを共有してみます。

- 社員数: 50 くらい（開発メンバーは半分くらい）
- 分析チーム: 2019-01 に発足、現在 2 人
- 主な事業: 有料会員 , [登山保険](https://yamap.com/insurance) , [EC](https://store.yamap.com/) , 観光・アウトドア周辺の営業

# Looker 導入前の課題と、どう解決するか

私達は、おおよそ以下のような課題を感じていました。

![looker_issue_01.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76918/ff39fd53-ac9e-1266-7fa7-03716108a78e.jpeg)

それがこうなります、Looker 凄い :tada: 

![looker_issue_02.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/76918/00d07d50-73c1-c7f7-ef2c-55065834fb40.jpeg)

以下でそれぞれ説明したいと思います。
なお [LookML については、分かりやすくまとめて頂いている記事](https://qiita.com/SAMUKEI/items/4de3ffbf952dcba453ad#lookml) があるので、そちらをご参照下さい :bow: 

## a. データ基盤をみんなに使ってもらうには敷居が高い

私達は BigQuery にデータ基盤を構築し、2019-06 から運用を始めました。
（構築に当たっては [私の考えた最強のログ＆モニタリング設計 - 下町柚子黄昏記 by @yuzutas0 ](http://yuzutas0.hatenablog.com/entry/2018/12/08/235900) がとても参考になりました。この場を借りてお礼を :pray: ）

ですがデータが1箇所に集まったのは良いものの、

- 何がどこにあるのか難易度が高く、分析者以外が使うのに敷居が高い

という課題がありました。

### どう解決するか？

これは **「分析者が LookML を定義すれば、それを元に Looker が UI が提供してくれるので、利用者はポチポチでグラフが作れる」** という特徴により、解決できます。

## b. Redash でクエリが乱立、メンテが大変

私達はもともと Redash を使っていました。
Redash は無料ですし、とても素晴らしかったのですが、運用を重ねるにつれ、

- 似たようなクエリが増殖
- どれが使われているのか分からない
- スキーマに変更があった際、参照しているクエリを修正して回るのが辛い

という課題が出てきました。

### どう解決するか？

これも **LookML が分析用 Object-relational mapping の如く、グラフとテーブルの間に入ってくれるので、テーブルに変更があったときは LookML を修正すれば、それを利用しているグラフを一括修正できる** ということで解決できます。

また Looker には Look（グラフ） ごとのアクセス数を可視化する機能が備わっており、使われていない Look を整理するのにとても便利そうでした。

## c. 人によってクエリの書き方が異なり、信頼性を担保しにくい

YAMAP では実際

- SQL を書く人の技量により、間違った集計を行ってしまう
- 技量が高くても分析対象のテーブルの細かい仕様までは把握しきれておらず、間違った集計を行ってしまう

といったケースが有りました。
（例えば、論理削除フラグや、契約履歴テーブルに "契約解除" でもレコードが挿入されるなどの仕様の把握漏れで、集計が水増しされてしまう. etc.）

こういう事が重なると、誰かがグラフを書いた時に「そもそも集計合ってるんだっけ？」といった確認作業が大変になるのも残念です。

### どう解決するか？

これまた **テーブル定義に精通した分析者が LookML を定義し、利用者はそれを使ってグラフを書く** といった明確な分担ができることで、集計の信頼性が格段に担保しやすくなります。

## d. 細かい集計依頼が多く、骨太な分析に時間を使えない

先に紹介したように、YAMAP は有料会員、登山保険、EC、営業と事業が多く、各チームから分析チームへ細かい集計依頼もコンスタントに来ています。

そして、YAMAP 分析チームは↓2つのミッションを掲げています。

1. データ分析で事業の意思決定にコミットする
2. ユーザーが投稿するデータを価値に変え、ユーザーに還元する

しかし先述したように現状分析チームは2人だけなので、各チームからの集計依頼が多くなると、2 に時間を使えなくなるという危機意識がありました。
（僕たちは 2 を "骨太な分析" と呼んでいます :smile: ）

### どう解決するか？

今まで書いたことでお分かり頂けると思うのですが、Looker は **データの民主化** という視点で、とても強力です。
**"LookML の定義に分析者が責任を持ち、利用者はそれを使ってグラフを書く" という切り分けができることで、データガバナンスとデータ民主化を両立できる** 訳です。
今まで Looker を使ってみて、このバランス感は本当に素晴らしいと感じます :heart: 

ということで、Looker を各チームに浸透させ、簡単な集計や分析はチーム内で完結できるように持っていくことで、"骨太な分析" の時間も確保していく方針です。

加えて LookML はとても優秀で、クエリをかなり動的に生成してくれます。
故にお決まりの集計やデータ抽出業務は、グラフ（Look）の FILTERS パラメータを良い感じに用意してあげると、仕組み化しやすいです。
（Redash にもパラメータ機能はありますが、Looker はパラメータの選択状況に応じて JOIN 文レベルで切り替わってくれるので、柔軟に仕組み化できます）

# まとめ

YAMAP での BI の課題と、それをどう解決できるのかを中心に、Looker をご紹介しました。

使えば使うほどに素晴らしいツールだと驚くのですが、特に

- **"LookML の定義に分析者が責任を持ち、利用者はそれを使ってグラフを書く" という切り分けができることで、データガバナンスとデータ民主化を両立できる**

点がミソなのかなと感じています。

しっかり使いこなして、みんなの登山をより安全にしていきたいと思います。 :mountain_snow: 
明日の [Looker Advent Calendar 2019](https://qiita.com/advent-calendar/2019/looker) もお楽しみに！