30人規模の開発組織におけるエンジニアリングマネジメントのアプローチ

はじめに

プロダクト開発部でキャリア事業のEM(エンジニアリングマネージャー)をやっている大野です。今回は自分が見ているチームに関して、普段どういったアプローチをしているのか?という話を元に、自身のマネジメント術に関して深堀りしていきたいと思います。

一般的なEMとは?

企業におけるフェーズや組織設計で、EMが持つ役割は変わるものの、大きくはピープルマネジメントを行いつつ、プロジェクトマネジメントやテックリード、プロダクトマネジメント等組織に必要な役割を多岐に担っている形が一般的なEM像かと思います。

大野の担当範囲

私自身、前職を含めると約9年EMに近い役割を担っています。 最近だとピープルマネジメント、テックリードが主で、状況次第でプロジェクトマネジメントやプロダクトマネジメントに近い役割で動くこともあります。 マネジメントボリュームの話をすると、エンジニア30人弱をEMとしてマネジメントしており、事業としても様々な方と仕事を進めるため、ステークホルダーとしては100名超の方とお仕事させてもらっています。

よく聞く「マネジメントは多くて10名まで」という一般的な数からするとかなり多い部類になるのかなと思います。 そのため、どうやって回しているのか?と聞かれることもよくあります。 こういった背景から、今回自分の仕事術を深堀りしていくことで参考になる人も多いのでは?と思った次第です。

ピープルマネジメント編

まとめてみた結果、極力、「マネジメントコスト = 人数*時間」にならないようにしているなと自分でも理解しました。

まずは任せる

メンバーと仕事を進める際、可能な限り裁量を渡すようにしています。

  • 事業側とのコミュニケーションをどう取るか
  • 開発におけるリファクタをどう進めるか

などの裁量を渡すことで、メンバー自身が考える成長機会となり、チームの成長に結びつきます。 任せる上で大事なこととしては

  • 狙いを伝える(裁量を譲渡すること・自分で思考する等)
  • 失敗も経験として恐れないこと
  • チャレンジした上でキャパオーバーするものは手伝う

あたりに気をつけて伝えています。ここが認識合わせできていないと、ただの丸投げとなってしまうので気をつけないといけない部分です。

1on1よりも普段の接点を増やす

これは前職で30人マネジメントすることになった際に定着したのですが、メンバーとのコミュニケーションは普段の接点を多く持つことに重きを置いています。 1on1でしか得られない高揚はもちろんあるのですが、1on1で改まって話をするより、普段の業務中に会話をしたほうが圧倒的に鮮度・頻度が増えるため、プラスになることが多いです。結果、1on1の頻度としては多いメンバーで隔週、大半のメンバーはQ単位で1回程度と一般的な1on1の頻度よりはかなり少ない形で運用しています。

リモート業務中心となり、偶発的な会話の機会が減ってしまったこともあり、業務上のコミュニケーションはSlack中心、雑談等はMTGの間のGoogle Meetでの通話等で行うことが増え、より普段の接点自体に意識を向けるようになりました。

自身もバリューを発揮する

上記のようなコミュニケーションをメンバーと取る上で重要なのは、自分が業務やエンジニアリングにおける示唆をするに値する人間であることをメンバーに知ってもらうことです。 もちろん、色々やり方はあるとは思うのですが、私自身は「背中で語る」が最も手っ取り早く効果も高いと思っています。 といっても、すべての領域で無双するような必要はなく、自身の強みをベースにチームメンバーとの関係構築を行っていくことで、エンジニアならではのスキルからくる信頼関係が構築されていきます。

テックリード編

自身の技術力

私自身、技術面に関してはそこまで尖っているわけではありません。元々、マネジメントにキャリアを歩むきっかけとしても、技術を極めていく自分が想像できなかった面もあったりします。 ただ、実際にマネジメントをやってきた結果、やはり技術力は必要だなと認識する場面は多々あります。

結果、自分としては「自チームにおいて、最も技術力が高い人と同じレベルで会話ができる」をモットーに技術面のキャッチアップを行うようにしています。 これが満たせない場合、チームでの技術的な意思決定に自分が関われず、それがビジネスに本当に必要なものなのか?の判断を間違える可能性があるからです。

メンバーの興味関心に合わせる

見る範囲が広い為、自分だけで技術面のチャレンジを行ったところで、チームには浸透しません。そのため、メンバーが今どういう部分に興味関心を持っているか、業務上どういう課題を持っているか等、メンバー個々が動機づきやすいような内容を中心に開発改善を進めることが多いです。 こういった流れ自体が定着していくことで、新たな提案にも前向きに取り組めるチーム文化ができていると感じます。チームに感謝!

プロダクトマネジメント編

事業を広い視点から理解する

事業に貢献するために、事業理解の中でも「色々な視点」から事業を見ることを意識しています。 それぞれの深い部分は各担当の人に勝てないので、実際に事業面で把握するようにしているのは以下のような情報です。

  • 大枠の事業戦略
  • 各担当が日々追いかけているKPIとその相関
  • サービスを利用するペルソナ
  • 隣のチームのHOTな話題

これらの情報をインプットとして、「事業の色々+エンジニアリング」を理解したユニークな人になるようにしています。 こうして、事業での意思決定の場で自分ならではのバリューを出すようにしています。

問題解決を進める

業務を進める上で、開発に限らず日々たくさんの問題が発生します。 私自身、どんな問題があっても必ず前に進めるというのを意識しており、これを体現していくことで周りからの信頼も勝ち取れ、更に自分に情報が集まりやすくなる好循環が生まれます。 ここで前に進めると表現したのは、必ずしも自分で解決する必要はないからです。重要なのは「大野に聞けば何かしら前に進む」と思ってもらうことなので、自分で解決してもよいですし、解決に適任な人に繋ぐこと自体にバリューがあります。

今は、メンバーにどんどん裁量を渡しているので、大野ではなくメンバーに真っ先に相談・質問が来るように関係構築を進めるよう推進しています。

また同時に、メンバーにとって困難な問題が発生した際はいつでもヘルプできるような距離感は保ちつつ、自身は比較的難易度の高い問題の解決に時間を充てられるようにしています。

おわりに

今回は、広い範囲の組織をみる上で、自分なりに行っている仕事術のような形で色々と書かせていただきました。 こういった言語化や、この記事から生まれる会話でよりEMとしても、組織としても成長していければと思います。