エンジニアの評価制度の詳細
前回記事からの続きです。
エンジニアの新卒採用を本格化させ、活動している過程で「中途エンジニアにとっては当たり前だが新卒エンジニアにとってははじめてでわかりにくいものがある」と気づいたため、詳細をここにまとめることにしました。
基本的な考え方
ソフトウェアエンジニア（以下、エンジニアと呼ぶ）の評価に関して、重要なのは次の3点と考えています。
エンジニアの人材市場に対してフェアであること
複数人のリファレンスによって成り立つこと
エンジニアの成長を促すこと
具体的には、ノーレイティング的な方法をとります。
まず、エンジニアが関わる業界は事業と人材の流動性が高いため、次が非常に起こりやすいです。
既存社員よりも新規社員の方が給与が高い、あるいはその逆
半年で急激に成長する人材がいる
半年経過する前にやるべきことが変わる
半年で市況が大きく変化する
エンジニアは長期の貢献を評価されるべきであり、短期の成果で評価しないほうが良い
よって、評価基準を内ではなく外に置くほうが妥当性があると考えます。言い換えると、社内における評価と社外における評価が一致しているべきです。
次に、経験的にわたしが理解していることとして、エンジニアは他のエンジニアの実力をよくわかっています。「あの人は自分よりすごい」「あの人はもう少し頑張ってほしい」。これらは概ねあたっています。そして、エンジニアの場合、他社ではどれくらいの給与を得られるかを知る手段が非常に多くあります。
よって、隠すことにあまり意味がありません。オープンに集合知を取るのがプラクティスになります。
また、継続的パフォーマンス管理によって成長を促すことが重要です。成長するのであれば、高い評価を受け、給与は上昇します。これは管理する側にとってはコストが上昇することと同じです。すなわち、エンジニアリングマネージャー（以下、マネージャー）の使命は人件費を下げることではなく、人件費を上げるほうが望ましいということを意味します。これは当然、政治的行動をとれと言っているわけではなく、エンジニアとしてのアウトプットの質を上げよ、という意味です。
評価の基準
わたし（CTO）は次を要求します。
開発と運用によるプロダクトへの貢献（プロダクト貢献）
開発チーム、技術チーム、他メンバーへの貢献（チーム貢献）
技術的に困難を伴う開発の達成や開発全体の効率化、あるいは大規模かつ複雑なシステムの安定的運用（技術貢献）
社内や社外のエンジニアに対する発信による貢献（コミュニティ貢献）
ミラティブメンバーとして模範的であること（行動指針の体現）
ここにまとめてあります。
特別なことは書いていなく、一言で言うと「これができればどの会社でも評価されるであろう」という考え方を採用しています。公平を期すために、影響を受けたドキュメントを挙げるとEngineering Management TriangleとVALVE HANDBOOK FOR NEW EMPLOYEESがあります。
また、全てを同時に行なうことは難しいでしょう。これに対しては、今、最も大切なことを行なうのが要点です。すべてのメンバーは各々異なるミッションを持っています。その時のその人の状況は考慮されるということでもあります。例えば、プロダクト開発が忙しいときにはテックブログを書けなくても構いません。このような状況ではプロダクト開発をすることが最も評価されます。しかし、プロダクト開発が重要な時期に「テックブログを書いていて開発が遅れた」のであればそれが評価されることは難しいと考えてください。それは一般的に言って望ましい行動ではないし、ミラティブメンバーとしての模範的な行動でもないからです。
スケジュール
下半期においては大雑把に言って次のようなスケジュールで進行します
7月：目標設定
8〜12月：月ごとに1on1
1月：振り返りとFB
ノーレイティングといっても、目標に対して「できた／できなかった」は振り返ってもらいます。これは評価のためというより、成長を促すパフォーマンス管理（「なにが良かったか／良くなかったか」「では、どうするか」）の仕組みになります。
ノーレイティング
ここでは簡単にまとめたものを紹介します。
前提
マネージャーは採用に深く関わり、人材の市況を把握している
メンバーを採用するとき、社内基準ではなく社外基準でオファーする
半期毎
「今、改めてオファーをするとしたらどのようにするか」
CTO、EM、HR間でキャリブレートする
具体的には、プランニングポーカー風のイテレーションを通して、最尤値を見つけにいきます。色々な調整が加えられていますが、全体の雰囲気としてはこのような形をとり、市場に対してフェアさを維持することを目指します。
おわりに
仕組みは改善していくものだと思っています、社内からでも社外からでもFBいただければ幸いです。
今回の評価制度のアップデートは現在の事業規模や組織規模に基づいて設計されたものであります。会社のフェーズや世の中の時流が変わったならば、柔軟に制度を更新していこうと考えています。
また、わたしの指向性と知識を共有することによって、本制度の意図がより理解できると思いこれも紹介します。
本稿の趣旨はエンジニアに関する評価制度ですが、エンジニア以外の評価制度に関してはこちらから聞いていただければと思います。
この記事が気に入ったらサポートをしてみませんか？