ダッシュボード開発をしよう

DX時代、データの有効活用が叫ばれて久しい昨今です。データを分析・可視化するために、BIツールを使ったダッシュボード開発を行うことがあると思います。この記事では1年間ほどQlik SenseというBIツールを用いてアプリ開発を行った経験から、ダッシュボードを作るにあたっての難点とその対応方法をまとめたいと思います。

ダッシュボード開発の難点

ダッシュボード開発の難しい点は、

・データが汚い！  

・データが大きい！  

の二点にあります。

データが汚い

本来数値が入るところに文字列が入っていたり、日付フォーマットがバラバラだったりするといったケースです。DBがしっかりと設計されていて、そこからデータを引っ張ってきてダッシュボードアプリにロードするだけなら話は簡単です。しかし時には、手入力で作成されたExcelファイルしかなく、そこからデータを持ってこなくてはならないケースもあります。そういった場合は、直にダッシュボードアプリにロードしようとすると、ロードに失敗したり、ビジュアライゼーションが異常表示されたりして使い物にならないアプリができあがってしまいます。

データが大きい

元データが膨大な量になり、データロードに時間がかかったり、アプリが重くなって操作性が悪くなったりするケースです。こうしたアプリを触りたいユーザーはいません。おそらく時間が経てば経つほどに、ユーザーはアプリを触らなくなり、ダッシュボードも見られなくなっていきます。これではダッシュボードを開発した意味がありません。

対応方法

ではこうした事態を防ぐためにはどうすればいいでしょうか。汚いデータを綺麗なデータに、大きいデータを小さいデータに変換する処理すなわち「前処理」を、ダッシュボードアプリにロードする前に行うのです。

この前処理ですが、なかなか簡単なことではありません。

汚いデータを綺麗なデータにするにしても、例えば表記ゆれを修正する場合でも、どういったケースの表記ゆれがあるのか、そのケースすべてを把握して処理をかけることは困難です。であれば、入力側に協力を要請して手入力に制限をかける等をしてもらう必要があります。また、異常値の入ったレコードを削除するにしても、あまりに異常値が多ければ多くのレコードが削除されてしまいます。そうしてデータ自体が減ってしまえば、ダッシュボードの信頼性も下がってしまうでしょう（このアプリは本当にデータを正しく反映できているのか？、このアプリに基づいてビジネス上の判断をしてもよいのか？等）。

大きいデータを小さいデータにするためにサマリーを作成するにしても、ダッシュボードで多くのフィルタをかけたいならば、サマリーも必然的に大きくならざるをえません。フィルタを減らす、日単位データを月単位データにする等の妥協が必要になります。そうした妥協を受け入れることをユーザー側に要請しなければなりません（本当は日単位の実績値の遷移を見たいのに月単位でしか見れない...等）。

いずれにせよ、ユーザー側の要望を全て満たしつつ、操作性の良いアプリを作ることは決して簡単なことではありません。多機能にしようとすればデータ量が大きくなり、操作性は悪化します。操作性を良くしようとすればデータ量を減らさざるをえず、必然的に機能も減らさざるをえません。こうしたジレンマがあるのです。ダッシュボード開発では例にもれず、ユーザー側との意見交換、情報交換、妥協点の決定が肝になります。