人材育成に関わっても評価されないエンジニアへ|後輩育成を例に


新メンバーの質問に毎日答え、詰まっているところを一緒に見て、レビューで設計の意図を説明する。おかげでその人は独り立ちした。半年後、評価が上がったのはその人のほうで、自分の評価は横ばいだった。

育成は、成果が他人の名前で計上される数少ない仕事です。私は評価を付ける側でこの矛盾をよく見てきました。ただ、扱い方を変えれば評価にも市場価値にもつながります。その方法を整理します。

📌 この記事でわかること
  • 育成が評価制度から漏れる3つの理由
  • 育成の成果を自分の実績として残す数字
  • 採用側が育成経験をどう評価するか
  • 抱え込まずに続けるための線引き
ペアで教える場面のイメージ

育成が評価から漏れる3つの理由

1. 成果が育成された側に計上される

後輩が成長して成果を出すと、その成果はその人のものです。当然のことですが、育てた側の評価シートには何も残りません。

2. かけた時間が開発時間を食う

質問対応、ペアプロ、レビュー。1日1時間使えば、月20時間が開発から消えます。その分だけ自分のアウトプットが減り、評価上は不利に働きます。

3. 期初の目標に入っていない

「後輩を育てる」は目標として設定されにくく、突発的に発生します。目標にない仕事は、期末の評価で拾われません。

この3つは、育成に限らずチーム全体を支える仕事に共通します。レビュー業務でも同じことが起きます。詳しくはコードレビューばかりしているのに評価されない理由|見えない貢献の伝え方に書きました。

育成の成果を自分の実績として残す

育成の効果は、意外と数字にできます。

育成でやっていること取れる数字
オンボーディング独り立ちまでの期間(週数)
ペアプロ・質問対応同じ質問が来る回数の推移
レビュー指摘件数、手戻り率、レビュー所要時間
教材・手順の整備新メンバーの初回コミットまでの日数
チーム全体への波及チームのレビュー通過率、不具合件数

一番伝わりやすいのは独り立ちまでの期間です。「以前は新メンバーが独力でタスクを回せるまで平均3か月かかっていましたが、オンボーディング資料と初期タスクの設計を整えて、直近2名は6週間に短縮しました」という形なら、自分の実績として語れます。

ポイントは、個人への支援ではなく仕組みとして語ることです。「よく質問に答えていた」は属人的な親切ですが、「質問の傾向を分析して、頻出分を先回りで文書化した」は再現性のある改善です。後者のほうが評価も市場価値も高くなります。

新メンバーを迎えるデスクのイメージ

採用側が育成経験をどう評価するか

シニア以上のポジションでは、育成経験はほぼ必須で見られます。理由は単純で、上の等級は「自分が出す成果」から「他人が出す成果を増やすこと」に軸が移るからです。

面接で確認されるのは次の点です。

  • 何人を、どのくらいの期間、どういう形で見たか
  • 相手のレベルに合わせて教え方を変えた経験があるか
  • 伸びなかったケースにどう対応したか
  • 個人への支援で終わらず、チームの仕組みに落とせたか

特に3つ目は差がつきます。うまくいった話だけの人より、「このメンバーは基礎の理解に穴があったので、タスクを渡す前に設計の読み合わせを入れる形に変えました」と語れる人のほうが、マネジメントを任せられると判断されます。

言い換えの例です。

  • 「後輩の面倒を見ていた」→ 新メンバーのオンボーディングを設計し、立ち上がり期間を3か月から6週間に短縮した
  • 「質問に答えていた」→ 頻出する質問の傾向を分析し、事前に解決する資料を整備した
  • 「レビューをしていた」→ レビュー観点を明文化し、指摘の属人性を下げた
  • 「メンターをしていた」→ 2名のメンターを担当し、うち1名は半年で主要機能の設計を任せられる状態になった

抱え込まずに続けるための線引き

育成は際限なく時間を吸います。続けるには線引きが必要です。

時間を可視化して上司と共有する

「今月は育成に25時間使いました」と数字で伝えます。これがないと、開発が遅れた理由が本人の能力の問題に見えます。

期初の目標に入れる

「新メンバー2名を独力でタスクを回せる状態にする」といった形で目標化します。評価の土俵に乗せる唯一の確実な方法です。

個別対応を仕組みに変える

同じ質問が3回来たら、その時点で文書化します。都度答えるより早く、しかも実績として残ります。

全員を見ようとしない

メンターが1人に集中している状態は、チームとしてリスクです。「私が離れたら誰も見られません」という事実は、役割分散を提案する材料になります。

それでも育成がまったく評価されない制度なら、その会社ではシニアへの道が実質閉じている可能性があります。外の求人で、育成が要件として書かれているポジションを見てみると、自分の経験の値段が分かります。

IT転職エージェント@PRO人

ITエンジニアの転職に特化したエージェント「PRO人」。専任のキャリアアドバイザーが、経歴やスキルを踏まえた具体的な求人・条件面を提示してくれます。

  • IT・Web業界の転職支援に特化
  • 経歴・スキルに合わせた求人を紹介
  • 年収交渉や条件面のすり合わせも相談できる
  • TechGoとは別の視点で市場価値を確認できる
PRO人にキャリア相談する

よくある質問

Q. 育成した相手が辞めてしまった場合、実績になりませんか A. なります。在籍期間中に何ができるようになったか、その過程で自分が何を設計したかが実績です。離職の理由が育成にあるわけでもありません。

Q. 正式なメンターではなく、なんとなく面倒を見ている状態です A. 実態があれば語れます。面接でも「正式な制度ではありませんでしたが」と前置きしたうえで、人数、期間、やったことを具体的に話せば問題ありません。

Q. 教えるのが苦手でも、やるべきでしょうか A. 全員に向く仕事ではありません。ただ、仕組み化の形なら貢献できます。口頭で教えるより、手順や観点を文書にするほうが得意なら、そちらで役割を取るという選択もあります。

まとめ

育成が評価されにくいのは、成果が他人の名前で計上され、かけた時間が自分の開発を削るからです。

  • 期初の目標に入っていない仕事は、期末に拾われない
  • 独り立ちまでの期間は、最も語りやすい数字
  • 個人への親切ではなく、仕組みとして語ると評価も市場価値も上がる
  • シニア以上では育成経験がほぼ必須要件になる

まずは、直近に見たメンバーが独り立ちするまでに何週間かかったかを思い出してみてください。それが最初の数字になります。

関連記事