育成・メンタリングがエンジニアの年収に効く条件｜等級要件と115万円の昇格差

後輩のレビューやオンボーディングを引き受けていても、評価の面談では触れられずに終わる。この状態で最初に確認するのは、努力の量ではなく、自社の等級要件に育成が書かれているかどうかです。書かれていれば昇格の判定材料になり、書かれていなければ加点の根拠が制度上存在しません。

結論から言えば、育成・メンタリングは年収に効きます。ただし効くのは昇格を通じてで、効く会社と効かない会社がはっきり分かれます。

結論：等級要件に書かれているかで扱いが変わる

育成の扱いは、会社の等級制度によって二つに分かれます。等級要件に「他者を通じて成果を出す」「メンバーの立ち上がりに責任を持つ」といった記述がある会社では、育成は昇格の判定材料そのものです。記述がない会社では、育成は評価シートの自由記述に書ける程度の扱いになり、昇給額を動かす根拠になりません。

この違いが重要なのは、同じ行動が片方では投資になり、もう片方では自分の成果を削る工数になるからです。レビューに週5時間を使えば、自分の実装に使える時間は確実に減ります。その5時間が要件を満たす証拠として残るのか、誰にも参照されずに消えるのかで、一年後の等級が変わります。

たとえば等級定義に「担当範囲を越えてチームの生産性に寄与する」とある会社なら、新メンバーが自力でリリースできるようになった事実は、そのまま要件の充足を示す材料です。一方、等級が担当システムの規模と難易度だけで定義されている会社では、同じ事実は「手が空いていた」とも読めてしまいます。

ただし、要件に書かれていない会社でも育成が無価値になるわけではありません。転職時の評価軸は会社ごとに違うため、社内で評価されない実績が、社外では等級を一段上げる材料になることがあります。社内の昇給と社外での提示年収は別の判定だと分けて考えてください。

等級が一段上がると年収はどれだけ動くか

育成を評価に乗せる目的は、評価面談で褒められることではなく、等級を上げることです。等級の段差がどれくらいの金額なのかを先に見ておきます。上場・大手／東京勤務／スキル中位という条件を固定し、経験年数帯だけを変えるとこうなります。

表のレンジはいずれも推定中央値の±8%で、実務3〜5年と6〜9年の中央値を比べると差は 115万円 です。多くの会社の等級制度はこの経験年数帯と対応しており、一段上がるかどうかが、この幅の移動にあたります。

この表の読み方には注意が必要です。年数が経てば自動で上がる額ではなく、その年数帯で任される責任範囲に対応した水準として置いた推定値です。経験年数だけが増えて責任範囲が変わらない場合、同じ帯の下端に留まることになります（経験年数だけ増えて年収が止まる型）。また企業タイプや勤務地が違えば幅も変わるため、自社の給与テーブルと直接比べられる数字ではありません。

逆に言えば、育成の要件を満たして昇格する道筋は、評価面談での印象より大きな金額を動かします。昇給率の交渉で動かせる幅と比べると、段差のほうが明確に大きくなります。

育成の成果が評価に乗りにくい理由

育成が評価に乗りにくいのは、本人の努力が足りないからではなく、成果が自分ではなく相手の側に現れるからです。実装なら「この機能を作った」と差分が残りますが、育成の成果は他人の成長という形で出るため、評価者から見ると誰の貢献なのかが判別しづらくなります。

もう一つの理由は、育成が日常業務に溶けていることです。レビューのコメント、設計相談への同席、障害対応の伴走は、どれも単独では小さく、記録に残らないまま流れていきます。評価の時期にまとめて思い出そうとすると、「よく相談に乗った」という印象しか残っていません。

具体的にはこうなります。新メンバーの最初のリリースまで三か月付き添い、その後は自力で進むようになった。この事実を評価シートに「オンボーディングを担当した」と書くと、担当したという役割の記述にしかなりません。「配属から三か月で、本人が設計レビューを通して単独でリリースできる状態になり、以降は自分のレビュー工数が週あたりで半分以下になった」と書けば、何が変わったかが残ります。

注意したいのは、相手の成長をすべて自分の成果として書くと、評価者から見て過大に見えることです。自分が関与した範囲と、本人の努力による部分を分けて書くほうが通ります。

自社の等級要件を確かめる4つの場所

要件が書かれているかは、人事に聞く前に自分で確かめられます。確認する場所は限られています。

• 等級定義書・グレード定義（社内ポータルや人事システムに置かれていることが多い）
• 評価シートの評価項目名（「人材育成」「組織貢献」などの項目が独立しているか）
• 昇格申請の書式（記入欄に育成の実績を書く欄があるか）
• 自社の採用求人票（同じ職種の上位等級で、育成が歓迎要件や必須要件に入っているか）

4つ目は見落としやすい確認先です。社内文書が整っていない会社でも、求人票には等級ごとの期待値が書かれていることがあります。求人票から等級を逆算する手順は必須要件・歓迎要件から等級を読む方法で扱っています。

これらを見ても育成に関する記述が見つからない場合、その事実自体が答えです。制度として評価対象になっていないため、上司が個人的に高く買ってくれても、昇給の原資を動かす根拠にはなりません（等級・グレード制度の読み方）。

評価材料として残す記録を4種類に分ける

記録は量ではなく種類で分けると、評価者が要件と突き合わせられる形になります。四つに分けて残してください。

この表は、四つすべてを埋めることを求めるものではありません。等級要件に「組織への波及」が含まれるなら三行目と四行目が効き、「メンバーの立ち上がり」に限定されているなら一行目が中心になります。要件の文言に合う行から埋めるのが順序です。

適用できないのは、チームの数字を自分では取得できない場合です。レビュー待ち時間を計測していない組織で推定値を書くと、根拠を問われたときに崩れます。その場合は数字を作らず、到達点と自分の工数だけで組み立ててください。評価で最も弱いのは、確かめられない数字を出して信頼を落とすことです。

期の初めに合意しておく3項目

育成の評価は、期末の書き方より期初の合意で決まります。評価者が期末に見るのは、期初に置いた目標に対する達成度だからです。

• 育成の対象と範囲（誰の、どの領域を、どの水準まで）
• 使う工数の上限（週あたり何時間を育成に充てるか）
• 達成と見なす状態（「単独でリリースできる」など、観測できる状態で書く）

三つ目を状態で書くのが要点です。「サポートする」と書くと達成度の判定ができず、期末に評価が付きません。OKR・MBOの目標設定と昇給額の関係で扱ったとおり、観測できない目標は配分の判断材料になりません。

二つ目の工数の上限も、期初に置いておく意味があります。上限を決めずに引き受けると、自分の担当分の進捗が落ち、育成で加点されても本来の成果で減点される形になりがちです。上限を合意していれば、超えた分は体制の問題として相談できます。

具体例：レビュー待ちの解消を成果として示す

実務での組み立て方を一つ示します。チームのレビューが自分に集中し、他のメンバーのマージまでの待ち時間が長くなっていた状況を想定します。ここで育成の目標を「レビューできる人を増やす」に置き、三か月で二人がレビュアーとして機能する状態を作ったとします。

このとき評価面談に出すのは、「二人を育てた」ではありません。レビュー依頼のうち自分以外が対応した比率、マージまでの待ち時間の変化、自分がレビューに使った時間の推移という三点です。自分の工数が下がり、チームの待ち時間も下がったなら、投下した時間がチームの処理能力に変わったことが示せます。

この型が効くのは、成果が自分の外に出ていることを逆に利用している点です。自分の時間が減ったという事実は、普通なら成果の減少に見えます。しかし待ち時間の短縮と並べれば、同じ事実が移譲の成功を示す根拠になります。

ただし、数字が動かなかった場合に無理に成果を主張しないでください。レビュアーが増えても待ち時間が変わらないこともあります。その場合は、要因がレビュー体制ではなく別の工程にあったという整理として出すほうが、次の目標設定につながります。

よくある失敗：面倒見のよさで終わる

最も多い失敗は、育成を人柄として扱われて終わる形です。相談には必ず応じ、詰まっていれば一緒に直し、ドキュメントも代わりに書く。この働き方は感謝されますが、等級要件の「他者を通じて成果を出す」には届きません。代わりにやってしまうと、相手ができるようになった証拠が残らないためです。

もう一つの失敗は、育成を引き受けた分だけ自分の担当成果が落ち、総合評価では下がるという形です。評価者から見ると、担当していた設計の遅れは記録に残り、レビューの時間は記録に残っていません。工数の合意がないままだと、この非対称がそのまま評価差になります。

三つ目は、対象を広げすぎることです。チーム全員の相談窓口になると、一人ひとりの到達点が追えなくなり、何が変わったかを示せなくなります。評価材料としては、二、三人に絞って到達点を追えている状態のほうが強くなります。

昇給の原資から見ると、育成だけでは幅が小さい

育成を評価に乗せても、同じ等級の内側で動く金額には限りがあります。情報通信業の1人平均賃金の改定率は 3.9%（令和7年（2025年））、改定額は 14,096円/月 です。昇給の内容が業績評価などによる企業の割合は 85.9% で、評価が昇給に反映される会社は多数ですが、反映される幅自体がこの水準に収まります。

つまり、評価を一段上げて同じ等級内で上振れさせても、動くのは月あたり数千円から一万円台の話です。これに対して等級の段差は、先の表のとおり中央値で115万円の移動にあたります。育成の記録を残す目的を昇給率の上積みに置くと、労力に対する見返りが小さく感じられます。昇格の判定材料として使うのが本来の位置づけです（昇給額が妥当か給与明細で確かめる）。

この比較は、昇給の交渉が無意味だという意味ではありません。同じ等級に長く留まる場合、毎年の上積みは積み上がります。ただし育成に時間を使う判断の採算は、等級が上がるかどうかで決まると考えてください。

等級要件に育成が入っていない会社での判断

要件に育成がない会社では、三つの選択肢があります。一つ目は、引き受ける範囲を上司と合意した工数に限り、自分の成果が出る時間を守ること。二つ目は、育成を自分の設計・技術判断の範囲に寄せ、技術的な成果として記録すること。三つ目は、育成が等級要件に入っている会社へ移ることです。

二つ目は現実的な落としどころです。たとえばレビュー基準をドキュメント化し、CIに検査を追加して、人が指摘しなくても品質が揃う状態を作れば、それは育成ではなく仕組みの成果として要件に当たります。他者への伝達を、人への指導ではなく仕組みへの埋め込みに変える形です。

三つ目を検討する場合、応募先の等級要件を選考の過程で確認してください。カジュアル面談や求人票で、上位等級の期待値に育成や組織貢献が含まれるかは確かめられます（カジュアル面談で年収と等級をどこまで聞けるか）。確認せずに移ると、同じ構造を繰り返すことになります。

避けたいのは、評価されないまま引き受け続けて、担当成果も落ちる状態です。これは本人の評価が下がるだけでなく、育成の質も落ちます。

テックリード・マネージャーとの線引き

育成の実績を積むと、マネジメント側への打診を受けることがあります。ここで確認するのは、打診された役割が等級の上昇を伴うのか、同じ等級のまま役割が増えるのかです。後者であれば、年収は動かないまま責任だけが増える形になります。

技術の責任を持ち続けるのか、組織の責任に寄せるのかは、年収の伸び方そのものが変わる分岐です。どちらが高いかは会社の制度設計によって変わり、一般論では決まりません（テックリードとマネージャーはどちらが高年収か）。

同じスキル水準でも、担当する責任範囲によって推定レンジは動きます。実務6〜9年・上場企業・東京で、スキル中位と上位を比べるとこの差です。

• スキル中位（スコア50）：638〜748万円
• スキル上位（スコア85）：723〜848万円

育成に時間を寄せると、この軸での伸びが鈍ることがあります。どちらを取るかは個人の選択ですが、両方を同時に最大化はできないという前提で配分を決めてください。

転職のときに育成経験をどう出すか

社内で評価されなかった育成経験も、選考では使えます。ただし書き方を変える必要があります。職務経歴書に「メンバーの育成を担当」と書くと役割の記述で止まるため、何が変わったかに言い換えます。

変換の軸は、人ではなくチームの状態です。レビューの待ち時間、リリース頻度、障害の一次対応ができる人数、オンボーディングにかかる期間。これらのどれが、どの期間でどう変わったかを書けば、応募先の評価者は自社の課題と重ねて読めます。書き分けの型は職務経歴書で提示年収が変わる理由で扱っています。

面接では、育成の方法論ではなく判断を聞かれます。どこまで任せ、どこで介入したか、任せた結果うまくいかなかったときに何を変えたか。失敗した例を一つ用意しておくと、再現性のある判断として伝わります。

注意点として、前職の同僚の能力を低く描く形で実績を説明すると、評価が下がります。人物への評価ではなく、状態の変化として話す範囲に留めてください。

まとめ

• 育成・メンタリングが年収に効くのは、等級要件に書かれている会社。要件の確認が最初の手順
• 効き方は昇格を通じて。同じ等級内の昇給は改定額の範囲だが、等級の段差は中央値で115万円
• 記録は到達点・自分の工数・チームの数字・仕組み化の4種類に分け、要件の文言に合う行から埋める
• 期初に対象・工数の上限・達成と見なす状態を合意する。状態で書かないと達成度が判定されない
• 要件に入っていない会社では、工数を限るか、仕組みの成果に言い換えるか、応募先の要件を確かめて移る