【エンジニアブログ】社内の分析レポートをLookerに移行した話！

はじめに

弊社が提供しているプロダクト・サービス「Rtoaster（アールトースター）」では、導入企業様のWebサイトの顧客体験向上のために行動データを蓄積して自動最適化などに役立てていただいております。蓄積されたデータをお客様のサイトパフォーマンスやレコメンド実績の確認、エンドユーザの理解促進にご利用いただけます。ご依頼があれば、弊社の経験豊かなスタッフが「Rtoaster action+（アクション・プラス）」の活用支援の一環で蓄積されたデータの集計可視化や分析結果の報告をさせていただいております。

この度、筆者が所属しているデータ基盤チーム（Rtoasterのログ・マスタデータを管理する開発チーム 過去の投稿はこちら）では、Rtoaster action+（以下action+）のデータ活用の支援で用いられるレポートを改善する取り組みを行っておりました。本投稿ではその経緯やレポート再開発で得た知見などについてご紹介したいと思います。

本投稿は以下の話題を含んでいます。

• 組織内でのデータ・指標の取り扱いが個別に独自発展していた背景
• 取り扱いの統一を図るために行った調整作業や試みたこと
• Lookerを採用した理由（データガバナンス、可視化機能）

そのためデータや指標管理に関わる仕事を行っている方や、業務効率向上のためのBIツール導入を検討中の方に興味を持ってもらえる内容となっているので、最後まで読んでいただければと思います。

背景

弊社で行っている業務の一つとして「action+の運用支援」があります。

action+を導入いただいた場合、運用担当者様は基本的にaction+を運用したご経験がない状態でaction+運用をしていただくことになるため、運用ノウハウが無かったり、action+の機能について把握できていない状態となります。そのため導入初期の段階では運用担当者様にaction+を使いこなしていただけますように、弊社のスタッフ「カスタマーサクセス（以下CS）」が運用支援を行っております。

運用支援の際に運用担当者様とCSで、Webサイトの訪問状況やaction+で設定したレコメンド施策のパフォーマンスなど（レコメンドを表示した回数・WebサイトでCVした回数など）を確認するレポートがあり、レポートで確認し合います。これを社内では「オンボーディングレポート」と呼んでいます。このオンボーディングレポートに対して、レポート開発関係者内で改善の要望があったため、この度データ基盤チームでレポートの再開発を行いました。

レポート改善の要望

レポート改善の要望としては以下の議題が挙がっていました。

• 利用観点（レポートに何が必要なのか？）の指標定義は適切に行われていたが、データ分析（レポート要件を満たす仕様か？）とシステム開発（レポート仕様を満たす設計か？）の観点も重視することで、より良いレポートになる可能性がある。
• レポート作成とレポート出力を効率化することで、CSの本来の業務である運用支援にもっと時間を割くことができるようになる（Excelでレポート出力をしていたため、手作業の工程があり出力に手間がかかっていた）
• レポート開発チームとシステム開発チームがそれぞれで指標定義を行っていたため、レポートとaction+で使っている用語や指標名に表記揺れが発生していた。（オンボーディング期間が過ぎたことにより運用支援がなくなり、運用担当者様自身で施策設定を行う際にどの指標を利用すれば良いのかを把握することが難しくなっていた）

これらの問題が発生していた理由としては、データ分析やシステム開発を行う職種の人間がレポート開発に積極的に関わることができておらず、CSにデータ活用の役割を任せてしまっていたことが原因でした。この原因により、特定のグループや職種だけで決められた指標定義が作成されたり、本来の業務範囲を超えた不得意な課題（ビジネス側の人間がシステム仕様を踏まえたSQLを実装するなど）に取り組まざるをえない状態になっていました。

改善の流れ

開発・運用体制の見直し
今回の問題を解決できるように「CSに任せきりではなくデータ分析者・システム開発者も関わるデータ活用」を目標として、レポート再開発時の関係性や今後想定している運用の流れを三者で協議しました。

協議の結果、それぞれの立場・役割を明確にして、それぞれがやるべきことに専念できる体制として

• CS）運用担当者様やCSが求めているレポートで実現したいことを社内関係者に伝える。運用支援業務。
• データ分析者）データの分析においてのレコメンド評価方法のチェック。指標の可視化設計。
• システム開発者）要件やデータ仕様を踏まえた指標設計・実装。データ管理。

という関係性を決めて、レポート再定義や指標再定義を行いました。

用語集の作成
指標定義や集計仕様を決めていく段階で、「PV数とは実際には何を数えているものですか？」、「CVの定義が自分の想定と違う」といった指摘があり、人や職種によって認識にズレがあることに気がつきました。

そのためはじめに、三者のデータ認識を合わせるための用語集の作成をしていきました。

（このビジネス側とシステム開発者との認識がずれているという問題は、古今東西どこの組織においても存在する問題でありさまざまな分野で解決方法が提案されています。例えばドメイン駆動設計という開発フレームワークではビジネス側とシステム開発側の認識を合わせるためにドメインモデルやユビキタス言語を用いたり、データマネジメントにおいては組織内のデータ管理を統制してデータ認識の齟齬が生まれない仕組みを作るデータガバナンスという概念があります。今回の取り組みではこれらの手法を参考に用語集を定義していきました。）

単に用語集を作成する場合では「定義と用語」を1対1で紐づけて認識がズレないように明記すれば良いのですが、今回のケースではCS・データ分析者・システム開発者といった立場が異なる人が関わるため、必要な知識が職種によって異なってきます。（指標設計を行うシステム開発者は細かいシステム仕様を網羅していなければ正しいSQL処理が実装できませんが、レポートを利用する運用担当者様やCSは集計が指し示す内容が把握できていれば最低限のレコメンド施策の評価はできます。）
定義を厳密にしすぎて細かいシステム仕様までも用語集に書き込んでしまうと、CSが定義を理解しきれずにレポート作成に関わりにくくなり当初に考えた運用体制が構築できなくなることにもつながります。

そのため今回の用語集では以下のような知識レベルに切り分けて、自分はどのレベルまでを把握しておけば良いのかを判断できるようにしました。

• [利用者レベル] 細かい仕様は理解しておく必要はなく、出力されている値が何を示しているのかをある程度把握できている状態（レポートを利用できるレベル）
• [分析者レベル] データ仕様や集計仕様を理解して、具体的に何を集計しているのかを把握できている状態（レポートを使った分析ができるレベル）
• [実装者レベル] システム面での細かい挙動やレアケースを理解して、仕様を満たす集計クエリの設計・実装ができる状態（レポート実装ができるレベル）

Lookerでレポート実装
三者での認識が揃い用語定義や集計方法が固まってきたので、それぞれの指標やレポートをLookerというサービスを利用して実装しました。

Lookerを採用した理由としてはLookerはデータガバナンスを保つためのサービスで、組織内のデータや指標を管理する仕組みが用意されているためです。（さらにLookerではデータ・指標管理だけでなく可視化機能もあるため、BIツールとしてオンボーディングレポートの構築や運用が楽になることも決め手となりました。）

Lookerでは以下の図のように、指標Aの定義が組織内で曖昧にならないようにLookerで定義した指標を利用するようになるので一定のデータ品質を保ちつつ利用規模を大きくすることができます。またLookerのメリットは品質面だけでなく各役割の人間にも恩恵があり

• [利用者（CS・運用担当者様）] 自分たちで集計のためにSQL実装を行う必要がなく、考察作業に集中ができる
• [分析者（データ分析者）] 開発にSQL実装を任せることができたり自分が把握していないレポートが展開されることがなくなるので、可視化設計に集中できる
• [実装者（システム開発者）] 実装したSQLがコード管理されるので、実装レビューがしやすくなる（LookerMLという専用言語で実装するので通常のSQLよりも煩雑にならなくなります）

Looker導入により、これまでのようにCSがSQL実装作業やレポート出力作業を行うことがなくなり、レポート改善の要望がデータ分析やシステム開発に届くようになりました。

レポート完成と今後

作成したレポートは現在社内展開中で、新定義のレポートの説明をCSに向けて行っている最中です。運用していく中で要望や改善点などが挙がってくると思うので、上記の運用体制で改善・改変に取り組んでいきたいと思います。

また今後の展開としては、オンボーディングレポートだけでなく社内の他レポートとの指標共通化や、Rtoasterプロダクトの集計定義との共通化も行って、導入企業様の運用がより簡単により効果的になるように改善を行っていきたいと思います。