![[レポート] BIツールカジュアル座談会 ~Lookerの集い~ #bilabo](https://devio2023-media.developers.io/wp-content/uploads/2023/06/looker-in-google_1200x630.png)
[レポート] BIツールカジュアル座談会 ~Lookerの集い~ #bilabo
2020年12月10日、「BIツール研究所」という"すべてのBIツールを扱うユーザーが交流・情報交換をするためのコミュニティ"によるイベント「BIツールカジュアル座談会 ~Lookerの集い~」が開催されていました。Lookerを扱っている弊社としては興味深いテーマのイベントでしたので参加(聴講)してきました。
当エントリではその内容についてイベントレポートの形でお届けします。
目次
登壇者
この日イベントに登壇されたユーザーの皆様の情報は以下の通りです。
- 司会：前側 将氏(@willanalysts、オープンエイト)
- 登壇者
- 佐々木 江亜氏(@0610Esa、マネーフォワード 分析推進室)
- 古賀 元樹氏(@KogyFine、タイミー 経営戦略本部 BIユニット)
- 土川 稔生氏(@tvtg_24、タイミー プロダクト本部 DREチーム)
- 香村 貴之氏(@k_data_analyst、株式会社エイチームブライズ)
- 他、匿名ユーザー氏1名
イベント関連リソース
イベント当日の録画内容はこちらです。
Lookerの集いのアーカイブです。
当面の間公開しておりますので、BGMとしてお聞きください❗️
質問やイベントテーマのご要望などもお待ちしてますー！#bilabohttps://t.co/YQViozOpPP
— BIツール研究所 (@bitoollabo) December 10, 2020
また、イベント関連ツイートに関してもTogetterでまとめました。宜しければご参照ください。
イベントレポート
ここからイベントレポートをセッション毎に紹介します。登壇者は複数名居ますが、発言に関しては(発言毎の)登壇者の情報は付与していません。ご了承ください。
1.製品の特徴を客観的に整理
まず最初のパートはLookerに関するざっくり概要説明。司会の前側氏によるポイント解説が行われました。
- 一般的なBIとしての特徴
- グラフの作成/管理/ダッシュボード化/配信
- データの集計をGUIで行える
- コーディックなBIとしての特徴
- SQLの拡張言語(LookML)のコンパイラ
- 上記の実装環境としてのIDE
- 上記管理をGitで対応/テスト環境
- ダッシュボードのコード化
- データ活用管理環境としての特徴
- 拡張言語ファイルをパースしてのメタデータ管理
- Admin GUIで実行/管理可能
- APIで操作可能
- スケジューラと依存関係の記述が可能
- データ出力環境として
- 外部API/ストレージへの出力機能
- 上記の拡張/及びGUIからの実行
- デフォルトアダプターが多彩
上記内容を踏まえ、前側氏は「Lookerはエンジニアの方が使うBIとしては非常に優れている」と総括。また、Lookerの概要をよりわかりやすく把握するための資料として、先日の弊社イベント「Developers.IO Showcase」でさがらが発表した「Looker歴2か月、元Tableau運用者がそれぞれの良さを語ります」#devio_showcase」の資料を参考情報として挙げて頂きました。(ありがとうございます！)
2.環境要因に対するメリット・デメリットの紹介
次のパートはLookerの環境要因におけるメリット・デメリットの紹介。ここも要点部分に関しては前側氏が解説を行いました。
- Lookerを使うにあたって意識しておくべき「前提」
- DWHが綺麗であること
- データエンジニアがいる
- 誰でも触れるツールではない
- メタデータを管理する気概があるか
- ビジュアライゼーションの表現幅
- メリット
- メタデータやSQLのロジックを一元管理出来る＝"定義がブレない"
- バージョン管理が出来る(gitを活用)
- API連携
- 拡張分析
- デメリット
- 丁寧な管理運用が必要
「LookerがFitする組織とはどういうものなのか」というトピックでは、前側氏が登壇者各位に会話を振る形で以下のような意見が出てきていました。
- データガナバンスがとても優れている。色々な層のユーザーが数字を見る際に、その数字の基準がブレていないというのはとても重要だと思う
- LookMLもそんなに難しいものではない。SQLよりは簡単だし、自然言語に近いので、ゴリゴリのエンジニアが居ない組織でも十分扱えるものだと思う
- Lookerのチャットサポートがとても充実しているのでそれを使っている。日本の営業時間内であれば日本語でも対応している。
- Single Source of Truthを実現するために、Lookerのデータガバナンスはとてもフィットしている。
- 誰がどういう数字を参照しても同じ数字に到達する、というのが実現させやすい
- ある程度データの民主化が進んでいて"爆発期"を迎え、それを収束させたい課題がある場合に便利。
- データマートを構築する際、派生テーブルを活用することでLooker上でその内容のレビューが出来るので、コードの品質と活用のスピード感の双方が保てている。
- Lookerの費用感：データの出し入れやメンテナンスを行うコストを考えると、全然コスト感としては見合っていると感じる。コスパは良い。
3.専門家が熱く推すポイントの紹介
このトピックでは、「Lookerの好きなところはどういうものがある？」という切り口で、登壇者の皆さんがそれぞれ思うところを語り合う形となりました。
- 何でもLooker上で完結出来る点。ローカル環境上でデスクトップツールを用いた場合、ツール間のバージョン違いなどで問題が発生する事が多く、この部分が無くなることで問い合わせ自体も減っているのは助かっている。
- 1にも2にもガバナンス。コードがgit管理出来ているというのは本当大きい。ここは他のBIには無いところ。
- Blocksが便利。用途に応じた部品を活用することでやりたいことがすぐ実現出来るし、重宝している。
- アップデートが頻繁に行われている。自分が欲しいなと思った機能がスピード感を以て実現されているのは嬉しい。
- コンテンツの埋め込みが柔軟に出来るのは便利。
- Lookerの場合「Customer Support」では無く「Customer Love」としているのはLookerの特色を示していて良いなと思った。皆さんエンジニアリングに関する部分の話が詳しくとても話がし易かった。
- 考え方が「併走」では無く「伴走」の思想を持っているところに好感が持てた。"次は自分たちでやれる"ようにサポートしてくれるのは良い。
4.それLookerでできます！
最後のパートは、当日の参加者からの質問も拾いつつのざっくばらんなトークが展開されました。主なディスカッション内容は以下の通り。
- Tableauを可視化面、Lookerをデータ基盤として捉える面はあるよね、という話が出た
- 元々Tableauだったものがどういう感じでLooker利用の形に変わっていったのか？(TableauとLookerを利用しているのは今回登壇社ではマネーフォワードが該当)
- 前職でTableauを触ってて現職でLookerを触った
- Lookerは単なるBIでは無いな、という印象。集計定義を一元管理出来るし、データ基盤としての側面が強い。様々な人が見ることになる色々なダッシュボードを展開する部分ではLookerを使い、アドホックで分析したり、少数人数内で触るようなケースではTableauを使う、という風に用途に応じて使い分けている。
- Tableauは何でも出来ちゃえるんだけど、何でも出来ちゃうばっかりに、管理が及ばない範囲で自由に作られちゃう(独自に計算式を作られるとか)と混乱を招くことがあるのでそれは困る。
- ガナバンスを効かせたい範囲の部分はLookerでやるようにしている。そこから外れる部分はどうぞご自由に、でも面倒は見切れませんよ、という感じ
- re:dashやmetabaseといったOSSプロダクトからLookerに移行する、となった場合のポイントとか
- 権限周りはre:dashは弱い。データソースに対して見れる・見れない、ダッシュボードを作れる・作れない、くらい。その点Lookerは細かく制御が出来るので強み。
- お客さん向けにLookerを使うケース
- クリエイター向けにLookerを開放している、というのは聞いたことがある
- データソースが固まっていれば割とライトに使えると思う
- LookerはDBコネクションを複数作れる＆繋げることは出来る(制限はあるけど)のでその辺上手く活用することも出来る
- 全てWeb上で作業が完結出来る、というのは新鮮だった(Tableauユーザーとしてのコメント)
- 操作すると常にクエリが飛ぶ
- 常に最新の情報にアクセス出来る／投げ方ミスるとデータソースに多大な負荷が掛かる場合がある
- Googleの傘下に入ったことで変わったことはあるか？
- アイコンとデザインがすごいGoogleっぽくなったw
- LookerにETL的な機能を寄せることがある。Lookerがコケると上流から下流まで全部死ぬ的なことがあるかなとも思ったけど、Googleの傘下に入ったことでその辺は大丈夫かな？
- Google傘下に入ったことで「Google関連のデータソースが使えなくなる？」みたいな不安→そういうことは無い
- BigQueryに対する派生テーブル作成時に(命名ルールなどが)制限厳しい感じだったので、その辺が緩和されてくれると嬉しい
- Lookerの勉強はどういう風にすれば良い？
- テーブルの構成図は改めて洗い出し作業を行いました(LookMLの定義を誤ると全体に影響が及ぼされるので、仕様を再確認するために)
- LookMLを書くために、テーブルのER図を再確認した。ドメイン知識が重要
- LookML自体はとても分かりやすい言語。「勉強しないと分からない」というものでは無いと思う
- Blocksを見ることで学べることも多い。
- 分からないことがあったらサポートチャットに聞くようにしている
- LookMLは書いていけば行くほど馴染む気がする。Looker = SQL生成ツールみたいなイメージが有り、LookMLをこう書けばこういうSQLが生成される...という感じでイメージが出来るようになる
- Lookerの開発ロードマップってある？
- 今後Looker周りで挑戦したいこととか今後の展望とか
- Lookerを使うユーザーが増えてきており、新たな発見・展開が期待出来るので、Lookerユーザーが出来ることも増えてくると思う。その辺が楽しみ。
- Lookerを入れて何が出来るか、という部分が大事。裏側・体制の構築はこれまで通り進めていく一方で、メンバーに対して「こういう事ができる」という啓蒙や、お悩み相談・サポート的な部分を対応してPDCAサイクルを回すところ、Lookerを自然と浸透させていくところに注力していきたいと思う。
- 今回のイベントをきっかけに、Lookerでモデル構築をどのように進めていくのか、とか知見的なものをもっと共有していければと思う。
- 「どうやったらLookerをもっと使ってもらえるようになるか」という部分にチャレンジしていきたいと思う。また「いかに自分たちが楽出来るか」というのがモチベーションでもあるので、その辺にもチャレンジしていきたい。
- 社内においては「ガバナンスと民主化の両立」は引き続き頑張っていきたい。社外的には、そういった部分を実現するためのノウハウ的なもの、ベストプラクティス的なものがまだまだ確立されていないのでは？という風にも思っているので、情報交換しながら一緒に考えていきたい。
まとめ
という訳で、コミュニティ「BIツール研究所」主催のイベント「BIツールカジュアル座談会 ~Lookerの集い~」の参加レポートの紹介でした。
Lookerの強みは、何と言っても「ガバナンス」におけるの対応部分が強力であるという点に尽きるのでは、と思っています。この点は他のBIツールやサービスには無い部分なのかなという気がしているので、この部分を最大限導入プロジェクトに適用させつつ、プロジェクトをドライブさせていける進め方や提案を弊社としても情報発信して行ければ...と思いました。
一方で、Lookerではカバーしきれない部分もあるかとは思いますので、その部分については他のBIツールやサービスを併用していく形も合わせて提案していければと思っています。弊社としては過去Lookerに関する発表を何度か行っています(冒頭で言及した相樂のものと合わせてたまちゃん＆私のヤツがあります)が、スタンスとしては「用途に応じてツールを使い分けていこう」という形で共通しています。それぞれの良さを見極めて活用していきたいところですね。
