見出し画像

Looker運用を２年続けて見えた課題と次の一手

443

こんにちは。マネーフォワード分析推進室の大塚です。
先月の記事ではササキさんが「マネーフォワードでなぜLookerを導入したか」について紹介しました。

この記事では2年（正確に言うと2.5年くらい）Lookerを運用する中でぶつかった課題についてこれからどうしていきたいかという話をしていきたいと思います。

運用改善自体は道半ばのためすでに実行したこととこれからやりたいことが半々くらいの記事になります。タイトルは私自身が観る将（観戦主体の将棋ファン）ということで「次の一手」としました。

Lookerの導入を検討している方やLookerを運用中で課題を感じている方の考えるヒントとなればうれしいです！

"たくさんの人"と快適にLookerを使うために

冒頭であげた記事でもご紹介した通り現在マネーフォワードでは事業と組織の数が増え続けています。
詳細は冒頭の記事に譲りますがざっとこのような状況です。

  • 幅広い事業ドメイン（法人向け / 個人向け / 金融機関向け…）

  • 法人向けのバックオフィスSaaSだけでも10を超えるプロダクト

  • 直近2年間で社員数が約倍増

この記事では事業と組織が大きくなったことになったことによって起こったことにフォーカスをあてていきます。

前提としてLookerは社内のプロダクトや各種ツールのデータを蓄積しているBigQueryに接続する形で活用しています。

多様な組織のLooker開発者と協働する

社内のデータ活用が進んだことで事業部のデータユーザが自らLookerを活用するシーンが増えています。

今までは分析推進室が中心にLookMLの記述とLookerでの可視化・分析双方を行なっていましたが、徐々に事業部のデータユーザーが自ら可視化・分析を進めてくださる事例が増えてきており、ここのステップを登っていくハードルをいかに下げるかということに向き合い始めています。

スケールし続ける組織におけるデータマネジメント:https://note.com/eassk/n/ndf12d0804621

組織が大きくなり、社内に多様なサービスが存在する中で分析推進室のみがLookerの開発をし続けるというのは現実的ではない状況となっていきました。
開発者が品質を保ちつつ効率よく開発していくためにやったこと＆これからやりたいことを２点ご紹介します。

LookML開発者ガイドラインの整備

最初はLookerの開発において重要な要素の一つであるLookML開発についてです。
今春に開発/保守/運用効率の向上と利用者の使いやすさ向上を主な目的に開発者ガイドラインをアップデートしました。

特徴的な点としてはなるべくBigQuery側に必要な処理を寄せるという方針を明示したということがあります。
この方針は後述の原則としてBigQueryの１テーブルに１つのViewを対応させることや派生テーブルは基本的に利用しないことなどのルールに反映されています。

派生テーブルなどLookerならではの機能が活用できないこともあるので各社方針がわかれるところではあるかなと思います。この方針の意図としては上流のテーブルに変更が入った際にBigQuery（SQL）にメンテナンスを寄せたい、Lookerを経由せずBigQueryに直接接続する他ツールからも同じデータを利用できるようにしたいというようなものです。

情報源をBigQueryに寄せていきたいという方針はSSOT（Single Source of Truth）にも基づいています。（詳しくは下記記事）

実際のガイドラインの内容について主なものを抜粋して記載します。

  • Viewファイルの作成単位

    • 原則としてBigQueryの１テーブルに１つのViewを対応させる

    • 派生テーブルは基本的に利用しない。（利用するのは一時的なもののみで永続的に利用したい場合はBigQueryにテーブルを作成する）

  • フィールド名（ディメンジョン・メジャー）の設定

    • ExploreでJOINが発生するviewについてはprimary_keyを必ず設定する

    • BigQuery上のテーブルにあるカラムと同一の場合は同名とする（自動生成の機能を利用してつくっておく）

    • メジャーの命名は集計関数に合わせたprefixを利用する

      • count_distinct：num_of

      • sum：total_

      • average：avg_

  • 利用者に配慮したルール

    • ExploreやLookML独自で定義したディメンション・メジャーには必ずdescriptionを書く

    • 類似の意味を持つ複数のフィールドが存在する場合はgroupパラメータを利用してまとめておく

    • 内部の処理のみに必要で利用者にとって不要なフィールドはhiddenパラメータで隠しておく

すでにLookMLの開発者ガイドラインの整備を検討している方はお気づきかもしれませんがこの内容自体にそれほど独自性があるわけではありません。
実際にクラスメソッドさんのまとめなどを通じてベストプラクティス参考にさせていただきながら作成しています。

後段の利用者増加にあわせ、descriptionの充実による使いやすさ向上という観点も重視しています。
これからもベストプラクティスが出てくると思うので参考にしていきたいと考えています。

ディレクトリ構造の再検討

LookML開発をしていて新メンバーから「このファイルはどのディレクトリにいれればいいですか？」という質問がよくでてきます。
小さいチームであれば非効率ながらも都度答えるやり方でも回っていたのですが、今後普段直接関わらないチームと共同で環境を使っていくとなると困ったことになります。

今メインで使っているプロジェクトのディレクトリ構造はとてもシンプルで、/Models以下にhoge.model.lkmlが複数存在し、その中でExploreを定義しており、/views以下に１つのviewが１つのhoge.view.lkmlの形で複数存在しています。

ディレクトリ構造も現在進行形で悩み中のテーマではありますが、まず利用者から遠い/views以下においてはBigQueryのテーブルとviewが1:1対応しているという原則を活かし、BigQueryのプロジェクト-データセットの階層と合わせて配置する方針をとろうとしています。
開発者にとってわかりやすい構造になるのではないかという狙いです。

他社のLooker管理者の方ともぜひお話ししてみたいテーマです。

より多くの社員にLookerを使ってもらう

教育コンテンツの充実

弊社では毎月Lookerの利用者が増え続けています。すべての方に直接レクチャするのは現実的ではないため社内Wikiに情報を充実させて各組織で立ち上げってもらえる方向にしていきたいと考えています。

デフォルト権限セットをもとにDeveloper（LookMLの開発を実施）、User（Exploreを活用した可視化）、Viewer（可視化の利用）の３つの権限ごとにどのような教育コンテンツを用意しているかご紹介します。

Developer向けについてはすでにSQLを使える方である場合が多く、LookMLの習得自体にはそこまで苦労しない印象です。Lookerの特徴について戸惑うことの方が多いため公式コンテンツをおすすめしています。

個人的には仮想環境で実際に触りながらLookMLを学べるGoogle Cloud Skills Boostの「Understanding LookML in Looker」がおすすめです（執筆時点では無料でした）

User向けについてはここ半年くらいで急激にアカウント数が増えており、もっとも教育コンテンツのニーズが高いところです。
Google Cloud Skills Boostの「Exploring Data with Looker」のエッセンスを抽出し日本語かつ社内データを用いて実践できるコンテンツ（Qiitaのものと扱っている操作は同じですが社内データを利用）を作成し展開しています。
分析推進室内ではオンボーディングの一環としてダッシュボードと同じものを一から再現するようなやり方もしています。

Viewer向けには活用が盛んな事業部の方が主導で「BIツールとは？」というところから伝え、フィルタやお気に入り機能など基本機能を解説するような資料を作っていただいています。
閲覧数が多いダッシュボードについてはダッシュボードごとの説明資料を作る場合もあります。

Lookerの使い所を見極める

Lookerのガバナンスの高さという特徴は管理者の方がメリットを感じやすく、利用者からすると価値が伝わりづらいところであると感じています。

Lookerとその他ツールの使い分けは議論中ではありますが、少なくとも「試行錯誤段階を終えていて」、「確認する人数の多いKPIを扱っていて」、「定期的にモニタリングすることが確定している」ダッシュボードであれば十分にLookerのメリットを享受できると考えLooker活用を推奨しています。

BIツール自体に馴染みのない方にとってはExcelやGoogleスプレッドシートと比べたメリットも伝わりづらいかと思うため、実際に触ってみていただいて良さを伝えています。

よく驚いていただけるのはlinkパラメータを活用してダッシュボード中の情報をもとに関連する社内システムにリンクできるような仕組みです。
例えば顧客のオンボーディングを管理するダッシュボードでフォローしたい顧客を見つけた時に管理コンソールにリンクできるようにすることで顧客の詳細情報をLookerダッシュボード中に表示することなく活用することができます。

さいごに

ベストなLooker運用に向けてはまだまだ手探り中の状態です。
この記事を見て興味を持っていただけた方は同僚のササキさんが2022年1月から3代目幹事を務めるLooker User Groupでぜひ情報交換しましょう！
下記ツイートのリンクからSlackに参加できます。


この記事が気に入ったらサポートをしてみませんか？