2 ヶ月かけて Looker Studio ダッシュボードを整理した話

オープンロジでは Looker Studio によりダッシュボードを作り、日々様々なデータを可視化して、業務に役立てています。コードを書かずに簡単にグラフを作ることができるため、事業部を中心として幅広く使われています。日々の数値のモニタリングに加えて、プロダクトとして開発される前に集計機能のモックを作って試験的に運用してみたり、関連会社へのデータ提供など、目的も様々です。2 ヶ月くらいかけて、260 件ほどのダッシュボードの整理を行ったので、その記録を残しておきます。

進捗

ダッシュボードの整理は以下のように進みました。最初は BigQuery のアクセス履歴から 100 件ほどのダッシュボードを抽出して整理を開始し、7/31 に Google Workspace の管理ログからダッシュボードを抽出したことで、整理対象が 60 件ほど増加しました。8/7 ごろに昔退職した 5 名のダッシュボードを削除したことで、さらに 100 件増えて、最終的には 260 件に膨れ上がりました。まだ整理は終わっていませんが、対象者にリマインドを送る作業だけになっています。

ことのはじまり

かねてより、様々な目的で多くのダッシュボードが作られ、社内外で活用されていることはわかっていました。また、その中には、試験的に作られたが既に役割を終えたダッシュボードも数多く存在していると考えていました。この残留ダッシュボードにより、いくつかの問題が発生していました。

• 管理・運用の手間：ユーザーが見ているかわからないダッシュボードでも、運用されている可能性がある以上、完全に放置することはできません。ごく稀にしか見ないユーザーの問い合わせに対応する手間を考えると、ユーザーと調整してダッシュボードを削除するという選択もあります。開発工数は限られているので、重要なダッシュボードに管理を集中する必要があります。
• 無駄なクラウドコスト：Looker Studio にはクエリの定期実行機能があり、使われていないダッシュボードでも BigQuery にクエリが発行され、クラウド料金が発生することがあります。さほど大きな金額ではないのですが、無駄なコストであることに変わりはありません。
• 退職者の Google アカウントの残留：退職者が利用中のダッシュボードのオーナー権限を他の社員に引き継がなかったため、Google アカウントを停止できず、アカウントが残り続けているケースがありました。パスワードはリセットしているので、セキュリティ上の大きな懸念はないですが、Google に支払う利用料が無駄ですし、アカウント管理者としては気持ちの悪い状態です。

これらの問題があることは、何となく察してはいたのですが、全体像を掴めていませんでした。把握しにくくなっている一番大きな要因は Looker Studio ダッシュボードは基本的に個人アカウントに紐づいて作られるので、一元的に管理する方法がありません。管理権限でアクセスすると、他の社員が作ったダッシュボードを一覧画面で見られるような機能があれば良いのですが、あいにくそれはできません。Looker Studio Pro などを契約すれば解決できそうですが、現状弊社ではフリープランだったので、とりあえず既存ダッシュボードを何とかする必要がありました。

ダッシュボードのリストアップ

まずは、稼働中のダッシュボードをリストアップする必要があります。弊社の場合、多くのダッシュボードは BigQuery にアクセスしているので、BigQuery のアクセス履歴（JOBS ビュー）からダッシュボードリストアップすることにしました。半年間で約 100 件のダッシュボードからアクセスがあることが判明し、「だいぶ多いな...」と思ってちょっと元気がなくなりました。

その後、1ヶ月後くらいに情シスから Google Workspace の管理ログへのアクセス権をもらい、管理ログからダッシュボードの抽出を行いました。この作業により追加で 60 件のダッシュボードを発見し、絶望しました。

BigQuery の JOBS ビューを使ったリストアップ

BigQuery のアクセス履歴は INFORMATION_SCHEMA.JOBS ビュー から取ってくることができますが、Looker Studio 経由の場合は labels カラムにアクセス元のダッシュボードの情報が入ります。以下のクエリで、特定の期間で BigQuery にアクセスしたダッシュボードをリストアップできます。

SELECT
  job_id
  , user_email
  , query
  , (
       SELECT ANY_VALUE(l.value)
       FROM UNNEST(labels) l
       WHERE l.key = "looker_studio_report_id"
    ) AS looker_studio_report_id
  , (
       SELECT ANY_VALUE(l.value)
       FROM UNNEST(labels) l
       WHERE l.key = "looker_studio_datasource_id"
    ) AS looker_studio_datasource_id
FROM `{project}.region-{region}.INFORMATION_SCHEMA.JOBS`
WHERE state = "DONE"
  AND parent_job_id IS NULL
  AND creation_time BETWEEN "2024-01-01T00:00:00+0900" AND "2024-03-01T00:00:00+0900"

looker_studio_report_id がダッシュボードの ID になっており、URL は https://lookerstudio.google.com/u/0/reporting/{looker_studio_report_id} となります。

ちなみに、BigQuery のアクセスユーザー (user_email) はダッシュボードの閲覧者ではないことがほとんどです。Looker Studio のデータソースには「認証情報」という設定項目があり、BigQuery に代理でアクセスするユーザーを指定できます。デフォルトではデータソースの作成者の認証情報が使われるため、閲覧者が誰であっても、作成者の権限でアクセスされます。

認証情報は以下の 3 種類から選択することができ、それぞれ user_email に記録される情報が変わります。

• 特定の個人アカウント
• 閲覧者
• Google Cloud サービスアカウント

Google Workspace の管理ログによるリストアップ

管理ログについてはこちらの記事が詳しいです。

https://glass-inc.jp/media/looker-studio-ga4-user-level-analytics/

管理ログを使うことで、BigQuery にクエリが発行されていないダッシュボードが抽出できる他、閲覧者のメールアドレスや削除・編集のログが確認できます。一番精度が高い情報ですが、直近半年のログしか閲覧できないため、半年間アクセスがないダッシュボードは発見できません。

ガイドラインの策定

何らかの形で不要なダッシュボードを一掃したとしても、ダッシュボードは日々作られるため、何ヶ月か経てば元の状態に戻ることは明白です。そこで、ダッシュボードのお掃除の前に、ダッシュボードが管理しやすくなる仕組みを用意する必要があります。今回は Looker Studio でダッシュボードを作る際のお作法をガイドラインとして明記し、ダッシュボードの作成者に普及する方針にしました。

オープンロジのいいところは事業部の方が自発的にダッシュボードを作り、データを可視化・分析している点です。エンジニアを介さずに SQL を書いてダッシュボードを実装できる状態は組織として大きな強みであり、厳しいガイドラインを設けることでその強みを潰さないか懸念がありました。色々な方と相談した結果、ガイドラインには大まかに以下のような内容を盛り込み、必要に応じて都度見直す方針にしました。

• ダッシュボード管理用スプレッドシートにオーナーや利用者、利用目的、運用状況を記載すること。
  • 管理用スプレッドシートを見れば、どんなダッシュボードがどのように使われているか一覧してわかるようになります。
• Looker Studio 管理用の Google Group に対して、編集権限を付与すること。
  • Google Group には Looker Studio の管理に関わる人が入っており、一括で管理者に編集権限が付与できる仕組みです。
  • 管理者メンバーを Google Group でまとめることで、管理者メンバーの変更があっても、ダッシュボードを編集してアクセス権限をいちいち変更しなくてよくなります。
• データソースの認証情報をサービスアカウントに変更すること。
  • データソースの認証情報が個人アカウントだと退職したときに権限変更が面倒なので、作成時にサービスアカウントを指定することにしました。
  • BigQuery に対してサービスアカウントによる Read 権限をつけておくことで、従来通り Looker Studio から BigQuery にアクセスできるようになります。
• ダッシュボードの引き継ぎ手順について明記した。
  • ダッシュボードのオーナー権限を他者へ委譲する方法について、説明しています。
  • 自分がオーナーのダッシュボード一覧を表示したとき、全てのダッシュボードが存在しない状態にしてして欲しい、という旨を記載しました。
• ダッシュボードに関する問い合わせ先について明記した。
  • いままで、問い合わせ先が不明確で、情報や依頼が錯綜してやや混乱気味だったので、どういうときに誰に連絡するか明記しています。
  • 基本的に、ダッシュボードへの機能追加や質問はオーナー（ダッシュボードを作った主に事業部の人）が責任を持ってもらう方針にしています。
  • オーナーが対処できない依頼や BigQuery, Looker Studio の使い方全般はデータチームが対応することにしました。

正直、簡単にガイドラインを守ってもらえるとは思っていません。今後棚卸しの中で、上記のガイドラインを守っていないダッシュボードを発見した際はその都度布教していくつもりです。

既存ダッシュボードの整理

ダッシュボードの分類

ダッシュボードをリストアップした後、直近数ヶ月くらいのアクセス状況を見て、以下の 4 パターンに分類しました。

• 削除予定
  • 全くアクセスされていないため、使われていない可能性が高い。
• アクセス制限
  • 多少のアクセスはあるが、積極的に使われている可能性は低い。
  • まだ使われている可能性もあるので、オーナー以外のアクセス権を剥奪し、2 ヶ月間様子を見る。その間にユーザーから連絡があれば、ダッシュボードの権限を元に戻し、何の連絡もなければ削除する。
• ユーザーに利用状況を確認
  • お客様など社外からアクセスがあるが、重要な目的で使っているわけではないのであれば、削除したい。
  • オーナーもしくは利用実態に詳しい人が、ユーザーに利用状況をヒアリングする。
• 利用中の可能性が高い
  • 一定のアクセスがあり、ダッシュボードは利用されている可能性が高い。削除は難しそう。
  • 実際にどう使われているかは別途ヒアリングを行う。

オーナーへの依頼

ダッシュボードのオーナーに対して、パターン別に以下のような依頼・対応を行いました。すぐに対応してくれる方もいれば、多忙でなかなか対応が難しい方もいるので、何度も繰り返しメッセージを送りました。退職した人から引き継いだダッシュボードを持っている場合もあり、そもそも自分がオーナーであることを認知していない方もいました。

• 削除予定
  • ダッシュボードを削除して欲しいが、もし利用中なら別途連絡して欲しい。
• アクセス制限
  • オーナー権限を私に対して委譲する。
  • その後、私がアクセス制限などの対応を実施する。
• ユーザーに利用状況を確認
  • 現オーナーからユーザーに利用状況を確認して欲しい。
• 利用中の可能性が高い
  • 私から現オーナーに対して、利用状況や経緯をヒアリングする。

利用実態のヒアリング

「利用中の可能性が高い」ダッシュボードについては、オーナーである事業部の方にアポを取り、以下の項目をヒアリングしました。

• 利用者：誰が使っているか？
• 利用頻度：どれくらいの頻度で使っているか？
• 作成された経緯：なぜダッシュボードが作られることになったのか？
• 利用目的：ダッシュボードを閲覧し、ユーザーはどのようなアクションに結びつけているか？

お忙しい中、お時間を作っていただいた事業部の方には感謝しかありません。ヒアリングの結果、運用中のダッシュボードの多くは社外で利用されており、細かい利用目的までは掘り下げられませんでした。利用実態を大まかに把握することはできたため、社内のオーナーへのヒアリングで完結としています。

退職者のダッシュボードの移管・削除

退職者がダッシュボードのオーナー権限を他の社員に委譲していないケースもあります。ダッシュボードが利用されているため、5 名ほどの退職者のアカウントを削除できていませんでした。Google の管理権限を持っている情シスであれば、退職者のアカウントにログインしてオーナー権限を変更することはできるのですが、ダッシュボードが 100 件以上あり、どのダッシュボードが使われているか情シス側が判断できず、オーナーの移管作業を行えない状態です。ちょうど私がダッシュボードの利用状況を可視化したこともあり、情シスからの依頼で退職者のアカウントへのログイン権限をもらい、一気にダッシュボードを削除しました。