新井：　ビジネス部門がやりたいことをやりたいタイミングでできないのが原因の一つですね。データを活用するのはビジネス部門のはずなのに、自分の手でコントロールできない範囲が広いという。

タイミングの問題　だって見てもしょうがないんだもの

新井：　システム構築の段階でビジネス部門がIT部門に要件を伝えるのにも限度があるので、後になって「これもあるよね、あれもあるよね」と必要なものがバラバラ出てきてしまう。でもそれを修正するには時間もコストもかかって、完成したころにはその要件の必要性が薄れているのが理由の一つだと思います。

　ダッシュボードができても更新頻度が低いと、欲しいナレッジを欲しいタイミングで引き出せないので、ユーザー部門からすれば「だって見てもしょうがないんだもの」で終わってしまうという。

プロジェクト期間の問題　なぜ改善要求が上がってこないのか

新井：　ビジネスのボトルネックは変わり続けるものなので、ダッシュボードへの意見を吸い上げて継続的に改善するプロセスが必要なんですよ。それを意識せずに作って終わりになるケースが多くて、ビジネス部門がそこで熱が冷めてしまって「見てもしょうがない」という意識になってしまうようです。

　ダッシュボードについても従業員個人はそれぞれ意見があると思うんですね。でもそれを吸い上げる機会がないというか、会社としてはダッシュボード構築プロジェクトは完了していて「何でいまさらそんなこと言うんだ」という雰囲気になって声を出しにくいこともあると思いますね。プロジェクトの形から考えるべきというか、スピード感や柔軟性を重視するっていうのはここでもポイントになりますね。

評価軸の問題　そもそもダッシュボードで何が見たいのか

新井：　ダッシュボードを作るときって、それで誰が何をするのか、何を判断するのか、どう動くためのダッシュボードかを考えるのが絶対に必要で。例えばダッシュボードを作るってなったときに「じゃあまずは売上高を表示できるようにしましょう」となりますと。そこで5億円と出たときに、それがいいのか悪いのか分からないわけですよ。

　本来は判断軸が必要なんですけどそれがないケースも多くて、ビジネス部門からすれば「ふーん。今5億円売り上げてるんですか。なるほどね」で終わってしまうと。

解決策は「ユーザーを真ん中に置いたプロジェクトを組む」

新井：　やっぱりユーザー部門を真ん中に置くのはすごい大切で。だって使うのはユーザー部門ですから。ダッシュボード構築プロジェクトではいかにユーザー部門にオーナーシップを持たせるかを考える必要があります。ユーザーがわがままを言える仕組みを用意してあげると結果的にすごく良くなると思います。周りはちょっと大人にならなきゃいけない可能性ありますけどね。

　プロジェクトの進め方も重要ですね。ダッシュボードへの要望っていったん形になってから見えるものもいっぱいあるんですよね。そうするとウオーターフォールで開発していると結構無理があって。

　Domoでもいきなり完成形なんて見せないんですよね。1週間くらいでイメージを見せて、フィードバックをもらってブラッシュアップして、アイデアを出しながら1カ月後に完成品を出しますと。ただそこで終わりじゃなくて継続的にフィードバックをもらう機械を設けて修正していくとユーザーさんがついてくるというか、有用なダッシュボードになっていきますよね。