評価制度は、エンジニアにとっての『仕様書』である
「これだけ技術力を磨いたのに、なんで評価されないんだ」 「あの上司は技術のことなんて分かってない」
そんなふうに感じているエンジニアは多いものです。 この記事は、会社にある程度しっかりとした「評価軸」や「評価制度」がある環境にいる人を対象にしています。
もし、あなたの会社に明確な評価軸がないなら、それはもう「上司の習慣」や「好み」で決まっているようなものです。成果主義やスキル評価といっても、基準がなければ結局は主観です。特にエンジニアのスキルは多様化・細分化しているので、上司がすべての技術領域に詳しいわけがない。そうなると、上司の知っている範囲、あるいは無意識の基準で判断されてしまうのは避けられません。
しかし、会社が用意した「評価軸」があるなら話は別です。 基準軸があれば、「その基準に対してどうだったか」という客観的な測定が可能になります。
それでも、「全然正当に評価されていない」と感じる人がいるでしょう。 なぜ評価軸があるのに、納得感がないのか。 それは、見ている視点が「自分」にしか合っていないからです。
評価の不等式を理解する
会社の評価というものは、基本的に以下のような優先順位、あるいは価値の重み付けで成り立っています。
個人の保有能力 ＜ 個人のアウトプット・成果 ＜ チームへの貢献・成果 ＜ チームのアウトプット ＜ 会社への貢献・成果
多くのエンジニアは、この図式の左側、「個人の保有能力」や「個人のアウトプット」を最重要視してしまいがちです。 「新しい言語を習得した（能力）」「難しい実装を一人で完遂した（個人のアウトプット）」、ここを評価してくれと主張します。
もちろん、それも大事な要素ですが、会社としての価値は右に行けば行くほど高くなります。
すべては繋がっている
重要なのは、これらが個別の独立した項目ではないということです。これらは基本的には繋がっていくものです。
- 個人の保有能力があるから、
- 質の高い個人のアウトプットが出せる。
- そのアウトプットがチームへの貢献となり、
- チーム全体のアウトプットを最大化し、
- 最終的に会社への貢献（利益や価値提供）に繋がる。
この一連の流れが通って初めて、高い評価が得られます。
多くのエンジニアが「評価されない」という感覚に陥るのは、この繋がりが「個人のアウトプット」で止まってしまっているからです。 どれだけ素晴らしいコードを書いても、どれだけ高難易度なバグを直しても、それがチームの成果や会社の利益という文脈で語れなければ、評価の天秤は思ったほど傾きません。
例えば、不具合修正の話をしましょう。 技術的には非常に簡単で、修正自体は小さく簡単なものだったとします。個人の「技術力」や「作業量」という視点で見れば大したことはないかもしれません。しかし、その修正のおかげでユーザーの行動が良くなり、結果として売上が上がったとしたらどうでしょう。それは「会社への貢献」として、高い成果と認識されます。
逆に、プロジェクトの推進で考えてみます。 自分自身の担当タスクは問題なく、スケジュール通り完了していたとします。個人のアウトプットは満点です。しかし、チーム全体として完了できなければ、そのプロジェクトは「失敗」とみなされます。会社から見れば、プロジェクトという単位での成果が出ていないからです。
評価制度があるにも関わらず評価が低いと感じる時、それは制度の欠陥ではなく、自分が見ている「成果の範囲」と、会社が見ている「成果の範囲」のズレであることがほとんどなのです。
じゃあ、どうすればいいのか
では、具体的にどう動けばいいのでしょうか。
まずは、自分のチーム、そして周りの人たちをよく見てみることです。 自分のことだけでなく、視界を少し広げてみる。
そこで困った人たちがいたら助けてあげる。あるいは、一緒に仕事を進める。 こうすることで、自然と周りの人たちからの評価が得られるようになります。
ここで重要になるのが、その行動が「どういった範囲」や「重要度」で行われているかということです。
これを確認するために、会社の評価基準を見直してみます。 最近だと成果だけでなくプロセスを見る「行動評価」を取り入れているところが多いので、まずはそこを確認してみる。 もし行動評価という項目がなかったとしても、自分自身のレベル感や等級に「何が求められているか」がどこかに設定されているはずです。
ただ、よく読んでみると、そこには「個人のこと」しか書かれていないことがあります。 「仕様通りに実装できる」「一人で完結できる」といった具合に。
そんな時は、先ほどの「貢献価値」の図式を重ね合わせて確認してみることです。 文言上は個人のことでも、背景にはチームや会社への貢献が期待されていることが多いからです。
逆に、等級定義に「独力で業務を遂行できること」みたいなものが強調されているときは、変に範囲を広げすぎず、そっちにフォーカスした方が良い場合もあります（笑）。 結局は、制度が求めていることと、自分の行動のピントが合っているかどうかなのです。
評価制度という「仕様書」
結局のところ、評価制度に書かれていることは、会社からの「仕様書」のようなものです。
どれだけ高度な技術を使っても、仕様に合っていなければ、それは成果としてカウントされにくい。 自分のやりたいことと、会社の求めていること。このピントが合っているかを確認するために、評価制度というツールが存在しています。
自分のスキルをどこにどう接続すれば、組織としての「機能」になるのか。 そう割り切って見てみると、納得のいかない評価に対する景色も、少し変わって見えるかもしれません。
