指標には増える力しか働きません。新しい施策のたびに追加され、やめる契機がない。結果として、誰も見ていない数字が並びます。
この回は、増えすぎた指標をどう整理し、どう畳むかを扱います。作る話ではなく、やめる話です。
1. なぜ増え続けるのか
増える理由は構造的です。どの段階でも、誰も悪くありません。
| 場面 | 起きること |
|---|---|
| 新しい施策が始まる | その効果を見る指標が追加される |
| 施策が終わる | 指標は残る |
| 誰かが「これも見たい」と言う | 追加される |
| 組織が変わる | 前の担当が作った指標の意図が失われる |
| 消す判断 | 誰の仕事でもない |
2行目と5行目の組み合わせが本質です。追加する理由は都度発生するが、消す理由は発生しません。そして消して問題が起きたときだけ責任が生じるので、消さないのが合理的になります。
これは レガシー再生の現場 EP.09 で扱った「現状維持は誰の責任にもならない」と同じです。残すコストは見えず、消すリスクは見えるという非対称が、あらゆる整理を妨げます。
2. 増えすぎると何が起きるか
指標が多いこと自体は無害に見えます。実際には害があります。
- 優先順位が付かない — 全部が同じ重みに見える
- 異常に気づけない — 見る対象が多すぎて、変化を見落とす
- 維持の手間が増える — 定義の変更、集計の修正
- 信頼が下がる — 古い定義のまま残った指標が混ざる
- 新しい指標が埋もれる — 本当に見るべきものが目立たない
2番目が最も実害があります。画面に30個の数字が並んでいると、1つが異常でも気づきません。LLM時代のテスト戦略 EP.11 で扱った「赤に慣れる」と同じで、見る対象が多いほど、見なくなります。
4番目も深刻です。定義が古いまま残っている指標が混ざると、「この数字は信じてよいのか」という疑いが全体に及びます。1つの古い指標が、他の正しい指標の信頼まで下げます。
3. 使われているかを測る
整理の第一歩は、実際に使われているかを記録から確認することです。感覚で判断しないでください。
| 確認する記録 | 分かること |
|---|---|
| ダッシュボードの閲覧回数 | 見られているか |
| 誰が見ているか | 1人だけなら、その人に確認 |
| 最終閲覧日 | いつから見られていないか |
| その指標を参照するクエリ | 自動処理から使われているか |
| 会議での言及 | 議事録に出てくるか |
4行目を忘れないでください。人が見ていなくても、自動処理が参照していることがあります。消す前に、参照している処理がないかを確認します。
5行目は定性的ですが有効です。会議で一度も言及されない指標は、実質的に使われていません。議事録を検索すれば分かります。閲覧記録では「開いた」ことしか分かりませんが、言及されたかどうかは「判断に使われた」ことを示します。より強い証拠になります。
-- ダッシュボードの閲覧記録から、見られていないものを探すWITH viewed AS ( SELECT dashboard_id, COUNT(*) AS 閲覧数, COUNT(DISTINCT user_id) AS 閲覧者数, MAX(viewed_at) AS 最終閲覧 FROM dashboard_access_log WHERE viewed_at >= DATEADD(day, -90, CURRENT_DATE()) GROUP BY dashboard_id)SELECT d.name AS ダッシュボード, d.owner AS 作成者, d.created_at AS 作成日, COALESCE(v.閲覧数, 0) AS 閲覧数, COALESCE(v.閲覧者数, 0) AS 閲覧者数, v.最終閲覧FROM dashboards dLEFT JOIN viewed v ON v.dashboard_id = d.idWHERE COALESCE(v.閲覧数, 0) < 5 -- 90日で5回未満ORDER BY COALESCE(v.閲覧数, 0), d.created_at;閲覧者数も見るのが要点です。閲覧数が多くても1人だけが見ているなら、その人に確認すれば判断できます。逆に複数人が見ているなら、消す前の調整が要ります。
4. 畳み方
使われていないと分かっても、いきなり消さないでください。段階を刻みます。
- 1候補を一覧にする — 記録にもとづく
- 2作成者や関係者に確認する — 意図が残っているかもしれない
- 3非表示にして様子を見る — 消さずに隠す
- 4一定期間、反応がなければ消す — 1〜3か月
- 5定義と算出方法は残す — 後から復元できるように
3番目が有効です。非表示にして誰も気づかなければ、実際に使われていなかったということです。レガシー再生の現場 EP.10 で扱った「止める前に鳴らす」と同じ手法です。
5番目を忘れないでください。指標の定義と算出方法は、消さずに残します。数年後に「あの数字をまた見たい」と言われたとき、定義が残っていれば復元できます。表示をやめることと、定義を捨てることは別です。
定義だけでなく、なぜその指標を作ったかも残してください。エンジニアの引き継ぎ術 EP.04 で扱ったとおり、判断の理由は書かなければ失われます。復元するとき、意図が分かれば判断が速い。
5. 増やさない仕組み
整理しても、放っておけばまた増えます。追加時に条件を付けると、増え方が緩やかになります。
- 1追加するときに、見直す時期を決める — 「この施策が終わったら畳む」
- 2誰が見るかを明記する — 見る人がいない指標は作らない
- 3どの判断に使うかを書く — 使い道が言えないなら作らない
- 4既存の指標で足りないか確認する — 似たものがないか
- 5上限を決める — 「この画面には8個まで」
3番目が最も効きます。「この数字がこう動いたら、こうする」が言えないなら、その指標は見ても行動が変わりません。これは ── 数字は増えるが判断に結びつかない指標 ── を避けるための問いでもあります。
5番目は強引ですが有効です。上限があると、追加するときに何かを外す判断が発生します。「足すだけ」ができなくなるので、優先順位を考えざるを得なくなります。データ屋の道具箱 EP.24 で扱った「何を置き換えるかを問う」のと同じ発想です。増えるものには、足すときに引く仕組みが要ります。
6. 定期的な棚卸し
最後に、継続する仕組みです。一度整理しても、半年後には元に戻ります。
| 頻度 | やること |
|---|---|
| 四半期 | 閲覧記録から候補を出す(自動でよい) |
| 半期 | 候補を関係者と確認し、非表示にする |
| 年次 | 指標の体系そのものを見直す |
| 施策の終了時 | その施策のための指標を畳む |
最下行が最も自然な契機です。施策が終わったときに、その指標も一緒に畳む。これを習慣にすれば、大きな棚卸しの必要が減ります。
3行目の年次の見直しでは、事業の段階が変わっていないかを確認してください。次回(EP.23)で扱いますが、成長段階によって見るべきものは変わります。同じ体系を使い続けるほうが不自然です。
指標は増える力しか働かない(追加の理由は都度発生し、消す理由は発生しない)。増えすぎると異常に気づけなくなるのが最大の害。整理は記録から使われているかを確認し、非表示にして反応を見る。消しても定義と作った理由は残す。増やさないためには、「どの判断に使うか」を追加時に言えることを条件にしてください。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。