肩書きと実態がズレているエンジニアの評価問題|実質マネージャーを例に


採用面接に同席し、メンバーの1on1をこなし、期の目標を配分し、工数の調整もしている。やっていることはマネージャーなのに、肩書きは一般社員のままで、等級も給与も据え置き。

この状態に置かれている方は思いのほか多いです。私は評価制度の運用側にいたので分かりますが、役割が先に広がり、等級が後から追いつかないのは、仕組み上かなり起きやすい現象です。ただし放置すると損が固定されます。この記事では構造と打ち手を整理します。

📌 この記事でわかること
  • 役割と等級がズレたまま固定される理由
  • ズレを放置するとどこで損をするか
  • 肩書きがなくてもマネジメント経験として語れる条件
  • 社内で役割を明示してもらう進め方
役割が曖昧なまま集まる会議室のイメージ

なぜ役割だけが先に広がるのか

1. 空いた穴を埋められる人に回るから

マネージャーが退職した、組織が大きくなった、プレイングマネージャーが手一杯になった。こうしたとき、実務が分かっていて信頼されている人に業務が流れます。これは能力を認められている証拠ですが、正式な任命とは別の経路で起きます。

2. ポストの数が決まっているから

多くの会社では、管理職のポスト数が組織図と人件費で決まっています。実質的にマネジメントをしていても、ポストが空いていなければ肩書きは付きません。ここは上司の裁量では動かせません。

3. 任命には手続きが要るから

等級を上げるには、評価会議、人事の承認、場合によっては役員決裁が必要です。一方、業務を頼むのは会話1回で済みます。手続きの重さの差が、そのままズレとして現れます。

同じ構造はチームリーダーの立場でも起きます。チームリーダーなのに評価されないエンジニアへ|採用側から見た伝え方もあわせて参考にしてください。

ズレを放置するとどこで損をするか

短期では「頼られている」で済みますが、中長期では次の形で損が出ます。

場面起きること
評価管理業務に時間を取られ、個人の開発成果が減って評価が下がる
給与等級が上がらないので、責任だけ増えて報酬が変わらない
転職職務経歴書に「マネジメント経験」と書きにくく、応募先が狭まる
社内異動正式な経歴として残らないため、他部署から見ると実績がない

特に厄介なのが1行目です。管理業務は評価シートに項目がないことが多く、そこに時間を使うほど評価が下がるという逆転が起きます。私が見てきた中では、実質マネージャーの人の評価が、専任で開発していた人より低くなるケースが実際にありました。

予定で埋まった1週間のイメージ

肩書きがなくても「マネジメント経験」として通る条件

採用側の実務として言うと、肩書きの有無は決定的な要素ではありません。見ているのは次の点です。

  • 何人を、どのくらいの期間見ていたか
  • 評価や採用に、どの程度関与したか(同席のみか、判断まで入るか)
  • 目標設定や配分を自分で決めたか、上から降りてきたものを配っただけか
  • メンバーの成長や離職について、自分の施策と結果を語れるか

これらを具体的に語れるなら、肩書きがなくてもマネジメント経験として扱われます。逆に、肩書きがあっても上記を語れない人は評価されません。

伝え方の例です。

  • 「リーダーではないが、実質まとめていた」→ 5名のチームで、目標設定と週次の進捗管理、1on1を担当した
  • 「面接に出ていた」→ エンジニア採用の一次面接官として年間20名程度を評価し、評価基準の設計にも関与した
  • 「後輩を見ていた」→ 新メンバーのオンボーディングを設計し、立ち上がり期間を2か月から3週間に短縮した
  • 「調整をしていた」→ 他部署との要件調整を担い、仕様変更による手戻りを削減した

数字を1つ入れると、一気に具体性が上がります。 人数、期間、頻度のどれかは必ず出せるはずです。

社内で役割を明示してもらう進め方

いきなり「昇格させてください」と言うと、ポスト数の話に流れて終わります。段階を踏むほうが現実的です。

1. 業務の内訳を可視化する

1か月、自分の時間を「開発」「管理・調整」「その他」で記録します。管理が3割を超えているなら、それが交渉の材料になります。感覚ではなく実績で話せます。

2. 評価上の扱いを確認する

面談で「この管理業務は、今の等級の期待役割に含まれていますか」と聞きます。含まれていないなら、評価されない仕事を無償でしていることになります。この質問は角が立ちにくく、事実確認として機能します。

3. 肩書きより先に、評価項目を求める

ポストは空かなくても、評価シートに項目を追加することは比較的通りやすいです。「マネジメント業務を評価対象に入れてほしい」という要求は、昇格要求より実現しやすい現実的な一歩です。

4. 期限を決める

半年後に状況が変わらないなら、制度として扱う意思がないと判断できます。ここを決めておかないと、何年も同じ状態が続きます。

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

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

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

よくある質問

Q. マネジメントはやりたくないのに任されています A. その場合も可視化は有効です。時間の内訳を示したうえで、開発に戻りたい意思を伝えるほうが、漠然と断るより通りやすいです。会社としても、誰がどれだけ管理業務を持っているかを把握していないことが多いです。

Q. 部下が2〜3人でもマネジメント経験になりますか A. なります。人数より、何を任されていたかが重要です。評価に関与していたか、採用に関わったか、目標設定を自分で決めたか。この3点のどれかがあれば、十分に語れます。

Q. 肩書きがないと、転職先でも管理職では採用されませんか A. そんなことはありません。ただし職務経歴書に実績を具体的に書く必要があります。肩書きがない分、人数、期間、関与範囲を明記してください。書き方はエンジニアの職務経歴書、採用側は最初の30秒でここを見ているにまとめています。

まとめ

役割と肩書きのズレは、能力が認められているからこそ起きる現象です。ただし放置すると損が固定されます。

  • 業務は会話1回で頼めるが、等級を上げるには手続きが要る
  • 管理業務は評価項目にないことが多く、時間を使うほど評価が下がる
  • 採用側が見るのは肩書きではなく、人数・期間・関与範囲・結果
  • 昇格より先に、評価シートへの項目追加を求めるほうが通りやすい

まずは1か月、自分の時間を開発と管理で分けて記録してみてください。それが交渉でも職務経歴書でも使える最初の材料になります。

関連記事