ふくふくHukuhuku Inc.
EP.22KPI 13分公開: 2026-09-01

指標の寿命 ── 使われなくなった KPI をどう畳むか

指標は増える一方で、減りません。見られていないダッシュボード、誰も反応しない数字。増えすぎた指標をどう整理し、どう畳むかを扱います。

#KPI#指標設計#運用#整理
執筆 / 監修
松尾 亮合同会社ふくふく 代表社員

データ基盤・データパイプライン構築 / BI / 生成 AI 活用支援を専門とするエンジニア (28 年)。 本記事は AI 利用ポリシーに基づき、生成 AI の補助で執筆 → 人間が監修・編集して公開しています。

プロフィール詳細
シェア

指標には増える力しか働きません。新しい施策のたびに追加され、やめる契機がない。結果として、誰も見ていない数字が並びます。

この回は、増えすぎた指標をどう整理し、どう畳むかを扱います。作る話ではなく、やめる話です。

1. なぜ増え続けるのか

増える理由は構造的です。どの段階でも、誰も悪くありません

指標が増え続ける構造
場面起きること
新しい施策が始まるその効果を見る指標が追加される
施策が終わる指標は残る
誰かが「これも見たい」と言う追加される
組織が変わる前の担当が作った指標の意図が失われる
消す判断誰の仕事でもない

2行目と5行目の組み合わせが本質です。追加する理由は都度発生するが、消す理由は発生しません。そして消して問題が起きたときだけ責任が生じるので、消さないのが合理的になります。

他の領域と同じ構造

これは レガシー再生の現場 EP.09 で扱った「現状維持は誰の責任にもならない」と同じです。残すコストは見えず、消すリスクは見えるという非対称が、あらゆる整理を妨げます。

2. 増えすぎると何が起きるか

指標が多いこと自体は無害に見えます。実際には害があります

  • 優先順位が付かない — 全部が同じ重みに見える
  • 異常に気づけない見る対象が多すぎて、変化を見落とす
  • 維持の手間が増える — 定義の変更、集計の修正
  • 信頼が下がる — 古い定義のまま残った指標が混ざる
  • 新しい指標が埋もれる — 本当に見るべきものが目立たない

2番目が最も実害があります。画面に30個の数字が並んでいると、1つが異常でも気づきませんLLM時代のテスト戦略 EP.11 で扱った「赤に慣れる」と同じで、見る対象が多いほど、見なくなります

4番目も深刻です。定義が古いまま残っている指標が混ざると、「この数字は信じてよいのか」という疑いが全体に及びます。1つの古い指標が、他の正しい指標の信頼まで下げます。

3. 使われているかを測る

整理の第一歩は、実際に使われているかを記録から確認することです。感覚で判断しないでください。

使われているかの確認
確認する記録分かること
ダッシュボードの閲覧回数見られているか
誰が見ているか1人だけなら、その人に確認
最終閲覧日いつから見られていないか
その指標を参照するクエリ自動処理から使われているか
会議での言及議事録に出てくるか

4行目を忘れないでください。人が見ていなくても、自動処理が参照していることがあります。消す前に、参照している処理がないかを確認します。

5行目は定性的ですが有効です。会議で一度も言及されない指標は、実質的に使われていません。議事録を検索すれば分かります。閲覧記録では「開いた」ことしか分かりませんが、言及されたかどうかは「判断に使われた」ことを示します。より強い証拠になります。

参照されていない指標を洗い出す
SQL
-- ダッシュボードの閲覧記録から、見られていないものを探す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. 1候補を一覧にする — 記録にもとづく
  2. 2作成者や関係者に確認する — 意図が残っているかもしれない
  3. 3非表示にして様子を見る — 消さずに隠す
  4. 4一定期間、反応がなければ消す — 1〜3か月
  5. 5定義と算出方法は残す後から復元できるように

3番目が有効です。非表示にして誰も気づかなければ、実際に使われていなかったということです。レガシー再生の現場 EP.10 で扱った「止める前に鳴らす」と同じ手法です。

5番目を忘れないでください。指標の定義と算出方法は、消さずに残します。数年後に「あの数字をまた見たい」と言われたとき、定義が残っていれば復元できます。表示をやめることと、定義を捨てることは別です。

「作った理由」も一緒に残す

定義だけでなく、なぜその指標を作ったかも残してください。エンジニアの引き継ぎ術 EP.04 で扱ったとおり、判断の理由は書かなければ失われます。復元するとき、意図が分かれば判断が速い。

5. 増やさない仕組み

整理しても、放っておけばまた増えます。追加時に条件を付けると、増え方が緩やかになります。

  1. 1追加するときに、見直す時期を決める — 「この施策が終わったら畳む」
  2. 2誰が見るかを明記する — 見る人がいない指標は作らない
  3. 3どの判断に使うかを書く使い道が言えないなら作らない
  4. 4既存の指標で足りないか確認する — 似たものがないか
  5. 5上限を決める — 「この画面には8個まで」

3番目が最も効きます。「この数字がこう動いたら、こうする」が言えないなら、その指標は見ても行動が変わりません。これは ── 数字は増えるが判断に結びつかない指標 ── を避けるための問いでもあります。

5番目は強引ですが有効です。上限があると、追加するときに何かを外す判断が発生します。「足すだけ」ができなくなるので、優先順位を考えざるを得なくなります。データ屋の道具箱 EP.24 で扱った「何を置き換えるかを問う」のと同じ発想です。増えるものには、足すときに引く仕組みが要ります。

6. 定期的な棚卸し

最後に、継続する仕組みです。一度整理しても、半年後には元に戻ります。

棚卸しの頻度
頻度やること
四半期閲覧記録から候補を出す(自動でよい)
半期候補を関係者と確認し、非表示にする
年次指標の体系そのものを見直す
施策の終了時その施策のための指標を畳む

最下行が最も自然な契機です。施策が終わったときに、その指標も一緒に畳む。これを習慣にすれば、大きな棚卸しの必要が減ります。

3行目の年次の見直しでは、事業の段階が変わっていないかを確認してください。次回(EP.23)で扱いますが、成長段階によって見るべきものは変わります。同じ体系を使い続けるほうが不自然です。

ここまでのまとめ

指標は増える力しか働かない(追加の理由は都度発生し、消す理由は発生しない)。増えすぎると異常に気づけなくなるのが最大の害。整理は記録から使われているかを確認し、非表示にして反応を見る。消しても定義と作った理由は残す。増やさないためには、「どの判断に使うか」を追加時に言えることを条件にしてください。

シェア

この記事の感想を教えてください

あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。

シリーズの外も探す:

まずは、現状を聞かせてください。

要件が固まっていなくて大丈夫です。現状診断と方針提案までを無料でお手伝いします。

無料相談フォームへ hello [at] hukuhuku [dot] co [dot] jp