【汎用ソフトスキル】エンジニアのための評価ハック

この記事の目的

エンジニアを7年くらいやってみて、「評価でモヤモヤしないためにはどうすればいいか」がなんとなくわかってきたので言語化してみる。

この記事の想定読者

• 適切な評価がもらえていない気がしてモヤっている人
  • 3年くらい前の自分に向けて、がコンセプトです
• 評価やら目標設定やらがうまくいかないが、具体的にどうすればいいのかを悩んでいる人
  • 正社員以外でも読んでいて意味があるように書いたつもりです
• シンプルにもっと評価されたい人
• もうちょっと評価されたいけどこれ以上責任範囲が広がるのは嫌な人

この記事の想定読者ではない人

• 評価システムの効率的な運用方法や構築方法を考えている人
  • ex) OKRの運用ノウハウなど
• 成果に見合わない評価を得るための方法論が知りたい人
  • 評価のクラッキングは取り扱いません
• 悪意のある評価をする会社との付き合い方が知りたい人
  • そんな会社に所属したことがないのでわかりません
  • 性善説の立場を取ります

前提: そもそも評価とは

結論から言うと、評価とは「報酬を決めるもの」だと私は考えています。

ここで言う 「報酬」とは具体的な金銭のことだけではなく「仕事上の経験をつめる」や「やりたいことをやれる」「働き方が選べる」などと言ったことも含まれます。
具体例を上げると「新しいPJの技術選定を任される」「自分の使いたい技術を仕事で使える」「自由な場所や時間で働くことができる」などと言ったことも、ここでいう「報酬」には含まれます。
（これらができるエンジニアは、平均するとそうでないエンジニアと比べて高い評価を受けていることは想像に難くないと思います)

評価は報酬がある以上どこにでも存在します。
評価システムができていない創業まもない会社でも、フリーランスとして働いていても。フリーランスの場合、「次の案件」や「単価」などという報酬を暗黙の評価によって決定されている、というと良いでしょうか。

これらの報酬は多くて困ることはまずないです。
そのため、この記事では、適切な範囲でできる限り高い評価をもらう、と言うことを評価ハックの目的として設定しています。

会社によくある評価システムというのはいわば「できるだけ公平性に報酬を支払う」ためのシステムです。効率化やクラッキング(「評価者と仲良くする」だけで高い評価を勝ち取る、など)対策がその目的で、「評価すること」自体は別に目的ではありません。たぶん。

評価が決まって報酬がもらえるまで

評価が決定し、あなたが報酬を手に入れるまでには3つのフェーズがあります。

1.会社に貢献する
2.貢献が会社に観測される
3.評価され、それに相応しい報酬が手に入る

軽く流れを追ってみましょう。

1.会社に貢献する

一番根幹の部分です。会社は社員その他の貢献を適切に運用して報酬を作る仕組みを持っています。これがワークしないと、そもそも会社側は金銭その他の報酬を用意できません。(いわゆる利益でない状態 / そのまま行くと倒産する)
そのため、OKR/MBOなどのいわゆる目標設定は「会社への効果的な貢献の仕方」を社員に伝え、それを促すように設計されています。

2.貢献が会社に観測される

どれだけ実際に会社に貢献していても、会社が観測できていない貢献に会社は報酬を払うことができません。
今回の記事でハックを行う主なポイントです。
特にエンジニアの仕事は「エンジニア以外には何やっているか理解するのが難しい」という特徴があります。そのため、この部分がボトルネックになって評価が悪くなっていることが非常に多い印象があります。

3.評価され、それに相応しい報酬が手に入る

観測された貢献に応じて、報酬が分配されます。
この部分は大体、実装者レベルのエンジニアにはハックできません。
いわゆる会社の用意したグレード設計だったり、チーム編成だったり、給与テーブルだったりします。この部分が評価のボトルネックになってしまった場合、改善するためには管理職になって精度をメンテナンスするか、転職する必要がでてきます。
いわゆる「ポジティブな離職」が増えてしまう理由の一つなので、この辺りが評価のボトルネックにならないようにするのが管理職の腕のみせどころと言えるかもしれません。
(みたいなことが、最近読んだオライリーの「エンジニアリングマネージャのしごと」にも書かれていました)

Happy Hyouka Hacking!

さて、ではここからは具体的なハックのやり方について触れていきます。

目標を使って「貢献すること」の認識を会社と合わせる

いわゆる「期待値調整」というやつの一つです。これは絶対にやりましょう。
一般的な会社で期初に行うことが多い目標設定が一番わかりやすいので、以下目標設定について話します。
(目標設定に該当するものがない会社や立場でも、似たようなことを定期的にした方がいいと思います)

目標設定のポイントは、この目標が達成されていたら、会社は自分の貢献を適切に観測できるかを意識することです。なぜなら、目標は会社にとって理解が難しいエンジニアの仕事を評価するための貴重な手がかりになるからです。
「目標を作った後に、技術者ではない評価者視点で推敲する」などが具体的なやり方となるでしょうか。「評価者に読んでFBをもらう」などができればなお良いです。
「ある程度期末の時点でのゴールを想像して目標を作る」なども効果的です。とにかく、評価をする側/される時 のことを意識しましょう。
会社によっては「エンジニア以外がエンジニアを評価する」仕組みになっているため、目標も出来るだけエンジニア以外でも理解できるようになっている ことが実は望ましかったりもします。この辺りは会社によってまちまちなので、しっかりと自分の評価者と対話して確認しましょう。
評価システムがよくできた会社であれば、この辺りのやり方が整っていることもありますが、そうでないこともよくあります。

アンチパターン: OKRを評価する会社でストレッチゴールを設定しすぎてしまう

(Tips的に書いておきます。OKRやってない人は読み飛ばし推奨)
OKRは最近よく使われる目標管理のフレームワークです。大抵「7割くらい達成可能な目標を立てろ」といわれますが、これが結構厄介です。
特に以下の場合、「会社側がOKRを評価に使っている」、かつ「自分が期待値調整に自信がない」場合、OKRの原則を無視して9〜10割達成可能な目標を立てることを強くお勧めします。
7割達成を前提とした目標の設定は、会社側との期待値調整の難易度がハネ上がります。目標がぼやけてしまうため、エンジニアの仕事を評価するための尺度としての精度が低くなってしまうのがその原因です。
その状態で適切な期待値調整ができる人は、そもそもOKRがなくても適切な評価を得られる調整力のある人であり、評価システムがなくても適切な評価を得られる人です。「期待値調整の能力が評価のボトルネックになる」というバグ(ないしは仕様)がある評価システムと言えるかもしれません。

そもそもOKRは「評価に使ってはいけない」という原則があるため、評価に使われているOKRは基本的にはアンチパターンです。とはいえ、これは多くの会社で実際に採用されてしまっている評価システムな気がしています。評価システムも人間が作ったものなので、私やあなたが作ったシステムのようにバグや不自然な仕様があります。これはその一つです。いつかfixされることを祈りつつ、ワークアラウンドをかけましょう。

金銭以外の報酬を目標に組み込む

目標は「会社と合意した評価の基準」ですが、同時に「業務として行って良いこと」の定義を会社と合意するためのツールとしても利用できます。
目標設定は、「キャリア」や「やってみたいこと」などの、金銭以外の「報酬」を手に入れるための絶好の機会です。「経験したい業務」「使ってみたい技術」などがあれば提案し、積極的に目標に盛り込むようにしましょう。
会社はあなたの「金銭以外の報酬を増やすこと」に対して、おそらくあなたが思っているより前向きです。誰にとっても価値が変わらない金銭と違い、「キャリア」や「やってみたいこと」などの報酬は、仕事の割り当てを調整するとその総量を増やすことができるからです。
もちろん、タイミングなどの問題でうまくいかないこともあります。しかし「自分にとってはこれが報酬になる」という意志を会社に伝えておくのはとても大切です。すぐには効果が出なくても、四半期後、半期後にチャンスが来た時、それがあなたに巡ってくる可能性が格段に高くなります。

「評価できない貢献」をなくす

「評価できない貢献」は2種類ありますが、どちらも極力減らすようにしましょう。

1. そもそも会社として必要がない / 優先順位が低い貢献
2. 会社が「必要だ」と認識することができない貢献

1はわかりやすいと思います。最終的なアウトプットに繋がらない貢献は評価することができません。やめましょう。
優先順位が低く設定されている貢献も、「他人の貢献を邪魔して会社全体のアウトプットを下げてしまう」可能性があるため、合意がない限りはやらない方がいいです。
(どうしてもやりたいならコッソリやりましょう)

問題なのは2.です。エンジニアだと 「リファクタリング」「コードレビュー」「ライブラリのバージョンアップ」「セキュリティ対応」 などの、目に見える形で生産性に寄与しない貢献が該当してしまうケースがよくあります。
これは「会社にその貢献を評価させる」方向に説得するのが最も良いやり方です。しかし、これらの貢献は評価がむずかしく、会社側から「優先順位が低い貢献」として扱われてしまうことがありがちです。

この場合、私は「会社と合意を取った上で、その貢献を一旦止めてみる」ことをお勧めします。

「ベロシティの低下」「エンジニアの退職」「インシデント」などの手痛い失敗を被る可能性がありますが、会社はその失敗から学ぶことができます。(なお、一発で会社が潰れたり、人が怪我したり死んだりするレベルの出来事を誘発するものはこの限りではありません。なんとしても評価するよう説得しましょう)

「ごんぎつね」のように陰で評価されない貢献を続けていると「その貢献の価値」を会社が学ぶことができません。それはあなたの評価が低くなるだけに止まらず、その貢献軽んじる文化を会社に与えてしまうことになりかねません。あなた自身が「ごんぎつね」のように扱われ「猟銃で打たれる」ような出来事が発生して、シンプルに辛い思いをすることもあります。

そしてなにより、「貢献をやめても何も起こらなかった」 ということが往々にして起こります。
これは残念ながら「自分の認識が間違っていていて、自分の今までしていたことは会社への貢献になっていなかった」ということを意味します。
体感で5割くらいの2は実はこのパターンである気がします。とても悲しい話ですが、かくいう私もこの経験が沢山あります。人生そんなもんです。

最後に 〜評価も人間がやっている〜

さて、私が目標と評価で意識していることは大体こんなもんです。

OKRのTipsでもちょっと触れましたが、大事なことは「評価は人間がやっていることだ」ということだと思っています。

評価は「自分より上の立場の人がする」という印象があるため、評価システムはどうしても「完璧なものであるべき / あって欲しい」という気持ちが強く出てしまいます。

しかし、残念ながら評価システムも人間が限られた時間の中で作ったものなので、バグもあれば不自然な仕様もあることがほとんどです。大体自社の手がけたシステムと同じくらいの完成度だと思っておくと、評価のモヤモヤに苦しむことも少なくなる気がします。「評価システム作る人も大変そうだな」 くらいの気持ちで、多少の実装の不具合は使う側で巻き取ってあげましょう。

大事なのは、知ることと活用すること、それから少しのリスペクト。そういうことだと、私は思います。