現実モデリング

データとかエンジニアリングとか健エミュとか

ダッシュボード・プロトタイピング：手戻りなくユーザーが本当に欲しいダッシュボードを作るためのHow to

技術 マネジメント

はじめに

ダッシュボードをつくるのは難しい。「自分が本当に欲しいダッシュボード」を説明できるユーザーはめったにいない。本当に欲しいダッシュボードの要求定義を聞き出せるアナリスト・エンジニアだってそんなにいるものではない。本当に欲しいものが何か説明できないユーザー、理解する能力のないアナリスト・エンジニアのやり取りの結果生まれるダッシュボード。古典的な「顧客が本当に欲しかったもの」の図式とそっくりである。

ダッシュボードの要件をめぐる認識の相違

  • そもそも三段のブランコって何に使うの？一段で良くない？
  • 過剰に要求を見積もりすぎていないか？本質的に解決したいことは何かわかっていないのでは？

ダッシュボード開発における難しさは要求定義だけではない。いかに素早く作るかも重要である。事業状況の変化が速い場合、素早くユーザーのニーズを満たすことは事業上の価値に直結する。要求定義が滅茶苦茶な状態で実装すれば手戻りが多く発生し、ユーザーに価値を届けるまでのリードタイムが長くなる。

ユーザーが本当に欲しいダッシュボードを素早く作るための方法論が必要だと思い、自分なりに考えて、実践してきた。その手法について書き下してみたい。

ダッシュボード・プロトタイピング

  • ユーザーの要求、つまりユーザーがダッシュボードで解決したいことを早期の段階でつかみ、手戻りを可能な限り抑えることに主眼を置く手法
  • 「手戻りがない」ことは、「素早くユーザーの本当の要求を満たすこと」と同義であるため、手戻りを抑えることに重点を置いている

1. ラフスケッチをする

ラフスケッチの段階ならやり直しが素早く可能なため、高速でフィードバックを受けながらユーザーの要求を固めていくことができる。このラフスケッチ段階が一番重要であり、手戻りを抑えるためのポイントになる。

ラフスケッチをするうえで気にするポイント

ラフスケッチを見ながら合意を取っていくことで、以下のようなポイントを抑えることができる。

  • 表の形式
    • 折れ線グラフの場合、横軸は何で、縦軸は何か？系列は何？
    • 表形式の場合、カラムは何か？
    • ピボット形式の場合、行・列・値はそれぞれ何か？
  • 粒度
    • 日単位か？月単位か？
    • 日付は関係なく、別の切り口でみたいのか？
  • フィルターコントロールの要素
    • 開始日と終了日だけでコントロールすればいいのか？
    • ほかにフィルター要素はないか？

新たにテーブルを作成する必要が発生した場合、上記のような項目はテーブル設計に大きな影響を与える。後続のタスクのことも考えたうえで、かならず抑えよう。

具体的なやり方

イメージが伝わればなんでもいい。素早く使えるものを選ぼう。

ラフスケッチの実例。この画像だけでも、見たい粒度が日時であること、フィルターコントロールの要素として開始日と終了日が必要であることがわかる。特に粒度に関しては認識のずれが発生しやすく、手戻りが起こった場合の再設計コストが大きいので、粒度をそろえられるのはかなり有効。

表形式のデータを見たい場合、スプレッドシートのスクリーンショットが一番手軽で認識をそろえやすい。とにかく高速にフィードバックループを回していくことが重要なため、「手軽にできる手段」を選ぶことが重要になる。

2. ラフスケッチの結果できたものを検討する

ラフスケッチで本当にユーザーが欲しいものが何かをつかんだら、どのように実現できるか考えてみよう。この検討結果によって次にとるべきアクションが決まる。

選択肢⓵：既存のシステムからほとんど変更なしで実現できそうな場合

例：

  • すでにあるデータセットから作成できる場合

この場合は、サクッとダッシュボードを作ってユーザーに見せて、フィードバックを受けながら変えていけばよい。

選択肢②：既存のシステムから変更する要素が大きい場合

例：

  • 新たにテーブルを作る場合
  • 現在のシステムでは取れていないデータを取る必要がある場合

この場合は、テスト用のデータセットを作成してから実際にダッシュボードを作って見せ、フィードバックを受けながら作っていくのが良いと思う。

  • テストデータを利用してできたダッシュボードで合意を得られたら、データソース取得処理、もしくはテーブル設計・アナリティクスエンジニアリングを含めた本格実装に入ろう。

実際に運用してみたTips

  • フィードバックを求める先を誰にするかが重要になる

    • フィードバックを求める先を間違えれば手戻りが発生することになるため
    • ダッシュボードを見る想定の人に必ずフィードバックを受けるようにしよう
    • 筆者は以前ダッシュボードを開発したとき、想定利用者のうちの一人からフィードバックを受けるのを忘れていたため、手戻りになりかけたことがある。

  • 相手に負荷のかからないフィードバックの求め方も重要になる

    • 高速に開発をしていく上では、フィードバックのやり取りも高速でなくてはいけないから
    • Slack上でやり取りする場合、「こんな感じでOKですか？OKなら :+1: (👍)を押してください」とやると効果的
    • 相手が最小限の動作で確認できるよう、文面を工夫しよう
    • スクリーンショットを添付しよう
  • ラフスケッチの初手はアナリスト・エンジニア側からやるようにした方がいい
    • 知識を持っているのはアナリスト・エンジニア側なので、その方が速い

おわりに

  • いきなり実装から始め、時間を無為に浪費していく。結果的に出来上がったものは誰にも使われない。そういうジュニアを何人も見てきた。
  • 「ラフスケッチを書いて、合意を取ってから実装を始めるだけでだいぶ楽になる」というところだけ知っていてほしい。
  • とにかくラフスケッチをやろう。ソフトウェア工学の知見を取り入れよう。