コネヒト開発者ブログ

コネヒト開発者ブログ

チームに「効く」ダッシュボードを考える

データ分析

Creating Effective Dashboards

こんにちは、サーバーサイドのお仕事してます金城(@o0h_)です。
つい先日、なんか気分が乗らないぜ〜〜って時にスピナーベイトを読み直してみたんですけど、気分の悪さが・・・上塗りされました・・・気をつけましょう。

スピナーベイト (1) (バーズコミックス)

さて、今回は抽象的な話になります。
「チームで毎日見るようなプロダクトの成長のためのダッシュボードってどういうのを作るんだっけ」という内容です。

https://cdn.mamari.jp/authorized/5b7ed6a6-dbc4-4548-a9f5-0017ac120002.jpg

TL;DR

以下のポイントを抑えると「効くダッシュボード」ができるのでは、と考えています。

  • 「なんとなく」で作るのはダメ🙅 目的を持ち、「誰が」「いつ」「何のために」という意図を明確にする
    • 通常のプロダクトと同じく「UX」「ペルソナ」大事
  • 「必要なこと」を厳選する。全てをダッシュボード上でやる必要はない
    • digるのは他の場所で。ダッシュボードは「解ではなく問を示す」場所
  • 「読む」🔠ものではなく「見る」👀ものにする
    • 視覚的に「一瞬でわかる」ものに

なお、今回は「現場メンバーが」「毎日使って」「ざっとした現状を把握する」というスコープに絞っています。

前置き

早いもので、もう10月です。
前クォーターにあたる7-9月期において、コネヒトのプロダクトチームは全体編成を新たにして動いていました。
私も「新しくなったチーム」の1つに所属しながら動いていたのですが、立ち上げの一環で取り組んだタスクの1つに「ダッシュボードの作成」があります。
今回は、その際に考えていた内容について整理しながら振り返ってみたいと思います。

チームメンバー間の視座を揃える

さて、「なぜダッシュボードか」というお話です。
新しく組成されたチームのメンバーには、「会社に新しくジョインしたディレクター」や「新しくプロダクト開発文脈でも参画してくるようになったディレクター」もラインナップされていました。
当然ながら立場が違うと「見え方」も違います。チームにおいては、ディレクター・デザイナ・エンジニアの「三者」が互いの武器や観点を活かせるのが理想です。逆に、フラットな意見交換やアイディア出しが実現されなければ、非常に大きな損失が生じると言えます。

コネヒトでは「機能の企画を出したり提案をしたりするのはディレクターの仕事」とはなっておらず、ロールに関わらずIssueを作るようになっています。こうした領域横断的な動き方を肯定していく場合、メンバーの「視座を揃える」ことの重要性が特に増すように思います。
その支援強化のためのツールを設け、導入することにしました。

  1. 中長期計画 : 自チームドメインにおける、数値的成長・ストーリー(提供機能)をまとめたロードマップ
  2. 短期計画 : 今スプリントのタスクを管理するカンバン(pipeline)
  3. 現状把握 : 基礎的な数値を集約したダッシュボード

必要なのは「目標を意識すること」と「そこに至るまでの道程イメージ、逆算思考」のための「現状認識」です。
そのための三種の神器として、これらを用意しました。用意した = チームメンバー全員が読み取れる形で&アクセス可能なところに公開した、という事です。

<!-- ここから 蛇足 --! >

何となく使っていますが、ダッシュボードって車の前面にあるアレですよね。「正しく走れているか」「このまま走れそうか」が、(ドライバーが凄いストレスに取り囲まれながらにしてたった一瞥で)必要な情報を取得できる、というアレです。
「ロードマップ」だって、道筋のことですね。地図です。ということで、ロードマップとダッシュボードは単語からして非常に相性が良いのかもしれません。 カンバンは・・・まぁこれはニホンゴなので・・・でも、並べてみるとあたかも「標識」的なニュアンスもあるのでは？と思えてきて、文学的ですね！！よろしくお願いします。

<!-- 蛇足ここまで --! >

これによって、「来月や再来月のこと」「来週のこと」「今現在のこと」を描き出す柱が揃うと考えました。
ロードマップについてはディレクター及びプロダクトオーナーが協議をし、カンバンについてはスクラムマスターを中心に取りまとめて毎日確認しています。 残るダッシュボードについて、私が設計・構築を担当しました。

今回は、実際に制作をしながら「何が必要だろうか」「どういうものなら、(上記に示したような)文脈に沿った効果を発揮できるだろうか」と考えたことをまとめてみたいと思います。

ぼくのかんがえたさいきょうのだっしゅぼーど

社内で「1つのダッシュボード」として0から作るのは初めてだったように思います。これまでも、(例えばmixpanelのdashboardやGAのカスタムレポートで)重要項目を1箇所に並べる、というものはあったのですが・・
そのため、まず「どうあるべきか」を言語化しながら取り組みました。実際にその時にテキスト化していたメモを(原文ママに)貼り付けてみます

A. ツール的側面

  1. 「必要な情報」を集約できること
  2. パッと開ける、見ようと思ったときに更新が済んでいる(サーバー側での定期更新)
  3. 誰でも簡単にアクセスできること

B. コンテンツ的側面

  1. 目的、エンドユーザーを定義する
  2. KPIとメトリクスを意識する
  3. 「全体」→「具体」→「詳細」
  4. より深い情報へと導くための「目次」となるように意識する
  5. 「何かした」ときに「何かが起きる」項目を置く

C. 活用支援

  1. チームとして「どう使うか」のデザインは絶対に必要。「各自毎日見て」で終わらせないこと

以下、これらをベースにして掘り下げてみたいと思います。

A. ツール的側面

・・の話をする前に、この問題が重要性を帯びているのはコネヒトの歴史的な側面にも少なからず理由があると思うので、ちらっと話をします。

長らく、コネヒトでは主要なデータ収集・分析ツールとしてGoogle Analyticsとmixpanelを活用してきました。主にweb面はGA、app内の行動はmixpanelという棲み分けです。
ここにFirebase Analytics(to BigQuery)も加わります。この時点で、組織文化的にエンジニアもディレクターも独自にSQLを実行し(MySQL/BigQuery)、「必要なデータにアクセスする」という態度はありました。
それと前後してBIとしてTableauの導入もありました。 最後に、「データの民主化」を銘打ってRedashが登場します。

・・・何だか「データを見る」ツールが多いですね。
そこで「何を使うか」は考えなければならない課題となります。

ツール的側面① ─ 「必要な情報」を集約できること

長くいたメンバーであれば、様々なツールやデータストアがある中で「どこにどんなデータがあるのか」は何となくの肌感は分かるかも知れません。しかし「バラけている」「行き来が必要」というのは、チーム歴の長短を問わず、それだけで「俯瞰的に、鳥の目で今をキャッチしよう」というダッシュボードの目的に対しての障害となります。

「マルチデータソースの集約性」観点で、BI寄りのレイヤーにあるツールが欠かせません。そこで最初にTableau・Redashに絞りました*1。

ツール的側面② ─ パッと開ける

これは単純に「開くときの重さ」のことです。
見るぞ〜ってなった時にレンダリング完了まで3分掛かるようなものは、意識するとせざるを問わず「何となく不便」なツールとなります。
今回、目指しているのは「習慣的に当たり前に見るものを作る」であり、また「行動の起点となるポテンシャルを持つものとして定着させる」です。それにあたって、この「何となく不便」は癌になり得ます。

なので、「開いてからすぐに最新のデータが取得される」もしくは「開く前に、定期更新が実行完了している」ということが要件として生じてきます。

データ読み出し後のレンダリング・・については各ツールごとに癖を掴んで「処理を軽くする」ためのチューニングが必要ですが、後者に関してはRedash・Tableau Onlineともスケジュール更新が機能として備わっています。
今回、我々が作ろうとしているものは「毎朝見る」「日時データを見る」ものだったので、深夜の適当なタイミングで昨日までのデータが集計できていればOKでした。

ツール的側面③ ─ 誰でも簡単にアクセスできること

ここまで考えて、当初は、個人的な慣れもありTableau(/ Tableau Online)で行こうかと考えました。
しかし、最終的にRedashで作成しています。その理由が、「チームメンバーの多くが馴れている・全員が触ったことがある」というものでした。
Tableau並の表現力・処理機能を用いたらダッシュボード構築早くなりそう〜という魅力を考えると、やはりこのツールが第1候補です。しかしながら、集計するメトリクスを集めていると「どうにかクエリ書くのだけ最初に頑張ってしまえば、Redashでも頑張れそう」というのが見えてきました。
チームのメンバーを見ると、TableauよりもRedashに慣れ親しんでいる人が多そうです。繰り返しになりますが、今回の目的は「習慣的に当たり前に見るものを作る」というものになります。そのため、ダッシュボードを組む側の労力で「抵抗感」「親和性の低さ」などを解消できるのであれば、選好すべき強い動機たりえました。

権限的なこともさることながら、この「頑張らなくても開ける」ことをもって初めて「アクセスできる」といえるのではないか、と思っています。それらを総合して考えて、「ちょっと構築は大変になるけどRedashで頑張ってしまおう」というのを最終判断としました。

B. コンテンツ的側面

中身をどうしていくか、という話です。
「ダッシュボードを作るぞ！」となったときに、通常の「開発」や「デザイン」と比べて侮られがちなのかな・・・？とも思っているのですが、これだって十二分に「UX」を捉えて「設計」されるに値すると思っています。
例えば「ターゲットを絞って」「コンセプトを決めて」「ワイヤーフレームを描き」「実際に中身を入れる」という一連の制作活動で捉えたら品質が上がります。

「何をして」「何をしないで」「そのためにやるべきこと」を洗い出していきましょう。

コンテンツ的① ─ 目的、エンドユーザーを定義する

何を作るのか

最初に「誰が」「なんのために」見るのかを明確にする必要があります。 「経営層が見るもの」「プロダクトオーナーが見るもの」「現場のメンバーが見るもの」は、それぞれ同じで良いでしょうか？
例えば「経営層がみるもの」であれば、収支やグロースに関する現在の状態や推移予測こそが知りたい情報でしょう。「現場のメンバー」用途であれば、利用者は詳細な知識や最近の施策に関する情報をある程度は把握できている〜という前提に立つことができると思います。すなわち、彼や彼女に期待される「何が起きているか」という事柄は、組織の上位の人間が見るものよりも高解像度なメトリクスになるはずです。

先に述べた通り、今回の目的は「現場メンバーが」「毎日使って」「ざっとした現状を把握する」ためのダッシュボードの作成です。「現場」で語られるべきは「今週頭から打ち始めた施策Aが効いてきた」とか「ABテストの結果はBを採択しよう」とか、そういう話です。ここを履き違えたなら、何も刺さらない、ただボヤっとしたものになるのを避けられません。

「何のために作成されるダッシュボードなのか」を明確にすることは、そこから発生するコミュニケーションやしいては得られるアクションのイメージを得ることを支援します。そうして「使いやすい」ダッシュボードを設計していきましょう。

コンテンツ的② ─ KPIとメトリクスを意識する

どんな要素で組み上げるのか

ダッシュボードを作りたいという動機は、どのように生じるものでしょうか？
それは、「ゴールと現在地の乖離を把握するため」であり「良くないことが起きて退化が始まっていることをアラートするため」だと考えます。
つまり、目標と強く結び付けられたデータを一覧できるというのがその機能です。

ここで id:yamo3 さんの記事にある「KPI」「メトリクス」という考え方を援用したいと思います。

KPIよりメトリクス - 自社のメトリクスを持とう - Yamotty Blog

  • 今の居場所と現実を理解するための指標
  • 行動を起こすための指標
  • コミュニケーションのための指標

今回の記事においては「KPIとメトリクスとはどう違って、境界線があるのか」という話には触れませんが、少なくとも「毎日見るようなダッシュボード」においては、この3つはエッセンシャルな性質であると考えます。

ゴールを意識しましょう。ダッシュボードには、「目指すべき」「満たすべき」「アタックすべき」数字たちを並べる必要があります。

コンテンツ的③ ─ 「全体」→「具体」→「詳細」

情報のレイアウトについて

基本的に、ダッシュボード上のデータ配置は「俯瞰→詳細」へと読み進めていけるように配置を行います。
これは読み手に対してコンテキストを養いながらデータに触れてもらえるようにするためです。

例えば書籍ECサービスであれば、EC全体売上->カテゴリ別商品別売上 > シリーズ別売上 > 単行本別売上 といった「大小関係」があると思います。
こうした時に、「昨日の売上はどうだったのかな？(良かった、落ち込んだ)」という「ザックリした現状」を文脈として捉えつつ「このシリーズが凄い頑張ったのね」といった情報に触れられるようにするべきです。なので、「先に知っておくべき」ことは上段に持っていきます。「どのタイトルが売れていて」という話の後に「サイト全体がどうだったか」を知るのは不自然に感じます。

コンテンツ的④ ─ やらないこと: 「細部まで全部わかる」

取捨選択を徹底する

「ダッシュボードというのは、解ではなく問を示すもの」だと個人的には考えています。
例えば「昨日のアクセスが増えたのは、地上波の情報番組であの芸能人が商品名を言及していたから」という具体的な内容までは、ダッシュボードだけでは辿り着ける必要はないかも知れません。求められるのは、「昨日の15時に急激にアクセス数が増えた」というデータがパッと見で分かることです。ダッシュボードはあなたに「異常」を教えてくれて、あなたはそこから「一体なにが起きたのか」を考えることになります。

このように「情報の解像度を荒くして、視野角を広げる」ことにより、ダッシュボードのシンプルさを保つと同時に、反復的に眺めるための密度の高い情報設計が達成されます。 それと同時に、「ワンクリックでより詳しい情報にアクセスできるようにリンクを貼っておく」などのドリルタウンがしやすいようにできるとベターです。

コンテンツ的⑤ ─ 「何かした」ときに「何かが起きる」項目

選好すべき項目

指標には、その声質によって「反応が鈍い」ものと「反応が鋭い」ものがあると思います。
とりわけ「毎日見るダッシュボード」であれば、昨日起きた「何か」に対してしっかりとグラフ上の動きで反応してくれる指標の方が好ましいです。
たとえば「LTV」は1日ごとに追ったところで大きな変化は起きにくいかもしれません。対して、「有料課金者数」や「問い合わせ数」といった数字は「広告出稿料を200%に増やした翌日」でも俊敏な反応を示す可能性が十分に見込めます。

それぞれの指標の持つ「早さ」を意識して取捨選択・配置を行うことで、より意味深いダッシュボードを組み上げられると思います。

C. 活用支援

最後に、ダッシュボードそのものからは逸脱した話です。
ここまでに「どんなツールを作るか」という話をしました。当然ながら、ツールというのは手段であり目的ではありません。目的は「習慣的に当たり前に見る」ものを作るというものでした。そして、サービスの現状認識についてメンバーの視座が揃った状態を理想とします。

まずはモノとして「毎日見る価値がある」成果物はできているでしょうか？これが最初の第一歩です。そして、このハードルをクリアしてもなお「やっぱり人って毎日継続して1つのものを見てはくれないよね」と思っています。それだけ、習慣化・・ましてや他人に習慣をインストールするというのは難しい事と思っています。

色々と方法はあり、またチームやメンバーの状況によっても効果的な取り組み方・向き合い方は異なってくると思います。
例えば、こんなやり方があるのではないでしょうか。

  • 毎日、ダッシュボードをSlackに投稿する
    • それについて、各メンバーが気づきをコメントする
  • 朝会にて、1つのモニターを眺めながらメンバー間で2,3分のディスカッションを行う
    • あるいは曜日ごとに「発表者」をローテーションする
  • 各施策の仕様定義時に、「ダッシュボードでいうとどの項目か」を紐付けて考えるようにする。Issueテンプレートに記入欄を設ける

いずれも、「物理的に、目に入るようにして」「その内容の意味付けをする」ということの組み合わせなのかなと考えています。
ここまでやって初めて、「チームに効くダッシュボード」は完成するものといえます。自分たちのデータに関するリテラシーの高い集団を築き上げてください。
チーム内のコミュニケーションとダッシュボードについては、THE GUILD 安藤さんのスライドでも非常に興味深く・分かりやすく語られていましたので、ご一読されることをおすすめします。

まとめと付録: 参考にした記事などをご紹介

随分と長いエントリーになってしまいました・・・ここまでご覧いただき、ありがとうございます。
ダッシュボードというのは真面目に作ると、相当に高度な作業物だと思います。 私自身、今回「どうして」「なにを」を改めて考えながら構築を行いましたが、完了に至るまでにたくさんの悩みを伴いました。その一方で、制作した内容の意図するところはしっかりチームメンバーに伝えられないと意味がないな〜と感じていました。
効果的なアウトプットを目指すに当たり、色々な「べき論」やプラクティスを調べながらクエリを書いたりダッシュボードを作っています。
その過程で「読んだ」「タメになった〜〜！」という記事をリストにしておきます。実践的で勉強になる内容が多分に含まれていますので、ぜひ御覧ください。

余談: 余裕があればこの本を読んでみたい・・・・

Information Dashboard Design: The Effective Visual Communication Of Data

Information Dashboard Design: The Effective Visual Communication Of Data

*1:この他に、クエリはRedashに寄せつつビジュアライズやダッシュボードはGoogle Spreadsheetで、という構成も検討の余地があります。実際、私が他チームにおいてETL構築やデータ出しで支援した際にはGoogle Spreadsheetを最終のアウトプットとしたケースもあります。データ量がある程度までに収まる + 繋ぎこむデータもさほど多くない ＋ 取得項目も十分に洗練され・枯れている、という条件を満たした時に、具体的な数字の確認しやすさ(方眼紙っぽいUI)や、Google Spreadsheetの機能としてのピボットテーブル、フィルタリングはとても魅力です。あと、セルにコメントが入れられる、複写が容易〜など。