エンジニアの目標設定〜自己評価の大事なポイント

はじめに

こんにちは👋
toB向けWebサービス開発の現場でエンジニアリングマネージャーをしています、shoooooriです。

私の所属する会社では年に2回人事評価のタイミングがあります。今月はちょうど上期評価の時期でした。各メンバーの自己評価を読んでいるうちに、「もったいないな…自己評価の書き方を伝えたい！」と感じたため、この記事を書くことにしました。

読者対象

• 事業会社のプロダクトエンジニア
• 事業会社のエンジニアマネージャー
• メンバー評価に苦労しているマネージャーの方

背景

まず、私が所属している会社の目標制度の流れについて説明します。

私の会社では年に2回評価を行います。期初に各メンバーと目標のすり合わせをし、期末に目標達成度を評価して、社内会議に提出し、最終的な評価が決まる仕組みです。
評価に関わる主な登場人物は以下の3名です。

• 被評価者（メンバー）
• 評価者（マネージャー、ゼネラルマネージャー等）
• 決済者（エグゼクティブマネージャー等）

事業会社では決済者がBiz分野に精通している方であることが多く、エンジニアの成果やプロセスをBizとの共通言語で伝える必要があります。

私は現在、11名のエンジニアを評価していますが、期末の評価には毎度多くの時間を費やしています。期初や期中に準備しているからこそ、この程度で済んでいるとはいえ、1つの期でトータルすると約1か月近くの稼働時間を使っています。一般論で言うマネジメントの限界人数（1人のマネージャーが抱えられる人数は7人が限界説）を超えていることもありますが、それよりもどのように伝えるとメンバーが正当に評価されるかを考える時間が多くを占めています。
これは最終評価を決める時にだけ考えれば良いという話ではなく、目標設定や期中の進捗サポート、来期への期待を伝えることも含みます。このような過程を踏んでいかないと評価者と被評価者双方にとって納得のいく評価に繋がらないと考えています。

私はマネージャーになってからの1年間そのためにアレやコレやと工夫をしてきました。
1人でメンバーの仕事振りを見れていたうちはまだなんとかなっていたのですが、見る人数が増えたり、チームが分かれてきたりしてきて、いよいよ「ヤバイよ、ヤバイよ」となってきたので、私の経験談から来る目標設定〜自己評価までの抑えておきたい重要なポイントをお伝えしたいと思います。

今回伝えたいこと

以下の4点を意識して目標設定と自己評価を行いましょう。

1. 会社や上司が自分に期待していることを知る
2. 自分の仕事内容を詳細に把握しているのは片手で数えられる程度の身近な人だけであることを知る
3. 成果の主語を事業に置き換えて説明する
4. 自分が取り組んだことの難易度を伝える

1. 会社や上司が自分に期待していることを知る

まず基本的なことですが、会社の評価制度を理解しましょう。評価制度にはその会社が理想とするエンジニア像が描かれています。会社が目指していない方向性での目標設定は評価に結びつきません。
少し前のエンジニアバブルの時を生きていると錯覚してきますが、企業に所属する以上はサラリーマンです。経営者が用意した土台の上で我々が働いているから、その分のインセンティブが得られるという事実を忘れてはいけません。
また、実際にその企業で活躍しているエンジニアを観察することも有効です。会社にとって有益な人材だと評価されている可能性が高いので、その人の真似をするというのも手です。

それと、どちらかと言うとこちらの方が重要な場面が多い気がするのですが、上司が自分に期待していることを知ることはとても重要です。直接メッセージとして伝えられる場合もあれば、仕事を頼まれる、というのもある種の期待です。後者の場合であれば、何を期待して自分に任せてくれたのかを聞いてみると良いかもしれません。

2. 自分の仕事内容を詳細に把握しているのは片手で数えられる程度の身近な人だけであることを知る

残念ですが、あなたが今向き合っている課題、それに対してどのような努力・工夫をしているかは、あなたの一部の同僚しか把握していません。
加えて、あなたの上司はあなたの評価だけでなく、他のメンバーの評価も行わなければならないため、リソースが限られています。
更に、評価者が仕事現場にいないケースとなると、成果ベースでの評価になりがちです。最悪、その成果を知らないケースもあるかもしれません。
なので、自分が取り組んだ事やその成果についてはしっかり全て伝えましょう。可能であれば、その過程や成果をエビデンスの形で残しておくとより具体性、納得感が得られるはずです。例えばエンジニアであれば調査結果をドキュメントにまとめる等、業務の中のちょっとした工夫で取り組めるはずです。

3. 評価の主語を事業に置き換えて成果を説明する

事業会社のエンジニアとしてあなたが取り組む仕事は事業として必要な何かを達成するための必要な何かです。例えば単純な機能開発だったとしても、それによって解決される課題にフォーカスする事で評価も変わります。開発の大小が必ずしも評価の優劣に繋がるとは限らないわけです。特に技術課題の解消等はこのパターンに当てはまりそうかなと思います。
その改善が事業にどのような好影響を与えるのかにフォーカスすることで、的を外すリスクを減らせるでしょう。

4. 自分が取り組んだことの難易度を伝える

私が特に伝えたいのがこれです。
冒頭述べた通り、Bizの言語に変換して伝える必要があります。
エンジニア同士であれば、その技術の難易度、プロジェクト難易度等理解できるかもしれませんが、職能が変わってくるとうまく伝わらないケースが出てきます。
開発現場であれば、開発期間や予算、影響範囲、メンバーのスキルセットなど、難易度に影響する要素がさまざまあると思います。自分にとってそれを達成する上で難易度が高いと感じた事、何故そのように感じたのか、それを解決するためにあなたが取った行動は何かを伝える事で、それを達成する上でどれだけ困難だったかより伝わりやすくなるでしょう。

少し具体的な例をもとに説明しようと思います。

私が思う自己評価のコメント例と改善案

コメント例①

期日通りリリースできました、指示された通りできました

コメント例①の改善点

• それが期日までにリリースできなかった場合の影響は何ですか？
  • 顧客に与える影響・損失は何ですか？
• 期日通りリリースすることはあなたにとってどの程度困難でしたか？
  • その困難だったことに対し、あなたなりに工夫したことは何かありますか？
    • どのような思考プロセスで考えましたか？（何を課題として捉えたのか、それは何故か、選択肢があったか、複数選択肢からそれが選ばれた理由、その結果は成果にどう繋がったのか）

コメント例②

〇〇のスキルを身に着けました

コメント例②の改善点

• 何故そのスキルを身につける必要があったのでしょうか？
• スキルが身についたと定量的に証明する方法はありますか？
  • 資格取得
  • 社内・社外へアウトプットして、他プロダクトの改善に役立った、いいねがたくさんもらえた等

コメント例③

（外的要因によって）達成できませんでした

コメント例③の改善点

• 達成するためにあなたが介入する余地は本当になかったのでしょうか？
  • 自分の立場、期待役割をセットで考えると、自分が取るべき振る舞いが見えてくる
• 達成できなかった事でどのような影響があったのでしょうか？
  • 悪影響があったのか、もしくは何もなかったのか
  • 予定が変わってやらなくなったとしても、その結論に導けたのであればそれも成果

コメント例④

開発生産性の向上をしました
品質の向上をしました

コメント例④の改善点

• それに努めるべきではあるが、オリンピックの短距離走選手ではないので最速タイムを出す事が大事ではないはずです。そのプロダクトが期待するスピード、品質であることを意識しましょう。
  • 例えばスケジュールが守れていない等の事実とセットで取り組む
    • なので取り組むべきタイミングも大切

まとめ

ものは言いようと感じる人もいるかもしれないけど、アピールしないと伝わるものも伝わらないです。
取り組んだことがちゃんと評価されるのは、評価者も願ってます。
お互い気持ちよく仕事するためにも意識していけると嬉しいなと思います。