IT・Web企業の評価制度｜エンジニアと管理職を同じ物差しで評価してはいけない理由

IT・Web企業では、エンジニア、デザイナー、PM、営業、管理職を同じキャリア観で評価すると歪みが出やすくなります。特に「上位等級＝管理職」という単線型制度は、専門性の高い人材に不自然な昇進を迫ることがあります。

図解：管理職ルートと専門職ルートを分ける

1. まず職種ごとの価値創出を分ける

営業は売上、PMはプロジェクト成果、エンジニアは技術成果・品質・生産性など、価値の出し方が違います。共通バリューは持ちつつ、成果指標を分けます。

2. 「マネージャーにならないと給与が上がらない」をなくす

専門職で高い貢献をする人が、報酬上限のためだけに管理職になると、本人・組織双方に損失が出ます。専門職の上位レンジを管理職と同等に設計します。

3. 技術力だけで上位等級にしない

上位専門職には、難しい課題を解く力だけでなく、レビュー、標準化、後進支援、全社技術への影響などを求めます。

4. PM・EM・Tech Leadの役割を明確にする

IT組織ではタイトルが似ていても責任が重なりやすいため、人・プロジェクト・技術の最終責任を分けます。

5. 評価会議で職種間の“見えやすさ”を補正する

営業の数字は見えやすく、バックエンドや基盤改善は見えにくいことがあります。多面評価や実績証拠、キャリブレーションで補正します。

評価項目例

YSKGのクライアントではどうだったか

※守秘義務の観点から、業種・規模・数値・時期など、事例の一部を特定できない形に一般化しています。

IT企業で、組織・役職によってKGI/KPIの比重を変える設計

あるIT企業では、全社員を同じ指標で評価すると、職種や役職によって自分では動かしにくい数値が含まれる問題がありました。YSKGでは、全社成果を表すKGIと、各部門・現場が動かせるKPIを分け、役職ごとにその比重を変える案をシミュレーションしました。

さらに、AI活用など今後強化したい戦略テーマはKPIの中に明示的なウェイトを持たせる一方、項目が増えすぎないよう既存項目を削減しました。IT・Web企業の評価では「全員共通のきれいな制度」より、職種・役割と会社戦略の両方に合わせて設計することが重要です。

よくある質問

Q1. このテーマに取り組むとき、最初に何から始めるべきですか？

職種名だけでなく、実際に誰が案件・技術・人材について判断しているかを書き出します。その役割と、現在の等級・評価が合っているかを確認します。

Q2. どのくらい作り込めば運用を始められますか？

一職種の役割と評価の案を、具体的な仕事の例に当てて確かめられます。処遇への反映は、他職種との関係や移行時の影響も確認してから進めます。

まとめ

全員に共通する期待と、役割によって違う期待。その両方を説明できる制度にしたいと思います。まずは、管理職になる以外にどんな成長の道があるかを確認してみてください。