はじめに
ダッシュボードをつくるのは難しい。「自分が本当に欲しいダッシュボード」を説明できるユーザーはめったにいない。本当に欲しいダッシュボードの要求定義を聞き出せるアナリスト・エンジニアだってそんなにいるものではない。本当に欲しいものが何か説明できないユーザー、理解する能力のないアナリスト・エンジニアのやり取りの結果生まれるダッシュボード。古典的な「顧客が本当に欲しかったもの」の図式とそっくりである。
- そもそも三段のブランコって何に使うの？一段で良くない？
- 過剰に要求を見積もりすぎていないか？本質的に解決したいことは何かわかっていないのでは？
ダッシュボード開発における難しさは要求定義だけではない。いかに素早く作るかも重要である。事業状況の変化が速い場合、素早くユーザーのニーズを満たすことは事業上の価値に直結する。要求定義が滅茶苦茶な状態で実装すれば手戻りが多く発生し、ユーザーに価値を届けるまでのリードタイムが長くなる。
ユーザーが本当に欲しいダッシュボードを素早く作るための方法論が必要だと思い、自分なりに考えて、実践してきた。その手法について書き下してみたい。
ダッシュボード・プロトタイピング
- ユーザーの要求、つまりユーザーがダッシュボードで解決したいことを早期の段階でつかみ、手戻りを可能な限り抑えることに主眼を置く手法
- 「手戻りがない」ことは、「素早くユーザーの本当の要求を満たすこと」と同義であるため、手戻りを抑えることに重点を置いている
1. ラフスケッチをする
ラフスケッチの段階ならやり直しが素早く可能なため、高速でフィードバックを受けながらユーザーの要求を固めていくことができる。このラフスケッチ段階が一番重要であり、手戻りを抑えるためのポイントになる。
ラフスケッチをするうえで気にするポイント
ラフスケッチを見ながら合意を取っていくことで、以下のようなポイントを抑えることができる。
- 表の形式
- 折れ線グラフの場合、横軸は何で、縦軸は何か？系列は何？
- 表形式の場合、カラムは何か？
- ピボット形式の場合、行・列・値はそれぞれ何か？
- 粒度
- 日単位か？月単位か？
- 日付は関係なく、別の切り口でみたいのか？
- フィルターコントロールの要素
- 開始日と終了日だけでコントロールすればいいのか？
- ほかにフィルター要素はないか？
新たにテーブルを作成する必要が発生した場合、上記のような項目はテーブル設計に大きな影響を与える。後続のタスクのことも考えたうえで、かならず抑えよう。
具体的なやり方
イメージが伝わればなんでもいい。素早く使えるものを選ぼう。
- iPadなどのタブレットのメモ帳でやる
- 紙に書いたものを写真で送る
- ホワイトボードに書く
- エクセル・スプレッドシートのスクリーンショットを取る
- ジェスチャー
- グラフを言語化する
- 単純な形式の場合は有効である
- 例)縦軸が○○、横軸が日付の折れ線グラフが欲しい感じですかね？
2. ラフスケッチの結果できたものを検討する
ラフスケッチで本当にユーザーが欲しいものが何かをつかんだら、どのように実現できるか考えてみよう。この検討結果によって次にとるべきアクションが決まる。
選択肢⓵：既存のシステムからほとんど変更なしで実現できそうな場合
例：
- すでにあるデータセットから作成できる場合
この場合は、サクッとダッシュボードを作ってユーザーに見せて、フィードバックを受けながら変えていけばよい。
選択肢②：既存のシステムから変更する要素が大きい場合
例：
- 新たにテーブルを作る場合
- 現在のシステムでは取れていないデータを取る必要がある場合
この場合は、テスト用のデータセットを作成してから実際にダッシュボードを作って見せ、フィードバックを受けながら作っていくのが良いと思う。
- テストデータを利用してできたダッシュボードで合意を得られたら、データソース取得処理、もしくはテーブル設計・アナリティクスエンジニアリングを含めた本格実装に入ろう。
実際に運用してみたTips
フィードバックを求める先を誰にするかが重要になる
相手に負荷のかからないフィードバックの求め方も重要になる
- 高速に開発をしていく上では、フィードバックのやり取りも高速でなくてはいけないから
- Slack上でやり取りする場合、「こんな感じでOKですか？OKなら :+1: (👍)を押してください」とやると効果的
- 相手が最小限の動作で確認できるよう、文面を工夫しよう
- スクリーンショットを添付しよう
- ラフスケッチの初手はアナリスト・エンジニア側からやるようにした方がいい
- 知識を持っているのはアナリスト・エンジニア側なので、その方が速い
おわりに
- いきなり実装から始め、時間を無為に浪費していく。結果的に出来上がったものは誰にも使われない。そういうジュニアを何人も見てきた。
- 「ラフスケッチを書いて、合意を取ってから実装を始めるだけでだいぶ楽になる」というところだけ知っていてほしい。
- とにかくラフスケッチをやろう。ソフトウェア工学の知見を取り入れよう。