エンジニアマネージャーやりたくない問題

2022年1月7日 20:32

数年エンジニアマネージャーとしてメンバーと接していく中で良くぶつかった「エンジニアマネージャーやりたくない問題」について考えたいと思います。ちなみにここで論じるエンジニアマネージャーはテックリード的な業務は省いて考えています。組織によってはテックリードを兼ねているケースも多いとは思いますが何の話をしているのかクリアにするために分けて考えてます。また、業界によっても色合いは違うと思うのでSIerではなくインターネット業界を前提として書いてます。

※ 以下、エンジニアマネージャー = EMと表記します。

インターネット業界は比較的人員の流動性が高い印象があります。流動性が高いという事は人が多く辞めていくという事です。退職者の中にはプレイヤーだけではなくマネージャーももちろん含まれています。そういう状況の中でどんどんとネクストEMを抜擢・育成していかなければ組織が機能しなくなっていってしまいます。

なぜエンジニアはマネージャーをやりたくないのか？

これは自分の経験則でしかないのですが多くのエンジニアはマネージャーをやりたがりません。その理由を過去に聞いたものを類型化するとだいたい下記のようにまとめられました。

- 人周りの話がつらい問題
- エンジニアとEMは別職種でありエンジニア能力がスタックしない問題
- EMの能力の証明が難しい問題

人周りの話がつらい問題

EMになってまず明確に変わる部分は評価者になるという点です。そうすると今まで同僚として仲良くやってたメンバーと少し距離が生まれたという話もあります。また、日々の1on1などでセンシティブな相談を受けることも増えます。「Aさんと一緒に働くの無理っす」「会社やめようと思います」「評価に納得がいかないです」のような受け止めるのがつらい問題が多くあり、精神面での負荷が上がる印象があります。

エンジニアとEMは別職種でありエンジニア能力がスタックしない問題

エンジニア業務は、ビジネス上の課題を技術力で解決するというものが多いと思います。「こういう機能が欲しい」「高速化してほしい」「自動化して欲しい」などなどです。もちろんビジネス要件を整理した結果、コーディングが不要でワークフローを整理すれば解決するというものもあるとは思いますが、メインの業務は実装を伴う課題解決だと思います。一方でEM（※TechLead業務を除く）の業務は採用活動、メンバー育成（目標設定、ピープルケア、評価、研修など）であったり、アサイン調整など技術力を基盤としながらも実装を伴わない業務が多い気がしています。つまりエンジニアとEMは共通点はあれど別職種という側面が強いのです。

もちろんEMでありながら他のエンジニアより技術的専門性が高い人もいますがそれはエンジニアとしての能力の高さでありEMとしての能力の高さとはイコールにはなりません。EM業務を遂行する以上、先述した採用であったり育成などに時間が割かれる事になり当然ながらエンジニアとしての専門性をスタックさせていく時間は相対的には少なくなります。代わりにEMとしての専門性を伸ばしていく必要があります。

EMの能力の証明が難しい問題

加えて、エンジニア業務は市場感・相場感が”ある程度”形成されており、どういう課題をどういう技術を用いてどう解決したのかでその専門性を伝えやすいです。業務で使用しているプログラムをそのままGitHubにあげることはないにしても、汎用ツールや趣味プログラムなどの成果物によって技術席専門性の信頼度をあげることも出来ます。一方でEM業務については相対的に①人数が少ない事、②業務が一人で完結しないという事、③業界・事業・会社によって求められる業務範囲が異なる事、など変数が多いことにより専門性に対する市場感・相場感があまり形成されてないように感じます。（マネージャー経験ならポジ。みたいな乱暴な相場は存在するかもしれませんが）

例えば、転職しようとしたときに「弊社でEMとして価値を出せる事の証明をしてください」と問われたときに言葉に窮するEMの方も多いと思います。

どうやって解決していくか

ここまでの課題をさらにまとめると、①人周りの話がつらい、②エンジニアとしてのスキルスタックが薄まる割にEMのスキルが溜まってる気がしないし証明も難しい、という2つになるかなと思います。

人周りの話が辛い問題について

人周りの話については、もちろん精神面での負担になることではあるのですが代わりに得ることもあります。平たく言うと多くの情報が手に入ります。

例えばEMをしていると大きな意思決定をしている人と近づきます。それは部長かもしれませんし社長かもしれません。さらに全体にはまだ周知できない情報なども事前にマネージャーには展開されることも多く事業の全体像を理解しやすい状況になります。加えて各メンバーとのクローズドな対話も多くなり、メンバーの悩み・課題感などメンバー同士だと話しづらい事も情報として入っていきます。

つまりエンジニアの頃と比較すると事業レベルからメンバーレベルまで多種多様な情報が手に入れやすくなります。そうなる事で今まで見えてなかった大きさの課題を発見でき、解決につなげる事が出来るようになります。

エンジニアとしてのスキルスタックが薄まる割にEMのスキルが溜まってる気がしないし証明も難しい問題について

これはまだ解決できてないテーマではあります。自分がこういう記事という形で考えをアウトプットし始めているのは、「EMとしての考え方を公開する」事によってその証明につなげようという考えによるものです。

EM業務を行っていて躓いた問題や感じた課題をどういう風に解決していったのか、また解決していってるのかを残していく事でそういう道を作っていければなと感じています。

つらつらと書いていったのでまとまりない文章になってしまいましたが、これをみて誰かの一助になれればなと思います。