エンジニアリング組織におけるOKRと評価、実際のところどうなの #EM #OKR

OKRを使い始めるとやはり評価に使えるじゃないかってなりますよね。

しかし、評価に使うのは勧めないという話は多いです。

re:Workより

OKR は、従業員を評価するためのツールではありません。

OKR自体がストレッチゴールを目指すというものである以上、OKRをストレッチするものに設定しなければいけません。しかし、OKRを評価に使ってしまうとストレッチゴールを狙わずに達成しやすいものを設定しがちになるというのが主なロジックだと思います。

一方で評価に関係ありませんと言ってしまった場合、OKRを達成しようとするモチベーションは起こらないのではという問題もあります。

業績連動型の評価

OKRといえばResilyさんですね。そちらの記事でも相当するものがありました。

OKR を導入する際の理想的な評価のあり方について

しかし、会社への貢献を業績の観点で評価することは自然ではないかと思われるだろう。
OKR もこの点を否定するものでは無い。

ということで、紹介されているのは業績を使って計算する方式に見えます。読み違えていたらすいません。

こちらでは営業やマーケターの例が出ているのですが、エンジニアの場合は出ていません。

こちらは営業とマーケターの例

（営業であれば受注額、マーケティングであれば有効リード獲得件数など）

なるほど。これでメンバーが納得評価が出るなら良いですね。

すいませんが、私は畑違いなのでこのやり方が営業とマーケターに合っているのかは分かりません。

エンジニアの評価を業績連動型にして良いのか

業績によって出せるお金が変わるのはしかたないのですが、果たしてエンジニアの評価を業績連動にして良いものでしょうか。

エンジニアと言っても様々な種類がいます、ユーザー数に直結するようなグロースハッカーもいればユーザーの課題を解決する機能を作る人もいて、更にはサービスが落ちないように監視したりするインフラ系の人もいます。

これらをいっしょくたに業績連動にするのは無理があるように思えますね。別に今Qの業績が悪かったとしても素晴らしいパフォーマンス改善を行ってくれているかもしれないし、来年のための基盤構築をやっていてとても素晴らしく、進捗も良いかもしれません。

それを直近のQや半年の業績が悪かったからといって評価を下げるのとモチベーションが下がるのは分かります。

進捗 × 難易度を評価の一部として取り込む

で、ここまで来て申し訳ないですがこれだという解決策が浮かんでいるわけではありません。

・OKRを評価と連動させねばOKRを追うモチベーションが湧かない
・OKRを評価に使うとストレッチゴールを設定しなくなる

という2つを解決するのはやはり一部を評価に使うということなのかなと思っています。

単純に達成度で評価を測るとストレッチゴールを狙うモチベーションがなくなるので難易度を数字化してそれと進捗の掛け算を使って評価するのが良いのではと思っています。

難易度 × 進捗

そしてこれが評価システムの一部であるのが良いかと思っています。これだけで評価するとエンジニアならではの普段のリファクタリングやライブラリアップデートなどの徳のある行動なんて呼ばれるものが減ってしまって将来のシステムが危うくなりそうだからです。

Measure What Mattersでも難易度を使った評価を勧めているのかなと読み取れますね。

さあこれでいかがでしょう？
こういうのは実際に運用をして1年は経たないと結果が分からない気がするのがやきもきしますね。でもとにかく試してみないことには始まりません。

メンバーには巻き込んでしまって申し訳ないと思いつつも将来もっと良くするから！と思う日々です。