うまくいくKPIマネジメント

私は、KPIの力をかなり信じています。

大げさに聞こえるかもしれませんが、KPIをうまく設計すれば、企業は変わります。

ただし、世の中で語られているKPI論には、大きな欠落があります。

それは、

そもそもKPIのデータが取れない

という現実です。

KPIのフレームワークは山ほどあります。

KGIから逆算しましょう。
KPIツリーを作りましょう。
インプットとアウトプットを分けましょう。
先行指標を見ましょう。
ダッシュボードを作りましょう。

どれも間違ってはいません。

しかし、現場ではその前で止まります。

データが存在しない。
定義されていない。
取れない。
取れても分解できない。
分解できても、行動につながらない。

ここに、誰も正面から向き合っていないように感じます。

私がこの問題に気づいたのは、Amazon時代の経験が大きいです。

当時、会社にはKPIがありました。
しかし、私にはそれが中途半端に見えました。

カテゴリー全体としての数字はある。
けれど、どのブランド、どのSKUというレベルのデータが無く現場のアクションにつながっていませんでした。

ブランドレベル、SKUレベルでデータを見るのに必要だったのは、SQLというプログラムでした。
だから私は、SQLを学び始めました。

自分でデータを取り、加工し、現場が動ける形に落とし込めれば、これは圧倒的な武器になると思ったからです。

実際にダッシュボードも作りました。

しかし、それだけでは不十分でした。

ビジネスリーダーたちは、なかなか動きませんでした。
彼らの関心は、季節性のバーゲンやメーカーとのタイアップ商品の開発に向きがちでした。

私は、それは違うと思いました。

顧客が本当に求めているものは、そこではない。
Amazonが大事にしていた基本は、価格、品揃え、配送でした。

その基本に沿ったインプットを改善しなければ、事業は変わらない。

だから私は、ビジネス責任者になりました。

自分でKPIを設計し、自分でチームを動かしました。

その結果、事業は大きく改善しました。

この経験から、私は一つの結論を持っています。

KPIは、レポートのための数字ではありません。
事業を動かすための経営仮説です。

KPIは、管理指標ではありません

多くの会社で、KPI管理が行われています。

ダッシュボードがあり、毎週レポートが更新され、会議では数字が共有される。

しかし、その一方で、

「KPIが多すぎて、何を見ればよいかわからない」
「数字は見ているが、行動が変わらない」
「ダッシュボードはあるが、誰も見なくなった」

という話もよく聞きます。

なぜ、こうなるのでしょうか。

私は、その理由はシンプルだと思っています。

KPIを、「管理指標」として扱っているからです。

もちろん、KPIは管理にも使えます。

しかし、本質はそこではありません。

KPIとは、

「この行動を変えれば、結果が変わるはずだ」

という経営仮説です。

だから、KPI管理の本質は、数字そのものではありません。

仮説の精度です。

KPIは、アウトプットから逆算して作ります

KPIを設計する時、多くの会社はいきなり数字を並べ始めます。

CVR。
CPA。
NPS。
LTV。
継続率。
解約率。
商談化率。

しかし、本来は順番が逆です。

まず決めるべきは、最終的に何を実現したいのかです。

売上なのか。
利益なのか。
継続率なのか。
顧客満足度なのか。

ここが曖昧なままでは、KPIも曖昧になります。

例えば、マーケットプレイス事業で考えてみます。

出店者数を増やしたいのか。
流通総額を増やしたいのか。
利益率を改善したいのか。
顧客満足度を高めたいのか。

ここが違えば、見るべきKPIは変わります。

営業組織でも同じです。

売上最大化なのか。
利益率改善なのか。
既存顧客深耕なのか。
新規開拓なのか。

アウトプットが曖昧なままKPIを作ると、組織は簡単に迷走します。

だから、最初に問うべきことは一つです。

この事業で、最終的に何を変えたいのか。

ここが決まらなければ、KPIは決まりません。

KPIとは、「最も効くインプット」の仮説です

アウトプットが決まったら、次に考えるべきは、

「何がその結果を最も強く動かしているのか」

です。

ここが、KPI設計の中心です。

例えばECなら、

品揃え。
欠品率。
配送速度。
価格競争力。
レビュー数。

このうち、どれが売上や利益に最も効いているのか。

SaaSなら、

オンボーディング完了率。
初回利用率。
サポート応答時間。
主要機能利用率。

このうち、どれが継続率を最も動かしているのか。

営業なら、

有効商談数。
決裁者接触率。
提案提出数。
フォロー速度。

このうち、どれが受注率を最も動かしているのか。

つまり、KPIとは、

「このインプットを改善すれば、アウトプットが改善するはずだ」

という仮説なのです。

だから、KPI管理とは本来、仮説検証です。

KPIは、基本的にインプットで置きます

ここで重要なのが、インプットとアウトプットを分けることです。

売上。
利益。
継続率。
解約率。

これらは重要です。

しかし、多くの場合、現場は直接動かせません。

「売上を上げる」
「利益を改善する」

これは結果です。

一方で、

欠品率。
提案提出数。
問い合わせ初回応答時間。
オンボーディング完了率。

これらは、現場が直接動かせます。

だから、KPIは基本的にインプットで置くべきです。

ここでよくあるのが、

「結果指標を追い続けているのに、現場の行動が変わらない」

という状態です。

売上だけを見ても、行動は変わりません。

重要なのは、

「その売上を動かしている行動は何か」

を特定することです。

ただし、アウトプットを見なくてよいという意味ではありません。

むしろ、アウトプットの確認は必須です。

なぜなら、インプットKPIは仮説だからです。

このインプットを改善すれば、結果が良くなるはずだ。

そう考えてKPIを置く。

であれば、その仮説が正しかったかどうかを、アウトプットで確認しなければなりません。

インプットだけを見ると、活動管理になります。

アウトプットだけを見ると、結果報告になります。

うまく行くKPIマネジメントでは、インプットで行動を変え、アウトプットで仮説を検証します。

KPIの選定基準は、Mustだけにします

KPIが増えすぎる会社は、たいてい「Nice to have」を入れています。

見られたら便利。
あった方が安心。
一応、参考情報として置いておく。
誰かが気にしているから残しておく。

こうしてKPIは増えていきます。

しかし、KPIのKは Key です。

本当に見るべきなのは、Mustだけです。

私は、KPIに入れるべき条件は3つだと思っています。

この3つを満たさないものは、KPIではありません。

参考指標です。

見ること自体は悪くありません。

ただし、KPI一覧に入れるべきではありません。

Nice to haveをKPIに入れた瞬間、組織の集中力は薄まります。

KPI管理とは、数字を増やすことではありません。

「見てもよい数字」と「必ず見る数字」を分けることです。

KPIが増えすぎる理由は、「仮説」がないからです

KPI管理がうまく行っていない会社ほど、KPIが増えます。

なぜでしょうか。

仮説がないからです。

本来、「最も効くインプット」は限られています。

しかし、それがわからない。

だから、とりあえず全部見ます。

CVRも見る。
CPAも見る。
CTRも見る。
NPSも見る。
リード数も見る。
商談化率も見る。

その結果、KPIが増殖します。

しかし、本当に重要なのは数ではありません。

「どのインプットが、最もアウトプットを動かすのか」

です。

ここを外すと、KPI管理はただの数字収集になります。

KPIが多い会社は、数字に強い会社ではありません。

むしろ、何が重要かを決め切れていない会社です。

KPIが目的化する罠があります

さらに危険なのが、KPIそのものが目的化することです。

例えば、マーケットプレイス事業で、

「出店者数」

をKPIにしたとします。

これは考え方としては間違っていません。

出店者数は、流通総額や品揃えにつながるインプットだからです。

しかし、KPIが目的化すると問題が起きます。

出店者数を増やすこと自体が目的になり、

売れない出店者ばかり集める。
審査を甘くする。
アクティブ率の低い店舗が増える。

ということが起きます。

結果として、

出店者数は増えた。
しかし、流通総額は増えていない。
利益も改善していない。
顧客満足度も上がっていない。

これは非常によくある失敗です。

だからこそ、アウトプットの確認が必要です。

インプットKPIは仮説です。

だから、

売上は増えたのか。
利益は改善したのか。
顧客満足度は上がったのか。

を確認し続けなければなりません。

企業活動は、最終的には、

売上、利益、顧客満足度

につながっていなければ意味がありません。

KPIは、そのための手段です。

手段が目的化した瞬間に、組織は間違った方向へ進みます。

良い仮説と悪い仮説の違い

では、良いKPI仮説と悪いKPI仮説は、何が違うのでしょうか。

私は、良い仮説には3つの条件があると思っています。

一つ目は、因果が説明できることです。

例えば、

「出店者数を増やす」

だけでは弱い。

「売れる出店者数を増やすことで、品揃えが改善し、購入率が上がり、流通総額が増える」

ここまで説明できて、初めて仮説になります。

二つ目は、検証可能であることです。

いつまでに。
どの数字が。
どの程度動けば。

仮説が正しかったと言えるのか。

これが曖昧なものは、仮説ではありません。

願望です。

願望は、反論されにくい。
しかし、検証もできません。

だから、願望をいくら並べても、事業は動きません。

それはKPI管理ではなく、願望の管理です。

三つ目は、外れた時に修正できることです。

KPI管理とは、最初から正解を当てることではありません。

間違った仮説を、早く捨てることです。

だから、仮説の精度は最初から高い必要はありません。

精度を高め続ける仕組みが重要なのです。

KPI仮説は、現場観察から始まります

ここで、多くの経営者が誤解していることがあります。

データを見れば、重要なKPIがわかると思っていることです。

しかし、私は逆だと思っています。

データは、仮説を検証するものです。

仮説そのものは、現場観察から生まれます。

例えば、

「過去1年で、最も業績が良かった時期はいつか」

を考えてみます。

多くの場合、

「あの時は市場環境が良かった」
「大型案件が入った」
「キャンペーンが当たった」

という説明になります。

もちろん、それも一因かもしれません。

しかし、本当に重要なのは、

その時、現場が何を変えていたのか

です。

営業は誰に会っていたのか。
どの顧客に時間を使っていたのか。
何を優先し、何を捨てていたのか。
オペレーションは何が違ったのか。

ここを掘ると、必ず変化があります。

逆に、業績が悪化した時も同じです。

売上が落ちる前に、現場の行動はすでに変わっています。

重要顧客への訪問頻度が落ちていた。
問い合わせ対応が遅れていた。
欠品対応が後回しになっていた。
新規顧客ばかり追い、既存顧客対応が弱くなっていた。

売上は最後に出る結果です。

その前に、必ず現場の行動変化があります。

だから、最初のKPI仮説は、

「業績が良かった時、現場は何をしていたのか」
「業績が悪化する前に、何が変わっていたのか」

を観察するところから始まります。

つまり、KPI管理の出発点は、ダッシュボードではありません。

現場観察です。

そして、データは、その仮説を検証するために使う。

ここを逆にすると、KPI管理は失敗します。

データだけを見ている組織は、必ず「見える数字」に引っ張られます。

しかし、本当に重要な変化は、最初は数字になっていないことが多い。

だから、優れた経営者は、現場を見ます。

データだけではなく、

「現場で、何が変わったのか」

を見ています。

KPI管理が失敗する本当の理由

KPI管理が難しい理由は、もっと構造的です。

KPIを設計する人と、データを取れる人が分断されているからです。

多くの場合、KPIを考えるのは経営企画です。

しかし、経営企画がSQLを書けるとは限りません。

すると、自分でデータを取れません。

開発部門やデータ部門に依頼することになります。

しかし、そこで、

「データ基盤の整備が必要です」
「要件定義をお願いします」
「来期のロードマップで検討します」

という話になります。

その結果、「今あるデータで見られるもの」に議論が引っ張られます。

本当は、

「どの行動が利益を動かしているのか」

を知りたかったはずなのに、

「今のシステムで取れる数字は何か」

に変わってしまう。

ここで、KPI管理は機能しなくなります。

本来は逆です。

事業上の問いが先にある。
その問いに答えるために、データを取りに行く。

これが、本来の順番です。

提言：経営企画にエンジニアを置くべきです

KPI管理を本気でやるなら、経営企画部のITリテラシーを圧倒的に引き上げる必要があります。

私は、その現実的な打ち手の一つは、

経営企画部にエンジニアを置くこと

だと思っています。

KPI管理が失敗する大きな理由は、経営の問いとデータ取得が分断されていることです。

経営企画は、

「どの施策が利益に効いているのか」
「どのインプットが継続率を動かしているのか」
「どの顧客群で異常が起きているのか」

を知りたい。

しかし、自分たちでデータを取れない。

開発部門に依頼すると、数ヶ月から一年かかる。

その間に、事業環境は変わります。

結果として、

「本当に知りたい問い」

ではなく、

「今あるデータで見られる数字」

に議論が合わせられてしまう。

ここで、KPI管理は弱くなります。

将来的には、ノーコードやAIによって、データ取得は今より簡単になるかもしれません。

しかし、それでも問題は残ります。

存在しないデータは取れません。

定義されていないデータは使えません。

入力されていない項目は分析できません。

例えば、顧客の流入経路を後から分析したくても、最初から記録していなければ取れません。

解約理由を分析したくても、解約時に理由を分類していなければ取れません。

商談の質を見たくても、決裁者接触や提案内容が記録されていなければ取れません。

つまり、重要なのはツールそのものではありません。

何を記録するべきか。
どの粒度で持つべきか。
どのアウトプットを検証するために、どのインプットを取るべきか。

を考える力です。

そのためには、経営企画がITやデータを「依頼する側」に留まっていてはいけません。

事業の問いを、データに翻訳できる必要があります。

KPIが報告資料で終わる瞬間を、私は何度も見てきました

WalmartやZARAのような会社では、数字が現場の行動を変えています。

数字を見る。
原因を掘る。
補充、生産、配分、営業活動を変える。

このループが回っています。

一方で、私が見てきた多くの会社では、KPIが報告資料の中で止まっていました。

数字を作る。
資料にまとめる。
会議で説明する。
承認を得る。

ここまでは非常に丁寧に行われます。

しかし、その後に、

「では、現場の行動をどう変えるのか」

という問いが抜け落ちる。

これでは、KPIは事業を動かしません。

数字はある。
会議もある。
説明もある。

しかし、翌週の現場の行動は変わっていない。

この状態を、私は何度も見てきました。

もう一つ、よくあるのは、仮説が外れることを避けるために、最初から曖昧なKPIを置いてしまうことです。

明確な仮説を置けば、当たったか外れたかがわかります。

しかし、外れた時に責任問題になる組織では、人は検証可能な仮説を立てにくくなります。

その結果、

「顧客満足度を高める」
「営業力を強化する」
「収益性を改善する」

といった、誰も反対しないが、誰も検証できない言葉が増えていきます。

これでは、KPI管理ではありません。

願望は、検証されない限り、いつまでも綺麗な言葉のまま残ります。

それは、願望の管理です。

さらに、現場観察よりも資料作成が優先されることも多い。

本来、見るべきなのは、

「現場で何が変わったのか」

です。

しかし、会議資料作成が目的化すると、現場を見る時間より、資料を整える時間の方が増えていきます。

そして、綺麗な資料ほど、時に現場から遠くなります。

私は、それでは企業は変わらないと思っています。

KPIは、経営者を説得するための資料ではありません。

現場の行動を変えるための道具です。

この違いを間違えると、KPI管理は必ず形骸化します。

KPI管理の本質

多くの会社では、KPIを「管理指標」だと思っています。

しかし、私は違うと思っています。

KPIとは、

「この行動を変えれば、結果が変わるはずだ」

という経営仮説です。

だから、KPI管理の本質は、数字ではありません。

仮説の精度です。

そして、本当にうまく行くKPIマネジメントとは、数字を並べることではありません。

正しい仮説を持つこと。
Mustの指標だけに絞ること。
現場を観察すること。
現場の行動を変えること。
アウトプットで検証し続けること。

この一連の仕組みを作ることです。

企業は、戦略だけで変わるわけではありません。

現場の行動が変わって、初めて変わります。