エンジニアのモチベーションが上がる目標設定・評価
はじめに
SkillnoteVPoEの安藤です。
今回はEMであれば誰しもが悩み、苦労（工夫）している目標設定・評価について書きたいと思います。
きっかけは#1の頃から参加している「EMゆるミートアップ」で、3月1日開催の#6のテーマがそのものズバリの「目標設定・評価」だったことです。
EMゆるミートアップ
そもそもエンジニアリングマネージャーという職務は最近になって出てきたもので、ITという比較的新しい業界の中でもさらに新しい役割、と言えるかと思います。（オライリーの書籍も日本での初版が2022年と相当に新しいことが分かります）
SaaSプロダクトが隆盛な中、エンジニアチームが継続的にハイパフォーマンスを発揮するため、また事業KPIに対して直線的に貢献できるようにしていくため、プロダクトマネージャーやエンジニアリングマネージャーといった役割の重要性が昨今非常に増してきている、ということと思います。
また、こういったポジションに対する専門的な資格は存在せず、その道のプロフェッショナルも多くない、元々エンジニアや近しい業務に就いていた方が半ば自然とその役割をこなすようになる、ということも多い現状があります。
そのためはっきりとしたEM像がない、という点が全体的に共通している課題・悩みになっています。
EMゆるミートアップは、そのようなエンジニアリングマネージャー同士がお互いの知見を共有し、横のつながりを持つことで相互理解を深め、「こんなに大変なことに直面しているのは自分だけじゃないんだ」という自己肯定感を高めることにも貢献してくれる、とても貴重な場になっています。
EMゆるミートアップ#6の感想
一部資料はconnpassにも上がっているのですが、オンラインオフライン合わせて70名近い参加者が集まった会だったようです。（オフライン参加しましたが、今までで最も参加者が多かったように感じました。継続は力なりですね素晴らしい・・）
#6のテーマは「目標設定・評価」で12名のLTがある盛況っぷりでした。（当初枠が6枠で、希望者が多すぎて増枠して、さらに不足したくらいとのこと。自分も時間的な余裕があれば発表したかった・・）
感想などをまとめると
多くの方が挙げたのは「目標の被評価者とのすり合わせ」が重要
メンバーの視座はマネージャーが普段から植え付けている視座そのもの（痛い）
組織目標を立てることは腹落ちするが、個人目標を立てることは腹落ちしづらい（共感）
といったことが挙げられます。特に個人目標を立てることに対する必要性については、エンジニアの中には個人目標がなくても方向性さえ間違わなければ（組織目標さえ立っていれば）高いパフォーマンスを出す人もいるため共感もしました。
Skillnoteにおける評価制度
そうは言っても組織ですので一定の基準で評価を行い、各メンバーが納得できる、ロールモデルにできる人を探せる制度を作っていく必要があります。Skillnoteでは全社共通の等級制度を取っており、エンジニアについてもビジネス職やバックオフィス職と同じ基準で評価するようにしています。
※ エンジニアに特化したキャリアラダーを作り、独自評価できるようにする仕組みは目下構築中です。
そのため、評価のキモはいかにその人がやる気になれる、自分の役割や業務を半年、1年先に目線を上げて考えられ、それを指標として落とし込めるか、という点になります。
目標設定に対する工夫
Skillnoteはスタートアップであり、競合状況などの外部環境含め、めまぐるしく日々の状況が変わります。
また、2023年から遅行指標、先行指標に分けて目標を立て、遅行指標への先行指標の相関仮説についてモニタリングするよう執行体制を整えました。
その上で日々の変化に対応できるよう、四半期ごとに目標の見直しタイミングを設ける運用としています。
プロダクト開発チーム目標について、2024年は主要ロードマップ案件の達成、生産性1.5倍、といった目標を掲げており、それに対して各グループが採用含めたそれぞれの目標を立て、それを個人の先行指標に落とし込む、といった目標設定を実施しています。
例えばグループ目標を「全員フルスタック化の加速」「1日1回以上のデプロイ」と設定し、その上で個人の目標として「1日1プルリクエスト」とするなどです。
最終的に立てられた目標は複数メンバーで重なることもあるのですが、先行指標が追う結果指標、つまり先行指標を達成した先にある目標が各自異なっており、その相関関係仮説がメンバーごとに異なる、という点が特徴的かと思います。
このような工夫をすることで、各メンバーごとに「目の前で追っている数字は同じ」でも見据える先がメンバーや役割や等級に応じて異なる、といったことになり、各自のモチベーションを引き出すことにつながる、ことを期待しています。
また、遅行指標への想定仮説があるため、EMとしても仮に先行指標が達成できていても遅行指標につながっていない場合は、例えば仮説に誤りがあったのではないか？といったことや、先行指標としての打ち手が不足していたのでは？といった仮説検証ベースでのサポートができることにもつながりますし、評価時も基本的には期中のサポートをまとめて伝えるだけ、といったようなこととなり、評価負荷も平準化できると考えています。
エンジニアの目標設定・評価は、過去の経験としても得てして絵に描いた餅になったり、実体を表していない目標になったり、単なるタスク目標になったりする（実施したかしなかったか、の 0 / 100 評価しかできない）ことが多く、評価も形骸化することを経験してきたのですが、上記の工夫をすることで進捗も見える化でき、期中での軌道修正もしやすいような形で運用ができないか、試行錯誤しています。
まとめ
ここまで記載した運用も、言葉にするとキレイに見えますが実体はその通りになっていないことも多く、課題も多いです。（例えば、事業KPIとグループ目標や、個人目標をどう仮説をもって接続するか、まだ良い目標になっていないなど）
引き続き個人の成長がチームの成長につながり、それが会社の成長にもつながる、また会社の目標を達成するために、まっすぐ個人が頑張り、イキイキと働いていける、そのような評価制度、目標設定であるよう、今後も整備を進めていきたいと考えています。
具体的にどんな目標を立てているか気になる、工夫についてもっと聞いてみたい、など気になった方は是非お気軽に話しにきてください。
この記事が気に入ったらサポートをしてみませんか？