担当業務が広がっているのに評価されないエンジニアへ｜PdM・PO寄りの仕事を例に

仕様を自分で決めている。どの機能を先に出すかも実質的に自分が判断している。事業側から相談が来て、実現可能性を検討して、代替案を出す。それでも職種は「エンジニア」のままで、評価基準も実装量で測られている。

これは、職種の定義が実態に追いついていない状態です。私は採用でこうした経歴の方によく会いますが、本人が「自分はただのエンジニアです」と説明してしまい、もったいないケースが多いです。この記事では整理の仕方を書きます。

なぜ職種の定義が追いつかないのか

専任がいない組織では、隙間が開発側に落ちる

PdMやPOが不在、あるいは兼任で手一杯の組織では、仕様の細部を決める人がいません。実装する人が決めるのが最も早いので、自然とエンジニアに流れます。悪意のある話ではなく、合理的な流れです。

職種の変更には手続きが要る

役割が広がるのは会話1回で済みますが、職種や等級を変えるには人事の手続きが必要です。この非対称が、ズレを固定します。同じ構造は肩書きと実態がズレているエンジニアの評価問題｜実質マネージャーを例にでも起きます。

評価基準が職種ごとに用意されている

エンジニアの評価シートは、実装、設計、品質で作られています。「どの機能を作らないと決めたか」を書く欄はありません。プロダクト判断は、エンジニアの評価基準では測れないのです。

プロダクト判断の実績を残す

この種の仕事は、記録しておかないと跡形もなく消えます。残すべきは次の4点です。

記録する項目	具体例
何を作らないと決めたか	要望のあった一括編集機能を、利用見込みが低いと判断して見送った
優先順位をどう変えたか	新機能より先に、解約理由の上位だった通知の不具合対応を前倒しした
判断の根拠	問い合わせログの分類、利用率のデータ、営業へのヒアリング
結果どうなったか	解約率が月2.1%から1.6%に改善した

特に重要なのが1行目です。作らない判断ができることは、プロダクトに関わる人材として最も高く評価されます。 エンジニアは作れてしまうので、作らない判断のほうが希少です。

数字が取れない場合でも、「どのデータを見て、何を根拠に決めたか」を書いておけば、判断のプロセスとして語れます。

採用側から見た、この経験の価値

率直に言うと、実装もでき、プロダクト判断もできる人は市場で取り合いになります。特に次のポジションで需要があります。

• 少人数の開発組織でのテックリード
• PdMとエンジニアの橋渡しをするポジション
• 0→1フェーズのプロダクト開発
• 事業側と近い距離で開発するSaaSの開発チーム

面接で見られるのは次の点です。

• 何を根拠に優先順位を決めたか。数字を見ているか、勘か
• 事業側と意見が割れたとき、どう着地させたか
• 実現可能性と事業価値を、どう天秤にかけたか
• 決めたことの結果を追っているか

言い換えの例です。

• 「仕様を考えていました」→ 事業要件を実装可能な仕様に落とし込み、スコープの線引きを担当した
• 「優先順位を決めていました」→ 利用データと問い合わせ内容をもとに、開発順序を決定した
• 「相談を受けていました」→ 事業側の要望に対し、実現コストと代替案を提示して意思決定を支援した
• 「要望を断っていました」→ 効果が見込めない要望を見送る判断をし、その根拠を関係者に説明した

社内で役割を認めてもらう

1. 時間の内訳を出す

1か月、実装とプロダクト判断に使った時間を分けて記録します。判断側が3割を超えているなら、評価基準が実態と合っていない証拠になります。

2. 評価項目の追加を求める

職種変更より、評価シートへの項目追加のほうが通りやすいです。「仕様策定とスコープ判断を評価対象に入れてほしい」という要求なら、上司も動きやすくなります。

3. 判断の記録を共有する

決めたことと根拠を、チームのドキュメントに残します。記録があると、評価面談で「自分が決めた」と示せます。口頭だけだと、上司の記憶では誰が決めたか曖昧になります。

4. 半年で判断する

役割が広がったまま評価が変わらない状態が半年以上続くなら、その会社では制度として扱う意思がない可能性が高いです。外で同じ役割がどう募集されているかを見ると、自分の経験の値段が分かります。

よくある質問

Q. PdMに職種変更したほうがいいですか A. 実装を続けたいかどうかで変わります。両方できることが強みなので、急いで片方を捨てる必要はありません。転職市場では「実装できるPdM」「プロダクトが分かるエンジニア」はどちらも希少です。

Q. データを見る環境がなく、勘で決めています A. まずは問い合わせ内容の分類から始めると、すぐに材料になります。完璧な分析基盤は要りません。「どの要望が何件来ているか」を数えるだけでも、判断の根拠として語れます。

Q. 実装量が減って評価が下がりました A. 典型的なパターンです。時間の内訳を示して、判断業務に使った時間を明示してください。示さないと、単に生産性が落ちたと見なされます。

まとめ

担当業務が広がっているのに評価されないのは、職種ごとの評価基準が実態を測れないためです。

• 専任がいない組織では、仕様の細部が開発側に落ちる
• エンジニアの評価シートには「作らないと決めた」を書く欄がない
• 作らない判断ができることは、市場では最も高く評価される
• 職種変更より、評価項目の追加を求めるほうが通りやすい

まずは直近で「作らない」と判断したことを1つ思い出して、その根拠と結果を書き出してみてください。

関連記事

• 肩書きと実態がズレているエンジニアの評価問題｜実質マネージャーを例に
• 調整業務が多いエンジニアほど評価されにくい理由｜会議が多い働き方を例に
• 裁量が増えないエンジニアへ｜技術選定を任されない状況を例に
• エンジニアの市場価値はどう決まる？採用側が実際に見ているポイント