目標設定の全てを定量にした方が良い理由

OKRでもMBO(目標管理)でも、目標は定量な数値を入れることを推奨される。これは何度も説明しても、仕事では優秀なメンバも目標設定になると定量的な数字を入れたがらない。面談をしてそれを促すと、3割くらいのメンバは数値目標を設定するが、その他のメンバは期限を設定するくらいがせいぜいだ。気持ちはわかるが、数値を設定するとプレッシャを途端に感じるのだろう。であれば、目標設定の際に、この数字で達成する中身は、こういったものだとマネージャと達成するゴールの仕様について詰めればいいだけであるが、そこまでするエンジニアはほぼいない。

目標に定量的な数値を設定する。その設定のし易さから言えば、達成時期は一番設定しやすい。極端なことを言えば、評価期間の末までに実現できそうなら期末を設定すればいいし、局面やプロジェクト終了が評価期間内であれば、終了月を設定すればいい。

終了時期が評価期間を超えてしまうなら、それは目標を1段階ブレークダウンして、分解した目標を評価期間に設定すればいい。

その定量的な目標がやらなければならない目標なのか、背伸びをした目標かでKRの対象になるかどうかを判断すればいい。

マネージャ側は、定量的な目標設定を促す立場である。もし、目標設定が業績評価と連動している場合は、全員の目標を全て定量的に設定すると評価時に少し面倒なことになる。

業績評価は、個人の目標達成と組織内での事業貢献の2段階評価になる。個人の目標設定を定量的にするように促しているなら、個人の目標は個人の実績を絶対評価するという制度であり、それをエンジニアに対してコミットしていることになる。

一方、組織内の業績貢献の評価は他のエンジニアとの貢献での比較になる。つまり、相対評価になっていることを表している。

個人の能力(=コンピテンシ)業績評価と貢献の評価を完全に切り離していて、コンピテンシで給与を決めるのであれば、2つの評価で起きる問題は起きにくい。連動している場合は、問題が起きるのはここまでの説明で理解できるだろう。

連動している場合に、個人の目標設定をエンジニアが自身で設定しないことを利用し、前述の問題を回避することもできる。これも想像力を働かせれば、どう利用できるかはわかるだろう。

これも、どれだけ制度に沿って目標管理という道具を使ってエンジニアのできることを増やそうかと考えているマネージャだけの話であって、印象でしか評価をしていないマネージャの部下であるならどうしようもないのであるが。

こうして見返せば、目標管理もOKRもエンジニアは制度としての仕組みをわかっているのだから、いくらでも攻略できるし、あとは、やったかどうかで評価自体も納得しやすはずであるが、大前提のところの目標設定を理解して設定しないから自分で評価時に諦めや不満を作ってしまいかねないのである。