機能部門や管理部門の業績評価は "状態成果" で評価する!
人事評価制度を設計する際に、業績評価の設計をしていると、多くの企業が同じような悩みに直面します。
営業部門の業績評価は比較的評価しやすい。売上、粗利、受注件数など、成果を表す数字が存在するからです。製造部門や物流部門などコストや商売に直結する部門も業績評価はしやすい。しかし、品質保証部門、技術企画部門、人事部門、経理部門などの機能部門(間接部門)になると、「何を成果として評価すればよいのか分からない」という声が聞かれるようになる。その結果、多くの企業では無理にKPI(業績指標)を設定しようとします。
例えば、人事部門であれば研修実施回数や面談回数、開発部門であればレビュー件数や不具合件数、管理部門であれば会議開催回数や報告書作成件数などが設定されています。
しかし、本当にそれらは成果なのでしょうか。
研修を10回実施したとしても、人材が育っていなければ意味はない。レビュー件数が増えたとしても、品質が向上していなければ意味はない。会議を何回開催しても、組織運営が改善されなければ成果とは言えない。
つまり、多くの企業で起きている問題は、「測定できるもの」と「評価したいもの」を混同していることにあります。本来、人事評価制度における業績評価は、担っている役割における成果を評価するための仕組みです。したがって、最初に考えるべきことは、「何が測定できるか」ではなく、「その役割は何に責任を持っているのか」です。そして、多くの企業には、この視点が欠落しています。
私は業績評価の制度設計をする際は、まず "役割が負っている責任" を二つに分けて考えています。
一つは成果責任です。成果責任とは、売上や利益、受注、生産量など、事業成果そのものに対する責任です。事業責任者、営業責任者、店舗責任者などが典型例です。例えば営業部長に期待されているのは、顧客訪問回数ではありません。売上や利益の創出です。事業責任者に期待されているのも会議の開催ではなく、事業成果や事業成長の実現です。このような役割では、成果そのものが数値として表現されるため、業績指標(KPI)との親和性が高い。当たり前ですね。
一方で、機能責任という考え方があります。機能責任とは、品質、人材育成、組織運営、標準化、技術力向上など、組織機能の維持・向上に対する責任です。例えば技術企画部門(ソフトウェア開発業務において開発品質を高めるために開発標準・設計指針・レビュー基準を設計して適用していく機能部門)に期待されている役割とは何でしょうか。
技術企画部門に期待されている役割は売上を増やすことではありません。品質の高い成果物を安定的に提供できる状態を実現することです。また、開発標準を整備し、知見を蓄積し、人材を育成し、継続的に品質を維持できる組織をつくることでもあります。人事部門であれば、人材が育っている状態を実現することが役割であり、品質保証部門であれば、品質が安定して維持されている状態を実現することが役割です。
ここで重要なのは、これらの役割に期待される成果は、売上や利益のような数値ではなく、「あるべき状態」で表現されるということです。私はこれを「状態成果」と呼んでいます。
機能責任を担う組織や役割の場合、業績成果よりも状態成果との親和性が高くなります。もちろん、機能部門だからすべて状態成果の評価になるわけではありません。技術企画部門であれば不具合件数や障害件数、人事部門であれば離職率や採用充足率などの指標を持つこともできます。
しかし、それらは本質的な成果ではありません。
例えば、不具合件数が少なければ品質が高いとは限らない。離職率が低ければ組織が健全であるとも限らない。これらの指標は、あくまで状態成果を観測するための情報に過ぎないのです。したがって、業績評価の制度設計において重要なのは、「KPIがあるかどうか」「測定可能かどうか」ではありません。
では、本質的な成果を見極めるにはどうすれば良いのでしょうか。
”その部門が担う役割は、一体何に責任を持っているのか” を明らかにし、その責任が成果責任なのか、機能責任なのかを見極めることが必要になります。売上や利益、コストのような成果責任を担う役割であれば業績成果との親和性が高い。そうではなく機能部門として提供している機能が組織に効いているかという機能責任を担う役割であれば状態成果との親和性が高い(あるべき状態を成果とする)。
この考え方を持つことで、なぜ営業部門と品質保証部門では評価の考え方が異なるのか、なぜ事業責任者と管理部門責任者では成果の定義が異なるのかを、一貫した理論で説明することができるようになります。そして、定量的で測定可能な業績成果で評価すべき部門と、機能部門として提供している機能の効き具合を評価する状態成果で評価すべき部門を、分けて考えることができるようになります。
シンプルな考え方ですが、ほとんど知られていません。具体的な展開方法は、別途改めてご紹介します。

