利用者目線のDB設計は、データ分析をラクにする

数年前、だいぶタイトなスケジュールで、ある実測調査を行った。
チームに課せられたのは「全国の自社店舗の待ち時間・応対時間を実測し、それを1年後に半分にしなさい」というオーダー。目標必達であることはもちろん、数字の間違いは許されなかった。

とはいえ、オーダーを受けてから調査結果を報告するまでの時間はかなり限られていた。

仕様設計～調査開始まで実質１ヶ月半。調査終了～結果報告までは2週間しかない。実測調査なので、調査員の入力したデータを分析するのだが、調査員が手入力したデータを1つ1つ集計する形だと分析の時間が十分取れないということで、委託先からの提案を受け入れ、システムで自動集計する方向に舵を切った。ただ、スケジュール上、システム開発には３週間程度しかかけられず、かなり突貫でシステムを構築した。

調査は無事終了し、なんとか期日までに報告はできたものの、突貫で作ったシステムということもあり、アウトプットのすり合わせが不十分だったため、システムから抽出したデータはそのままでは使えず、都度加工する必要があった。

アクションの進捗を確認する上で、その後も定期的に調査を行うことが決まっていたものの、このままのデータではスピーディーに集計・分析ができないというのが調査実施後の課題の一つとして浮かび上がった。

その時、委託先からいただいた提案に、私は度肝を抜かれた。

「DBに蓄積するデータの構成を、報告フォーマットを起点に、ガラッと変えましょう！システムから、加工せずにそのまま使えるデータを出力できるようにします。」

扱いづらいデータであったため、確かに困ってはいたが、DB側のシステム自体をガラッと変えるという発想までは思い浮かばなかった。私が想像していたのは、抽出したデータを簡単にデータ加工してくれるツールを作ることだった。

実際にシステムが改善されると、そのまま報告書として使えるデータがリアルタイムで出力できるようになり、集計～分析までの時間が大幅に短縮でき、アクションまでのスピードも早まったので、結果として目標達成につながった。

この経験は、最終的なアウトプットを起点に、最も上流にあるDBの設計をすれば、データ分析～アクションまでの流れがスムーズになる、というのを実感した瞬間でもあった。

その際の委託先の総責任者は、現場でたたき上げで偉くなった方で、システムも詳しく、利用者目線で何が知りたいか、きちんと落とし込むスキルにもたけていた。一緒にプロジェクトをやっていく中で、学ばせていただくことが本当に多かった。

今思えば、あの調査は、私にとって、データドリブンの原点になったと思う。