OKRとエンジニアの業績評価の一案

OKRをやるなら、業績評価とは別立てにしてやらないとサイクルの短いMBOの、且つ、MBOとは違ってトレースされる嫌な仕組みになってしまう可能性がある（組織のマネージャの運用次第）。

エンジニア個人のKRは、背伸びをした挑戦、定常業務のKRの2つの組み合わせが良いのではないかと今の所は考えている。

背伸びをした挑戦は、コンピテンシのバンド、つまりエンジニアの組織内のレーティング）との連動させる。

背伸びをした挑戦は、挑戦の結果がコンピテンシの伸長に繋がるので、現状維持を強く希望するエンジニアでなければ異論はないだろう。KRを設定するときに、到達は60%でいいくらいにする。%は組織のキメだが100%の達成で標準にはしない。ストレッチをさせるのであるから、半分も行けば上出来だ、くらいな目標にしておく。

個人のOKRは、次の2点だけに使う。

• KRは事業の成長に繋がる目標を設定する
• KRに関わり方をコンピテンシの伸長に関連づける

ここで、業績評価はどうするのか問題が出てくる。こちらは、エンジニアも非エンジニアも不確実性の高い業務の時代になっているので、一律業績連動で良いのではないか。

個人の待遇は、

• OKRと組織の業績（例えば経常利益）で導出

としてしまう。

エンジニアは、モブプログラミング を採用するところは誰の成果とも言えないし、チーム開発では、業績評価は個人を対象にするのは現実的でない。これは誰の、あっちはあの人の、とはしづらい。

もともと、個人評価はどうやるのがいいのかという課題は以前からあったが、アジャイル開発でペアワークが浸透してきたことで、平成（昭和か）の時代のように、やったことを評価するのは過去の話なのではないか。

であれば、これからは挑戦したことで『できるようになった』というコンピテンシ評価で十分なような気がする。ペアワークをしているのでできるようになったと周囲が認めやすくなっている。

そうすると、ある程度の自主的に滞留するエンジニアの存在をどうするんだ問題が浮上してくる。これも今だって、経年に渡り滞留したら降格させる制度を取っている組織もあるだろう。

挑戦しているエンジニアなら、コンピテンシの様々なスキルのデコボコは、何かしら、ちょっとずつでも凸が増えていく。だから微速であっても前に進もうとしているエンジニアは救える。

本当に留まっているエンジニアだけ炙り出して、弾けば良い。

クェルサ（Crusar）車載用　かわいい ミニ ゴミ箱 小物入れ　グリーン [並行輸入品]