データ活用の知見や困り事を共有する「突撃! 隣のダッシュボード」会をやっている話

こんにちは。MackerelチームにおいてCRE（Customer Reliability Engineer）をしているid:syou6162です。主にカスタマーサクセスを支えるデータ基盤の構築や、データ分析を担当しています。

最近、はてな社内のさまざまなチームでデータ活用が進んでいます。しかし、そういったデータ活用の知見は、それぞれのチーム内でとどまってしまいがちです。この記事では、チームを横断したデータ活用を推進するため、昨年の秋から開催している「突撃! 隣のダッシュボード」という会の企画を紹介します。

データ活用についてラフに議論できる場所

データ活用の知見は、なぜチーム内にとどまってしまいがちなのでしょうか。例えば知見を広めるために、各チームでデータを可視化しているダッシュボードをチーム外のメンバーにも見えるようにすることが考えられます。

しかし、チーム外のメンバーがそれだけで知見を得ることは、以下のような要因から難しいでしょう。

  • ダッシュボードを読み解くには、そのチームのドメイン知識が必要
  • 活用しているデータソースや、データパイプラインまで見れることはほぼない
  • 重要個人情報を含むダッシュボードは、公開範囲が制限される

特にデータソースやデータパイプラインでどういった工夫や苦労があったかについては、当事者でなければなかなか分かりません。

そこで、はてな社内で利用されているダッシュボードの実例を紹介しあう会を企画し、以下が達成できることを目標にしました。

  • 各チームにおけるダッシュボードの作り方や、その活用状況、必要な情報をどのように集めているか？ などをラフに議論する場を作る
  • 社内で「誰がどういったデータ活用をしているか？」を知ることで、チーム間でデータ活用の相談をよりしやすくする
  • 技術面だけでなく、よいチーム文化やコミュニケーションの取り方も広めていく

なお、データ活用には大きく分けて、人間のためのもの（例えば、施策のためのペルソナ設定）と、機械のためのもの（例えば、機械学習を用いたパーソナライゼーション）の2種類が存在します。この企画では、主に前者を取り扱いました*1。

ダッシュボードの事例：種類といくつかの観点

こうして企画した「突撃! 隣のダッシュボード」会は、回ごとに1つのチームが活用中のダッシュボードについて発表するリモートのミーティングで、現時点では第5回まで開催されています。

メンバーとしてはCREをはじめとするエンジニアのほか、デザイナー、プランナー、営業、営業事務、サポート、ディレクターなど、多様な職種の方が参加してくれました。紹介されたダッシュボードも多岐にわたりますが、大きく次の3種類に分けられます。

  1. チームで定期的に見返すダッシュボード
  2. 施策を定量的に検証するダッシュボード
  3. アイディアを生み出すダッシュボード

定期的に見返すダッシュボードとは、例えばチームの「KPIダッシュボード」で、その場合は売上やMAUが中心になります。そのほか、定量的にヘルスチェックをしたり、異常を検知する目的のものもあります。

施策を定量的に検証するダッシュボードの例としては、マーケティング施策の効果検証や、新規機能リリースの効果検証があります。

アイディアを生み出すダッシュボードは、定期的に見るというより、少しくらい雑でもいいのでどんどん分析していく用途のものです。スプレッドシートを駆使したものだったり、Jupyter Notebookを使ったものも多く見られました。

会では、こういったダッシュボードを題材に、大きく分けると「設計」「作成」「活用」という3つの観点から、発表と議論がありました。

ダッシュボードの設計という観点から

ダッシュボードの設計においては、主にそのダッシュボードを作る目的や背景という点が紹介されました。

まず「誰がいつ、どういう目的でダッシュボードを見るのか？」を明らかにすることによって「どういったダッシュボードを作るといいか？」がいっそう明確になります。また、さまざまなチームや職種の参加者がいるため、背景にあるコンテキストを把握することもある程度は必要です。

ダッシュボードの作成という観点から

ダッシュボードの作成においては、主に「どういったデータソース群をもとに、データをどう加工しているか」という点が紹介されました。

データソースやデータの加工は、作成におけるHOWの部分です。例えば、裏側に巨大なスプレッドシートが隠れていたり、データの入力にコストがかかりそうなソースが存在したりと、ダッシュボードの作成や管理で困っている点などが共有されました。

ダッシュボードの活用という観点から

一方、ダッシュボードの活用においては、主に「作成したダッシュボードでもともとの目的を達成できたのか？」という点から語られました。

達成できたのであれば、どういった工夫が特によかったかを共有します。例えば、KPIの分解やファネルの設計がしっかりできたおかげで、ぱっと見ただけでどこがボトルネックになっているか分かるようなダッシュボードがありました。

達成できていない場合は、「なぜ達成できなかったのか？」を技術的な面や文化的な面から振り返ってみます。技術的な面では、ダッシュボードが重すぎて使いものにならなかったり、ダッシュボードを更新する手間が大きすぎて古びてしまった事例がありました。文化的な面では、ダッシュボードを作ったはよいものの、仮説検証のプロセスをあまり回すことができず、活用まで至らなかったダッシュボードがありました。

ダッシュボードの育て方

ダッシュボードも、最初から現在の形をしていたわけではありません。あるメンバーはダッシュボードが現時点に到達するまでの歴史、紆余曲折を紹介してくれました。

このように「データ活用を進めはじめて、どういった過程を経て、今に至っているか」といったことが他チームの事例として共有されていると、データ活用のフェイズを考える際に次のようなことが期待できます。

  • 自チームが今どのフェイズにいるか分かる
  • どういったことを実施すれば次のフェイズに進めるかが学べる

どのチームでも課題になることがあれば、資料を書いておいたり、ツールを作成するといった整備によって、社内のデータ活用の高速道路を作ることができます*2。

データ活用の課題感と解決に向けた動き

会を通して、メンバーが感じている課題感も明らかになってきました。データ活用における代表的な課題と、それを解決するため社内で実際に行われている取り組みを紹介します。

データ活用の3つの壁とメンバー固定化されがち問題

参加者の中から「実際にデータ活用をしようと思ったときに、以下の3つの壁があった」という声がありました。

  1. 必要なデータが正しく存在するか？
  2. データを正しく取得できるか？
  3. データを正しく分析できるか？

そもそもデータが存在しなければ、データ活用はできません。また、存在しても正しくなければ、後段の分析も誤ったものになります（1つ目の壁）。

次に、取得できるデータは分析の意図に合っている必要があります。企画や分析のスピードを上げたければ、自分で正確なSQLを書ける必要があります（2つ目の壁）。

データを正しく取得できても、見るべき統計量が誤っているなど、データ分析が正しくできなければ、意思決定も誤ったものになります（3つ目の壁）。

さらに、こうした壁を乗り越えられるメンバーはいるものの、まだまだ限定的であるため、データ活用ができるメンバーは固定化されがちだという問題がありました。

データ活用を固定化させないためにも、多くのメンバーがこの壁 （特に2と3）を越えられるように、社内でSQLレクチャー会や、データ分析レクチャー会が開催されるようになりました。

SQLやデータ分析は書籍もたくさん出ていますが、社内レクチャー会ではサンプルデータやダミーデータではなく、実務で使う馴染みのあるデータをもとに練習課題が設計されています。そのため、より素早く力を付けることができたり、モチベーションも保てたという声がありました。

学習サイクルがあまり早く回せていない問題

データ分析単独で価値が生まれることは、まれです。分析を通じて課題が明らかになり、その課題を解決するための施策やプロダクト開発が行なわれた結果、課題が解決され、価値が生まれます。うまく課題が解決できないことも当然あるため、試行回数をいかに増やせるかも重要です。

こうした一連のサイクルを「より高速に回せるようになりたい」という課題感を持っているチームがありました。

スコープがデータ活用より少し広いですが『DMM.comを支えるデータ駆動戦略』という本の輪講がチーム内で始まったり、アジャイルやスクラム開発に興味があるメンバーが集まっているサブ会に相談するなど、データ活用の文脈にとどまらず、改善を進める活動が始まっています。

継続的に見ることができない問題

ダッシュボードができたものの、ディレクターや企画職のメンバーしか普段数字を見ておらず、なかなかチーム内に数字を見る文化が定着しない、という課題も挙げられました。見るメンバーが少ないと、ダッシュボードも時間がたって朽ちてしまい、見るメンバーがさらに減ってしまうという悪循環が起きてしまいます。

チームのあらゆる職種の人が数字を見るための第一歩として、KPI指標をSlackなどのコミュニケーションツールに定期的に通知するといったアイディアが共有されました。指標に変化があった際にもメンバーに積極的に共有することで、数字をベースとしたユーザー理解をチーム内で深めようという動きも進みつつあります。

企画をやってよかったこと

ダッシュボードについて発表し議論する場を設けることで、データ活用の課題感やその解決策を明らかにできました。そういった直接の成果だけではなく、この取り組みを通してよかったことがいくつかあります。

多様な視点の意見がもらえる

さまざまな職種の人が参加してくれたこともあり、データ活用に関して多様な視点の意見をもらえたことが、よかったこととして挙げられます。

例えば「BigQueryのここにデータを置いといたので、好きに分析してもらっていいですよ」とエンジニアが伝えていたとしても、データ分析をするプランナーにとっては「いくつか似たようなカラムがあるけど、どれがこの分析に適しているんだろう……」と迷ってしまい、思いのほか分析のスピード感が出せなかった事例がありました。。

他には、部署Aの方が「こういう分析をしています」という紹介があった後に、「こんなデータがあったのか。うちのXXXのデータとも突き合わせて分析すると面白いことが分かりそうなので詳しく教えてください」といったように、他部署の人とのコミュニケーションが生まれた事例もありました。

ダッシュボードの運用での困り事を共有できる

困り事が共有できたことも有用でした。

ダッシュボードにデータを出しているものの「毎月のデータ更新がそれなりに手間で、手動更新による間違いも発生しうる」という悩みに対して、あるチームから「似たようなケースでこういった運用をしている」という事例が紹介されたり、エンジニアからは「こういうツールを使うと楽になるかもしれない」といった提案がありました。

また、前述した「閲覧する人が限られていて、データを見る文化がなかなかできない」といった困り事を共有できたこともよかったです。

あるチームで課題となっている課題は、他チームでも課題になっていることが多いため、今回のようなチーム横断の会を開催する意味は大きいなと感じました。昨今のリモート勤務の状況下ではチーム外のメンバーと雑談をしたり、こういった困り事を共有したりする機会が減ってしまいがちという背景もあり、特にこの点はよかったというメンバーの声も多かったです。

AS-ISだけでなくTO-BEを考える機会になった

効果検証のためのデータ分析など、日々の課題をやっていると、AS-ISばかりを考えてしまうことも多いです。

しかし、こういった会をきっかけに、普段より一歩引いた視点からデータ活用のことを考えてみると、サービスの改善やよりよいユーザー体験に繋げるためにはデータ活用はどうあるべきかなど、TO-BEの目線を参加者で持てる機会となりました。

おわりに

今回は、社内でデータ活用を促進するために行なっている企画を紹介しました。さまざまなチームの取り組みを共有することで、今後もさらにデータ活用を進めていきたいなと思います。

はてなでは、新卒・中途、東京・京都を問わず、エンジニアを募集しています。データ基盤、データ分析に興味のある人はぜひご応募ください！

エンジニア採用 - 採用情報 - 株式会社はてな

*1:意図してそうなったというよりは、結果としてこうなった形です。

*2:ITの利用により、後進が過去の知見を高速に学習できることを「学習の高速道路」と呼ぶことに倣った。もとは棋士の羽生善治さんの言葉として梅田望夫さんが紹介したものが広まった。