2022年昨今のEngineering Management(EM)界隈を見ていて、1つトレンドもしくは兆しがあるなぁ、と思っていることがあります。端的に言ってしまえば、EMを専門職種として切り出して、人（や組織）のマネジメントに専念させるパターンが出てきている、ということです。

もちろん、以前からこのような形態をとられている企業もあると思います。しかし、おそらくは専門性を高めている社員がキャリアラダーの1つとして、プレイングマネージャー的にマネジメントに携わるケースが多いのではないでしょうか。

プレイングマネージャーとして人のマネジメントに関わることの問題点は、2点あると考えています。ひとつは、プレイングしている内容（開発者であれば技術的なこと、デザイナーであればデザイン的なこと）と、人（と組織）に向き合う内容とのいずれにも注力できずに、どちらも中途半端な状態になるということです。結果として、周囲のステークホルダーの期待値を満たすアウトカムを出せずに終わります。

もうひとつは、仮に周囲のステークホルダーを満たすようなアウトカムが出せたとして、それができる人材がどれだけいるのか、という点です。技術と人とのマネジメントは別物です。たとえば、保守性の高いAPI設計をできるスキルと、人のモチベーションを損ねずにフィードバックを与える方法は別物でしょう。

個人的には、仮にあるエンジニアが突然、ピープルマネジメントに携わるようになったら、それはLv1からのスタートに近いと考えています（とはいえ、100%の能力が適用できないわけではないので、ドラクエ3のように能力が半分になってスタートするようなものに近いかも）。そのため、有限な時間の中でどちらも高いレベルに達している人材は、決して多くないと思います。

この問題の解消のために、プレイングとして関わる専門領域を切り離して、人（や組織）に向き合うマネージャーロールを作っておく、という方法（組織設計）が増えてきているように見えます。そう考えるにいたったのは、次の3つの事例をここ1年で見てきたことにあります。(n=3でしかないですが、1つの仮説として捉えていただければ)

1. Chatwork社との対談からの例

先日、Chatwork社の @tan_yukiさん と対談させていただいた記事(「EMやること多すぎ問題」が組織にもたらす弊害は？Chatworkの失敗事例に学ぶパフォーマンス最大化の秘訣)が公開されました。

記事の中で、

ChatworkのEMは大きく二つ、テクニカルマネジメントとピープルマネジメントを担っています。
二つと言えど、そこに含まれる細かいタスクは多種多様でどれも専門性の高い仕事ばかり。

そんな役割の多角化を当社では「EMスーパーマン問題」と呼んでいます（笑）。
テクニカルマネジメントだけでなく、ピープルマネジメントも100％の力でこなすなんて、
スーパーマンの領域であろうと。

と @tan_yuki さんが語られており、個人的にも同感するところです。そして、この対応として

Chatworkでは、直近取り組んだ「ピープルマネジメント部の新設」を通じて、
こうした「結局いろいろなタスクをEMが背負う」場面も”結果的に”減らせると考えています。

と、専門の部を新設されているアプローチを取られる点が紹介されています。

2. Timee社の例

2つ目の例は、自身の主宰するPodcastである fukabori.fm の (ep74. PMFしているスタートアップがスケールする上での組織課題と解法 w/ kameike) でTimee CTO の @kameike さんが語られていることに当たります。

具体的には

プロダクトの成果と切り離したところに、エンジニアリングマネージャーがいて...

と述べられており、人や組織（制度）に特化して向き合うロールを配置されているが分かります。人のキャリアに向き合い、適切な評価制度を設計・運営し続けるのは、決して簡単なことではなく、専門Roleを用意してそこに注力する人材を確保しているということです。

3. engineer meeting podcast の例

engineer meeting podcast, vol.200 200回やってる間に変わったこと の中で、語られていることも事例の1つです。

詳細は本編をお聴きいただきたいのですが、デザイナーチームで、1人の人材によるプレイングとマネジメントが回らなくなったので、プロダクトが分かる、かつマネジメントが得意なメンバーを社内から連れてきた、その結果うまくいっている、という話が出ていました。

本例はエンジニアリングマネージャーではありませんが、プロダクトを作る人材としてはほぼ同義として捉えられるのでは、と考えています。

銀の弾丸？

以上のように、ここ1年で3つの事例に当たったことから、組織設計の兆し・トレンドかもしれないなと考えています。一方で「やった！これですべて解決だ！」というと、そんなに簡単な話ではないでしょう。そう考える理由は大きく2つあります。

1. そもそも少数であり、採用が困難

「人に完全に振り切ってピープルマネジメントだけやります！技術はわかりません！」という人は、チームメンバーとの対話に苦労する可能性が高いです。

たとえば、マネージャーに対して技術用語がまったく通じないとしたら都度、噛み砕いて説明をする必要が生じます。徐々にマネージャー側の知識が増えて、コミュニケーションがスムースになるとしても、一定のコスト・時間が必要です。また、チームのメンバーからの信頼を集めるのに苦労するでしょう。一定のスキルがあるエンジニアは、周囲が普段の仕事ぶりを観察する中で、自然と信頼を獲得しているはずです。

したがって、一定の専門性を備えていて、エンジニアリングマネジメントに振り切ってもいいよ、という人が必要となります。ここに矛盾、もしくは葛藤があると考えています。

「人に向き合うのではなく、技術と向き合う IC(Individual Contributor) として生きていきたい」と考えている人のエンジニアやデザイナーは、かなり多いのではないかと思います。（私の観測範囲による主観なので、ここはTwitterで軽いアンケートしてもいいかもしれません)

2. マトリクス組織の難しさ

EMを専門として切り出すと、自然と「プロダクト x エンジニアリングマネジメント」や「技術 x エンジニアリングマネジメント」のようにマトリックス的な構造が生まれやすくなります。あるメンバーのレポートラインや評価ラインが分岐して、2人の上司・マネージャーが存在するようになります。

マトリクス組織の難しさは、 書籍: 組織デザイン などで語られており、ここでは詳細を省略しますが、運用は簡単ではないため、常にケアしていく必要がありそうです。

補足：向き不向きは状況に依存する

本記事で述べている内容は、一定以上の規模（数十人、100人以上）で当てはまる内容です。

スタートアップのように少数精鋭で企業を運営している場合、人員は常に不足している状態となっているでしょう。たとえば、10名の会社、うち4名しか技術陣がいない状態で、そのうちの1人が「人のマネジメントだけやります！」といっても、良い結果は得られないと思います。そんなRole割付けとするよりも、全員でコードを書いたほうが、価値があるでしょう。

おわりに

ここ最近、類似の事例が重なったことから思い立って、本記事をさっと書いてみました。たった3件の例から帰納していることから、再現性はあまりないかもしれませんが、少しでも参考になる内容になっていれば幸いです。