私は業務で、KPIを管理するシステムの保守開発運用をしているエンジニアだとそう思っていた
しかし実際にやっていることを振り返ると、
どうもそのKPIは「意思決定のための指標を設計開発する」ではなく、「数値を都合よく並べ替えるゴーストライター的な開発」 に近い気がしてきた
業務内で「これは本当にKPIなのか？」という違和感が消えなかった
この記事では、KPIを定義から整理し直し、
なぜ現場でKPIがKPIとして機能しなくなるのかを言語化しようと思う
KPIとは何か
KPIは Key Performance Indicator の略である。
- Key：重要であること
- Performance：成果に関するものであること
- Indicator：行動や判断を変える指標であること
重要なのは、KPIは
「見るための数値」ではなく
「行動を変えるための数値」
KGIとKPIの関係
KPIは単独では存在できない。
必ず KGI（Key Goal Indicator） が先に必要になる
- KGI：最終的に達成したいゴール
- KPI：そのゴールに近づいているかを判断する途中指標
KGIが曖昧なままでは、
KPIは「それっぽい数値」にしかならない
KGI → KPI → 行動 の関係
KPIは、次のような一直線の関係を持つ
[KGI]
↓（達成したいゴール）
[KPI]
↓（判断・評価）
[行動]
もう少し具体的に書くと、
売上を伸ばす（KGI）
↓
新規顧客の月間獲得数（KPI）
↓
広告予算を増やす／施策を変更する（行動）
KPIは、
行動が変わらない限り成立しない
KPIが成立するための前提条件
KPIがKPIとして機能するためには、最低限次の条件が必要になると思っている
- 目的（KGI）が固定されていること
- 成果との因果関係が仮説として合意されていること
- 一定期間、定義を変えない覚悟があること
- KPIを見て取る行動が決まっていること
どれか一つでも欠けると、KPIはただの数値になる
なぜ現場ではKPIが壊れるのか
意見がコロコロ変わる
- 見たい数値が頻繁に変わる
- 定義がその場で変更される
- 十分な期間を待たずに評価する
これは改善ではなく、
観測条件を変え続けている状態である
「欲しい結果」だけが渡される
- 結果は指定される
- なぜその結果なのかは共有されない
- どう測るかは決まっていない
KPI設計とは、本来
仮説設計そのものである
仮説が存在しないままでは、KPIは成立しない
KPIが安心材料になる
- 数値があると安心する
- グラフが整うと納得する
- しかし行動は変わらない
この状態では、KPIは
意思決定のための指標ではなく
説明のための装飾
になっている
定義から見た「KPIではなくなる瞬間」
KPIを定義に照らして見ると、壊れるポイントは明確である
- Key：重要度が毎回変わる時点でKeyではない
- Performance：成果との関係を説明できなければPerformanceではない
- Indicator：行動が変わらないならIndicatorではない
多くの場合、
KPIという名前が付いているだけで、
中身は単なるダッシュボードである
BIツールの問題ではない
PowerBIを含むBIツールは中立である
問題はツールではなく、
- 定義を決めないまま可視化すること
- 決めきれない状態を数値で覆い隠すこと
可視化は、思考を代行しない
ゴーストライター化する瞬間
数値は作る
だが、意味付けや意思決定は他人
ストーリーを語るのも別の人
気づけば、
数値という文章を書くが、
名前は載らないゴーストライター
のような立場になっていた
結論：KPIを作る前にやるべきこと
KPIを作る前に、次の問いに答える必要がある
- 何を達成したいのか（KGI）
- 何が変われば成功と言えるのか
- 数値を見て、誰が、何を決めるのか
これが決まらないなら、KPIを作らない方が良いと思った。 会社内でこの知識を持っている人が多いことを願う