Looker のアクションによるデータドリブン業務フローパターン

解決する課題・使い所

エンタープライズ企業において、BI の活用が進んでくると、以下のような課題が顕在化してきます。

• 複数の部署やメンバー間でレポートやダッシュボードに利用されるビジネス指標の定義が合わない

• レポーティングやダッシュボードでビジネスやサービスの指標が可視化されたが、アクションにつながらない

• 主にデータ分析に不慣れなメンバーが BI ツールにアクセスすることに面倒を感じ、幅広くデータ活用が進まない

「売上」という指標 1 つとっても、税を含むのか、注文後のキャンセルされた商品も含むのか、ディスカウント前後いずれの数値なのかなど、部署や見る人の立場によって定義は変わります。しかし、そのような乖離がある状態では、より組織間で横断的な分析の信頼性が乏しくなり、企業活動の重大な妨げになります。こうした状況を防ぐには、数値の定義を一元的に管理し、その変更に対して統制が取れる必要があります。

また、一度データを可視化する基盤が整うと、ビジネスに関するさまざまな指標が正しく把握できるようになりますが、本来あるべき分析に基づいたアクションにつなげられない状況が起こりがちです。これは、意思決定から実際のアクションに至るために組織をまたぐ必要があったり、アクションを起こすシステムと BI ツールとの連携に開発コストが必要であったりすることなどが理由であり、BI ツールから直接アクションへつなげることができることが重要です。

最後に BI ツールは、分析になれたメンバーには苦労なく扱えますが、非分析者や非エンジニアからすると学習するツールが増える印象を与えたり、シンプルに普段アクセスしないインターフェースにわざわざアクセスする必要があることから浸透しないケースがよくあります。そこで、社内のポータルサイトやモニタリング ツール、営業支援ツール上で直接 BI ツールの分析結果を利用できることが必要です。

このデザイン パターンでは、これらの課題を解決するモダナイズされた BI を Looker と BigQuery を用いて実現する方法を説明します。

アーキテクチャ 

• BigQuery に集約されたあらゆるデータを Looker から接続し、データ分析の処理を BigQuery の強力なパワーで行います。

• Looker上で、LookML を用いて指標の計算定義などのデータモデルを記述し、Github と連携してガバナンスが効いた開発が行えます。

• Looker のダッシュボード上で、分析の結果出力されたレコードに対して、簡単に外部ツールによるアクションが行えます。

• プライベート埋め込みを利用し、既存のツール上でダッシュボードなどを利用可能にします

アーキテクチャ

LookML は、定義すべきビジネス指標のためのディメンション、ロジックとなる、集計、計算、およびデータ関係を記述するための言語です。Looker は、LookML で記述されたモデルを使用して、特定のデータベースに対する SQL クエリを作成します。LookML は Github で管理され、変更に対する承認プロセスを確立することができるので、チームによる開発に適しています。

以下は、LookML の一例です。connection で接続するデータベースやそれに関連する設定を指定します。explore でクエリするビュー（BigQuery の場合はテーブルに相当）を指定します。また、ここでは 2 つのビューを結合しています。dimension や measure に、それぞれディメンションと指標を定義します。

アクション

アクションハブを利用することで、Looker のダッシュボード上の分析操作からアクションへ直接つなげることができます。例えば、顧客データの分析において、特定セグメントや特定条件に合致する顧客を抽出し、その顧客に対して SMS メッセージによるコミュニケーションを実行するなどができます。以下は、抽出した顧客の電話番号のセルをクリックして、表示されたアクションである Twilio と連携してメッセージを送るイメージです。

同様に、Slack やメールのメッセージを送る、Salesforce のレコードを更新するなどのアクションが簡単に実装できます。

 標準以外にも、アクションハブに任意の外部ツールとの連携を登録したり、プライベートのアクションハブを構築するなど、自由に外部ツールとの連携を実装できます。

プライベート埋め込み

以下のような iframe を利用することで、任意のウェブサイトに Looker のダッシュボードや Look を埋め込むことができます。オプションの設定により、ログインしていないユーザーにログイン画面を出すこともできます。外観を変更して、埋め込み先のウェブページに違和感なく統合することもできます。

そのほかの埋め込み方法として、誰でもアクセスできる「パブリック埋め込み」、埋め込み先の認証を利用する「シングル サインオン（SSO）組み込み」があります。

利点

• BigQuery の強力な分散処理パワーを利用することができ、ハイパフォーマンスにデータ処理ができます。また、BigQuery の機能であるマテリアライズド ビューや BI Engine を活用することで、より効率的な BI 環境が構築できます。

• LookML によるデータ モデリングで、ビジネス指標の定義を組織内で統一することができ、その変更管理もガバナンスを保つことができます。これらの事前定義により、分析者がデータの格納場所や集計方法などの多くを意識することなく、すぐに分析業務を開始することができます。 

• ダッシュボードなどからコミュニケーション ツールへのメッセージ送信や、マーケティング ツールによるユーザーへの施策実行などのアクションが直接実行できたり、Looker で作成した分析結果を社内ポータルや営業支援ツールなどで直接参照したりすることができるため、業務プロセスに沿ったデータ活用がしやすくなります。

注意事項

• Looker の利用時は、Looker の費用とは別にデータベースの利用料も発生します。本パターンでは、BigQuery の料金がかかります。

• Looker で取れるアクションの内容や対象（セル単位のデータ、ダッシュボード レベル、クエリの結果など）は、連携するツールに依存します。 

• プライベート埋め込み時に、ログインしていないユーザーがアクセスしたときに、ログイン画面を出さない場合はエラーが返ってきます。

このパターンで作成された事例

• 現場から経営層までが同じデータを見てスピーディに意思決定。Looker が起こすデータの民主化とは ?

関係するデザイン パターン

• BigQuery に蓄積したデータ活用のパターン

参照文献

• Looker Documentation - 統合サービスのリスト

• Looker Documentation - Sharing data through an action hub（英語）

• Data Actions: Take action on what you learn - Right from Looker（英語）

• Looker Documentation - プライベート埋め込み

• Looker Documentation - iframeタグによるパブリック埋め込み

• Looker Documentation - シングル サインオン（SSO）組み込み

Looker による外部へのデータ提供パターン

解決する課題・使い所

エンタープライズ企業において、組織内でのデータ活用を推進するとともに、契約している法人や顧客などの外部に対してデータを提供したいというニーズが生まれます。データの外部提供により、外部の法人や顧客とともに自社サービスをより活用していくための分析を行うことができ、相互にサービスをよりよくする環境を構築することができます。

一方、外部へのデータ提供においては、正しいアクセス コントロールを実現することが 1 つの課題となります。例えば、マーケット プレイスのようなサービスを展開している場合、そのプラットフォームを利用する複数の契約法人に対して、それぞれの売り上げの集計データを提供するとします。その場合、当然ほかの法人のデータが見えてしまっては困ります。このような場合、法人ごとの売上集計のデータマート テーブルを DWH 上などに作って、それぞれに正しいアクセス権を付与する方法がよく利用されます。

これはデータの多重持ちや、増え続けるテーブルへのアクセス権の付与における運用負荷などを引き起こし、データ基盤の運用コストが増える結果となります。また、人為的ミスなどにより、本来見えてはいけないデータが見えてしまうというリスクにさらされます。あらゆる法人の売上データに対して、適切にレコード レベルでアクセス制御ができれば効率よくデータを外部提供できます。

このデザイン パターンでは、これらの課題を解決する方法として、主に Looker のユーザー属性機能を用いて紹介します。

アーキテクチャ

• BigQuery に集約されたあらゆるデータに Looker から接続し、データ分析処理を BigQuery の強力なパワーで行います。

• Looker 上で、ユーザーに付与するユーザー属性を作り、ユーザーごとの属性値を設定します。

• Looker 上で、LookML を用いてユーザーに設定された属性と、アクセス制御の基準とするディメンションの組み合わせを定義します。

• 法人ユーザーは、外部公開されたダッシュボードなどにアクセスし、ログインした状態で認識されるユーザー属性情報に基づいて、適切なデータのみアクセスできます。

ユーザー属性

Looker のユーザー属性は、各 Looker ユーザーやグループに対して付与できるメタデータです。管理者権限相当のユーザーが属性を作成できます。たとえば、作成したユーザー属性 “Country” に対し、対象のユーザーに “JAPAN” という値を付与します。

データ モデリングを LookML で行う際に、以下のように “access_filter” を使って、ユーザーが持つユーザー属性 “Country” の値と “orders” ビューのディメンション “nation” が一致するものだけをフィルタする定義を記述します。 “field” に対象となるディメンション、 “user_attribute” に利用するユーザー属性を設定します。

“access_filter” を設定しない場合は、以下のようにあらゆる “nation” のデータが見えています。

“access_filter” を設定すると、以下のように JAPAN だけのデータしか見えなくなります。

利点

• 公開するデータを法人ごとに作成する必要がなくなり、無駄なコストの発生を抑えることができます。

• ユーザー属性により自動的に適切なデータへのアクセス制御が実施されるので、手動によるアクセス制御で発生する可能性のあるセキュリティ リスク（ヒューマン エラー）を排除することができます。 

注意事項 

Looker の利用時は、Looker の費用とは別にデータベースの利用料も発生します。本パターンでは、BigQuery の料金がかかります。

関係するデザイン パターン

• BigQuery に蓄積したデータ活用のパターン

参照文献

• Looker Documentation - ユーザ属性