エンジニアリングマネージャーの定義について
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点に深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、エンジニアリングマネージャーの定義をどう捉えるか、です。
このエンジニアリングマネージャーの定義、SNSでたびたび話題になっているのを見かけたりしております。
今日は、そういった定義に関して、私がどう捉えているのか、どう捉えるといいのかな、みたいなところをお話しできればなと思っています。
エンジニアリングマネージャーの問題集。今日はですね、たびたびSNSなんかで話題に上がったりするのを見かけるんですけれども、
エンジニアリングマネージャーの定義というか、いうところに関して、
広木さんが一つ記事を書かれているので、まずこの記事を復習というか、中身を確認したいと思っており、
そこから私自身どういうふうに解釈するのかとか、その話をしてみたいなと思っています。
まず、広木さんの記事ですね。これ、読まれている方すごく多いんじゃないかなと思うんですけれども、
タイトルは、エンジニアリングマネージャー、プロダクトマネージャーのための知識体系と読書ガイドというタイトルで書かれた記事でして、
この中に、エンジニアリングマネージャー、EMとは何か、みたいな話だったり、
それから、弱めのEM定義とか強めのEM定義というようなお話が出てきています。
まず、この記事に書かれていることを簡単に整理したいなと思っていますが、
まずこの弱めのEM定義、強めのEM定義あたりですね。出発点としては、
広木さんはまず、エンジニアリングマネージメント周辺にある4つの機能領域というんですかね。
マネジメント領域から出発されていて、その4つは何かというと、
プロジェクトマネージメント、プロダクトマネージメント、ピープルマネージメント、それからテクノロジーマネージメントですね。
この4つに対して、それぞれの領域がかぶっているところもあるんですけれども、
エンジニアリングマネージャーとしてどれくらいどこをカバーしていくのかというところから、
代表例として強めのEM定義というのと弱めのEM定義というのを書かれています。
記事に書かれている表でいくと、
広木さんの記事『エンジニアリングマネージャー、プロダクトマネージャーのための知識体系と読書ガイド』について
ピープルマネージメント、テクノロジーマネージメント、プロジェクトマネージメント、プロダクトマネージメントの4つの領域を、
何というか、この表現が正しいかどうかわからないんですが、広く、
浅めにかどうかわからないんですが、とにかく全部をカバーするような形で責任を持って仕事をするエンジニアリングマネージャーを
強いEM定義というふうに呼ばれています。
一方で、よりテクノロジーとかピープルのところに特化したような
マネージメントですね。狭い範囲だけに責任を持ち、
しかし多分ニュアンスとしては、より現場にしっかり入って、
強めのパワーを持つというんですかね。
改造、理解だったりとか、そういう意味も含めてかなり深く入り込んで
マネージメントするような責任の持ち方をするエンジニアリングマネージャーを
弱いEM定義というふうに名付けられています。
で、これ分かりやすさのためにこの2つをあえて言語化されているだけだと思うので、
世の中にある様々な会社でのエンジニアリングマネージャーというのは、
この2つどちらかということは決してなくて、当てはまる場合もあるでしょうけれども、
この中間というかグラデーションのようにバランスが劣りながら
マネージメントされているというのが現実かなというふうに思っています。
はい、で、あとこの記事にいろいろ面白い
まとめも書かれていまして、例えばチームの特徴によって
こういうこっちのマネージャーの方がいいんじゃないかみたいな提案のようなことも書いてあって、
例えばチームがより専門職チームというふうに書かれていますけれども、
バックエンドエンジニアだけのチームみたいな、
機能単位でまとめられているようなチームの場合は、
弱めのEM定義を採用することが多いというふうに書かれています。
一方でチームが何というんですかね、クロスファンクショナルというか、
その1つの機能の職能の人で構成されているのではなくて、
どちらかというとそのミッションを元にいろいろな機能の職能の人が集まったチームの場合、
ミッションチームと書かれていますけれども、
こういったチームの場合は、より幅広く物事をマネジメントしなきゃいけないという役割に、
そのマネージャーの役割が変わってくるのでということもあり、
強めのEM定義を採用することが多いというようなことが書いてありますね。
前者の専門職チームの場合は、チームを低タスク型ダイバーシティと呼んでいて、
後者のミッション型チームの場合は、高タスク型ダイバーシティというふうに呼んでいたりと、
なかなか面白いまとめ方をされているなというふうに読んでいます。
記事の評価と応用について
この記事って1つ、たまにSNSで見かける議論として、
強い・弱いという言葉に引っ張られちゃうと言いますか、
強い・弱いと書かれると、強いほうがいいんじゃないかというふうに自然に思っちゃいますよね、我々としては。
ただ、おそらく広木さんはそこに良し悪しを込めてこのネーミングをしたわけではないと僕は考えてまして、
これもどこかでもしかしたら広木さんも言われているかもしれないんですけれども、
2つの分類を作ったときのネーミングとしては定義①と定義②でも良かったものを、
そのときたまたま思いつかれたんだと思うんですよね、強い・弱いというような言葉を。
それで使われたというぐらいだと思うので、
必ずしも、今たまたま弱い定義に当てはまるような責任の持ち方で
エンジニアリングマネジメントをされている方が、お前は弱いんだというふうに言っているわけでもありませんし、
今後この強いEMのほうになっていこうぜというようなことを主張しているわけでもないんですよね。
単に2つの分類の仕方を提示されている、エンジニアリングマネージャーの仕事というものがどういうものなのかというところを
体系的に整理する上で、たまたまこのような言葉を使ったということだと思いますので、
この強い・弱いという言葉に振り回されないようにしましょうというのはまずここで強調しておきたいなと思っています。
とはいえ、すごく参考になる記事で、これを出発点にいろいろな議論が生まれているというのはすごくいいことだと思っています。
とはいえ、私のこのポッドキャストでもいろんな会社でのマネジメントのこととか
伺ってくる中では、必ずしもここに書かれているような分類の考え方だけで答えが出せるというか、
ヒントになるわけでもないものもあったりするかなと思っていて、
例えば代表的な例が何度か前にこのポッドキャストで収録したユメミさんの例なんかで言うと、そもそもエンジニアリングマネージャーを置いてないと。
なので、例えばエンジニアリングマネージャーを持つべき4つの機能みたいなのがありましたよね。
この4つの機能を人が持つっていう考え方をしていなくて、機能として委員会みたいなものでカバーしたりだとか、
そういった考え方をしているところもあるので、もうそうなってくると、そもそもエンジニアリングマネージャーっていう話でもないし、
強い弱いみたいな話ですらないと。
なので、考えの出発点としては面白いんですけれども、やっぱりその会社の中でマネージメントがどうあるべきなのかなっていうのはまた別の話なのかなというところがあります。
というわけで、記事の話は一旦これぐらいにして、私自身がこの記事を読んだときに、とてもいい内容なので、
それを自分自身のマネージメントへの理解だったり応用というか、自分が何か新しい現場だったりだとか会社さんのことを考えるときに使える道具にしたいと思うわけですよね。
ただ、使える道具にしようとすると、この書かれている通り、そのまま当てはめて考えるというやり方ももちろん一定ワークすると思うんですけれども、
僕でしたらそこから踏み込んで、自分自身の理解というところまで消化させたいんですよね。
そこは何か私の好みの問題なのかもしれないんですが、といったときに、どういうふうに自分のものにこの分類みたいな考え方をしていくのかというところで、少し深めていこうかなと思っています。
最初にまずこの記事を読んだときに、この4つの分類ですね。何度も言いますが、テクノロジーとピープルとプロダクトとプロジェクトみたいな。
この4つの機能分類というカットは当たり前のように使われているんですけれども、その4つのカットだけじゃない議論というのも必要なのかなというのが1つあります。
エンジニアマネージャーの話をするような組織って一定スケールしているような組織が前提だとは思う。
100パーじゃないですよ。スタートアップの小さめな組織でエンジニアマネジメントをやっているところもあるので、組織のサイズはさまざまなんですが、一定スケールしたところが多くなってくるのかなと思っています。
といったときに、会社で持っている事業領域だったり、1つの事業領域をどう分割するのかみたいな話がまず大前提としてあって、
その分割の中で、ある程度チームが縦割りというかされた後に、一定動かせる範囲の中で、エンジニアマネージャーだとかプロダクトマネージャーだとかエンジニアたちがいて、
その中で責任をどう持っていくのかみたいなコンテキストが、この四つの分類がある大前提として暗黙的にはあるのかなと思ってしまうんです。
例えば僕が今仕事している会社でいうと、まだそこまでのスケールではないというところがあって、といったときに、もっとこの大前提みたいなところからストラクチャーだったり役割の持ち方をチューニングすることができるんですよ。
組織のストラクチャーと役割分担
チューニングすべきなんですよね。これは前回お話ししたスマートバンクさんなんかも、やっぱりカルチャーを大事にしていると、カルチャーをもとにどういう組織にしたいのかみたいなことを考えているときには、やっぱり組織のストラクチャーみたいなのを前提にせずに、どういうふうに振る舞ってほしいのかみたいなところから考え直すというところもあったので、
そういった要素というか変数も合わせて、エンジニアリングマネージャーの在り方というか、どこまでカバーすべきなのかというと議論をしたほうがいいんじゃないのかなというふうに、僕自身の好みで引きつけちゃうところがあるんです。
はい。
で、ちょっと話が散らかっちゃいましたが、なので、何ていうのかな。
例えばその組織みたいな観点でこの役割分担を考えていくときには、プロテックなのか、ピープルなのか、プロジェクトなのかというカットだけではなくて、その組織で持っている事業の中のどれだけの範囲まで役割を広げるのか。
1つの事業の中をA、B、Cというふうに分割できるとした場合に、今は分割して3つのチームで担当していますといったときに、でもエンジニアリングマネージャーは3人のマネージャーが1つずつチームを見ているとしたら、
やっている事業によっては、もうAというチームを担当しているマネージャーは、もうAのところだけに完全にフォーカスして、他のBとCという領域の知識は一切持たなくてもいいというぐらいフォーカスしてほしい。
それでやることが、効率とかそういう面でもいいだろうし、会社の事業、短期にも長期にも貢献するはずだというふうに考えている会社とか、そういうプロダクト事業の場合もあると思いますし。
一方で、これは僕が今所属している会社なんかはそうなんですけれども、そこまでチームがA、B、Cと分かれていたとしても、チームの境界ごとにやっていることというか、使っているものとかがスパッときれいに分かれていないと。
むしろ、このA、B、Cと分けていたとしても、A、B、Cの間での少なくとも知識レベルのコラボレーションというんですかね。仕事はある程度独立してやれるかもしれませんけれども、作りたいプロダクトとしては何か一つのものだったりするので、
この横で連携して、総合的にどういうものを作っていくのかというようなコミュニケーションがなされないと、本当にいいものが作れないというような会社もあったりすると思うんですね。
僕の会社は本当にそうなんです。そうだとすると、少なくともメンバー全員とまでは言わないにしても、何をやるべきかと考える人、これはプロダクトマネージャーだったりしますし、このプロダクトマネージャーのカウンターパートとして動くことを求められるエンジニアリングマネージャーなんかは、一定チームの中だけに知識が閉じるのはよくないというふうに考えることもあると思うんですね。
むしろエンジニアリングマネージャーは、アサインされたチームはAという一つのチームかもしれないけれども、知識としては常にA、B、C全て、事業全体をカバーするような知識を持ってくださいというふうにした方が短期で物事を動かすときのスピードも出るし、
長期的により革新的なものを作るときの、そういった全体的な知識を基にしたエンジニアのアサインだったりだとか、提案だとか問題解決だとかいうことができるようになっていくだろうというふうに考える場合もあると思うんですよ。
これは会社とか扱っている事業だったり、扱っている事業の中でもパーツごとに特性が異なったりするので、ものすごく専門性が必要なパーツをやっているチームと、ある程度一般的なアプリケーション開発みたいなことをやっているチームとで特性によって分かれるとかもあると思います。
これは会社とかチームとか状況によって全然違うんですけれども、何が言いたいのかというと、やっぱりこういったどういうふうに役割を持つべきなのかという議論は、その会社がやろうとしていることに沿って考えないと、そもそもおかしな話になってしまうというところがあります。
なので、そこを抜きにエンジニアリングマネージャーの定義というか、どれくらいの範囲の責任を持つのかという話をしてもあまり意味がないよねというのがまず言いたかったことなので。
この話は僕としてはもう、聞いている方の中には全然違う話をしているように聞こえる方もいるかもしれないんですけれども、僕としては絶対ここはセットで話すべきものかなと考えているので、ものすごく強調しました。
で、それから一方で会社としてこうあるべきというか、それは社長がこう思っているからみたいなこととは別に、やろうとしている事業の特性だとか、そういった客観的なところから導かれる、こうあるべきというのが一定あると思うんですね。
それは一つの答えが出るわけではないんですけれども、一定収束している答えがあると思っています。
ただ一方で、それだけに寄せちゃうと、なんていうんですかね、エンジニアリングマネージャーも人ですから、一定自己実現みたいなところの、自分のキャリアとかね、そういうところの幅もあってもいいとは思っていますし、
あと、必ずしも会社が入社した時にCTOみたいな、最初にそういった役割の設計みたいなのをしている人がいて、それが会社のやってほしいことだとした時に、それが必ずしも正解とは限らないじゃないですか。
ちょっとおかしいなという場合もあると思うんですよ。往々にしてあると思うんですよね。
そういった時に、自分だったらこっちのやり方、こういった責任の持ち方の方が正しいと思うというか、この会社にとってよりいいと思う。
だったり、もしくは元々自分の中にエンジニアリングマネージャーとしての一定ワークする革新というか経験というかみたいなものがあって、それは会社で求められているものとはちょっとずれているんだけれども、でもきっとこの会社ではこれのやり方がワークするはずだとか、そういう場合もあると思うんですよね。
なので、一定その完全100%会社が求められているような役割のデザインだけではなくて、自分視点での動き方というか責任の持ち方というところも観点としては持っててもいいかなと思っています。
ちょっと役割のデザインの話なので、デザインをするときに何を元にデザインをするのかという話ですね。
そういった組織観点だったり、自分視点、内発的にどうなのかみたいなところを抑えた上で、さっきの4つの分類、プラスアルファみたいなところを考えていくというのが必要かなと思っていまして。
エンジニアリングマネージャーの広さと深さ
ちょっと余談なんですけれども、ちなみに僕個人的には、これ広木さんの強い弱いに引きずられて思っているわけではないというのを強調しますけれども、
個人的にはやっぱりできるだけ広い範囲の知識だったり責任を持ちながら、同時に一定、現場まで降りていけるというか、現場の具体的な問題に対してすごく高い解像度を持って理解していて、
それの対処法だとかに対してアドバイスできたり意思決定できる状態というのが、僕の考えるいいエンジニアマネージャーだと思っています。
そういう方向を僕としては押していきたいんですよね。
そういう広さみたいなのが圧倒的に、広い範囲に、とにかく知識だとか責任を広げていくということが必要だと思っていて、
何ならそれってエンジニアリングにすらこだわらないというか、ビジネスの方にまでも踏み込んでいくぐらいの柔軟さかもしれないし、ある種割り切りというかぐらいのところまで必要なのかなと思っています。
たまに、物を作らずに解決できるならそれが一番いいみたいな話ってたまに出てきたりするじゃないですか。
やっぱりソフトウェアを実装して作っていくのってすごいコストがかかることだし、本当に解決したい、顧客が本当に欲しかったものみたいなのが、
ソフトウェアを作ることではなかったりもするんですよね、稀にというか。よくある話かもしれません。
そういった本当に顧客が欲しいものっていうところに、エンジニア自身、今マネージャーの話からちょっとそれちゃってますけど、
エンジニアとしてアプローチできることも結構重要なのかなと思ったりもしているので、
それぐらい幅を広げて、自分のやることすらなくすというか、これ作らなくていいんじゃないですかっていう判断すらできるぐらいの広さの責任というか、
アプローチできる範囲というんですかね、というのを持って仕事をするぐらいが、僕としては理想なのかなと思っています。
これ全然余談なんですけれど、最近とある起業家の方と話す機会があって、プロダクト作りみたいなことを話してたんですけれども、
その時にその方がすごい強調されてたのが、その方、これまでに2度くらい01でプロダクトを作って売却したみたいな経験がある方なんですよね。
なので、結構どういうふうにクイックにコンセプトを検証してプロダクトにしていくかみたいなところに結構長けている方かなと、僕としてはお見受けしていて、
その方がすごい言われていたのが、ソフトウェア作り始めると、これさっきの話も完全につながってるんですけど、めちゃくちゃコストがかかると。
それは特に言ってたのが、エンジニアのコストが高いと。
それって単に人件費が高いっていう話かもしれませんし、やっぱりそれだけではないものとして作っていくっていう、
具体的にソフトウェアを作るっていうことがやっぱり大変というか、工数がかかることだったりもしますし、
一度作り始めるとなかなか軌道修正するのが難しかったりしますよね。
作り直すコストもすごいかかってくるので。
そういったところを含めて、コストが高いっていうふうに言ってたっていうふうに僕はその場では理解していて、
企業家というか、そのプロダクトを作ってきた人として、すごく説得力のある話だなと僕は思ったんですけれども、
一方で、ある種ソフトウェアエンジニアとしての危機感というか、
ソフトウェアエンジニアリングはコストが高いみたいに、企業家の人から思われてるのってあんまりいい状態じゃないなというふうに思っていて、
やっぱりソフトウェアを作るっていうこと自体が、ある種、もっと身軽なものというか、
エンジニアリングマネージャーの定義と責任範囲
簡単に試せるものであるかのように、これは認知の仕方だけなのかもしれないんですが、
思われてたほうがいいだろうなと思うし、ソフトウェアエンジニアとしてはやっぱり、
そういうところから価値を発揮できるような状態っていうのが、やっぱり僕個人としてはいい状態かなと思ってるんですよね。
企業家みたいな人がゼロから何かものを作ろうとするときに、最初はソフトウェアエンジニアはいらないって言われちゃうと寂しいじゃないですか。
そのフェーズにも入っていくことって、たとえソフトウェアのコードを書かないにしても、
エンジニア側が持っている知識とか、いろんなものを最初のゼロからのフェーズのところで持ち込むことが意味があることだって絶対あると思うので、
そういったところに入れない状態をエンジニア側がもし作っちゃってるんだとしたらあまり良くないなみたいなふうに思ったっていう、
かなりちょっと余談なんですけれども、エンジニアだったりエンジニアマネージャーがどういったところまで自分の仕事のカバー範囲っていうんですかね、
広げるって言ったときに、ちょっとその話も関係あるのかなと思って余談で話しました。
そんなこともありつつなんですが、ちょっと繰り返しになりますけれども、私の主張としては、
できるだけ広い範囲の責任までですね、理想としては。
責任まで持てないとしても、知識としてはできるだけ広い範囲をカバーしていくほうが、
少なくともエンジニアリングマネージャーにとっては理想的な状態かなと思っています。
ただし、これが広く浅くになってしまっていると、単にその人のマインドシェアを奪っちゃうだけみたいになりがちなので、
ただお勉強して知識の範囲を広げているだけだとあんまり意味がないかなと思っていて、
やっぱり適度に責任も持った状態で、カバー範囲が広いという状態がバランスのいい状態かなと思っています。
これは組織によって可能不可能みたいなのがあるので、やりたいと思ってすぐにできることじゃないかもしれませんが、
僕としてはそのほうがいいとは思っています。
責任を持っているという状態は、単にそのチームのマネージャーとして任命されているだけというのでは当然なくて、
エンジニアリングマネージャーの理想的な状態
そのチームだったり領域をマネージしているということは、その領域で起こっている日々の問題、課題だったり、
人々、メンバーたちがぶち当たっている課題だったりもしますし、
扱っているソフトウェアだったりプロジェクトだったりで起きている問題だとか、そういうことをきちんと把握していて、
それに対して自分が何かソリューションを提示できたり、実装まですることも必要な場合もあるかもしれませんし、
できないにしても現場の人たちが取ろうとしているソリューションが適切なのかどうかということに対して、
自分がきちんと理解して発言ができる、よしよしを判断できる、そういう状態であることがベストだと思っていますので。
おそらく僕は、ひろきさんの定義に当てはめると、強いEMよりの定義のものを指向していると言えると思いますが、
これは強いって書いてあるからそっちがいいと言っているのではないと、そのような定義の方がいいと僕が思っているだけで、
強い弱いという言葉に僕自身が振り回されているわけではないということは、皆さんこの話を聞いてご理解いただければと思っています。
というわけで、今日はエンジニアリングマネージャーの定義というんですかね、設計というのかな、そのあたりの話をいろいろとしてきました。
僕自身何か皆さんにこうでなければならぬみたいなことを言いたいわけではないんですけれども、とはいえ僕自身のいいと考えているものがあって、
ただそういうのにこだわりすぎてもダメな時もあるというか、会社で何が求められているのかとか、そういうところもきちんと観点として
織り込みながらどうなっていけばいいのかなというのは、皆さんが柔軟に考えられるようになるといいなと思っております。
さて、この番組では感想や質問、リクエストなどお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株式スタイル、COO兼CTOの後藤英典でした。
