KPIの設計_Vol.1　KPI設計のフレームワーク

今回からは、前回の「KPIで予算達成度とその再現性を高めよう」の続きとして、どのようにモデリングすればいいのか（KPIの設計）について、複数回にわけて書き進めていこうと思います。

KPIツリーのアウトライン

KPIを設計するときに欠かせないフレームワークが「KPIツリー」です。
KPIツリーは、ロジックツリーの一種です。

ロジックツリーとは、ある事柄に対して、それを構成している要素をツリー状に分解して可視化したものです。

KGIを頂点として、それを実現するための要素をKPIで分解し、ロジックツリーに表現したものがKPIツリーです。

KPIツリーをつくる手順は大雑把に言えば次のとおりです。

Step.1　最終的に達成したい目標であるKGIを決める

まず、KPIツリーの頂点となるKGIを決めます。
KGIは、最終的に達成したい目標です。
事業全体または会社全体のKGIとしては、「売上」や「利益」が設定されることが多いです。

Step.2　KGIをKPIでロジックツリー状に分解する

Step.1で決めたKGIを起点に、それを実現するための要素をKPIとして抽出し、ロジックツリー状に分解していきます。
左端にKGIを置き、右側に樹形図を伸ばしていきます。
KGIを達成するために重要と考えられるKPIを抽出し、どんどん分解していきます。

KPIツリーのメリット

KPIツリーのフレームワークを使ってKPIを設計することの主なメリットは、次のとおりです。

メリット1　漏れなくダブりなくKPIを抽出できる

KPIツリーを使ってKPIを設計することで、KGIを構成するKPIを漏れなくダブりなく抽出しやすくなります。
そうすると、今まで見えていなかったKPI、すなわち目標（KGI）達成につながる要素が浮き彫りになります。

メリット2　事業の全体像やKPI同士の関係がわかりやすい

KPIが同列に列挙されているより、KPIツリーの形で並んでいる方が、ビジネスの全体像やその中でのKPI同士の因果関係がわかりやすいです。
たとえば、契約数の達成状況が悪かったときに、その原因を探るには、そのすぐ下の階層を見ればわかります。
契約数のすぐ下の階層で「成約率」と「商談数」に分解されているとすると、契約数の達成状況が悪い原因は、「成約率」か「商談数」のどちらかに問題があるはず、という因果関係が生じています。
因果関係がわかれば、KGIの達成に向けて「どこに課題があるのか」「どこに注力していけば良いのか」は一目瞭然です。

つまり、KPIツリーのこのメリットをPDCAに沿って整理すると、

• KGI達成に向けた要素（KPI）が明確になる（Planの精度が上がる）

• KGIを達成した時、または未達成だった時に、その要因がどのKPIにあるのかの検証がしやすい（Checkの精度が上がる）

• KGIが未達成になりそうな時、どのKPIに注力して改善することで挽回できるのかがわかりやすい（Actionの精度が上がる）

といったメリットがあります。

KPIツリーの基礎知識

KPIツリーを作り始める前に、いくつか注意点があります。

注意点1　四則演算でつなげる

分解前のKPI（ロジックツリーの上位階層）と分解後のKPI（ロジックツリーの下位階層）はすべて四則演算、すなわち足し算（＋）、引き算（－）、掛け算（×）、割り算（÷）でつなげます。

そのメリットは以下のとおりです。

• 漏れなくダブりなくKPIを抽出できます。

• KGIの目標値とKPIの目標値を紐付けやすくなります。

• KPIの数値が変動した場合に、KGIにどのように影響が出るかを簡単に測定できます。

四則演算を使って分解した場合、たとえば「顧客満足度」というKPIは、KPIツリーの中に出てきません。
なぜなら、顧客満足度は定量化しづらい上に、仮に定量化できたとしても、その数値が「1」変動したら、他のどのKPIがどれくらい変動するかを表せず、四則演算で他のKPIとの関係を定義できないからです（ただし、「顧客満足度」というKPIが重要ではないということではありません）。

このように、KPIツリーをつくることでKPI同士の関係がわかりやすくなりますが、四則演算を使って分解していくことで、さらにKPI同士の関係がわかりやすくなります。

複数人／複数部門でKPIを活用してPDCAをまわしていくには、「誰にとってもわかりやすくて共通認識が持ちやすい」PDCAであることが大切です。

四則演算以外の複雑な数式を使って分解すると、「誰にとってもわかりやすい」という特徴が失われるので注意が必要です。

注意点2　単位に注意する

「円」「千円」「%」「人」「回」などの単位を間違えないように注意します。

掛け算、または割り算で分解した場合、分解前のKPIの単位と、分解後のKPIのいずれかの単位が同じ単位になります。
足し算、または引き算で分解した場合、分解前のKPIの単位と、分解後のすべてのKPIの単位が同じ単位になります。

注意点3　計測可能

KPIとして適した条件は、「数値化できて計測できる」「コントロールができる」「関係者の同意が得られる」ことです。
この中でも特に「数値化できて計測できる」という条件が大切です。

せっかくKPIツリーをつくっても、それを計測できなければ、どのKPIに問題があるのかがわかりません。
そこで次の3つを意識しながらKPIツリーをつくります。

KPIに適した条件1　数値で計測できる 

たとえば、前述の通り、「顧客満足度」は数値で計測しづらいものかもしれません。
計測できなければ、そのKPIの現状が目標に対して「良い」のか「悪い」のかの基準が曖昧で、その基準が関係者間で異なっていると、意見が食い違って共通認識が持ちづらくなります。
KPIツリーをつくるときは、個々のKPIを「客観的な数値で定量的に計測できるのか」に気をつけます。

 KPIに適した条件2　データとして入手できる

たとえば、顧客数について、「新規の顧客数」と「リピートの顧客数」に分けてデータを取っていなかった場合、「やろうと思えば分けてデータを取ることができる」のか、それとも「どう頑張っても分けてデータを取れない」のかによってKPIツリーは変わってきます。
前者であれば、「顧客数」を「新規の顧客数」と「リピートの顧客数」に分けてKPIツリーをつくれますが、後者であればそれができません。
KPIツリーをつくる過程で出てきた各KPIについて、データを実際に取れるのかどうかは重要です。

KPIに適した条件3　手間をかけてでも入手すべき価値がある

さきほどの「新規の顧客数」と「リピートの顧客数」のデータについて、「やろうと思えば分けてデータを取ることができる」とします。
その場合、次に考えるのは、手間をどこまでかけるかです。
手間をかけてでも入手した方がよいのであればKPIツリーの中に入れるべきですし、手間をかけてまで入手するほど重要なKPIではないのであればKPIツリーの中には入れないでおきます。

注意点4　定義を明確にする

KPIの定義が関係者間で異なることも多いです。
管理部が営業部に「商談数」のデータを依頼したものの、届いたデータの「定義」の認識がお互いに食い違っていて、その内容を確認するのに双方手間がかかるということが起こりがちです。

一口に「商談数」といっても、どの時点の商談を意味するのかによって、出てくる数値が変わります。
たとえば、「最初に訪問したとき」「商品・サービスの説明したとき」「見積書を出したとき」など、その「定義」はいろいろ考えられます。

このように、KPIの意味するところは、チームによって、または人によって、解釈が異なることが多いです。
そうすると、どの定義で取得したデータなのか、一つひとつ確認しないといけません。

管理部が欲しい商談数のデータと、営業部が依頼されたと思っている商談数のデータの定義が食い違ってしまうと、その確認にお互い手間がかかるだけでなく、誤った判断につながりかねません。

これは管理部と営業部というような部門間の話だけではなく、営業部の部門内でも、メンバー間の定義がバラバラだと同じことが起こります。

なお、KPIの定義は「フロー」か「ストック」かによっても変わってきます。

フローとは、たとえば、「今月新しく発生した商談の数」です。
つまり、特定の「期間」に増えた数や減った数を意味します。

一方、ストックとは、たとえば、「今月末時点で商談中になっている数」です。
こちらは、特定の「時点」でその状態にある数を意味します。

この場合は、「今月新しく発生した商談で、今月末時点でまだ商談中のステータスにある商談の数」だけではなく、「前月までに新しく発生していた商談で、今月末時点においてもまだ商談中のステータスにある商談の数」を含みます。

どちらの定義かによって全く異なる数字になります。

関係者間で各KPIの定義をすり合わせて、その上でコミュニケーションできるようにします。
具体的には、KPIツリーで設計したKPIごとに、関係者間ですり合わせた定義を辞書のようにテキストで明記しておくといいでしょう。

次回に向けて

今回はKPIツリーの基礎知識のお話でした。
次回はKPIツリーを実際につくるときの各種のポイントについてです。
「KPIの設計_Vol.2　トップダウン？ボトムアップ？」をぜひご覧ください。

当社では、予実管理の精度を高めるクラウドシステム「Scale Cloud」を提供しています。
一般的な予実管理システムとの違いは、①結果指標だけでなく先行指標のKPIも集約してPLの予実管理と紐付けられ、②KPIの設計と運用のコンサルティングサポートがついていて、③料金は2分の1以下（月額10万円から）です。
Scale Cloudが管理部と事業部の共通のプラットフォームとなり、予実の達成や未達成の要因がどの部門のどのKPIにあるのかの共通認識を持ちながら議論し、一緒に予算達成に向けてPDCAを促進することができます。
少しでも興味を持っていただけたら、ぜひWebサイトをのぞいてみてください。

書籍を出版させていただいています。
起業してからの約１７年間で多くの企業とお付き合いさせていただきましたが、成長する企業や組織には、「数値の大切さを知っている」という共通点があるように思います。
単に知っているだけではなく、数値を使って事業の状況を客観的に見て、考え、意思決定して行動することが習慣化（仕組み化）されていました。
本書では、KPIという数値を活用して、ロジカルに、スピーディーに、組織的に、PDCAをまわす仕組みを書いています。
事業目標を達成するための仕組み、さらに、その目標達成を一時的なもので終わらせるのではなく、継続的に達成し続けることができる仕組みづくりを、具体的に実践することにこだわって書いていますので、少しでもみなさまのご事業のお役に立てれば幸いです。

X（旧Twitter）のフォローもぜひよろしくお願いします。https://twitter.com/hirose_yoshi