評価をするということはその人を知ることであるということをダメマネージャはまだ知らない
期末になると、組織人なら業績評定が通知されます。でね、大体予想しているもんです。今年は頑張った、とか、うーん、微妙...とか。でも、もしかしたら？とか。
＃もしかしたら、は起きないんですが。
大体、業績評定なんて色々な思惑の中で様々なバイアスを掛けあい引き合いながら次年度予算の中で分捕り合うための口実にするものですから。
今時、エンジニアリングの企業ならエンジニアのキャリアパスや求める人物像がキラキラと描かれて、誰ならなれるんだよとか思いながらも、ね。業務とキャリアパスのマッチングとズレを考えてみたり、業務がキャリアパスとずれているのに「どうせいちゅうんじゃ、ボケ！」と毒を吐いたり、ね。実際、そんなもの(＝キャリアパスで求められる人物像)どうにでもなるんですが。
で、この時期、最近だとtwitterやfacebookでぶーたれるひともチラホラ。大体やることやってねーんだろ？とか短絡的に思いもせず、あーこれ、上司を上手く手のひらで転がしていねーや、的に思うことが多いんだけど。
ダメなマネージャにダメなエンジニア
周りを見ていてコイツは何でマネージャになっているんだ？って言うやつは、揉めて部下の不平不満が聞き漏れて来ることが多いですね。機会があって、たまたまプロジェクトのdeliverableのレビューアを頼まれたりするとすぐに「こいつはセンスがない...」と思ってしまう。
そういったマネージャは、マネージャとして求められる基礎的なスキルが備わっていないのが手のひらを見るようにわかってしまう。端的に言うと、エンジニアの延長線上でしかない。マネージャのマの字も持ち合わせていない。しかも、本人がそれが必要だということの自覚もなさそう。
そんなマネージャに育てられたのか、育てることを知らないマネージャにネグレストされて自由奔放に育ったのか、それともそれ以外かはわからないけれど、ダメなエンジニアも同じようなもので、聞き漏れてくる不平不満も感情的なものばかり。エンジニア本人が冴えているなら、ダメなマネージャなんていくらでもコントロールできるだろうにね、と思う。
そんなマネージャなんて、ポリシーも裏も持ち合わせていないのだから。
オカシイ業績評定には、ダメなマネージャとダメなエンジニアが揃ってこそ成り立つんじゃないかな、と。
評価でぶーたれる半分は自分の責任
オカシイ業績評定は、その当事者、少なくてもマネージャとエンジニアの二人がいる。マネージャの上長やその上のエグゼクティブは口を突っ込んでくることもあると思うけれど、棚上げ。
二人の当事者の会話とコミットの上に業績評定が成り立っているのだから、その結果の責任は二人にある。マネージャが全部だろう、だって？そんなことはない。
それは誰の目標かを考えればわかることだ。そのエンジニアの目標なのだから。
ダメなエンジニアくん、なんでそうなったか、業績評定の結果だけでしかものを見ていないんじゃないか？ワタシは結果を重視するけれど、いきなり結果を評価することはしないし、そうするマネージャがいたらハリセンで思いっきりひっぱたくよ。結構真顔で。
でも問題なのはエンジニアにだってあるのだ。そんな業績評定にならないように幾らでも修正できたのだ。
- その評定のもとになったモノは何だろう。
- その評定にたどり着く間、何があっただろう。
- その評定の基準はなんだったろう。
定性的目標と定量的目標
業績評定のもとは、業務目標であることは簡単に思いつくだろう。当たり前の話だ。でもね、忘れるんだよ。エンジニアは都合が悪くなると。そもそも、どれだけのエンジニアが目標設定を“真面目に”考えて作ってくるのか。10人居ても1割いれば良い方だ。(当方調べ)
一体どれだけのエンジニアが組織の目標、つまり、組織が進もうとしている方向と自分自身が目指すキャリアパスと向こう1年で経験できそうな業務(=プロジェクト)と今の自分のスキルと向こう1年で学び補完するスキルを整然と並べ、考えているのだろうか。
まぁ、考えていないんでしょ？って思いますね、エンジニアくんたちの目標を見ていれば。
幸いにもワタシのメンバには、毎年1回しか目標設定はありませんが、その都度、それこそ何年もご説明しますし、目標設定のチート、導き出し方もご説明させていただくんですが。
基礎スキルの目標、技術スキルの目標、組織内研修、自己研鑚の4つを上手く使うと、あとは組織目標や目指すキャリアパスをパラメータに突っ込めばいいんです。
業績評定で当事者同士が揉めるのは、業務目標が定量的でないから他ならないのです。もう、それだけ。スタート時点でそうなることが予見されるのです。で、当事者二人がその認識がないから、期末の拙い雰囲気を作る。自分たちでそうなることを自分たちで選んでいる。
そういうことです。
すべての業務目標を定量的に測れるようにしないといけないの？と思うかもしれません。80%は、定量的な数値を入れた目標に、20%を定性的な目標にするのがポイントです。
業務目標も、1つではギャンブルです。ギャンブルは、外しても食べていける蓄財の分でやるのが正解。1年棒に振ってもいいなら、それでもいいです。止めません。
なら、10個も20個もとすれば、馬鹿だな、と思われても仕方がない。共通項を見出せよ、と言われるかもしれない。そもそも、そんなに業務目標を書くスペースなんて用意されていないだろうし。
5個、＋2個までがおすすめ。
その導き出した目標を並べて(＝目標として置いて)、ぶれない定量的な数字をきちんと入れる。その数字は、ちょっと頑張るとできるように設定するのがコツ。
あと、定性的な業務目標も20%ほど入れておくのもポイント。定量的な目標ばかりだと、退路がないです。人は曖昧な生き物です。逃げ道は必要。エンジニアにもマネージャにも。その定性的な目標は、同じ定性的な業務目標として設定しても、エンジニアとマネージャによっての真の使い方は違うので。
この考え方は、エンジニアにもマネージャにもどっちにも必要だから。
＃テストに出ます。
説明責任が果たせるように
わかっていないエンジニアとミーティングするとき、こんなことを思う事もある。
「キミよりワタシの方がキミのスキルを知っているんだ...(言わないけれど)」
だってね、ワタシはあなた自身になったつもりで、まるで自分の事のようにあなたの業務目標を見ているのだから。エンジニアくんが窮する質問を、なぜを何度も聴くのはどうしてだろうと考えたことあるかい？
ワタシはあなたが知らないところで、あなたのアウトプットの出来不出来をサーベイしているんだよ。それは、マネージャとして、ビジネスを広げようとするとき、そのビジネスに必要な人材を必要とするから。それを担うのがあなたなのか、それともあなたの後輩か、と。
マネージャの仕事の一つは、育成ですね。
ダメなマネージャはそれがわかっていない。全く分かっていない。仕事を取ってきて、プロジェクトに押し込み、やらせておけばいいと思っている。放任も大事だけれど、放任することで経験させるのが何か両者が認識していないなら、それは、コンテキストが高すぎる丸投げだ。それでは、時間がかかりすぎる。今の経営スピードには間に合わないのだよ。
業績評定はマネージャの仕事です。目標をエンジニアに設定させて、間違った、いや、組織の方向性や事業計画に沿わない目標を修正させ、実行をトレースして。そして、評価する。
目標設定から業績評定に深く関与することを自覚しなければならないのです。そこには、responsibilityがあるのです。当事者のエンジニアの疑問に対して、なぜ、そのようになったか上長からの疑問に対して。
マネージャは業務目標設定時に、実は業績評定のための評価基準を作らねばなりません。目標設定時に何を評価するのか、その基準は何か、を。その評価基準は、誰かに見せるものではありません。見せてもいけない。しかし、それがないのにする業績評定なんて、インチキに他ならない。評価時点での不確かな記憶と感情に委ねられてしまうのだから。
ダメなエンジニアこそ、いくらロジカルに業績評定をしていても揉めるものです。でも、評価基準を持っていれば、たとえ上長が仲裁に入ってきたとしても、なんら怖くないのです。responsibilityを果たすための材料を持っているのですから。
