人事制度・組織開発
エンジニアとPMとEMの役割と評価をどう分けるか
エンジニア、PM、EMの役割を分けるときは、役職名の一般的な説明に合わせる前に、自社の案件・技術・人材に関する判断を整理します。同じPMやEMという名称でも、会社によって権限や責任は異なります。
この記事ではPMをプロジェクトマネージャーとして扱います。プロダクトマネージャーをPMと呼ぶ会社では、プロダクト戦略や優先順位を誰が決めるかを別に整理してください。
判断の対象を分けて役割を置く
以下は一般的な役割分担の設計例であり、唯一の正解ではありません。
| 判断の対象 | 主に担う役割の例 | 連携が必要な相手 |
|---|---|---|
| 案件の範囲、進行、納期 | PM | 顧客、開発責任者、営業 |
| 技術方式、設計、技術品質 | Tech Leadや技術責任者 | PM、エンジニア、関連チーム |
| 実装、検証、改善 | エンジニア | Tech Lead、PM、品質担当 |
| 採用、育成、配置、評価 | EMや組織の管理職 | 人事、技術責任者、事業責任者 |
| 事業上の優先順位、投資 | 事業・プロダクトの責任者 | PM、EM、経営者 |
肩書を増やすことが目的ではありません。一人が兼務している場合でも、どの役割として何を判断しているかを分けると、負荷と権限を確認できます。
兼務は作業時間と責任を別々に確認する
PMが納期の調整、技術レビュー、部下の育成まで担っている場合、評価項目を整えるだけでは過負荷は解消しません。今後の案件量と人員を確認し、何を他者へ移すかを検討します。
期待する役割を増やすときは、減らす実務も決めます。「育成もしてほしい」と追加しても、個人の開発作業量が変わらなければ、育成は後回しになりやすくなります。
評価は役割ごとに証拠を置く
| 役割 | 確認する成果・貢献の例 | 評価材料の例 |
|---|---|---|
| エンジニア | 担当範囲の品質、課題解決、改善 | 成果物、レビュー、障害対応の記録 |
| 上位専門職 | 難しい課題への貢献、標準化、他者への技術支援 | 複数案件への適用、意思決定の記録 |
| PM | 合意した範囲の実現、変更・リスク管理 | 変更記録、進行見込み、振り返り |
| EM・管理職 | チームの成果、育成、配置と負荷の改善 | チーム結果、役割移譲、育成の進捗 |
コミット数や処理件数など、数えやすい指標だけで全員を比較しないようにします。担当する仕事の難しさと影響範囲を踏まえ、複数の証拠から判断します。
専門職の上位役割を具体化する
管理職にならないと報酬が上がらない制度では、専門性を伸ばしたい人が管理職を選ぶことがあります。専門職の上位等級には、個人の高い能力だけでなく、組織への技術的な貢献や影響範囲を定義します。
ただし、上位専門職全員に人事評価や部下管理を求めると、管理職と区別しにくくなります。何を期待し、何を求めないかを役割として説明できるようにします。
YSKGのクライアントではどうだったか
公開しているIT企業向けの記事では、全社KGIと各部門が動かせるKPIを分け、役職ごとの比重をシミュレーションした取り組みを紹介しています。
この事例は、PM・EM・専門職の役割分離を完了した実績として示すものではありません。参考になるのは、全員を同じ指標で評価する前に、本人の役割と動かせる範囲を確認した点です。
よくあるご質問
PMとEMを同じ人が担ってもよいですか
兼務は可能ですが、仕事量、権限、判断の衝突を確認します。案件を優先すると育成が止まるなどの問題が続く場合は、分担か作業量の見直しが必要です。
職種ごとに評価制度を完全に分けるべきですか
共通の価値観や等級の大きな考え方を揃えつつ、役割に応じた成果と証拠を分ける方法があります。独立した制度を増やす前に、共通部分と固有部分を整理します。
YSKGへのご相談
この記事で扱ったテーマについて、貴社の状況に合わせた進め方をご相談いただけます。
株式会社YSKGは、経営支援・組織人事・ビジネスコーチングの3領域で、個別テーマだけでなく相互のつながりを見ながら成長企業に伴走しています。
職種の役割と評価について相談するエンジニアの離職率が高く、退職理由の集計では原因がつかめなかった会社
