ビジネス インテリジェンスのモダナイゼーション  

エンタープライズ企業におけるデジタル トランスフォーメーションは、データドリブンな意思決定を必要とします。そして、それを支えるビジネス インテリジェンス(BI)も非常に重要です。 昨今のビジネスを取り巻く環境の絶え間ない変化を受け、従来の BI と比較し、より柔軟性高く、迅速かつ安全にデータを社内で活用する必要があります。そのためには、データ処理の高いパフォーマンスとスケーラビリティ、データのガバナンス、分析結果に対する高いアクション性、コラボレーション性などが求められます。 本項では、エンタープライズ DWH である BigQuery と Looker を用いたモダナイズされた BI 環境を実現するためのデザイン パターンを紹介します

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

解決する課題・使い所

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

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

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

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

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


アーキテクチャ 


アーキテクチャ

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

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

アクション

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

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

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


プライベート埋め込み

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

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


利点


注意事項


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


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


参照文献

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

解決する課題・使い所

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

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

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

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


アーキテクチャ


ユーザー属性

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

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

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

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

利点


注意事項 

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


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


参照文献