← エピソード一覧に戻る Episode 182 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― ダッシュボードが変えるのは見た目ではなく判断速度
タカシ
今日は SaaS デザインのダッシュボード設計です。実は PrizePicks では、重要ファネルのエラー率が二十五パーセントから七パーセントへ、二カ月足らずで七十二パーセント改善しました。きっかけは、問題を見える化するダッシュボードでした。
ミカ
へえ、それは大きいですね。ダッシュボードって、つい『グラフがいっぱいある画面』くらいに見てしまいますけど、本当は経営判断の速さそのものに効くんですね。
タカシ
その通りです。B2B SaaS では、売上、活用率、問い合わせ、障害、未処理タスクが別々の場所に散らばりやすい。だから良いダッシュボードは、数字を並べる画面ではなく、今どこに注意を向けるべきかを揃える画面なんです。
ミカ
なるほど。今日は、何を表示するかより、どう優先順位を見せるかがテーマなんですね。経営者向けと現場向けの違いも含めて、整理していきたいです。
Chapter 2 原則 ― まず誰の問いに答える画面かを決める
タカシ
まず原則です。Datadog は二〇二六年の記事で、経営層向けの high-altitude view と、マネージャー向けの lower-altitude view を分けるべきだと説明しています。経営層は『進捗は順調か』を見たい。一方で現場は『なぜ崩れたか』を掘りたいんですね。
ミカ
たしかに、同じ画面に売上サマリーと API エラー詳細を一緒に置いたら、どちらの人にも中途半端かもしれません。社長には細かすぎるし、運用担当には粗すぎる感じです。
タカシ
ええ。だからダッシュボードを作る前に、『この画面は誰が、どの会議やどの判断で使うのか』を決める必要があります。ここが曖昧だと、便利そうなグラフを足し続けて、最終的に誰も開かない画面になります。
ミカ
ありますね。親切のつもりで何でも載せたら、逆に『どこを見ればいいの』になる画面。ダッシュボードって、情報量の勝負じゃなくて、問いの明確さの勝負なんだなと分かります。
Chapter 3 設計 ― 載せない勇気と文脈づけが使いやすさを決める
タカシ
次はレイアウトです。Geckoboard は、目的を明確にし、最も重要な内容だけを置き、サイズと位置で階層を示し、数字に文脈を与えるべきだと言っています。つまり、上にある数字ほど『まず見るべき理由』が必要なんです。
ミカ
文脈って、前週比とか目標との差みたいなものですか。たしかに MRR が出ていても、増えたのか減ったのか、想定通りなのかが分からないと、結局は会議で誰かに聞くことになりますよね。
タカシ
その通りです。さらに HubSpot は、プロパティ別の内訳が百値を超えるレポートはダッシュボードに載せられないと明記しています。これは厳しい制限に見えますが、実際には『画面で判断できる粒度まで絞れ』という健全な圧力なんですね。
ミカ
なるほど、見せられるから載せるじゃなくて、見て判断できる形に圧縮しろということか。ダッシュボードって、データの倉庫じゃなくて、意思決定の玄関なんですね。
Chapter 4 具体例 ― KPI とアクションを同じ画面に置く
タカシ
Stripe の Dashboard は分かりやすい例です。ホームには business performance の分析とチャートがありつつ、未解決の dispute や本人確認の通知も同じ場所に出ます。しかも overview の widget は追加や削除ができ、Payments analytics では承認率や disputes を比較期間つきで見られます。
ミカ
それ、いいですね。『今どうなっているか』と『今どこに手を打つか』が離れていない。ダッシュボードって、観賞用のサマリーじゃなくて、次の一手を決める操作盤に近いんですね。
タカシ
Mixpanel の発想も実務的です。Company KPIs Dashboard template は、二つのイベントから四クリックで九つのレポートを作ります。さらに PrizePicks は施策ごとにダッシュボードを持つ運用へ変え、エラー率二十五パーセントを七パーセントまで下げました。
ミカ
つまり、良いダッシュボードは『あとで分析しよう』を減らして、『今これを直そう』を増やすわけですね。見える化そのものより、合意形成の速度を上げる道具なんだと分かります。
Chapter 5 まとめ ― 一枚で全部見せず、迷わず動ける順番を作る
ミカ
今日の話をまとめると、失敗パターンは四つありそうです。全部の指標を載せる、数字に文脈がない、役割別の見え方を作らない、そして異常が見えても次の行動につながらない。この四つですね。
タカシ
ええ。まずは主要ロールごとに『この画面で答える問い』を一つ決め、主指標は三つから五つへ絞ることです。左上に最重要 KPI、右上に要対応事項、下段に要因分析を置くだけでも、判断の迷いはかなり減ります。
ミカ
しかも、地域やプラン別の違いは画面を量産するより、フィルタや saved view で切り替えたほうが運用も軽くなりそうです。使われない widget を定期的に消すのも大事そうですね。
タカシ
その通りです。ダッシュボード設計の本質は、情報を増やすことではなく、迷いを減らすことです。皆さんの製品でも、最初の一画面が『全部ある』ではなく『まず何を見て、誰が動くか』になっているか、ぜひ今日チェックしてみてください。