Best Practice: Create a Positive Experience for Looker Users

以下のベスト プラクティスは、経験豊富な Looker の部門横断的なチームが共有する推奨事項を反映しています。これらのインサイトは、実装から長期的な成功に至るまで、Looker のお客様との連携に携わった長年の経験に基づいています。ベスト プラクティスはほとんどのユーザーと状況に対応するよう作成されていますが、実装の際は慎重に判断してください。

LookML デベロッパーは、次のヒントを参考にして Looker のユーザー エクスペリエンスを向上させることができます。

これらの推奨事項については、以降のセクションで詳しく説明します。

ユーザーにわかりやすいフィールド名を用意する

  • label パラメータを使用して、ディメンションまたはメジャーにわかりやすい名前を適用すると同時に、ビューファイルとモデルファイル内ではデータベース フレンドリーな名前を維持します。カウントを数に、総計を合計に変えるなど、一般的な単語名をいくつか変更することをおすすめします。ユーザーにとって意味のある単語がわからない場合は、ビジネス ユーザーと連携して共通レポートをいくつか作成し、ユーザーの使用目的を表現するレポートで使われている単語を確認してください。たとえば、Inventory Items、Order Items、Orders、Products の各ビューに Count というメジャーがあるとします。label パラメータを使用して、それぞれのメジャーに一意でわかりやすい名前（Number of Inventory Items、Number of Order Items、Number of Orders、Number of Products など）を指定できます。
  • 同じ名前のフィールドを複数公開しないでください。たとえば、type: count のメジャーは、Looker 内で Count という名前で自動的に作成されます。その結果、多くのビューファイルに同じ名前のカウントのメジャーが含まれることになる。同じ名前のフィールドが複数存在する場合は、ユーザーを混乱させる可能性があります。ラベルを追加したり、count メジャーの名前を変更したりして、カウント対象のオブジェクトを示すことで、混乱を防ぐことができます。他にも、ディメンション グループなどで [作成日] や [更新日] などのフィールドにご注意ください。
  • type: yesno のフィールドにはわかりやすい名前を付けます。たとえば、商品が返品されたかどうかを示すフィールドには、[返品済み] ではなく [この商品は返品されましたか？] という形式で名前を付けます。
  • 比率にはわかりやすい名前を付けます。たとえば、[注文の割合] よりも [購入者あたりの注文数] のほうが明確です。
  • フィールドには一貫性のある名前を付け、モデル全体で一貫した値を使用します。value_format パラメータまたは value_format_name パラメータを使用して、通貨記号、パーセンテージ、小数の精度などの書式設定を数値フィールドに適用すると、すべてを明確にできます。

類似するフィールドをグループ化し、使いやすくする

  • group_label パラメータを使用して、個々のビュー、または複数の関連する結合済みビューのディメンションやメジャーを統合します。たとえば、すべての地理情報を [地理] グループにまとめることで、フィールド ピッカーで、アルファベット順に一覧表示するのではなく、住所や地域に関するすべての情報をまとめて表示できます。
        dimension: city {
      group_label: "Geography"
      type: string
      sql: ${TABLE}.city ;;
    }

    dimension: country {
      group_label: "Geography"
      type: string
      map_layer_name: countries
      sql: ${TABLE}.country ;;
    }

    フィールド ピッカーの [地理] ラベルでグループ化された都市と国のディメンション

  • view_label パラメータを使用して、大規模な非正規化テーブルを分割します。フィールド内の view_label パラメータを使用すると、フィールド ピッカー内で、フィールドを論理的に個別の見出しにグループ化できます。多数のフィールドを含む大規模な非正規化テーブルは、操作しにくい場合があるため、左側の Explore フィールド ピッカーでは複数のビューがあるような錯覚を与えます。

最初はユーザーにあまり多くの情報を公開しないようにする

  • 最初の Looker のロールアウト時には、あまり多くの情報をユーザーに提供するのは避けます。最初は簡潔に始め、次第にオプションを追加していく。 すべてのテーブルまたはディメンションとメジャーを一度に公開する必要はありません。最初に最も重要なフィールドを公開し、その後ビジネスユーザーがデータの活用に習熟するに従い、機能を追加していきましょう。
  • ユーザー インターフェースで、不要なディメンションは非表示にします。ユーザー インターフェースで使用されないディメンション（ID フィールド、データベース更新日など）には、hidden パラメータを使用します。
  • Explore と結合で fields パラメータを使用して、ユーザーが使用できるフィールドの数を制限します。含まれるフィールドは、Explore に関連するフィールドのみにする必要があります。これにより、肥大化を軽減し、ユーザー エクスペリエンスを向上させることができます。hidden パラメータとは異なり、field パラメータでは Explore ごとにフィールドを追加または除外できます。
  • Explore の hidden パラメータを使用して、特定の Look、ダッシュボード タイル、フィルタへの情報入力のみに使用される Explore は非表示にします。ユーザーによる探索を意図していない Explore は、ユーザー インターフェースには表示されません。
  • Explore の数を最小限に抑えながら、ユーザーが必要な情報に簡単に到達できるようにします。ユーザー層の異なる複数のモデルに Explore を分割し、各ユーザー グループが利用できるオプションを制限することを検討してください。最適な Explores 数はそれぞれのビジネスによって異なりますが、Explores の数が多すぎるとエンドユーザーを混乱させがちです。[Explore] のプルダウン メニュー内で Explore を効果的にグループ化できるように、モデル内の Explore で group_label パラメータを使用することを検討してください。

説明を追加して、使用するフィールドと Explore をユーザーが把握できるようにする

  • ディメンションとメジャーで description パラメータを使用し、モデル内で利用されるロジックや計算に関する補足情報をユーザーに提供します。この方法は、複雑なロジックや計算が利用されているディメンションとメジャーの場合は特に重要です。とはいえ、シンプルなフィールドの説明文についても検討し、ユーザーがその背後にある定義を理解できるようにすることをおすすめします。
  • ユーザー向けに Explore の説明を定義します。各 Explore に簡単な説明を追加し、その Explore の目的と使用するユーザー層を指定します。

一般的なワークフローを Looker に組み込む

  • 関連するすべてのメジャーに drill_fields を追加します。ドリル フィールドを使用すると、ユーザーは集計値をクリックして詳細データにアクセスできます。set パラメータを利用して、ビュー内の任意の数のメジャーに適用できる再利用可能フィールドのセットを作成します。
  • すべての階層ディメンションに drill_fields を追加します。たとえば、都市の drill_field を都道府県のディメンションに追加すると、ユーザーは都道府県を選択してから、その都道府県内の都市にドリルダウンできるようになります。こうした階層のドリルダウンは、時間のディメンション グループ内に自動的に適用されます。
  • ユーザーが簡単に操作し、他の Looker ダッシュボードや、Looker 以外のシステムまたはプラットフォームにフィルタを渡すことができるリンクを設定します。ドリルダウンでフィルタを渡す例については、link パラメータのドキュメントをご覧ください。