元調査会社のTableau芸人がLookerを使い始めて1ヶ月が経った所感ポエム
はじめに
Looker Advent Calendar 2019 14日目の記事です。
タイトル通りですが、Tableauをゴリゴリ無茶もしつつ使っていた自分が転職を機にLookerユーザーになったので、その過程で感じたことをまとめておくという趣向です。いつか振り返って赤面することになるはず。
自己紹介と略歴
- 1991年6月生まれ、好きなものは音楽と深夜ラジオと落語
- 2014年4月、新卒で調査会社に入社しその後データアナリストとして5年半勤務
- アドホックな調査もモニタリング基盤の構築もTableauを使い倒して対応してました
- Tableau Certified Associate保有
- 2019年11月、株式会社マネーフォワード入社、分析推進室に配属
- 入社と同時に出来た新設部署、インターン含め4人のチーム
- Looker導入直後(最初の顔合わせでLooker社員の方に
唆されてご依頼いただきこの記事を書くことに)
この記事の位置付け
- TableauからLookerユーザーになった時に感じたこと・困ったことをまとめます。
- 慣れもあるのでLookerで困ったことが多くなっていますが、決してネガキャンしたいわけではないです。
- どちらかというと開発サイドの所感です。
- 弊社では全社共通のデータ分析基盤を構築し、Lookerでダッシュボード化しています。
- アドホックな分析はまだあまり実績がないです。
- BIツールを導入したいけど迷ってる方の参考にもなれば嬉しいです。
- TableauもLookerも楽しいです。用途以上に思想が合う方を選ぶのが良いと思います。
一般的に言われる違い
- TableauはGUI,LookerはLookMLという独自言語によるCUI。
- ビジネスユーザーにも使いやすいTableauだが、使ったデータや集計の定義がばらけてしまうことも。
- CUIかつGitレポジトリと連携しているLookerは集計定義の一元管理がしやすい。
- Tableauはローカルにデータを保持、Lookerは都度データベースに接続する。
- Tableauはデスクトップアプリケーションでも開発できるが、Lookerはブラウザで操作・開発する。
まとめ
- 探索的な分析が多い場合、Tableauの方が気楽。
- モニタリング基盤の作成はLookerの方が安全。
- 集計定義が厳密で、かつ命名規則で端的にわかる。
- ただしLookMLを読める前提。読める人はよくわからないデータを集計して結論を出すことはしないような気もする。
- アドホックな分析をしたい時は以下の2点が検討ポイント。
- Lookerの方が集計定義が一元管理されている(はず)なのでミスリードは防ぎやすい
- GoogleSpreadSheetやExcel、.txtがインプットデータとなりうるのであれば、Tableauの方が楽
- 気軽さと安全性ってトレードオフですよね。
- Tableauで探索的な分析とかプロトタイピングして、Lookerでダッシュボード化できたら全能感溢れる。
Lookerを使い始めて思ったこと
LookMLは思いの外書きやすい(というかIDEが優秀でサジェストが捗る)
Looker概念の構造理解は難しい
- Project,Model,Explore,View,dimension,measure,Look,Tile…
- 包含関係のところもあれば、再帰性のある"定義する/される"関係だったりするので余計に難しい
ビジネスユーザーが同じ集計定義で分析できるのはやっぱり安心
- 切り口自体を変えつつも、指標の集計定義は開発者がハンドリングしている定義
- 命名規則とdescriptionを上手く使うことでスムーズに(ガイドラインも書きました)
と言いつつ、ビジネスユーザーがインプットデータ自体をいじるような使い方をしたい時もある
- ExcelやGoogleSpreadSheetで営業アプローチ状況を管理している場合とか
- 手元でサッとデータをいじってダッシュボード化するという使い方でTableauを導入したい気持ちになっている
SingleValue&Comparison大好き
- すっきりしてるし、イケててわかりやすい。
- 欲を言えばもう少し自由度が高いと嬉しい(フィルタで直近月しか表示していなくても前月比が出て欲しかったり)
Vizを作りながら集計して、示唆が得られそうな切り口を見つけたら深堀して、みたいなのはTableauの方が楽だった
- Tableauだとサイドバーで計算フィールドを作れば解決したものが、Lookerだと別タブでview定義に入ってdimension/measureを定義しないといけない
- Fixed関数で集計した結果をディメンションとして使う、とかいうちょっと無理した使い方ができない(ユーザーごとのPV数集計して、その分布を見るとか便利だった)
ダッシュボード上のフィルタがもう少し使いやすくなってほしい
- 場所が移動できないから動かすとどのLookに影響があるかわからない
- ラジオボタンやチェックボックス、スライダー、カレンダーとか制御の仕方も選べると嬉しい
テキストTileをもっと自由度高く扱えたら嬉しい
- Dashboardでしか表示しないものでHTML書くのは管理コスト含め結構大変。
- フォントサイズ、背景色、枠線くらいがいじれればなんとかなる。
Dashboardの"データをダウンロード"から直接クリップボードにデータを入れたい
やっぱりTableauよりは学習コストが高い
- 公式ドキュメントや、ググって出る記事がほとんど英語
- SQLの知識があると少し楽だが、LookML+SQLで開発すると保守コスト/後任育成コストがあがるので基本的にはLookMLで完結させたい気持ち
- Tableauにあるような本での学習はできない
- Gitの使い方にも慣れる必要アリ
ブラウザでしか開発/参照できないのは地味に辛いときも
- ネットワークがないと開発/参照できない
- Undo/Redoができない(特にダッシュボード作成時)
- 画面更新をしないと反映されないのに最初慣れなかった(Exploreの名前変えた時とか、複数タブで開発する時とか)
困った時にチャットサポートで対応してくれるの嬉しい&楽しい
- 実データを見ながら一緒に考えてくれる。
- 17時までなら日本語で対応してくれる。それ以降は英語で頑張る。結構察して言い換えてくれたりする。優しい。
- Tableau時代は参考書 or ググるとDevelopers.ioやエクスチュアさんのブログが出るので見てた記憶(本当に助かってました)
最後に
挙げたものの中にはきっともっと習熟すればできるようになることもあるんだろうなと思っています。
Lookerユーザーが周りにいないので、「それ最初困るよね〜こうやったら解決できるよ!」みたいなコミュニケーションができるお友達が欲しいです。サンタさんへのお願いです。
Author And Source
この問題について(元調査会社のTableau芸人がLookerを使い始めて1ヶ月が経った所感ポエム), 我々は、より多くの情報をここで見つけました https://qiita.com/esa/items/b4a415d922da114096dc著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .