![見出し画像](https://assets.st-note.com/production/uploads/images/164617993/rectangle_large_type_2_876142837b42f4a373710b064c97da5c.png?width=1200)
EM vs DevHR:埋もれるHRの価値、そして突破口
こんにちは、ジンジニアで活動しているtakakazu(@tkkz1009)です!
普段は開発組織の人事 or Engineering Office的な仕事をしております。
この記事はジンジニア アドベントカレンダー Advent Calendar 2024の6日目の記事です。前回(5日目)はてぃーびーさん(tbpgr)の「ITエンジニアの情報発信文化を人事領域に広げたい」でしたね。
12月1日に引き続き6日目担当させて頂きますのでで何卒よろしくお願い致します。
ちなみに12月1日(1日目)の記事はこちらです
さて6日目ですが、最初は「EMとDevHRの役割について考える」という話で書こうとしていたのですが、書いていくうちに開発組織での人事業務でよく聞く悩みの話を書きたいことに気づいたのでそっちにシフトします。
EMとDevHRはともに組織を良くしていう上でよく連携していく立場でその業務も共通する部分があります。この役割の重複からくる悩みやそのネクストアクションについて触れていければとおもいます。
EMとDevHRのそれぞれの役割
EM(EngineeringManager)とは?
EngineeringManager(EM)は、開発組織を率いる役割であり、その範囲は組織や状況に応じて幅広く変化します。
会社によってEMの役割や責務は異なりますがここでは、ピープルマネジメントに特化したEMにフォーカスします。
この場合、EMは開発チームの業務(事業開発)をPdMに移譲していることが多く以下の役割が多いです
採用活動
採用広報/技術広報
組織設計
開発組織用の評価制度の運用
開発組織の課題解決/施策など
メンバーのマネジメント
ピープルマネジメントを通じて、開発組織のスケールと成長を担う存在です。
DevHR(開発組織のHR)とは?
DevHRとは、開発組織に特化した人事部門の役割を指します。組織によっては「ProductHR」、「開発組織付けのHRBP」とった名称、役割が担う場合もあります。
採用活動(主にオペレーション)
採用広報
オンボーディング
人材データの管理: パフォーマンスやキャリア進捗を測定するためのデータ管理。
組織文化の醸成: 開発チーム全体で一貫性のある価値観や文化を育てる。
開発組織用の評価制度の運用
開発組織の課題解決/施策など
DevHRは、組織全体を横断的にサポートする存在であり、開発組織のマネージャーやリーダーたちと密接に連携します。
EMとDevHRの違い:内側と外側の視点
EMとDevHRの最も大きな違いは、組織内でのポジションと視点の違いにあります。「本来でいうと」以下のような視点からそれぞれ役割を考えていくことが求められます。(以下はGPTさん解説)
EM: チームの内側から見る視点 EMは開発チームの一員として、日常的な業務や課題に深く関与します。チームメンバー一人ひとりの仕事ぶりや悩みを把握し、即時的な対応が可能です。これは「現場感覚」に基づいたマネジメントを実現します。
DevHR: 組織の外側から見る視点 一方で、DevHRは組織全体や市場全体を俯瞰し、戦略的な施策を立案します。メンバー個々の状況というよりも、全体最適を図るためのアプローチを優先します。採用や制度設計など、組織の「骨組み」を作る役割が主です。
よくある悩み:役割のカニバリと解決策
上述した通り、役割の重複が多く、会社によっては適度なラインで役割分担をしているかと思います。ここではHR側の悩みとなりますが以下のような悩みをよく聞きます。
「HRに介在価値がない」と感じてしまう
HRはオペレーション業務に特化してしまうことが多くコアとなる部分に携わることが少ない。それによりキャリアアップが難しい。
組織内部に深く入り込むEMが課題を先回りして解決してしまうため、課題に対してアクションする機会がなくなる。ゆえにオペレーションに寄ってしまう。
どうするの?
よくある整理
EMとDevHRの役割を補完し合うためには、以下のポイントが重要です
(by GPT)
全体設計をHRが担う
HRは、EMが個々の課題に対応する一方で、組織運営の「全体設計」をリードする必要があります。たとえば、組織全体の評価基準やキャリアパス設計を主導し、EMと連携して実行します。
HRの専門性を磨く
採用活動だけでなく、タレントマネジメントやデータ分析、労務知識を活用した施策設計など、EMにはない専門的なスキルを強化します。
コミュニケーションの強化
EMとDevHRの定期的な連携ミーティングを通じて、課題の共有や優先順位の調整を行います。
根本の原因:HRの専門性が高い人が決して多くない
ただ、役割の整理/補完も重要ですがそれでも多くの場合はEMが大きくオーバーラップすることが多いです。上述の2「HRの専門性」という観点でHRの知見が少ないことが多いためです。
これはHR全般に言えるのですがHRは業務が多岐にわたるため、ほとんどのオペレーションが型化されていることが多く知識がなくてもできてしまうという弊害があります。
では、今からでも学べ場いいのでは?という話です。EMも決して人事知識が豊富なわけではなく、むしろ欠けているケースが多いのです。そういう意味で差があるわけではありません。
一方でEngineeringを主戦場にしてきたEMはよくわからないことを学ぶを調べる、学ぶが得意(エンジニア全般はそういう傾向にある)であり、スタート地点が同じだったとしてもEMの方がすぐに人事の専門性をもってしまうため、本来有意であるはずの「HRの専門性」でさえEMの方が高いことがあります。優秀なEMほどケイパビリティとアクション量も高いのでどこまでも越境していきます。
![](https://assets.st-note.com/img/1735526633-YxJHKZGR4UAOXa6kPjpBhcE8.png?width=1200)
昨年の記事でもこの件は少し触れていました。
対応策:実践知を高めていくために
結論、よりHRの専門性をより高めていくためにはとにかく学び、実践知を高めていくことが必要かなと考えています。また役割が重複するのであればDevHRからもどんどん深く入りこんでいくことが重要です。
知識を高めることにおいてEM含めたエンジニア全般が学びに強いのは、プロダクト開発の環境もそうなのですが、目の前の不確実性を突破するために社内外の知見を集めるためにコミュニティ活動が活発であることが挙げられます。
エンジニアの方であれば言わずもがなですが、は技術的な知見を様々なコミュニティで共有してそれを実践してまたその知見を共有、FBして。。と実践知のサイクルが回っていくのです。
XのTL上では勉強会、カンファレンスで発表した資料の共有とFBが盛んに行われています。自らの経験や学びを言語化することで学びを深め、さらに周囲からのその学びに対してFBをもらうことで新たに気づきを得るので新しい学びにも繋がっていきます。
てぃーびーさん(tbpgr)の「ITエンジニアの情報発信文化を人事領域に広げたい」でも語っていたように是非HR(人事)でも発信文化や学びの共有を広げていきたいなと自分も感じます。
人事系の勉強会はあまり登壇系が多くないかった印象ですが、最近は徐々にLT会も増えきた印象です。
人事の学びの場としては「人事図書館」が今年で来ましたね。人事書籍が豊富かつ、来訪者同士で意見交換したりできますし、イベントも頻度高く実施されたてます。私はまだ行けてないですが、行ってみたいです。
私も「ジンジニア」でイベントを定期で開催してより学びの機会を作っていければと思います。
最後に
明日(12/7)はAngelaさん(@posi0202)の「キャリア戦略としてのジンジニアを振り返える」です!
お楽しみに!!