この記事のポイント
- Looker User Meetup Part 4に登壇
- 運用分析という観点からLookerの良さを発信
- セマンティックレイヤーによって組織のデータをわかりやすくした
- Looker 会話分析を使った検証を披露
はじめに
Jagu’e’r データ利活用分科会でLookerの知見を共有する会「Looker User Meetup」がGoogle 渋谷ストリームとオンラインの2箇所で開催されましたので登壇しました。
＜アジェンダ ＞
・12:00~12:05 オープニング
・12:05~12:25 Lookerユーザー LT 1 : Google 山本様
・12:25~12:45 Lookerユーザー LT 2 : アイレット 山田
・12:45~12:55 質疑応答
・12:55~13:00 クロージング・アンケート回答
・13:00~14:00 Google Cafeにてランチ（オンサイト参加者限定）
今回は第4回でテーマは「セマンティックレイヤー」ということだったので「運用分析におけるセマンティックレイヤーの構築」というタイトルでセマンティックレイヤーの重要性について見解を述べました。
要約
※発表前にはGoogle Agentspaceの全社導入の件について触れた。
アイレット社内に提供している運用分析プラットフォームというMSPのあらゆるデータを可視化するプラットフォームでLookerを採用したことにより、分析に関するあらゆるデータに対して意味（セマンティックレイヤー）を持たせることが可能になった。
セマンティックレイヤーが構築される以前は以下のような課題があった。
- セルフホストRedashによる属人的な分析ダッシュボードの提供
- 分析の指標が一致しないなどの数値誤差
- チーム間でデータに対する認識を誤るなどのコミュニケーションコストの発生
いずれにしてもデータに対する共通認識がないために起きるため、これらをセマンティックレイヤーを構築することでおおむね解決することが可能になった。
また、構築済のセマンティックレイヤーでLooker 会話分析を使った結果についても説明した。
発表内容
冒頭（余談）
まずは余談としてEnterpriseZineの月間アクセスランキング10位にランクインした話をしました。
ここ数年間におけるLookerに関する活動
- 外部発信
- オウンドメディアではLookerを中心に発信
- 運用分析プラットフォームとLookerの統合
- 運用分析プラットフォームにLookerを導入してから現在に至るまで（Lookerを実装する挑戦）
- LookerをLooker Studio Connectorに接続！だれもが分析に参加できるBIの整備
- 最近の検証
- セマンティックレイヤーの構築・修正（LookMLの調整）
- Looker 会話分析を触り始める
オウンドメディアではLookerを中心に発信
まずは登壇者の私（山田）が書いたiret.mediaについて説明しました。
執筆した33件中12件がLookerに関する記事であり、雲勉（アイレットのYouTubeチャンネルで配信している技術解説動画）では運用分析をテーマに登壇した話をしました。
運用分析プラットフォームにLookerを実装する挑戦
まずは今回のセマンティックレイヤーの説明するために重要なキーとなる運用分析プラットフォームについて解説しました。
MSPの監視/運用 業務に関するあらゆるデータを収集・可視化し、品質向上・効率化・監視設計の改善や提案を実施しています。このサイクルの中心で Looker を利用しています。
具体的なアーキテクチャや技術選定の過程についてはFindy様が提供しているFindy Toolsにて共有しています。
cloudpackにおけるLookerの活用事例 – Findy Tools
運用分析プラットフォームにLookerを導入してから現在に至るまで
運用分析プラットフォームを解説したのち、Looker導入に至るまでの変遷を説明しました。
運用分析プラットフォームは2021年にAWS上のセルフホストで分析環境を構築するところからスタートしました。
それから分析ダッシュボードの需要が増え、以下のような課題が出てきました。
- 課題1：Lookerを閲覧するにはViewerライセンスが必要
- 課題2：セルフでダッシュボードを作成できない
これらの課題を解決するために、いくつかの解決策を模索しました。
具体的には以下のとおりです。
課題1：Lookerを閲覧するにはViewerライセンスが必要
まずは「課題1：Lookerを閲覧するにはViewerライセンスが必要」の対策として
Looker APIとSlack Appを使ったレポーティングアプリケーションを開発して提供しました。
これにより、Lookerのライセンスがない人でもLookerの実績を共有することができるようになり、運用改善のサイクルをより高速に回せるようになりました。
課題2：セルフでダッシュボードを作成できない
2つ目の「課題2：セルフでダッシュボードを作成できない」という課題の対策として、LookerをLooker Studio Connectorに接続し、だれもが分析に参加できるBIを整備しました。
これにより、LookerをLooker Studioから操作できるようになり、コードを書くことなく分析ができるようになりました。
Lookerの導入を通して
Lookerを導入したことでデータに対する説明がつくようになり、データに対する議論がより活発になりました。
議論をしていくなかでデータに対して関心を持てるようになったのはセマンティックレイヤーあってこそのものだと実感しました。
Looker 会話分析を触り始める
運用分析の話は以上。
ここから先はLooker 会話分析（以下、本文では「会話分析」と記載）でこれまでの積み重ねで作成したセマンティックレイヤーで検証を進めた話をしました。
発表では、期間で検索するなどのシンプルな会話分析の検証と、少し複雑な会話分析について検証した話をしました。
※より具体的な検証内容については以下のiret.mediaの記事をチェックしていただけたらと思います。登壇で話した内容も含まれています。
運用分析プラットフォームでバイブスを上げろ！LookerによるVibe Analytics
Looker 会話分析に必要なものについて
実際に会話分析を使ってみたところ、以下の従来からある3つの要素以外に必要なものがあると説明しました。
- データエンジニアリング
- データモデリング
- セマンティックレイヤー
会話分析には上記3つある要素に加えて、データ分析の仕様書（Analytics Spec）が必要であるという見解（自論）を話しました。
※Analytics Specというのは、要するにどのような分析が欲しいかの定義書のことで、登壇者の山田が勝手に考えたワードです。
現地の質問
※覚えている範囲で記載
- 質問：会話分析の検証部分で求めている対応率の指標と実際に出力されたものが違うという話で、計算式を示した会話分析による解決方法について説明があったが、LookMLで個別に指標を定義すれば良いのでは？と思った。
- 回答：おっしゃるとおり。しかし、割り算等して割合を求める指標がほかにもたくさんあるため、LookMLで全てを定義するのは難しいので会話分析で出せると良いと考えています。
- 質問：同じくRedashを使っている。山田さんは運用面とダッシュボード基盤の両方を知った上でLookMLを書くといったことをしているように見えた。そもそも運用しながらの分析は難しいうえにLookMLのハードルが高いこともあると思う。LookMLを定義するといったときにどういったことをしているのか？
- 私もLookMLについてはここ数年で書いた身なので詳しいというわけではないです。LookMLを書くときはコーディングAIエージェントを使って書くこともしています。なお、最近になってLookMLのコーディングエージェントが登場しているので使ってみると良いかもしれません。
今後の抱負などを少しだけ
発表が終了後の質問前に今後の抱負について説明する場面があったのでいくつか語りました。
- notify-looker-reportをGoogle Cloudベースで再構築する
- Looker 会話分析のAPIを使ったアプリケーションの開発（notify-looker-reportの延長？）
- Lookerユーザー数の拡大やGoogle Agentspaceとの連携
まとめ
クラウド環境の運用分析をテーマにLookerを運用したら、みんなでデータの議論ができるようになるところまで辿りついた。
- 「セルフホストされたOSSで地道にSQLを書いてはダッシュボードを作る」という作業
- 専門知識と個人スキルが分析のボトルネック
- LookerとLooker Studioを導入したことによって、ノーコードで分析ができるようになった
- ライセンスが不足している分をLooker APIを活用することで対応（notify-looker-report）
- Looker 会話分析による迅速なクエリ作成を検証
- セマンティックレイヤーその他とデータ分析の仕様書（Analytics Spec）が重要
簡単30秒