エンジニアの評価って難しくないですか？
これは、エンジニアをメンバーに持つマネージャーや、
営業畑で出世していった、事業部の課長や部長クラスの人向けの記事です。
私自身、エンジニアの評価を聞かれる機会が多くなる中で、
色んな人から「エンジニアってどう評価したら良いんだろう」という相談をされます。
これ、凄く分かる話で、エンジニアをどう評価したらよいかというのはかなり難しい仕事だと思います。
営業サイドは目標も結果も定量的に判断出来る為、判断し易いが、
エンジニアはどうしても定性的になってしまい、評価するのが難しいです。
また、後に詳しく書きますが、「前回からの成長」等のポイントもどう評価するかというのも難しいポイントの1つです。
軽く例題
例えば、以下のような3人のエンジニアがいた場合、あなたならどう評価しますか？
- Aさん
- 与えられた仕事はしっかりとこなし、毎回自分で設定した工数通りに納品、ミスもない
- Bさん
- 主にインフラを担当しており、常に軽微なアラートにも気づき、危険な兆候があれば事前に対応して問題の顕在化を防ぐ
- Cさん
- 与えられた仕事をただやるのではなく、「なぜやるのか」を常に営業にしつこいくらい聞いた上で本当に必要なものを作る。故に成果物は想定以上だが、開発に取り掛かるまでのスピードが遅い
いかがでしょうか。
皆きちんと仕事をやっています。
ただ、この情報だけでは評価は難しいと思います。
というのも、前回との比較がないため、「前回からどれだけ成長したか、事業に貢献したか」が分からず、
昇格や昇給をどう判断すればよいか分かりません。
おそらく、多くの評価する側の立場の方たちは、この部分の悩みが多いのではないかと思います。
(実際、評価=昇格・昇給にどう反映させるか。という前提があるため)
じゃあ、どうしたら評価が出来るのか
例えば、上の例題に出した3人ですが、3人ともに良い仕事をしているのは分かりました。
ただ、半年前と全く同じ仕事をこなしているだけでは評価出来ませんよね。
その場合は「成長」していない訳ですから、昇格・昇給は難しいと思います。
※ これは私が2-3年、エンジニアのプレイングマネージャー的な立場として経験した結果に基づく考え方ですので、まだまだ甘い部分もあると思います。そういった場合はコメント頂けると大変うれしいです。
私の考える評価ポイント
まず、エンジニアを非エンジニアが評価する場合、以下の2点を明確にしておくと少し見え方が変わり、
評価も定性的であるものの、成長や結果が見えやすくなると思います。
- 各エンジニアが与えられているポジションを明確にして、それを目標設定時に認識をすりあわせておく
- 各ポジション毎に、成長・評価ポイントを考えておき、そこに当てはめて評価を行う
1. 各エンジニアが与えられているポジションを明確にして、それを目標設定時に認識をすりあわせておく
文章で書こうとすると長文になりそうなので、ポイントだけ絞って説明します。
- エンジニア自身のキャリアプランを聞きつつ、どのポジションに充てるのが適切かを考える
- ここで言うポジションとは？
- 新規開発担当
- 運用担当
- 保守担当
- etc...
- 本人に明確なビジョンがなかったとしても、普段の何気ない会話や雑談から、好きなもの、得意そうな事を考え、適切なポジションを与えるのも上司の仕事です。
「エンジニアの評価は難しい」と言って、評価する側もされる側も逃げているだけでは永遠にこの問題を解消できません。
評価される側としては納得の行かない評価結果になるリスクもあります。
早いうちに手をうち、予め目標の目線合わせを行い、「半年後、こういう事が出来、このような状態になっていたら評価出来るよね」という事を互いに磨り合わせておく事は非常に大事です。
2. 各ポジション毎に、成長・評価ポイントを考えておき、そこに当てはめて評価を行う
- 各ポジション毎に、評価出来るポイントを明確化し、それを予め目標に組み込ませる
- 例
-
新規開発担当
- この機能が何を必要として作っているかきちんと考えられているか
- 「誰の」「どんな問題を」解決するために作っているかを意識出来ているか
- 競合なども意識し、必要があれば同一の機能と比較し、自社に必要なものを作れているか
- 開発時の設計判断が適切化どうか(今後必要となりそうな機能などへの拡張性が意識出来ているか)
- 使う技術選定が適切に行われているかどうか
- 設定された工数通りに開発が行われているか
- 予め予期せぬ事態へのバッファ等も含んで工数設定をしているか
- リリース時、どこが事故ったらまずいかを把握出来ているか(その仕組みを用意出来ているか)
- 事故った時に、問題を顕在化させずに切り戻す手段を作れているか
- この機能が何を必要として作っているかきちんと考えられているか
-
運用担当(ここで言う運用というのは、営業やその他運用調整者の業務保守等の事です)
- 既存機能の改修などが、何の問題を解決するものか意識出来ているか
- 開発前に関係各所に正しくヒアリングして、解決したい問題を意識出来ているか
- 既存機能の改修依頼は、「今xxが出来ないから、xxを出来るようにして欲しい」というレベルで来る事が非常に多いです。
- 本質は、「なぜxxが出来なくて困っているのか」を掘り下げて本当に必要な機能を洗い出さなければ、作ってみて「やっぱりこの機能は要らなかった」となりかねません
- この辺は以前書いたエンジニアの為の問題解決思考という記事に書いてみたので良かったら参考にして下さい
- 解決した結果、改善前後での結果が可視化出来る仕組みが用意されているか(営業のxxの作業時間がoo時間減った等)
- 今後の改修頻度や、想定される機能追加・変更を意識して修正が行われているか
- 例えば、リファクタリングして保守性を上げるなどの判断もするかと思いますが、そこに明確な判断基準があったか。等
- コードにべた書きで書かれていた定数やデータを、このタイミングでデータベースで管理出来るようにした。等
- これらの判断が「あった方が便利だから」ではなく、きちんとした根拠を元に判断出来ているかも評価ポイントとして良いと思います
- 既存機能の改修などが、何の問題を解決するものか意識出来ているか
-
保守担当(ここで言う保守は、インフラ周りの保守関連です)
- インフラ周りは、非エンジニアからすると、非常に評価しずらいと思います
- インフラ関連に関しては、一言で言えば「何も起きなかった事」が評価対象となります
- その為に、インフラ担当者は工夫をしているはずなので、どのような工夫をしたか
- 例えば、リリース後の異常に気づきやすいようにDataDogで特定のエラーレベルのログ数を監視して必要があればSlackに通知する仕組みを構築した。とか
- サーバの負荷高騰に事前に気づきやすいように監視対象を増やした。とか
- 事前に危険水域のしきい値を決め、アラートを仕込んで於いて、アラートが発生したら対応出来たとか
- とにかく、「何か問題が起きたから対処しました」ではなく、その「問題が起きない為にどんな工夫が出来たか」という部分が評価対象にしていけると良いです
これらの判断基準を、対象となるエンジニアのレベルや役職毎に変えていって見ていければ、
これまでの何もない状態よりも評価がしやすくなるかと思います。
まとめ
今回は、「明確なポジションを与えて、目標を磨り合わせ」「そのポジションで評価出来る内容で成長が感じられたか」という2点に絞ってまとめてみましたが、実際はもっと評価出来る部分もあると思います。
大事なのは目標設定
個人的な感覚ですが、エンジニアの場合は目標設定を明確にしていない場合がある気がします(そもそも定性的にしか設定出来ないため)。
目標が明確でなければ、振り返って見たときに、どこが成長して、評価出来るか判断出来ません。
なので、これらの評価ポイントを意識しつつ、一緒に目標設定をしていけるチームにつくりあげていく事が大事だと思っています。
評価する側は、被評価者が納得出来る評価システムを構築する事が大事
私は入社して以来、「エンジニアの評価は難しい」とか「今回彼をどう評価すれば良いか分からない」という話を何度もされてきました。
自分自身がエンジニアだったときは「エンジニアの評価は難しいものだ」と考えて、明確な目標設定が出来ていませんでした。
しかし、自分がマネージャー的な立場も担当し、年下年上構わず、色んな人を評価するという立場になったときに、真剣にこの問題に立ち向かい、「エンジニアをどう評価すべきか」を常に考えて、その考えも修正してきました。
ただ、難しいと言って逃げているだけでは優秀なエンジニアの流出に繋がる可能性もありますので、
評価者は納得出来る評価の基盤を作る事が非常に大事だと思っています。
評価ポイントは常にアップデートすべき
現状、私はこのようなポイントに絞って話をしましたが、例えば人数が増えて似た仕事をしている人が増えたときや、的確なポジションを与えられなかった場合、領域が広がった場合などは、評価ポイントは逐一更新していく必要があります。
現状に甘んじず、常にチームメンバー全員に目を向け、全員が納得出来る、必要な評価項目とそれを元にした目標設定が出来る環境を用意して行く事がマネージャー陣にとってはかなり大事な仕事だと思っています。