エンジニアリングマネージャーを3年やってわかってきたコト

以前に書いた記事で、エンジニアからマネージャーを目指したきっかけを書きました。

devopsチームのリーダーになって始めたエモい目標と取り組み

PLAN-Bに入社して5年と10ヶ月が過ぎました。 入社した当時はエンジニアとしてDMPプラットフォームの開発や、新規プロダクトの開発を行っていました。 2年ほど前から社内のdevopsチームのリーダーを経て、現在はエン…

今回は2021年10月現在のPLAN-Bのフェーズにおけるエンジニアリングマネージャー(※以下EM)の役割や、実際にはどんな仕事内容なのかをまとめました。

エンジニアに関する組織の構造としては以下のような形です。システム開発本部には他にも、プロダクトマネージャーやUI/UXデザイナーが所属するグループ、組織横断でDXやアジャイル、データ駆動の支援をするグループなどがあります。

マネージャーとして管理する範囲は紫色の部分で、実務を行う複数のチームとメンバーを見ています。

EMを経験してわかったコト・悩んだコト

エンジニア組織のマネージャーとして役割をいただき、だいたい3年が経ちます。

当時はDevOpsとしてプロダクトを2つ見ており、実務もこなしつつ、メンバーとの1on1や目標設定、チームづくりをする日々でした。実務とマネジメントのバランスが取れずにかなり苦労した覚えがあります。自分のマネジメントスタイルが正解かわからず悩んでいたコトも覚えています。

上司に相談したり、上司の上司に相談したりもしましたが、言うコトがバラバラに聞こえて当時は混乱していました。今はわかるのですが、バラバラなのは当たり前でマネジメントスタイルに型はなく、自分自身にあったスタイルを自分自身で作っていくしかないんだと気づいたのは1年ほど経過したあとでした。

EMを始めたころ患っていた「はやり病」

EMを始めたばかりの頃は「自分でやらないと気がすまない」という気持ちがありました。なかなか人に任せられない病や、メンバーから相談されて困っているようだと仕事を巻き取ってあげて自分でやっちゃう病などなど。

今考えるとメンバーの成長にストップをかけてしまうようなコトをたくさんしていたなと思います。当時の気持ちとしては「メンバーが困ってる、助けてあげなあかん、それがEMとしての役割やー」と思っていました。

しかし次第に「成長速度遅くないか？」などチームとしての課題がボディーブローのように効いてきて、自身もタスクに追われていたこともあり、まともにマネジメントできなくなっていきました。そこでようやく、メンバーの成長機会を僕が奪っていたコトに気づくことができました。

改めてEMとして大事なコトを見直すきっかけになりました。今のPLAN-Bのフェーズにおいて

• 自分自身に求められているコトは何なのか？
• 自分はどうしたいのか？
• PLAN-Bとしてはどこに向かっているのか？
• 何を達成したいのか？

などを考え始めるようになり、少しずつ自分のスタイルを変えるコトができて来ました。

EMの役割

辿り着いたのは【チームの成果を最大化する】コトです、自分の成果ではなくチームの成果を最大化するコトがEMのミッションです。もちろんですが、チームの成果を最大化し続けるためにはメンバーの成長も必要です。

成果を最大化するためには色々な取り組みを行います。常に頭の中で「現在の課題はなにか？ボトルネックはどこにあるのか？」を考えます。課題・ボトルネックの解決のため、短期・長期的な取り組みを考えて実施します。

課題というのは永遠になくならないと考えています。1つ課題を解決しても、チームのメンバーが変わる、プロダクトのフェーズが変わるなど、状況の変化によってまた新しい課題が生まれてきます。常に状況のキャッチアップを行うコトもEMの大事な仕事です。

もう少し具体的にかくと、いわゆるピープルマネジメントとテクニカルマネジメントです。 僕の場合、ピープルマネジメントには人・チーム・組織を含んでいます。テクニカルマネジメントは技術戦略などを含みます。

※会社的なマネージャーの役割には労務管理などもありますが割愛します。

ピープルマネジメント

• 1on1
• 相談・雑談
• 役割設定（権限委譲）
• OKRの策定・トラッキング（チーム・個人目標）
• プロダクトチームの状況把握（各メンバーからの情報キャッチアップ）
• エンジニア採用
• メンバーの成長

メンバーとの信頼関係構築は特に大事と考えています。週次の1on1、雑談などです。いつでも相談できる雰囲気作りも大事にしています。メンバーから「忙しくしてるなー」と感じさせないように振る舞っているつもりではありますが、なかなか隠しきれずに感づかれてしまってる場合もあり、課題だと感じています。

プロダクトに関してはメンバーに大きく権限委譲をしています。しかしチーム内で解決できないコト、たとえばリソースの問題であったり、お金の問題であったりは相談できるタイミングをとっています。

あとはエンジニア採用や、組織体制をフェーズによって組み替えていくなどを行っています。

いつも苦労する点は信頼関係の構築です。メンバーによってWill（やりたいコト、目標、夢）が違うので、まずはWillを把握しモチベーションを高く動けるようにするのに苦労します。100％できている訳ではないですが、多くの力を割きます。

またWillだけではなく、プロダクトや事業を成功させるためのミッションも含めて、適切なチャレンジを織り交ぜつつメンバーと一緒に成長を考えていきます。

テクニカルマネジメント

• 技術戦略の立案
• 技術選定・方向性の決定（アーキテクチャ）
• 開発組織体制の構築・計画

プロダクトの未来を見据えた技術の方向性を考えて、技術戦略を策定します。これもフェーズによってアップデートします。

※技術戦略については以前に書かせてもらいました

PLAN-Bのありたい姿と技術戦略

PLAN-Bではプロダクト開発における再現性を上げていくタメに2021年の末から技術戦略の構築に取り組んでいます。 1年後のありたい姿として… 「アイデア（プロダクト）を形にするスピードを高速に高品質に、仮説検証を高速回…

ただ技術選定などは、メンバーからもルールに則って提案・変更していける仕組みを作っています。現場の声を拾い上げるコトにも注力しています。

まとめ

広義のEMにはプロダクトマネジメントやプロジェクトマネジメントも含まれていますが、PLAN-Bではプロダクトチームに内包し完結させています。 PLAN-BのEMの役割としてはそれらは含みませんが、僕の場合は実務を兼任するコトもあるのでプロダクトのPMをしているコトもあります。実際に現在はPMを兼任しています。

今回はEMとしての役割をいただいた頃の話と現在の役割について書きました。冒頭に書いた「はやり病」からは抜け出たと思いますが、まだまだ兼任で実務を担当するコトも多いです。成長フェーズの組織の成長痛なのかなとも思っています。またそれが自分のマネジメントスタイルなのかなという思いもあります。

マネジメントの難しさは日々感じていて、知識としてあってもなかなかできるコトではないと感じています。ですが知識がないと太刀打ちできないコトも多々あるので、EMの勉強もしてそれを実践し改善して【チームの成果を最大化】を考えていきます。

またエンジニアとしてのレベルアップも必須だなと考えています。技術戦略・技術の方向性の意思決定や、開発メンバーとコミュニケーションで会話が噛み合わないなどが出てこないように勉強を続けています。

会社の成長・プロダクトの成長によって自分に求められるミッションがどんどん変わっていくと思っていて、それに遅れるコトなく自身と組織の成長を心がけていきます。