担当者の退職で Looker Studio のレポートが壊れてしまう問題への対処法
風音屋の兼業データアナリスト、星野（@mochigenmai）です。
Google Workspace 利用者であれば、BI ツールとして Looker Studio を使う機会も増えてきたのではないでしょうか。 無料で簡単に利用でき、社内外に共有できる Looker Studio は、組織内の誰かが使い出すと、いつの間にか色々な場所で見かけるようになっています。
しかし、Looker Studio を大規模に利用していくと様々な問題に出くわします。 例えば、Looker Studio を利用していく中で「作成者の退職でレポートが壊れた」経験はありませんか？（風音屋でもよく相談を受けます）
Looker Studio Pro では共有スペースでのコンテンツ管理をサポートしていますが、ほとんどの方がフリープランを利用されていることと思います。 Looker Studio のフリープランではデフォルトのリソースは作成者のアカウントに紐づいており、その個人が組織を離れると、リソースへのアクセスが難しくなります。 Google Workspace 管理者が復旧しないと、最終的に自動削除されます。
この記事では以下の4つの観点を通して Looker Studio のフリープランにおける「作成者の退職でレポートが壊れた」問題への戦い方の一例を紹介します。
- レポートのリソースを適切なアカウントに紐付ける
- 離任フローを整備する
- レポートの利用者を特定する
- 定期的な棚卸を行う
今回、調査にあたって@na0fu3yさんに協力していただきました。
レポートのリソースを適切なアカウントに紐付ける
Looker Studio で注意して管理すべきリソースは主に3つです。これらのリソースは必ず誰かに紐づく必要があります。
- レポート（グラフのまとまり）
- データソース（グラフに使われるデータをどこからとってくるかの設定）
- 認証情報（データソースのアクセスには誰の権限を使うか）
レポートとデータソースは、作成者の Google アカウントに紐付きます。 作成後に他の Google アカウントに移譲もできます。 認証情報は、オーナーか、閲覧者か、サービスアカウント（BigQuery のみ利用可能）から選ぶことができます。
基本的に非個人に紐づけるのが管理上楽ですが、次のように考えるのが良いでしょう。
レポートとデータソースを誰に紐づけるか
原則、作成者にレポートとデータソースの権限を紐づくため、そのまま何もしないのが良いでしょう。 退職時には、管理者を移譲するフローを明記しておきましょう。 そうすることで Google Workspace 管理者は、削除されたアカウントに紐づいたレポートやデータソースの管理者再割り当てをスムーズに実施できます。
小規模かつ Google Workspace の管理力がない組織の場合は、共有（非個人）の Google アカウントを作成し、レポートやデータソースを、作成したアカウントに移譲すると便利です。 Google Workspace では共有アカウントは推奨していませんが次のようなメリットがあります。
- 退職時のアクセス不能な状態を避けることができる
- 各個人がレポートやデータソースの移譲先が明確にできる
ただし、個人のレポート作成を禁止できないので、みんなに運用を呼びかける必要があります。 Looker Studio log events や Google Workspace 管理者権限でレポートのオーナーが個人に紐づいたままではないかチェックすると良いかもしれません。 （そこまでできるなら、Google Workspace 管理業務に時間を割くほうが良さそうですが）
認証情報を誰に紐づけるか
認証情報はオーナー、閲覧者、サービスアカウントの３種類から選びます。 以下のような観点で考えるのが良いと思います。
- 誰でも同じデータが見える全社レポート
- 原則的にはサービスアカウントが好ましい
- 一時的に見せるだけであればオーナーでも可
- 閲覧者によって見せるデータを変えたり見えないようにしたい
- 原則的には閲覧者が好ましい
- データの一部をフィルタして見せるなど、データ基盤の実装上必要な場合はサービスアカウント
認証情報の種類によって以下のようなメリデメがあります。
| 認証者 | メリット | デメリット |
|---|---|---|
| オーナー | 全員が同じデータを見ることができる。また、キャッシュが効きやすい。 | 認証情報を持った個人の退職時に、データの認証情報のアップデートが必要。 |
| 閲覧者 | 退職時に何もしなくてよい。閲覧者によってデータを出し分けることができる。 | Google アカウントなしだと閲覧できない。また、キャッシュが効きにくい。人によって閲覧可否や表示内容が異なるため、管理者の手間は増える（権限確認の依頼など）。 |
| サービスアカウント | 退職に強く、全員が同じデータを見ることができる。また、キャッシュが効きやすい。 | BigQuery のデータにしか利用できない。 |
離任フローを整備する
異動や退職で担当者が組織から離れる際に、スムーズに引き継ぎができるように手順を整備しておきましょう。 レポートや認証情報に比べて特にデータソースの引き継ぎミスは後々問題になりやすいと考えられます。 その点を考慮して以下の優先度で引き継ぎ先を決めると良いのではないかと考えます。
- データソースの管理者
- レポートの利用者（利用頻度が高い人）
- Google Workspace 管理者
上記の引き継ぎ先の人が最低限困らないように、以下のような観点を記載したドキュメントを作成するようにしましょう。 社内独自で起きうる問題を引き継ぎ先の人とすり合わせを行い、それに対する対応などもドキュメントに記載することをオススメします。
- レポートの作成背景と簡単な更新遍歴
- 作成背景と違う用途で運用されないように意思を引き継ぐ
- データソースのメンテナンス方法
- 引き継ぐ人がデータソースへの理解ができるようにメタデータを記載する
- データソースの責任者が他者の場合、問題が起きた時の問い合わせ先を明確にする
- 認証情報の設定理由
- 作成背景をもとに記載する（データセット全体に制約があるのか、特定のカラムに制約があるのかなど）
レポートの利用者を特定する
レポートの主な利用者と編集者を特定しましょう。 今後もメンテナンスを続けてくれる編集者に対して、管理者権限を移譲するのが良いと思います。
レポートの閲覧者権限が絞られている場合はそちらで特定し、絞られていない場合には、 Looker Studio log events から実質的な閲覧者を特定します。 Looker Studio log events を用いると、誰がレポートを閲覧したか、編集したかログから特定できます。 6ヶ月以上遡りたい場合や、Google Workspace 管理者以外がログを見たい場合には、BigQuery エクスポートも検討しましょう。
Google Workspace 管理者は、主要な編集者にレポート管理者権限を移譲しましょう。 編集者がいなかった場合は、よく閲覧している人に移譲するか、閲覧者の許可をとって捨ててしまいましょう。
定期的な棚卸を行う
Google Workspace 管理者がやること
- 退職者がオーナーのレポートやデータソースがないか確認して、必要なら別な人にオーナー権限を移譲する。
- Looker Studio log events を確認し、不要なレポートがあれば捨てる。また、重複しているレポートがあれば統合を促す。
LookerStudioを作成した担当者個人がやること
- 不要なレポートがないか確認して捨てる。
- Looker Studio log events を確認する。
- Google Analytics を仕込み、レポートが利用されているのか、ページやリンク単位で確認する。
- 不要なデータソースを捨てる。
- よく使っているレポートに紐づくデータソースの名前を整理する。
まとめ
今回は Looker Studio のフリープランにおける「作成者の退職でレポートが壊れた」という問題について、以下の4つの観点で対処する方法を紹介しました。
- レポートのリソースを適切なアカウントに紐付ける
- 離任フローを整備する
- レポートの利用者を特定する
- 定期的な棚卸を行う
レポートには以下3つのリソースがあり、これらを基準に引き継ぐための作業観点を列挙してみました。
- レポート（グラフのまとまり）
- データソース（グラフに使われるデータをどこからとってくるかの設定）
- 認証情報（データソースのアクセスには誰の権限を使うか）
また、レポートの主な利用者を特定する方法や定期的な棚卸についても紹介しました。 場合によっては紹介した作業内容や棚卸し方法が適用しづらいといったこともあると思います。 そんな時でも、レポートに関する3つのリソースを意識して最適なフローを考えてみてください。
最後に余談になりますが、Looker Studio Pro ではレポートを組織として管理でき、Dataplex のリネージに Looker Studio のコンテンツも取り込むこともできるようです。 ガバナンスに注力していく場合はフリープランからの乗り換えも検討してみてもいいかもしれません。
