こんにちは！株式会社Diverseで働いているsamukeiです。
昨日は @python_spameggs によるAWS System Manager セッションマネージャーを利用してEC2インスタンスにシェルアクセスする時に楽したい話でした。
AWSにシュッと入るTipsですね！便利！
明日は @shiranuik さんによる記事です！楽しみ！！！！
さて、9日目の記事として、Diverseで導入したLookerの話をします。
Lookerとは？
日本法人立ち上げが2018年9月と日本ではまだ馴染みが少ないかなというBIツールです。 1
後述しますが非常な強力なBIツールのため、海外のスタートアップでの利用が広がっているなど、日本でも認知され活用されていくと考えています。
Diverseの課題
いきなりですが、Diverseには数字分析・解析に関して以下のような課題があります。
- TreasureDataを利用しているが、分析しにくいテーブル構造
- 集計はスプレッドシート運用
- 分析基盤もベースはスプレッドシート運用
- Kibana/Redashも利用はあるが、一部プロダクトで頑張って用意して放置
- クエリを叩けるのがエンジニアだけで、エンジニアに毎回依頼が来る
- クエリを叩けるのがエンジニア以外いないので、KPIを追うための数値を用意するまでにリソースが必要
- クエリと叩く人が属人化するため、数値の根拠がその人に依存した数値となる
Lookerを知ったきっかけ
エンジニアを魅了する次世代 BI ツール『Looker』を Quipper が導入した理由（わけ）
プロダクトのリリース前から新ダッシュボード「Looker」の導入に踏み切ったわけ
この2つの記事を見てLookerの存在を知り、現状抱えている課題の一部でも解決ができるのでは！？
・・・と非常に興味がわいてデモの登録を行いました。
実際に触ってエンジニアとして感動したところ
実際に活用できるまでLookerの方からのトレーニングがあり、まだトレーニング期間中ですが感動する箇所が何箇所もあるので共有します。
LookML
Lookerの特徴といえる、SQLの抽象化のモデリングレイヤです。
モデル定義をyaml形式で記述できるため、エンジニアであれば抵抗感なく学習することができると思います。
LookMLという記法さえ学習していれば、どの値を利用してどういう数字を出すかがすぐわかるため、属人化を排除することが可能です。
LookMLの可読性の高さ
各columnを dimension として定義でき、ラベリングすることで利用者(Explore)にわかりやすいワードとして提供することができます。 また、 hidden 属性をつけることで利用者(Explore)に見えない項目として扱うことも可能です。
以下の例では、利用者(Explore)からは member_id ではなく、 メンバーID として表示されます
dimension: member_id {
label: "メンバーID"
hidden: yes // 利用者(Explore)はIDでフィルタしないから見せない
type: number
sql: ${TABLE}.member_id ;;
}
dimension で定義した値を変数のように measure で参照することができます
以下の例では、COUNT(DISTINCT member_id)と同等の定義となります。
measure: member_count {
label: "メンバー数"
type: count_distinct
sql: ${member_id} ;; // `${TABLE}.member_id`ではなく`${member_id}`なのが肝
}
LookMLの変更容易性の高さ
dimension で定義した値を変数のように利用できるということは、変更容易性にも繋がります。
例えば手数料を変更するなどの修正は以下の例のように非常に簡単に出来ます。
Appleの手数料は売上の30%での合計金額を出す
dimension: amount {
label: "金額(手数料抜き)"
type: number
// Appleの手数料は売上の30%
sql: ${TABLE}.amount * 0.7 ;;
}
measure: total_amount {
label: "合計金額(手数料抜き)"
type: sum
sql: ${amount} ;;
}
Appleの手数料は売上の35%での合計金額を出す
dimension: amount {
label: "金額(手数料抜き)"
type: number
// Appleの手数料は売上の35%に変わった
sql: ${TABLE}.amount * 0.65 ;; // ここの割合を変えるだけ！
}
measure: total_amount {
label: "合計金額(手数料抜き)"
type: sum
sql: ${amount} ;;
}
Gitでのバージョニング
LookMLのGitでのバージョニングが可能です。
Gitで管理できるということは、差分がわかりやすくどういう理由でどういった変更をしたかがすぐ追うことが出来ます。
また、Develop Modeでの変更はProduction Modeによる定義中の利用者への影響させない仕組みなど必要な機能は十分に備わっています。
Explore
BIツールとしての機能も十分に備わっています。UI上でポチポチするだけでグラフ表示が可能です。
Redashでは、クエリを作る、という点でエンジニア以外の職種が触れなかったのですが、Lookerは他の職種の人が"とっつきやすい"UIを提供しています。
しかも、Explore単体で探索した結果同士をマージ(副問い合わせの結果でJOINするようなイメージ)することができる強力な機能も持っています。
俺たちの戦いはこれからだ!
前述したとおり、まだまだトレーニング期間中なので、エンジニア陣 + プロダクトオーナー陣も学習途中です。
ですが、スプレットシートで頑張ってグラフを出すのではなく、出来るだけLookerで追える数字を出すような文化の定着を進めていこうと思いっています。
Lookerは強力なツールですが、スプレッドシートの優位性がある部分(スプレッドシートのほうが過去N年での比較などでは使いやすい)など、方針を決めつつツールに振り回されずに有効活用していきたいと思っています。