こんにちは。「LookerはBIツールではなくデータプラットフォームです」と言われて、結局何がどう違うのかわからないという方も多いと思います。
実際に10以上のBIツールと比較検討した上でLookerを導入して10ヶ月程度たった一人ビジネスパーソンとして、その他のBIツールと明らかに違う点が2つあると思っています。

LookMLというSQLを抽象化する言語で集計ロジックを一言管理し運用負荷を下げられること
Lookerを経由して他システムに必要なデータを正確にデリバリーできること

1だけで３日間くらい語り明かしてしまいそうなので、1についてはこちらで詳細を記事にしておりますのでぜひ読んでみてください。
本記事では2の部分について掘り下げてお話しようと思います。

柔軟なデータデリバリーを実現する３の機能

SSO Embed

実際にプロダクトのダッシュボード機能として埋め込みを行っており、Lookerで作成したダッシュボードをシームレスにプロダクトのユーザー様に提供しています。さらにSalesforceにも埋め込みを行い社内での意思決定を促進するダッシュボードもSalesforceのUI上で提供しております。実際にこういった埋め込みを行おうとすると権限管理やダッシュボードの運用保守にかなりの開発工数を割かれるところですが、大幅に削減し短期間でリリースすることができました。

Schedules

個人的にはこれがなかなか秀逸な機能だと思っているのですが、一般的には「Slackにダッシュボード定期配信する機能でしょ？」と思われている節があるので少し応用的な話になりますが、 datagroup_triggerを引き合いにただのバッチスケジューリングではないことを強調したいと思います。

datagroup_triggerにSQLをセットしSchedulingすると、Lookerは5分に一回データベースにクエリを発行し、5分前の実行結果と違う結果がデータベースから返却されるとトリガーが発火し、データの配信が行われます。

この機能を応用するとzapierやintegromatのようなシステム間のデータ連携のhubとして使われるRPAツールとほぼ同じ役割かそれ以上の役割をLookerが担ってくれます。internalなユースケースだと数え切れないほどのワークフローを自動化できると思いますが、思い切ってプロダクト開発におけるAlert機能のプロトタイピングの際に使用したりもしました。

Action

SSO EmbedとSchedulesのバッチスケジューリングに関しては他BIツールでもよく見る機能ですが、Action機能についてはLookerがユニークで持つ機能ではないかと思っています。ダッシュボードからデリバリーしたいデータを探索したのちに、1レコード単位で他システムにデータを送信できます。

実際にAccreteというSMS配信システムとLINEWORKSの2つのシステムと連携しましたので紹介します。

Action機能を用いたLookerとAccreteの連携

今回はLookerからAWS lamdaにデータを送信しAccreteのAPIをcallしてSMS送信を行います。

  dimension: phone_number{
    type: string
    label: "電話番号"
    sql: ${TABLE}.phone_number ;;
    action: {
      label: "Send SMS Message"
      url: "{{lamda_url}}"
      icon_url: "{{icon_url}}"
      param: {
        name: "telno"
        value: "{{ value }}"
      }
      param: {
        name: "text"
        value: "こんにちは。テストメッセージです。"
      }
    }
  }

ここではLamdaの中身については割愛します。
実際に位置情報を元に車両を検索し、対象車両のドライバーにSMS送信を行う画面のキャプチャがこちらになります。

Action機能を用いたLookerとLINE WORKSの連携

  dimension: line_works_id{
    type: string
    label: "LINE_WORKS_ID"
    sql: ${TABLE}.line_works_id ;;
    action: {
      label: "Send LINE WORKS Message"
      url: "{{lamda_url}}"
      icon_url: "{{icon_url}}"
      param: {
        name: "line_works_id"
        value: "{{ value }}"
      }
      param: {
        name: "text"
        value: "こんにちは。テストメッセージです。"
      }
    }
  }

ここでもLamdaの中身については割愛します。
実際に位置情報を元に車両を検索し、対象車両のドライバーにLINEWORKSでメッセージ送信を行う画面のキャプチャがこちらになります。

まとめ

LookerがBIツールではない理由をお話してきました。
ある程度BIツールを使い込んでいる方は「いろなところで謎定義のダッシュボードができて、結局正しい数値かどうか確認しないといけなくて意思決定にストレスがかかり保守も作った人しかできない」「ダッシュボードではデータみれてるけど、他のシステムにデータを渡すには結局別のツール導入や開発が必要」という状況はあるあるかなと思いますのでぜひ検討してみてはいかがでしょうか。

LookerがBIツールではない2つの理由