ダッシュボード開発で抑えるべき点
経営判断に役立つダッシュボードを開発する場合、「まずは小さく、とにかくシンプルに」、「すべてをシステムに頼らない仕組み」という２点を抑えておくべき
現在、クライアント先のあるベンチャーで、経営ダッシュボード的なものを開発したいなという話があり、議論を進めている。こういったニーズは大企業においても多く、「ダッシュボードを開発する」というプロジェクトが立ち上がったりするのだが、この手のプロジェクトはドツボにはまって混迷を極めることが多い。
その理由としては、大きく２つあると考えている：
- 仕様が複雑になりがち
- システムで全てを解決しようとする
まず1点目について、ダッシュボードというものは仕様がやたら複雑になりやすい。おうおうにして「経営陣から現場まで同じ数字をみて判断する」といった思想に基づいて仕様検討を進めたりするが、見る人間によって同じデータでも異なるセグメントで見たいというように視点が異なることが多く、それらに全て答えようと要件定義書を作ると、膨大な機能数になったりする。たとえ見る人間が取締役に限られていても同様なことが起こり、関係者の合意を取る事が非常に難しいのがダッシュボードという代物なのだ。一方で、妥協をして、例えばプロジェクト責任者の意見に重きを置いて、機能を絞っていくと「結局は使いにくくて誰も見ないシステム」が出来上がることが多い。
そして、1点目にも関わるのだが、ダッシュボードで全てを解決しようとするが故に、機能過多になりがちである。ダッシュボードを作ろうという人は全てをそこに詰め込もうとするが、そうすればそうするほど機能が複雑になり、使いにくい＝誰も使わないシステムになってしまうのである。
基本ダッシュボードなど作らない方がよい、というのが自分の中でのざっくりした結論なのだが、作る場合は、上記2点の反対、つまり、ごくシンプルにとどめ、システムで全てを解決しようとしない、という割切りが極めて重要になる。
ちょうどその議論を進める中で、ある有名なITベンチャー社内で用いられているダッシュボードをちらっと見る機会があったのだが、驚くほどシンプルで、ペライチの画面に5～6個のグラフが表示されているだけだった。バリバリのITベンチャーでログは完璧に取れているはずで、色々な切り口でデータをこねくり回すことができるはずなのに、経営判断をする上で見ているグラフはその程度なのである。「結局見なくなるんですよね、複雑だと」と言っていたが、その通りで、誰もがぱっと理解できて、でも事業の本質を突いた数個の数字が表示されていれば、それで十分なのである。より複雑な分析が必要になったら、分析チームが適宜アドホックに行う、といったシステムに100％頼らない仕組みで担保しておいた方が、柔軟に事態に対応できてよい。
ダッシュボード、安易に開発しようとしない方がよい。開発する時は、割切って思いっきりシンプルにすべきなのだ。
