データを整える前にダッシュボードを作って失敗した話

正直に言います。見える化のためにアプリを試作して、見事に失敗しました。データがバラバラのまま器を作っても、準備の手間が増えるだけだったのです。この失敗から学んだ「整える順番」を、チェックリスト付きでお伝えします。

予測と実績を並べてみたら、"見えただけ"だった

業務の「予測値」と「実績値」を並べて見えるようにしました。
目的は単純で、ズレを早めに見つけて手戻りを減らすためです。

やってみると、見える化そのものは達成できました。
数字が散らばっていた状態から、ひとつの画面で追えるようになったからです。

ただ、そこで安心できませんでした。
見えるようになった途端、「予測との差」が毎回気になり始めたからです。

予測が外れているのか。
実績の取り方がブレているのか。
それとも、途中の前提が変わっているのか。

見える化はスタートラインで、ゴールではない。
この当たり前を、体感として理解しました。

アプリを作ってみた → つまずいた3つのポイント

仮説は「可視化アプリで差の議論が進む」でした。
そこで、Webアプリで試作品（PoC）を作りました。

やったことを、できるだけ具体的に書きます。

1) まずは画面に出す項目を決めた

予測値、実績値、差分（予測−実績）を基本にしました。
さらに、差が大きいものを上に出す並びにしました。

この時点では「これで議論できそう」と思っていました。
差が大きい順に並ぶだけで、確かに見やすくなるからです。

2) 元データを取り込む流れを作った（ここが重かった）

ところが元データが集約できていませんでした。
置き場所も形式もバラバラで、揃える作業が毎回発生しました。

• 表の形が日によって違う

• 項目名が微妙に違う

• 欠けている値があり、手で埋める必要がある

• そもそも最新がどれか分からない

• 予測の元になった前提がどれか分からない

• 実績の数字がいつ確定したのか追えない

• 途中で条件が変わった記録が残っていない

アプリ側で吸収しようとすると、作り込みが必要です。
作り込むほど、試作品のはずが"開発案件"になっていきます。

3) 使い勝手でつまずいた

入力や更新の手順が増えました。
「見るだけ」のつもりが、「整形して投入する」が前提になったからです。

結果、現場の感覚としてはこうなります。

「見えるようになったけど、準備が大変」
「今までより手間が増えた」
「毎日は回せない」

試作品としては、ここで失敗でした。

失敗から引き出した教訓

良かった点も、ちゃんとありました。
予測と実績を同じ画面に置いたことで、会話の起点は作れました。

「どれがズレているか」を探す時間は減りました。
差が大きい箇所がすぐ目に入るのは、やはり強いです。

ただ、失敗した点のほうが学びが大きかったです。

失敗1：データが揃っていない状態でアプリを作ると、手間が増える

アプリが悪いのではなく、順番が違いました。
"可視化の器"を先に作ると、データを後追いで整えることになります。

後追い整備は、必ず「例外対応の沼」になります。
試作のスピードも落ちますし、運用も続きません。

失敗2：使い勝手は最後に直すものではなく、最初の要件

毎日触るものは、操作が少ないほど正義です。
クリック数、入力回数、更新の待ち時間。
このどれかが重いと、継続が止まります。

「正しい可視化」より「続く可視化」。
ここを軽く見てはいけないと痛感しました。

実は、作っている途中では気づけませんでした。
「良いものを作れば使ってもらえる」と思い込んでいたのです。
使う人の"毎日の負担"を先に想像することが、最初の設計だったと今は思います。

失敗3：「全部見せたい」が、誰も見ない画面を作る

せっかく作るなら情報を全部載せたい——その気持ちで項目を増やした結果、画面が"数字の壁"になりました。
「どこを見ればいいか分からない」と言われ、最初に戻ることに。

表示項目は引き算で決めるほうが、結局は使われます。

明日から試せる6つのチェックリスト

同じ失敗を踏まないために、明日やれる一歩をチェックリストにします。

• まず「予測」と「実績」の定義を1枚に書き出す（ズレる理由の半分がここ）

  • 例：予測＝月初時点の見込み件数。実績＝月末の確定件数

• 元データの置き場所を1つに寄せる（フォルダでもスプレッドシートでもOK）

• 項目名を固定する（表の"列名"だけ先に揃える）

• 差分が出たときの原因候補を3つに絞る（例：前提変更／計上タイミング／分類）

• ダッシュボードは最小にする（「差が大きい順」＋「確認すべきメモ欄」から始める）

• 週1でもいいので、差分を見て"次に確認する人"を決める（見ただけで終わらせない）

アプリを作るのは、その後でも遅くないです。
先に「揃う」「続く」を満たすほうが、結局早いと感じています。

次の実験

次は、アプリ作りより手前に戻ります。
差分が出たときに"原因に当たりをつける"ための、最小のデータ形を決めます。

たとえば「差分が大きい上位10件だけ、原因候補のタグを付ける」など。
この運用が回ったら、初めて可視化の器を選びます。

#AI活用100本ノック 進捗：3/100
次回の実験：差分の原因候補（前提変更／計上タイミング／分類）をタグ化し、週1で回る最小フォーマットを作る