Looker の概要: LookML によって BI ワークフローがどれだけ簡単になるか

※この投稿は米国時間 2020 年 8 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

組織でビジネス インテリジェンス ワークフローを確立すれば、どの地域で事業を拡大するか、リソースをもっと効果的に配備するにはどうすればよいかといったビジネス上の意思決定をより的確に下せるようになります。私はデータ アナリストやオープンデータ アドボケイトとして働き、以前は Google Cloud 一般公開データセット プログラムでリーダーを務めていました。こうした経験から、「データチームはどのようにビジネス インテリジェンス ワークフローを策定すべきか」という問いに対して広い見方ができるようになりました。私は幸運にも、これまで小売、気象、金融サービスなどのさまざまな業界でデータ分析チームに所属してきました。この経験を通して、ビジネス インテリジェンス ワークフローには常に立ちはだかる共通の課題があることを知りました。  

チームの課題は選択したツールに根差していると考える人もいるかもしれませんが、どのビジネス インテリジェンス ツールにもそれぞれ利点があります。データの可視化に秀でたものもあれば、ダッシュボードの共有に優れたものもあり、一部の BI ツールはデータの準備機能が卓越しています。ほとんどの BI ツールは、少なくともいくつかのデータ ウェアハウスに簡単に接続でき、そのデータを可視化できます。

しかし、欠点のない BI ツールはありません。また、企業内の各チームの BI に対する要件は完全には一致していないため、チームごとに異なるツールが選ばれるケースが多く、その結果社内でセグメンテーションの問題が生じます。私の経験で最もよく見られた問題は、指標の定義がツールごとに異なっていて一元的なデータ ガバナンスが存在しないことです。これは、社内全体に不必要に重複したワークフローが生まれる原因となります。

新たに Google Cloud の一員となった Looker は、このような「中間プロダクト」の問題に対応します。LookML（Looker の強力なセマンティック モデリング レイヤ）を使用すると、標準化されたデータ ガバナンス構造を簡単に作成でき、社内のすべてのユーザーが同じ「信頼できる唯一の情報源」を使ってそれぞれ独自の分析を行うことができます（Looker が LookML を開発した理由については、このブログ投稿をお読みください）。

今回は、LookML のメリットが得られる 5 つの職種に焦点を当て、それぞれの職種の BI ワークフローが LookML によってどれだけ簡単になるかを見ていきます。職種ごとに、LookML コードのスニペットを例に挙げて LookML の利便性を示します。「例を見る」というリンクをクリックすると、GitHub リポジトリにある完全な LookML ファイルが表示され、詳細なコードを確認できます。

データ エンジニアおよびモデラー

職務: これは LookML から最も明白なメリットが得られる職種です。肩書はおそらく「ビジネス インテリジェンス アナリスト」や「データ エンジニア」でしょう。所属するチームは、データドリブンな意思決定を可能にする基盤インフラストラクチャの構築、主要な指標の元となるデータの標準化、KPI の達成に向けた進捗の測定を行います。

LookML を利用するメリット: LookML により、再利用性が向上します。Git 統合による共同開発、オブジェクト定義、継承など、ソフトウェア開発で使用される多くのツールや方法論をデータ モデリングの作業に活用できます。ディメンションを定義できるほか、一度測定した後それを基に構築するという手法をとることもできます。つまり、同じ作業を何度も繰り返さなくて済みます。これにより、指標とそれを定義するデータを標準化し、時間を節約するスケーラブルな方法で標準化を社内全体に展開できます。LookML を使用して元データを意味のある指標に変換することで、経理部門からマーケティング部門までの社内全体の BI ユーザーが、適切に定義、集計された指標を使用して独自のダッシュボードの作成を簡単に始めることができます。

例を見る: ビジネスに共通の課題のひとつに、異なる事業単位の間で収益およびマージンを比較できるようにすることがあります。事業単位が違うと収益源、在庫費用、人件費、その他の要素が異なるため、収益およびマージンを比較するのが難しくなります。これはしばしば、意思決定者が他の事業単位と連携できず互いに孤立する状況を招きます。また、事業単位を越えた比較のたびに手動での調整作業が必要となります。

しかし、LookML があればこの問題は解消されます。以下の LookML スニペットでは、inventory_items テーブルのアイテム費用を order_items テーブルの販売価格と結合し、gross_margin を sales_price - inventory_items.cost として定義しています。いったんこのように定義しておけば、あとは他のディメンション定義で ${gross_margin} を呼び出すだけで、gross_margin を繰り返し参照できます。毎回 SQL を書き直す必要も、複数の場所で同じ SQL ステートメントを再実行する必要もありません。

これが重要である理由: 指標の定義を一元化すると、データ パイプラインの破壊につながるおそれのある人為ミスが入り込む可能性が低下します。また、グロスマージンを参照するたびに同じ SQL ステートメントを実行しなくて済むため、SQL エンジンの利用頻度も下がります。最も重要なのは、グロスマージンの標準的な定義が社内全体で 1 つだけ存在するということです。これにより、その複雑さが下流ユーザーから見えなくなります。

データ アナリスト

職務: この職種には、分析の正確さを検証することが要求されます。肩書は「データ アナリスト」や「ビジネス アナリスト」で、これらの分析の背後にあるデータがどれだけ複雑であるかを理解しています。同僚はデータ アナリストを信頼し、データを正しく解釈できるのはデータ アナリストのおかげと考えています。

LookML を利用するメリット: LookML は、データ プロフェッショナルに他者をサポートする力を与えます。データに関する広範な知識を文書化する、一般的な集計を事前に定義して誤用を防ぐ、同僚が各自の分析に集中できるように信頼性の高いデータ定義レイヤを提供する、といったことが可能です。LookML はデータに関する情報の中央リポジトリを提供し、ユーザーはそこで直接答えを得ることができるため、データ アナリストへのチャット、メール、電話による問い合わせは減少します。

例を見る: データ アナリストは通常、それほど頻度が高くない質問、またはある特定の方法で答える必要がある質問に回答できる単発の分析を開発するよう求められます。この作業に時間を取られ、結果的により重要なプロジェクトの仕事が疎かになる場合があります。

アナリストは、LookML を使用して主要な指標を公開できます。これにより、ユーザーは指標が一貫して計算されているかどうかを気にせずに、独自の分析を行うことができます。これは、社内のすべての人に信頼できる唯一の情報源が提供されることを意味します。医療業界の例を見てみましょう。ユーザーの健全性スコアはさまざまに定義されています。特にさまざまなツールで異なる定義がされていて、その計算方法が必ずしも明確でない場合は、2 人のユーザーが健全性スコアに異なる定義を与えるという状況は簡単に起こり得ます。

しかし、LookML を使用すれば、アナリストがビジネス ユーザーのためにこの定義を定めることができ、ユーザーは信頼できる情報源を使用して独自にトレンドを掘り下げることができます。また、特定の指標がどのような前提でどのように計算されているかをユーザーに知らせるために、開発者がコメントや説明を追加することもできます。このようなカスタム指標の説明は、Looker のフロントエンドの Explore 環境にツールヒントとして表示されます（以下の画像を参照）。さらに、Looker の新しいデータ ディクショナリ（Looker Marketplace から無料で入手可能）には、各指標のすべての説明と SQL 定義が格納されています（以下の画像を参照）。

これが重要である理由: アナリストとエンドユーザーのコミュニケーションやコラボレーションを支援する LookML の機能を利用すれば、ビジネス ユーザーや意思決定者がデータ アナリストの手を煩わせずにデータをさらに掘り下げることができます。また、Looker の Explore 機能を使ってデータの関係を独自に探索し、基になる指標や計算が信頼できることを自ら確認することもできます。つまり、アナリストがミーティング、メール、チャットで分析やその基になる前提を説明する時間が少なくなり、より重要なプロジェクトのデータ分析に多くの時間を費やせるようになります。

IT セキュリティ

職務: この職種は、データにアクセスできなければならない人がデータにアクセスでき、データにアクセスできてはならない人がデータにアクセスできないようにします。肩書としては「IT スペシャリスト」や「データ セキュリティ スペシャリスト」が考えられます。その業務には、会社が HIPAA、GDPR、CCPA などの規制要件を遵守するよう支援することや、会社のデータが必要のない人にさらされないようにして顧客のプライバシーを保護することが含まれます。

LookML を利用するメリット: LookML は、今日の複雑なデータを扱えるように設計されています。IT セキュリティ リーダーは、ディメンション、ダッシュボード、Looker のインスタンスを別途作成して管理しなくても、必要な人にアクセス権を提供し、不要な人からのアクセスを拒否できます。Liquid（LookML のオープンソース テンプレート言語の実装）を使用すれば、Looker のユーザー権限を使用してユーザーのアクセスレベルをプログラムで決定できます。つまり、ディメンションやメジャーに対するユーザーのアクセス権を、そのユーザーの LookML で直接管理されているアクセス権限に基づいて動的に制限できるのです。このような仕組みにより、Looker 内のユーザー属性やグループに基づいて決定される行ベースのアクセス フィルタや列の非表示、データ マスキングを設定できます（データ マスキングの例については、以下の画像をご覧ください）。これは、データ アナリストは（複数ではなく）単一のダッシュボードを維持するだけでよいのに対し、IT セキュリティ リーダーのようなセキュリティ プロフェッショナルは、権限の管理に必要なすべてのツールを使用できることを意味します。

例を見る: 現在のセキュリティ チームは、それぞれ独自の権限と定義を持つ複数のデータ ウェアハウスにわたってユーザー権限を管理することが要求されています。これは煩雑であるだけでなく、適切なユーザーだけに適切なデータを提供するために個々の製品から適切な権限を取得しなければならず、不必要に複雑さが増します。

LookML では Liquid SQL がサポートされており、このプロセス全体が簡素になります。Looker のユーザー権限に直接接続し、そこで個々のユーザーごとに属性やロールを設定できます。次の例は、ユーザーの属性に応じて顧客の完全なクレジット カード番号を表示するリテール バンキングのユースケースを示します。LookML の Liquid SQL を使用すると、特定の列へのアクセス権を与えるかどうかをユーザーの属性に基づいて動的に決定できます。複数のデータ ウェアハウスにわたって列レベルの権限を管理する必要はありません。

これが重要である理由: すべてのユーザー アクセス権限を 1 か所で管理すると、時間と労力が節約され、不適切なデータアクセスにつながるミスのリスクも軽減します。LookML の Liquid テンプレートを使用すると、権限を指標定義のすぐそばで管理できるので、該当するユーザーに何へのアクセスを許可しようとしているかが正確にわかります。さらに、データ ウェアハウスでなんらかの構文を使用してどの権限が与えられている必要があるかを調べる必要もなくなります。

エグゼクティブ / CXO

職務: この職種の仕事は、より望ましい結果を生むために企業全体でデータを活用できるようにすることです。肩書としては「最高データ責任者」や「アナリティクス担当シニア バイス プレジデント」が考えられます。その職務は、会社の経営を可能な限り円滑化することにあります。つまり、指標の測定と報告が全社的に一様に行われるようにする必要があるのです。

LookML を利用するメリット: データ ウェアハウスの技術とニーズは長い年月をかけて進化してきました。このようなパラダイム シフトが繰り返された結果、多くの企業ではデータがさまざまな場所に異なる構造で保存されており、重要業績評価指標の定義も社内で一貫していません。そのため、場合によっては、異なる事業単位の間で業績を比較することが困難または不可能になっています。LookML を使用すると、これらの定義を全社的に標準化できるため、事業成果の分析が容易になります。つまり、仕事の重複が少なくなり、指標がより合理化されます。

例を見る: エグゼクティブは絶えず会議から会議へと走り回っており、データを思い通りに深く掘り下げる時間が常にあるとは限りません。つまり、提示された答えが異なる事業単位の間で比較可能であることを信用する必要があります。そうでないと、リソースに優先順位を付けて予算をできるだけ効果的に配分することはできません。

売上継続率は、Software as a Service（SaaS）企業にとって重要な指標のひとつです。スプレッドシートでデータを操作してさまざまな形にスライスする代わりに、LookML でドルベースの売上継続率を計算することで、この作業がどれだけ簡単になるかを見てみましょう。売上継続率はしばしば取締役会や投資家会議で報告されるほど重要であり、毎回正確な数字を出すために大きなプレッシャーがかかっています。LookML では、指標を一度定義すれば、あとはまったく気にする必要がありません。そのため、チーム間の重複した作業がなくなります。さらに、Looker には分析の結果を必要な形式で定期的に送信する機能もあります。たとえば、すぐに閲覧できる PDF 形式のファイルをメールで送信できます。また、Google スプレッドシート形式を選択すると、データをさらに深く掘り下げることができ、次回のプレゼンテーション用のスライドデッキを自動的に更新することも可能です。

これが重要である理由: このような自動化によって時間と手間が省かれ、ビジネスの状況を把握しやすくなります。どこでデータを閲覧しているかにかかわらず、データの鮮度を気にする必要はありません。さらに重要なのは、社内の別々のチームが同じ作業を繰り返す必要がなくなることです。これにより、時間が節約され、受け取る情報が常に合理化された一貫した最新のものとなります。

オペレーション

職務: この職種の仕事は、日々のビジネス オペレーションを監視することです。肩書としては「オペレーション マネージャー」や「カスタマー サポート ディレクター」が考えられます。大まかな傾向を把握することが重視されますが、データの詳細に即座にドリルダウンできることも必要です。

LookML を利用するメリット: LookML は、今日の複雑なデータを扱えるように設計されています。オペレーション リーダーが監視するビジネス セグメントは複雑で、そこで生成されるデータもそれを反映しています。大まかな傾向を知ることは有益ではありますが、データの単一の抽象化または集計だけでは、その奥に潜む複雑さはわかりません。この複雑さを知ることは、成功を収めるうえで不可欠です。LookML のデータへのドリルダウン方法を定義する機能を使用すれば、必要な詳細にアクセスでき、ダッシュボードから行動を起こすことができます。Looker のアーキテクチャと組み合わせると、抽出されたデータだけでなく、行レベルの詳細なデータにもアクセスできます。Looker には、データの異常や重要な傾向を把握するために必要なすべてのツールが揃っています。

例を見る: オペレーション リーダーは、監視しているビジネスのすべての部分について詳細を把握している必要がありますが、それらの情報を得るために配下のチームと一日中ミーティングするわけにはいきません。傾向が集約されたダッシュボードは、どこにエネルギーを集中させるかを判断する材料にはなりますが、潜在的な問題を解決する、チームや顧客に状況を伝えるといった意味のある行動を起こせるほど詳細な情報を与えるものではありません。

以下の画像は、LookML で小売業のオペレーション リーダーまたはカスタマー サポート チームのリーダーを支援する方法の具体例を示します。最初の 2 つの画像では、LookML を使用してダッシュボードの drill_fields を定義しています。これにより、ユーザーは注文数などの集計された指標をクリックして、その集計を構成する各データ行の指定されたフィールドを含むテーブルを見ることができます。また、別のダッシュボードにドリルダウンして、特定の指標についてさらに詳しく知ることもできます。

LookML で action を定義することも可能です。最後の画像にその例を示します。これにより、Looker のドリルダウン機能は一層強力になります。アクションは特定のフィールドに対して定義でき、Looker から離れることなくデータを調べながらアクションを実行できます。この例で定義されているアクションは、データ閲覧者がユーザーのメールアドレスをクリックしたときにそのユーザーに対して販促メールを送信します。アクションは必要なだけいくつでも定義できます。

これが重要である理由: 上記の機能を使用すると、必要な情報そのものが得られます。また、必要なときに詳細がわかり、直ちに行動を起こすことができます。これにより、他者への依存が軽減し、チームの時間とエネルギーが解放されて、メンバーはもっと重要なプロジェクトに注力できます。また、データから得られた洞察に取り組み、そこから直接行動を起こすことで、オペレーションの効率が向上します。

LookML が BI ワークロードをどのように支援できるかについてさらに詳しく知るには、LookML のドキュメントをご覧いただくか、Google Cloud Next ‘20: OnAir で開催される Looker のディープダイブ セッションにご参加ください。LookML のユニークな機能をすぐに使い始める場合は、無料トライアルにお申し込みください。