[中間管理職の中期／事業計画の進め方]#8 KPIを設定しよう
KPIの設定
中期計画や事業計画を作っていく中でKPIという言葉をよく聞くと思います。
KPIはKey Performance Indicatorの頭文字をとったもので、日本語では”重要業績評価指標”や”重要達成度指標”といわれています。
この記事では中間管理職という立場で考えると業績というよりは重要達成度指標のほうがしっくりくるかもしれません。
KPIに似た言葉としてKGIというものもあります。Key Goal Indicatorの略で最終ゴールの指標として使うものです。イメージ的にはKPIは進捗を管理するための指標、KGIは最終的になっている状態の指標という感じになると思います。いずれも測定できる指標というのがポイントになります。
測定できる指標
測定できる指標というと、売上とか利益といった数値として出せるもののイメージが多いと思います。また、設計でも不具合件数や開発日程といったところを指標に置くようなケースもあると思います。
いずれも測定できる仕組みがあるということが重要になります。
売上や利益の指標は経営としても重要なので測定できるというよりは、しないといけない指標といえます。
不具合件数はどうでしょう。件数を数える以前に不具合の定義を決めていく必要がありますし、件数のカウント方法や管理方法といったことも決めないと測定できるとは言えないということになります。
目標を達成するためにKPIとして指標を置いたとして、測定できる必要がありますが、あくまで目標を達成に対して進捗を見える化するということなので、業務に沿ってやっていけば測定できるというのが重要で、測定のための業務を作るというのがは本来は避けるほうがいいと思います。
目的に近づくことが確認できるか
KPIは目標に対して達成できそうかを見ていく指標になりますので、目的にあっているかを見ていく必要があります。
開発において設計不具合を減らしたいとした場合に、不具合件数をKPIと置くというのは、一見わかりやすい指標ですね。
ただ、これを色んな立場で見た時にこの指標が目標達成に向けた進捗としてあっているかというのを考えていく必要があります。
例えば、製品化を担っている部署であれば製品に直結する不具合をKPIとして管理して製品の品質がどうかを見ていくということはあっています。
設計部署ではどうでしょうか？
不具合件数というのは結果としては管理すべきだと思いますが、不具合削減に向けてとした場合に適切かどうか。結果としての不具合件数というのはゴールであって、KPIとするのは不具合削減に向けた活動を見えるかするというのはどうでしょうか？
不具合を削減するためにFMEAを取り入れたとしたら、そのカバレージを指標化するであるとか、シミュレーションの強化ということを挙げたとすると、バグだし件数(シミュレーションで未然に防ぐことができた)としてみたり、レビューでの指摘件数によって見落としを防ぐといったことも考えられます。
つまり、部とか課のレベルでは目標を達成するために行う行動がしっかり測定できるということがKPI設定のポイントになります。ここを意識するだけでも格段に意識が変わって自分事のKPI指標となります。
行動すれば達成できるか？
組織のKPIとするときにもう一つ気を付けたほうがいい点として、自分たちでコントロールができるかどうか？です。全てではないにしても自分たちが行動すればKPIの指標に影響するということがポイントになります。
特に組織の責任範囲が狭い場合は大きな目標に対して自分たちの関与が小さくなりがちです。そうなるとKPIに対して、頑張ったど達成できなそう、逆にうまくいかないけど、他でやってくれる部分がほとんどなので達成できてしまった。
そうならないように自分たちでコントロールができる部分を見極めて設定する必要があります。
ただし、すべて自分たちでコントロールできてしまうということでは逆に良くない点も多いと感じます。今の世の中はいろんな人とのかかわりの中で仕事を行っていくので、他部署との影響を自分たちも感じながら仕事をするということは重要ですし、そこをおろそかにしてしまうと、自分たちの責任だけ守ればいいといったようなことに陥ることになるので、他と責任を分かち合いながら、自分たちのコントロールできる部分を認識して進めるということが重要です。
また、他への影響を意識できたら、そこへ自分たちがどう関与すればより目標に近づけるかと考えることが重要になります。
今は分業化が進んで、効率化重視となりますが、そんな時にこそ繋がりの部分を気にするということは成功への重要なポイントになります。
(計画を立てるということに直接関係はないかもしれませんが、実感も含めてここ最近、ここの重要性を感じています。
少し上の目標設定を
ここまでの話を踏まえてKPIを設定するわけですが、目標の目線をどうするかが重要になります。KPIは評価の指標になりますので、保守的につけがちになります。KPIの難易度の面でも評価していくことが大切になります。
簡単な目標値で達成したからいいのか、難しい目標をぎりぎりで達成出来なかったら評価が低いのか。ここはぜひ、できる目標の少し上に設定してみることをやってもらえればと思います。
この少し上の目標というのはKPIを自分たちのコントロールできる部分が多いものにしようといっていたように、あと少しを自分たちの努力で達成できるかことにつながりますので、モチベーションにもつながります。
PDCA
KPIは設定して終わりではなく、どのように達成していくかが重要になります。事業計画だと１年間、中期計画だと３年や５年の中で活動をアクションプランとして設定すると思いますが、その際に意識することとしてPlan（計画）、Do（実行）、Check（評価）、Action（改善）を意識してやることです。はじめのうちはPDCAを明示的にアクションプランを書くといいと思います。
ここではPDCAの実行部分については非常にボリュームも大きくなるのでここでは触れずに別の機会にしようと思いますが、目標値に向かってこのサイクルをしっかり回すということが目標に近づくことになります。
最近ではOODAループという業務フレームワークもありますが、目標指標を決めて活動するという場合にはPDCAがあっていると思います。
OODAループについてもどこかで触れたいなと思いますが、PDCAに慣れた組織がOODAループを回そうとするとなかなか難しいと思います。明確な目標ではなく、方向性が決まっているようなケースではOODAループが合うケースがあるかと思います。
今回は目標が明確になっているケースなのでPDCAがやはりいいと思います。このあたりの違いも別の機会にまとめたいと思います。
Action Plan
最後にこれらをまとめ計画としましょう。
下記のようなテンプレを用意してみました。ポイントを書いていきたいと思います。
①重点項目 ”#6重点項目を設定する”で考えた項目が入ります。
②KPI この項で検討したKPIが入ります。
③担当 計画においては誰がというのを明示することは重要です。
④目的/⑤目標 Why/WhatはActionPlanを進める存在意義になりますので
必ず定義しましょう。
⑥結果の評価方法 KPIを測定できることを示します。
⑦現状と課題 現在の認識を合わせるための記載です。
⑧必要資源 必要リソース(人・物・金)を定義して実現性を確認します。
⑨リスク＆オポチュニティ ”#7幅で考える"で考えたものを入れましょう。
⑩マイルストーン PDCAを意識したマイルストーンを設定します。
フェーズがわかるように色分け等で明示することで
PDCAの意識づけをするのもいい方法だと思います。
⑪Action Plan 具体的なアクションを記載していきます。その際にタスクの
つながりやPDCAを意識して書くのがよいでしょう。
ここまでで計画としては終わりになります。次の最後の章では振り返りをしてみましょう。
#1 はじめに(2024/5/19公開)
#2 存在意義について考えてみる(2024/5/20公開)
#3 客観的/多面的な分析をする(2024/5/30公開)
#4 STPを考える(2024/6/9公開)
#5 目線をあげる(2024/6/15公開)
#6 重点項目を設定する(2024/6/24公開)
#7 幅で考える(2024/7/1公開)
#8 KPIを設定しよう(本投稿)
#9 計画と存在意義の一致(2024/7/13公開)
この記事が気に入ったらサポートをしてみませんか？