結局のところ、エンジニアリングマネージャーとは何者なのか
はじめに
これはEngineering Manager Advent Calendar 2023 25日目の記事です。
毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。
最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。
Advent CalendarにおけるEMの多様性と共通点
LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。
新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。
共通しているのは「マネジメント対象とするエンジニアチームの価値を最大化する」というミッション。一方、エンジニアチームのあり方は会社の規模やステージ、エンジニアリング領域の特色などで千差万別となります。
そんなかんじで興味関心は異なるし、実際アウトプットとしての記事も全然ジャンルがバラけていたりするのですが、不思議なことにどれも「わかる〜」ってなったり「勉強になる〜」ってなるんです。自分の考え方とは異なる記事でも「そうはならんやろ」ではなく、「自分は違うけど、そういうのもあるよね」と思えるものばかり。
これはEM業に共通するものがあるということもですが、一定の抽象化スキルが伴っている、というのが大きいと感じました。自分が経験したことから省察し概念化する、経験学習サイクルを回すことが習慣化しているのではないでしょうか。
あと、何気にすごいなーとおもったのが、ほとんどの参加者が期日までに投稿してくれていたこと。「やると宣言したことはやりきる」というGRIT力は、EMというロールを担う上での基本スキルなのかもしれません。
私が歩んできたEMとしてのキャリア
シャッフル組織のマネージャー
私が初めて「マネージャー」と名のつくロールを担当することになったのは2013年。実に10年も前になります。ただ、このときの役割はPMでした。ProjectなのかProductなのかでいうと、所属していた組織ではあえてそこを区別せず"PM"としていました。
その2年後に、People DevelopmentやPeople Evaluationを担う役職に就きました。Recruitingについてはメインではないものの関わることがしばしばありました。育成と評価、そして採用に責務を持つ役職で、EMという名前ではありませんでしたが、自分の自意識としてはこのときがEMとしてのキャリアのスタート地点になっています。（ただ、"PM"に就任した時点で多少なりとも育成というのは意識していましたし、コミットメントもしていました。）
では、自分の中ではなぜ、育成と評価、採用に責務をもった時点でEMとしての自意識が芽生えたのか。エンジニアリングマネジメントトライアングルを眺めながら考えてみました。
Product ManagerとProject Managerを包含するPMのフォーカスは、あくまでプロダクトでありプロジェクトです。いずれもミッションを遂行するためにはメンバーの育成、採用などが必要となってくるため、RecruitingやPeople Development, Team Buildingなどにもコミットしていくことになります。
ですが、EMについてはフォーカスがTeamになります。チームそのものをプロダクトと捉えその価値を高めていく、その手段としていわゆる「ピープルマネジメント領域」に踏み込んでいきます。
この「チームにフォーカスして行動する」という視点が得られたから、その時点でEMとしての自意識が芽生えたんだと思います。
前職ではマトリクス型組織の形態がとられ、日頃のエンジニアリング業務は事業単位で行うけれども、育成と評価は横串の「ユニット」という単位で行っていました。
意図的にシャッフルされた（さらに、それが毎年シャッフルされる）エンジニアたちの育成と評価を行うというミッションはかなりチャレンジングなものでした。自分がそれまで歩んできたバックグラウンドとは異なる専門領域のエンジニアを管掌することになるからです。
私はバックエンドのアルゴリズムエンジニアとしてのキャリアがメインだったので、たとえばスマホアプリのエンジニアのスキルセットやキャリアプランを把握し支援することは、当初とても大変でした。マトリクス組織がどんなだったかは、こちらの記事にて紹介されています。
ただ、この組織体制のおかげで、なかば強制的にバックグラウンドが共通していないエンジニアを育成、評価し支援するためのスキルが備わっていきました。
マネジメント対象のメンバーの専門領域に対して最低限のナレッジを持つ
そのナレッジを（浅くてよいので）アップデートし続ける
自分は専門家ではないという自覚を持ち専門家の意見も聞くようにする
傾聴などコーチングスキルを鍛え自分にバックグラウンドがないスキルの成長支援を可能にする
2019年からVPoEを担当することになったとき、この経験とスキルは多いに役に立ちました。ダンバー数を超えるような規模のエンジニア組織に対して、すべてのエンジニアの専門領域に対して自分も同等の専門性を保有することはかなり難しいことです。そのときに、「詳しくなくても概要をおさえ、コーチングを軸に育成・評価にコミットする」というスキルがかなり有効に作用しました。
この頃の話は、いくつか記事になっているのでぜひご覧ください。
小規模チームのマネージャー
2023年10月に転職してからは、エンジニア4名、PdM3名、そしてEMの私1名という小規模なチームに所属しています。
このチームは新規事業のプロダクト開発をミッションとして抱えています。まだまだPMFに向けて探索が必要なフェーズで、要求の不確実性も技術の不確実性も高い。
目の前の不確実性と向き合い、学びながら前進するために、私達のチームではスクラムを採用しています。これは私がジョインする前からそうでした。
ここでEMに求められるのは、件のTriangleでいうと以下の要素でした。
Process Management
Resource Management
Stakeholder Engagement
Team Building
そして、スクラムで開発しているチームにおいてこれらの要素はスクラムマスターが担っていくことが多くあります。そういった意味で、小規模の新記事業プロダクト開発チームに求められるEMのスキルセットはスクラムマスターのそれと類似しています。
少し視座を上げてみると、チームそのものを強化していくためには以下の要素をおさえておきたくなります。チームがどうあるべきかを描き、そこに向けてチームを成長させていく。そのためには評価が必要となるし、成長のドライブとなる人材の採用もやっていきたい。採用するならDevRel観点も必要だよね、といった具合にやりたいことは増えていきます。
Team Design
Team Development
People Evaluation
Recruiting
DevRel
今この瞬間に求められているものはスクラムマスター的です。チームのパフォーマンスを最大化する、そしてそのことによりチームが所属する事業部、ひいては会社を圧倒的にグロースさせていくと考えたとき、なすべきスコープは広がっていきます。スクラム畑の人はピンときたかもしれませんが、これってScrumMasterWayっぽいんですよね。
組織はグロースしていくものなので、スタートアップ企業で小規模チームのEMを担当していてもいずれはスコープを広げていくことになるのかな、と思っています。事実、私はこの会社にきて2ヶ月とちょっとですが、すでに自分のスコープが広がってきていることを感じています。
なお、新任EMとして取り組んでいることの詳細はこちらのブログに書いているので、ぜひご一読ください。
2つの組織でのEM経験で感じたこと
（現職についてはまだ2-3ヶ月経ったばかりということで、あれこれ論じるのは性急な気もしますが）2つの組織での経験から、「組織によってEMに求められることは全然違う」というのを肌で感じているところです。面白いのは、ある程度の規模のエンジニアを対象としていた前職よりも現職のほうが（いい意味で）狭い意味の責務となっていることです。
前職ではピープルマネジメント、プロダクトマネジメント、プロジェクトマネジメントのグラデーションの中で活動しているイメージでしたが、現職では専任PdMが3名いることもあり、自分がプロダクトマネジメントする色彩はかなり薄くなっています。
そして、小規模チームにおいても前述の4つのポイントは有効に作用しました。なので今自分の肌感覚としては、EMとして機能するためにおさえておくポイントは、メンバー向き合いのものとしてはこちらの4つなんだろうなと思っています。
マネジメント対象のメンバーの専門領域に対して最低限のナレッジを持つ
そのナレッジを（浅くてよいので）アップデートし続ける
自分は専門家ではないという自覚を持ち専門家の意見も聞くようにする
傾聴などコーチングスキルを鍛え自分にバックグラウンドがないスキルの成長支援を可能にする
シニアに対してマネージャーは必要か
現職はメンバーがシニア揃いです（スキル、年齢ともに。最年少が35歳なので、エンジニア定年35歳説になぞらえれば私達はシルバー人材センターのような存在です。）
ハードスキル、ソフトスキルに対してEMが積極的に介入し成長を促す場面はいまのところ観測されていません。むしろ私が成長させてもらっている。
毎年新卒が配属されてくる前職では、経験の浅いメンバーをオンボーディングさせ急成長させる、というのがEMの重要な役割のひとつでした。現職ではそれがありません。
自意識としてはメンバー育成が得意だし好きだ、と思っていたので、いってしまえば得意技を封じられた形になります。いやーこれは一番下手くそでいられる環境だ！
そもそも、以前は「シニアな人たちにマネージャーの支援なんて要るのか？」とさえ思ってました。じゃあ、実際問題、シニアに対してマネージャーという存在は必要なのか。結論からいうと、「シニアな人たちは、マネージャーは要らないかもしれないがうまく支援できると信じられないパフォーマンスを出す」と考えています。なので「シニアの能力を最大限引き出す」という観点では、むしろマネージャーの必要性は増すということです。
ドラゴンボールに最長老というキャラクターがいます。
最長老が手をかざすと、かざされた相手は潜在能力が引き出され信じられないようなパフォーマンスを発揮することができます。シニアエンジニアが集う環境では、この最長老のような働き方をすることでGoodなチームをGreatなチームにすることができます。
EMとは何者か
コードを書くべきか、エンジニアであるべきか、一般的なマネージャーなのか
さあ、あらためてEMとは何者なんでしょうか。まずは、よくある論争から考えてみましょう。
EMはエンジニアであるべきか。コードを書いていたほうがよいか。そんな論争は今日でも観測されます。
コードを書いていたほうがよいか。これはシンプルに「よい」が答えです。できたほうがいいに決まってる。
では、コードを書いていないとEMは務まらないか。これは「いいえ」が答えだと考えています。エンジニアのためのマネジメントキャリアパスでも「極力書き続けたほうがよい」ということは書かれていますが、ラダーを登っていくとどうしてもコードを書く時間は取れなくなっていくことにも触れています。
また前述のシニアだらけチームの話をすると、彼らはコードを書くのが非常に得意な人たちです。そして好きな人たちです。3度の飯よりコードが好きな人たちが、自分たちの気が済むまでそこに没頭する状態を作るというのもEMにとって大事な仕事だったりして、そういった現場であれば自分が書く必要性はあまりないのかなーと考えてます。
コードを書くなどエンジニアリングができないと、エンジニアの尊敬が集められないのではないか＝信頼貯金を貯められないのではないか。
そうかもしれません。でも、「エンジニアリングができる」人を求めるとしたら、そしてそこにハイパフォーマーであることを求めるとしたら、それは本当にマネージャーへの期待なのかは点検したいところです。
北斗の拳のアサムのように、自らの腕っぷしで信頼を勝ち取るやり方だってもちろんあります。あるし、かっこいいです。「コーディングで信頼を勝ち得る」という方法をずいぶん前に置き去りにしてきた自分からすると眩しい存在です。
ですが、「エンジニアリングの力で信頼を勝ち取る」は手段でしかないのかなと思っています。他の方法で「信頼を勝ち取る」ことができ、そちらのほうが得意だったり、今のロールの中ではやりやすかったりするならその道を選ぶことだってアリです。
では、逆にEMは一般的なマネージャーと等価か。
近しい部分はあるけれど、等価ではないと私は思います。見積もりに対しての勘所、新規開発時のリスクマネジメント、エンジニア文化への理解…。やはり、EMならではの要素があります。
そして、ソフトウェアエンジニアリングの分野は比較的歴史が浅く、また変化がダイナミックであることから、こういったポイントに対して一切の経験なしにEM業を担うことはなかなか難しいのではないかと思っています。（きっとできる人もいるんだとはおもいます）
たとえば、EMについて基本をおさえておきたい、となったとします。O'Reillyから「エンジニアリングマネージャーのしごと」という素晴らしい書籍が出ています。本書はエンジニアバックグラウンドを持つ人がEM業にチャレンジするタイミングで読むには絶好の一冊です。ですが、エンジニアにとって当たり前の部分は特に触れられていないので、エンジニアバックグラウンドのない人が本書からEM業に求められるエンジニアエッセンスを習得することは難しいんじゃないかな、とおもっています。
基本をおさえておくなら、CSの入門書を読んだり、独学プログラマーなどを参考に実際に手を動かしてみると良いかなと思います。
なお、カーニハン先生のCS入門書は、エンジニアバックグラウンドをもつEMにとってもおすすめの一冊です。意外と抜けがちだったり忘れがちだったりする基本的なところの復習ができます。
エンジニアはEMに何を期待する？
EMとしてなすべきことを考えるときにもうひとつ大切なのが、メンバーからの期待を理解しておくこと。私のチームは明確に「こういうことをやってほしい」というメンバーばかりなので、とても助けられています。とはいえいいづらいことだったり本人が気づいていないこともあるので、1on1等で傾聴スキルを駆使しながら期待をインサイトをしていくのがいいでしょう・・・
って書いてる途中で、チームメイトの @bufferings さんから熱烈なラブレターが届いた！N=1ではありますが、シニアエンジニアがEMに求めていることが端的にまとめられています。そして胸熱。
私にとってのEMの定義
というわけで、こちらが私なりの「EMとは何者か」の答えです。
EMは、マネジメント対象とするエンジニアチームの価値を最大化する。
そのためにやるべきことは組織の状況により異なるが、自分自身のエンジニア経験に根ざしたエンジニアリングへの理解、ナレッジ、スキルがマネジメントスキルを支える土台となる。
価値を最大化するというミッションを遂行するための手段は問わない。よってコードを書くべきならそうすればいいし、ピープルマネジメントに専念するのがよいならそうすればよい。ただしチームは変わる。チームにあわせて変幻自在に変化し、価値の最大化にコミットし続ける。それがEMである。
私自身は、この考え方に基づき、これからも変幻自在に活動していきます。
良きEMであるために
ふたたび、Engineering Management Triangleをみてみます。
今、自分が得意だったり好きだったりするところ。逆に苦手なところ。それぞれあります。
じゃあ苦手なところを埋めていけばいいのだろうか？そういうアプローチもあるでしょう。ですが、自分に焦点をあて自分のスコアを上げる行動をとるのではなく、チームと向き合ってチームが今必要としているスキルを練り上げていくのがいいんじゃないかなーというのが私のスタンスです。
みんなで成長していこう
だいぶ長くなってしまいましたが、私が考えるEM像について書きました。
EMとは固定的なものではありません。常に変化しながら、その変化に追随する成長を遂げていくことがEMにとっては大切です。
求められる領域は果てしなく広い。それに一人で立ち向かうのはあまりにも心もとない。このAdvent CalendarにたくさんのEMが集結してくれたように、実は仲間はいっぱいいるんです。知見を共有しながら、切磋琢磨しながら、一緒に成長していきましょう。
おまけ
EMはスクラムマスターと似ているところがあるし、変幻自在だよ、ということを伝えたい資料