陥りやすいアンチパターン「エンジニアリングマネージャーやること多すぎ問題」はなぜ発生するのか
こんにちは！ 株式会社grooves（グルーヴス） エンジニアリングマネージャー（EM）の福井です。
インフラやサービス運用に責任を持つOpsチームのマネージャーで、沖縄の離島からフルリモートで働いています。
今日は既にEMとしてご活躍中のみなさん、あるいはこれからEMとしてのキャリアにご興味をお持ちのみなさんが転職する時に必ず直面するであろう「EMやること多すぎ問題」について考えていきたいと思います。
なぜ「EMやること多すぎ問題」が発生するのか
EMに求められる役割や担当する業務範囲は組織のフェーズや解決したい課題などの要因によって大きく左右されるため、一言でEMと言ってもその仕事内容にはかなりバラつきがあります。
手前味噌ですがエンジニア求人を探す時はForkwell Jobsが一番使いやすく、インフラエンジニアやEMなどの開発エンジニア以外の求人も充実している印象です。
試しに「エンジニアリングマネージャー」に絞って検索して求人の中身を詳しく見てみると、いくつかおもしろい発見がありました。
まず、多くの企業で共通している業務として、
1 . 1 on 1の実施やメンバーのキャリア形成支援など、いわゆるピープルマネジメント
2 . スカウト送信や採用ブランディングなどエンジニア採用など組織開発に関わる業務
があることがわかりました。
在籍しているメンバーのキャリア志向性（やりたいこと）とチーム、事業全体で達成すべきことを結びつけるための施策を実践することでメンバーのモチベーションを向上させるとともにエンジニアリングが効果的に事業に貢献する体制を構築する。それと同時に事業拡大を見据えて新しいメンバーを採用するための活動を短期、中長期それぞれで行うことを求める企業が多いようです。
一方で企業ごとにバラつきがある業務内容としては、
1 . 適切な技術選定や品質担保(QA)のための施策立案などのいわゆるテクニカルマネジメント
2 . 開発プロジェクトを円滑に推進するために開発チームを代表してステークホルダーとの調整業務
3 . 開発・保守するうえでの環境的/構造的にボトルネックとなる要因の特定および解決
などが挙げられます。
一般的なEMの役割はピープルマネジメントや組織開発に関わる業務として認識されている一方、それ以外にもテクニカルマネジメント領域にも染み出したり、いわゆる「調整マン」や「何でも屋さん」として頼られることがあるようです。
特に人員が限られているベンチャーやスタートアップで組織の規模が小さくなればなるほどEMに求める役割が多くなる傾向であり、「EMやること多すぎ問題」が顕著に発生しやすいようです。
これはなぜでしょうか。
これは個人的な意見ですが、「マネージャー」という名前がついていることが一つの原因になっているように思います。
ビジネスサイドの人から見た時のマネージャーとはいわば「チームの代表者」です。何か相談したいことがあったり、解決して欲しい問題があった時はまず「代表者」に取り合ってみるのが自然な発想です。
このためEMには組織全体で解決すべき大きな課題が共有されるミーティングに参加が求められたり、ビジネスと開発がよりうまく連携を行うための課題解決のアイデアが寄せられます。
いくらEMとはいえ、課題があれば解決したくなるのがエンジニアの性でしょう。ピープルマネジメントと組織開発が自分の本業だと分かっていても他の領域にも手を広げてしまいたくなります。その結果、周りからEMへの期待値が過度に大きくなってしまい「EMやること多すぎ問題」が発生するのではないでしょうか。
自分に合ったEM求人を見分けるポイント
やることが多すぎるEM求人を必ず避けるべきかというと実はそうではありません。
ある程度EMとしての経験を積んだ後に新たなチャレンジとしてあえてこうした環境に飛び込むことはむしろ良い選択です。
やることが多いということは組織運営において、より多くの領域に参画できるチャンスがあるということであり、与えられた裁量が大きい場合が多いからです。
また、「EMやること多すぎ問題」と向き合い、もし解決することができればその経験は他の組織でも大きく役立つことでしょう。あなたのキャリアにとっても大きなプラスになります。
しかし、これからEMとしてのキャリアを積みたい場合はまずある程度体系化された組織で限定された役割に集中できること環境を求めるのが得策でしょう。この場合はEMに求められる役割がピープルマネジメントから大きくはみ出していない求人を選ぶと良いでしょう。
グルーヴスにおけるEMの歴史
グルーヴスに初めてEMが誕生したのは2019年冬のことです。
当時グルーヴスにはエンジニア組織というものが存在せず、誤解を恐れずに言うと「寄せ集めのエンジニアをサービス開発にアサインしている」ような状態でした。組織全体として目指す状態の定義や事業計画と連動したエンジニア組織開発といった長期視点で計画を立てる役割は存在せず、まさにその日のプロダクト開発を個々のエンジニアの主観で正しいと思う方法で回していました。
そんな無秩序なチームに初めて採用されたEMにとっては困難の連続だったでしょう。
改めて当時のEMが残したドキュメントやログを見直してみると、開発組織全体に対して標準化されたフローやルールを導入することで組織として活動するための土台を整備してくれていたことがよくわかります。
今となって反省していることは、何か「これをやってほしい」という具体的なミッションを定義しないまま採用してしまったことです。グルーヴスとしてもこれまでEMを採用した経験がなかったので仕方ない部分はあるのですが、組織に足りないことを自分で見つけて進めていくという形で役割を決定する方針を取ったことで「EMやること多すぎ問題」が発生してしまいました。
開発組織内の人はエンジニアリングマネージャーというものの役割や業務内容について正しいイメージが持てていたのですが、事業部（ビジネスチーム）や管理部の人からするとどうしても「開発チーム全体のマネージャー」として見えてしまいます。グルーヴスとしては最初のEMだったので特にその傾向が顕著でした。
開発（テクノロジー）に関わるトピックはまずEMに相談して進め方や担当を決めてもらおう、という動きが多発した結果、EMには多くの役割が積み重なっていきました。具体的には、IT統括（社内IT）、情報セキュリティ事務局、担当者不在の自動化ツールのメンテナンスがこれに当たります。
しばらくはこれらの業務すべてを一人のEMが担っていたのですが、案の定これでは本来の業務であるピープルマネジメントに専念できないということになり、新しいEMを採用したり専任のチームを作って徐々に役割と権限を移譲、分散していきました。
現在のグルーヴスにおけるEMの立ち位置
この経験を踏まえて、現在のEMの役割は「いちプロダクト開発チームのマネージャー」としてチームメンバーのピープルマネジメントを通じた生産性の最大化に専念することを中心に設計しています。
具体的な仕事内容は下記求人を参照してください。
PMやデザイナーを含めた開発組織全体をスコープとした施策の立案や実行責任、意思決定はそれぞれのマネージャーとそれを束ねるグループマネージャー（GM）で構成される「CPO室」が担っています。
CPO室設立の背景やその役割の詳細はぜひ次の記事をご覧ください。
私自身、主にインフラやサービス運用に責任を持つOpsチームのEMとしてはたらいていますが、メンバーのキャリア形成のサポートや全体におけるチームの方針決め、タスクの優先度決定に十分な時間を投資できている実感があります。
また、CPO室において他のEMからプロジェクトの方針や施策の進め方に感してフィードバックを得ながら進めることができるので、自分の主観だけに基づかない意思決定を行うことができています。
何より自分以外のEM、立ち場が異なるPM・デザイナーのマネージャーがいて、その人達の知見や経験を参考にしながら仕事を進めることができる、というのは当時と比較してかなり整備された部分かと思います。
最後に
ここまで読んでくださり、ありがとうございました！
グルーヴスでは体系化された新しい組織体制のもと、開発エンジニア、EMの両ポジションで新しいメンバーを募集しています。
これまでのご経験やこれから歩みたいキャリアに応じて柔軟にポジションをご提案させていただきます。
少しでもご興味を持っていただいた方、ぜひお話させてください！
下記のページからお申し込みいただけると弊社EMとのカジュアル面談を設定させていただきます。
あなたにお会いできるのを楽しみにしています！
その他にも、グルーヴスでは、マーケティング、セールス、カスタマーサクセスなどで力を発揮していただける方を積極的に採用しております！ご興味のある方はぜひお気軽にエントリーください。