10年エンジニアリングマネージャーをやって気づいた4つの大事なポイント 【EMはもっと自由でいい】

はじめに

※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。

 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。

 なぜEMが難しいのか?その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても、マネージャーになった時から期待される役割、必要な動きが180度変わってしまいます。頭ではわかっていてもそこに適応することは簡単ではありません。

 一方でエンジニアリングマネージャーの仕事を理解しはじめると、こんなに自由で面白い仕事はなかなか他にないぞと思う場面にもたくさん遭遇しました。色々な要素を組み合わせ、自分ができる最大限の成果を狙う。その自由度と解決策の幅の広さに面白さがあると思っています。

この記事ではそんなエンジニアリングマネージャーの壁を乗り越え、その仕事の面白さを堪能するためのエンジニアリングマネージャー成長サイクルというものをご紹介したいと思います。

エンジニアリングマネージャーの成長サイクルとは

 冒頭でエンジニアからEMへのジョブチェンジの難しさを話しましたが、そこへの対処法は、「エンジニアからいきなり完璧なエンジニアリングマネージャーになろうとしない。」だと思っています。そうではなく少しずつ自分ができることを増やすこと、そしてマネージャーとしての視点や引き出しを増やしながら自分の役割や動きを変えていくことが大事だと考えています。  ではどうやって、その成長サイクルをまわしていくのか、以下の4つのステップがあると私は考えています。このステップを一つずつ掘り下げて行きます。

f:id:TaisukeF:20211221210704p:plain

Point1:視点を変える

 EMの成果はチームの成果。自分の成果ではない。書いてみるとシンプルです。だがしかし頭で理解することは簡単だけど、腹落ちさせるとなるとがなかなか難しい。私もここでつまづきました。マネージャーになってみると、1日の終りの明確な成果が見えない。今日何をしたっけと振り返ってみても、コミットしたコードもないし、プルリクのレビュー捌いたわけでもない。MTGの連続とその隙間をぬってのSlackの返信や承認作業。自分の重要タスク実行に取っていた時間も雑事に忙殺され、それが終わるころには気力がなくなってるなん てことがよくありました。

そして、「あれ、自分は何をやっているんだろう」とぼんやり考えてしまうのですが、こういった場合は、自分がどこ視点で見ているか振り返ってみると良いです。テックリードであればプロダクト開発への貢献がないことは受け入れ難いです。しかしマネージャーであれば、日々、目に見える成果が積み上がることはまれです。つまり「何をやっていたのか」と考えている自分はあくまでテックリードとしての視点であり、マネージャーとしての視点ではありません。

自分の成果を10%増やすよりチームの成果を10%増やすことがマネージャーには求められます。今日行ったことは、チームの成果につながる活動だったのだろうか?と考え始めると考え方が変わっていきます。

ただし、すぐにそれをすぐに行うのが難しければまずは小さいチームをEM兼テックリードとして半分からはじめてみるのも良いと思います。テックリードとしての成果を確保しつつ、徐々にマネージャーとしての視点を増やしていくのです。

Point2:自分の仕事をデザインする

そもそもEMとは何か、EMの成果とは  先程、EMの成果はチームの成果と書きましたが、ここでもう少しEMの成果と役割についてを考えていきます。EMの役割は

「チームの生み出す価値を定義し、その価値を最大化すること」

だと思っています。

この定義のポイントは、マネージャー自身が自分でチームの生み出す価値を定義することにあります。もちろん、組織からの期待や上位のOKRがあり、全て完全に自由ではないです。ただ、与えられた枠の中でもどこに着目するか、どういった時間軸で何に成果をだすのか、どういう手段でその解決にあたるのかということについては、エンジニアリングマネージャーに裁量があります。そしてここをどう定義するかによって、自由度がぐっと広がっています。自由であるから難しいとも言えますが、ここが醍醐味であり、面白さであると思います。

 チームの状況、組織や周りの状況を観察し、課題を抽出する。そこから自分で成果を定義します。チームビルディングに専念でもよいし、メンバーの成長へのフォーカスでもよい。重要なことは自分でチームの出すべき価値を決めてそこに対してアクションをすること、そしてその結果を得ることにほかなりません。

EMは中間管理職的な宿命があり、つい上司や経営からの課題を抱え、メンバーからの要望に全部応えたくなり、言われたこと全方位で対応してしまう、結果本来やるべきことが見えなくなるとなりがちです。ただそこに流されず、自分で課題を見つけ取り組むこと、仕事の主体者を周り預けるのではなく、自分の中に取り戻すことが大事です。

さて次に定義のもう一つのポイント、「価値を最大化すること」について考えていきます。

「アイデアとは一つで複数の問題を解決すること」

任天堂でマリオを作った宮本さんの言葉です。つまるところトレードオフや対立軸を整理して別のあらたな軸や価値を出すということです。エンジニアリングマネージャーが常に考えるべきもこれだと思っています。ソフトウェアエンジニアのリソースは貴重です。それをただプロダクトの開発にだけ費やすのはもったいないです。プロダクトの価値とシステムの開発レベルをあげられるとエンジニアのスキルもより上がります。このように一つの開発や施策でいくつものメリットを生み出すようなことを行うことで成果の最大化につながっていきます

f:id:TaisukeF:20211221211422j:plain

例えば、モノタロウでは3年前の話にPython2系から3系へのバージョンアップ案件を行いました。モノタロウではPythonのコードセットが多く、単純に行うとかなりの作業量になります。ただEOLに対応するためのマスト案件であり、必ずやりきる必要がありました。しかもどちらかというと単純作業も多くあまりやりたがらない仕事でもありました。  この時にこの件を担当していたエンジニアリングマネージャーは、PJTの体制に工夫を凝らし、テストの整備を同時に進めることで、1粒で何度も美味しい取り組みに変えていきました。やることの意義を見出したメンバーも士気もあがり、具体的には以下の様なたくさんの成果をあげることができました。

  • セキュリティ観点:システムのEOLを回避して、セキュリティの強化ができた。
  • システム観点:CIやスナップショットを導入し、システムの品質、生産性を向上させた
  • 開発カルチャー観点:チームメンバーの品質に対する考えが変わりテストコードを書くのが当たり前という価値観がチームに浸透した
  • 育成観点:PJTのリーダーをメンバーから抜擢することで、個人の成長に大きく寄与した
  • 組織観点:プロダクトチームを横断したバージョンアップチームを組成して、組織の横や斜めの関係性を強化させた。

特に何も考えずに実行した場合は、セキュリティ観点でのリスク回避だけが得られた成果になりますが、そこだけに留まらずテストまわりの改善が大きく進み、関わったメンバーのスキル成長がみられ、以後大規模案件の段階リリースなどのノウハウなどが残せるなどかなり将来への資産が残せた案件となりました。 (この時のテストに関する活動は別のテックブログにまとめられています。)

Software Design連載 2021年10月号 スナップショットテストの可能性を追求する - MonotaRO Tech Blog


 出すべき成果を決めた。あとはそのために実行あるのみ。しかしここで一つの問題があります。EM忙しすぎる問題です。そうです。EMはいつでも忙しいのです。次はこの問題の対策を考えていきます。

Point3:自分のやるべきことにフォーカスする

「できることを全部自分でやる」をやめて「自分がやるべきことだけをやる」

 EMは色々なロールを兼任することが多いと思います。PdM(プロダクトマネージャー)、PM(プロジェクトマネージャー)、テックリード、アーキテクトなど。組織が小さくてプロダクトマネージャーをデキる人がいない。マネージャーになってと言われたがもともとやっていたテックリードを引き継ぐ先もなく、現場の足りないロールを自分で埋めてしまいがちです。埋めること自体は全く間違っていません。それが今チームに足りない役割で、チームの成果につながるのであればそこの穴埋めをすることは大事な仕事。ただ注意したいことは複数のロールを兼務しているという意識です。

まだそのロールを行うにはチャレンジングな人がうまく立ち回れる環境をサポートするという選択肢もあったかもしれません。EMにはマネージャーという役割があり、プレイングとマネジメントのバランスをよくよく考える必要があります。

EMで一番大事なことは自分の時間を何に使うかきめること

 そこを一度立ち止まって考えるため、最近では、自分の元でエンジニアリングマネージャーをやっている方には一度、下のフレームワークを使って自分の役割を整理してもらっています。

f:id:TaisukeF:20211221211857p:plain

EMの役割はチームの価値を最大化することです。そのためにEMが関与できる領域は以下の3つしかありません。

 「技術」 - 技術的意思決定、開発品質、生産性

 「プロダクト」 - タスク優先度決定、プロジェクトマネジメント、アサイン決定

 「チーム」 - 評価、育成、採用、チームビルディング

そしてEMはそれぞれに対し3つの関わり方があります。

「リードする」
直接的に関与します。自分でもタスクを持ちチームの活動の品質も確認します。

「要求する、ビジョンを伝える」
Whatは決めるがHowは委譲します。チーム活動に主体的には関わりません。

「任せる、把握だけする」
What,Howも委譲し、意思決定だけ関わります。または決定も委譲し、レポートだけ受け取るということもあります。

この3つの領域、3つの関わり方の3x3で自分がどういう態度で臨むのかを決めていきます。

このフレームワークを使うことの意義は以下の3つです。

  1. 現状の自分のスキルセットとまわりの状況を整理する。
  2. どこで自分のバリューを発揮するべきかを決める。そしてそれを周りにも伝える。
  3. 自分が学ぶべきポイントを明確にする。

まずは状況の整理です。自分のチームの状況、自分の得意不得意、メンバーの様子を整理します。その中で、自分がどこに入るのが一番チームにとって良いのかを考えます。そして決めたら、周りの人に共有することも重要です。他の人は、EMがどう動くかについてわかっていないとうまく動けないことがあります。

整理すると例えば自分がどういった動き方をしているのか、どうするべきかが見えてきます。例えば以下のような形があります。

例1テックリード兼任EM

自ら手を動かすテックリード兼任マネージャーです。古参のメンバーが同じチームのマネージャーになるときなどに多くある形だと思います。ポイントとしてはチームの大きさを小さくしておくこと。技術的な面はリードし、その役割を発揮できる余地を残しておかないといけません。そしてPdM/PM、Scrum Masterなど案件・タスクをリードする部分は他の人に主体をおまかせするようにすることはかなり重要です。案件も全部自分でまわすという状態なのであれば、なるべく早く任せられる状態を作るのが得策と言えます。

f:id:TaisukeF:20211221211947p:plain
テックリード兼任EMの例

例2 PdM(PM)兼任EM

比較的大きい業務系のシステム案件のプロジェクトマネジメントが得意な方がEMになるパターン。またはプロダクトマネージャーが組織におらずEMが兼務する場合などがこれに該当すると思います。今度は逆に技術的な部分は誰かに任せる必要がでてきます。技術部分を完全に手放せなかったとしても、できるだけ一部分だけでも渡せる状況をつくっていくことは必要だと思います。またPMは直接行うとしても実務をこなしていくわけではないのでTechLead/EMに比べると比較的チームのサイズを大きくすることは可能です。

f:id:TaisukeF:20211221212032p:plain
PdM(PM)/EMの例

実際に使っていた例

社内で実際に使っていた例を多少変更してご紹介します。このフレームワークを実際はこれくらいの粒度で役割を整理して会話しておりました。複数のチームをもっているEMがある特定の一つのチームにより深く入るにはという課題設定で、それぞれのチームへの任せるポイント、逆に自分が今より入るポイント、そこから派生して、どの会議は出るべきかでないべきかなど、細かく議論、目線をあわせることが出来ました。チームのリーダーともこの図を持って会話することで、案件のアサインフローの整理も進めることができました。

f:id:TaisukeF:20211221212116p:plain
実際の例

Point4:フィードバックを得る。新しい視点を獲得する

 自らのチームの成果を定義し、またそのなかでの自分の活動のフォーカスポイントも整理して日々のチームマネジメントにあたる。ここまででEMとしての活動のリズムはできています。ここから行うべきはフィードバックを得ることです。もともと狙っていた成果を出すために動き方、アクションを変えているので、まずはそれに対しての振り返りを行います。またやってみると思わぬ効果や発見、逆に副作用や問題などが出てきます。このあたりを自分の狙った成果に照らして解釈をすることが大事です。

またPdMやデータサイエンティスト、デザイナーなど他の職種、他の部署、他のチームにとってどういう効果があったのかをヒアリングしてみることも大事です。自分たちのチームの成果はチームの外側にあることが多いです。また短期的なことだけでなく、長期的にどういう意味があるのか多面的に解釈をすることで、違う視点を得ることができます。

 こうした振り返りによって、見える視点が変わってくると、新たにチームが出すべき成果や価値が再定義される、自分の仕事のデザインをし直すという、次のサイクルに入っていきます。エンジニアリングマネージャーの活動に終わりはありません。

おまけのポイント:問題解決の引き出しを増やすには

自分のできるやり方でしか問題を解かない→いろいろな選択肢の中から解を提供できるようになる

「愚者は経験に学び、賢者は他人の経験に学ぶ」は初代ドイツ帝国宰相、オットー・フォン・ビスマルクの言葉です。エンジニアリングマネージャーはあらたな視点を得る時に他のマネージャーの視点を真似することはとても有効だと考えています。  ソフトウェアエンジニアだった時に比べてEMについて参考文献が少ないこと。また、課題を抽象化した場合に、どのEMにとっても共通する課題なりやすいからです。

そこで最後にモノタロウでやっているEMのノウハウ共有会という取り組みを行っています。こちら簡単に紹介しておきたいと思います。

モノタロウで行っているEMノウハウ共有会

 モノタロウでは現在社内でエンジニアリングマネージャーのノウハウや悩み意思決定の判断などの共有会を毎週やっています。もともとは私がエンジニアリングマネージャーのみなさんと1on1などを通して個別に課題解決を一緒に行っていたのですが、みなさんそれぞれ違う悩みを抱えていそうで、同じ課題にあっていることもあり、横展開した方がよい、と考えました。具体的には毎週30分の時間をとって、その週で起きたこと、直近の課題からアジェンダを出して議論を行います。

 現状はEM8人が参加していてそれぞれ異なるバックグラウンド、専門分野をもっているので、視点や関心事もさまざまです。横との関係性がありお互いの事情はある程度把握できているので、込み入った話でも共有が簡単にでき、短時間でもその深い議論が行えます。またそれぞれがやっている良い施策を真似しあえるという点でもワークしております。

例えばここ数週間での話題としていたことはこういうところあたりです。

  • 「アンビシャスターゲットツリー」を使ったメンバー成長計画のブラッシュアップ
  • 各EM毎のメンバーの成長プランとそれに対するディスカッション
  • 「Google re:Work - マネージャー」共有とディスカッション

まとめ

というわけで記事も長くなってしまったので、あらためて重要と思っているポイントを整理しておきます。みなさんの仕事の参考になっていれば幸いです。

  • いきなり完璧なエンジニアリングマネージャになろうとしない。できることから少しずつステップアップする。
  • マネージャーの成果はチームの成果。ただしその成果をマネージャが定義して、それに対する取り組みを行う。解像度をあげてフォーカスするポイントを整理する。
  • エンジニアリングマネージャー同士で課題の出し合い、視点の共有は有効。

最後に我々と一緒に、エンジニアリングマネージャーを切磋琢磨して、向き合っていただける方のご応募お待ちしています。

またこの記事やエンジニアリング組織のマネジメントについて、執筆者である普川とカジュアル面談していただける方は、こちらからお申し込みお待ちしてます。