見出し画像

みんなで「エンジニアリングマネージャー」について考える

dora_e_m

はじまりは社内勉強会

しいばさんがXで呟いていたとおり、社内の勉強会でゆのんさんが「エンジニアリングマネージャとは？」について話をしてくれました。

ゆのんさんといえばEM.FM。日本でエンジニアリングマネージャーという概念が浸透し知見が蓄積されていったのは、EM.FMを立ち上げたゆのんさんとひろきさんの功績はかなり大きいと思っています。(まさたんがジョインしてさらに厚みを増してるのもいいですね)
そのゆのんさんの口から「EMとは」について語る場があるとは、これを福利厚生といわずしてなんとするという感じです。（僕からするとしいばさんと一緒に働けるのもめちゃくちゃ福利厚生ですが）

この社内勉強会、それはそれは盛り上がりました。エンジニアだけでなくプロダクトマネージャーとかも参加して、それぞれの視点でSlackは大盛りあがりでした。

ただ、このnoteの本題はそこではありません。勉強会自体については、きっとゆのんさんから発信があるでしょう。あるよね。あるにきまってる。

なので私は、その勉強会をきっかけに感じたことや考えたことをこのnoteに書き留めておきます。

エンジニアリングマネージャーなにするものぞ

この社内勉強会が開催される数日前、アンドパッドのVPoEげっしーさんがこんなことをつぶやいてました。

これは至極まっとうな疑問で、EM界隈で話題に上がるイシューは「それ、エンジニアの分野じゃなくても存在する課題だよね?」というものが多いという肌感があります。

以下の記事でいうところの「弱めのEM定義」ではピープルマネジメント・テクノロジーマネジメントがメインに据えられていますが、組織によって定義がまちまちであるEMの共通項がこの「弱めのEM定義」であり、かつテクノロジーに関してはそれこそ事業ドメインごとに全然違ってくるから、共通で話せるのが「ピープルマネジメント」に帰着する。だから勉強会を開催すると「一般的なマネージャーと何か違うの?」という疑問が生まれるんだと思います。

エンジニアリングマネージャーとエンジニア

エンジニアリングマネージャーは組織が求めるマネジメント領域により、その役割が変動します。シード期に近いスタートアップであれば限りなくエンジニアリングに寄った活動が求められ、組織が成熟していく（拡大していく）に従ってエンジニアリング以外のマネジメント領域が求められていきます。そうすると「一般的なマネージャーと何が違うの？」になるわけですが、その責務を全うするためのバックグラウンド、スキルが異なるというのが大きな違いのひとつです。

エンジニアは、プロダクト開発にまつわる課題をエンジニアリングで解決する。
エンジニアリングマネージャー(/VPoE)は、チーム・組織にまつわる課題をエンジニアリングで解決する。

コンウェイの法則・逆コンウェイ戦略について言及されることが多いですが、チームや組織をエンジニアリング対象として捉え、生成されるアーティファクトと相似系をなす形でマネジメントしていくところがEMの特色だと私は考えています。

軸足とフットワーク

社内勉強会で興味深かったのが、どのロールに属している人もゆのんさんの話に共感していたことです。これはゆのんさんの話がよく練られていて完成度が高いというのもありますが、どんな立場であっても共通する課題があるからこそ生まれた共感だと思います。

「エンジニアリングマネージャーのしごと」を読んだとき、それこそ「これはEMに限らないなー」と感じました。「プロダクトマネージャーのしごと」を読んだとき、まなざしの起点はプロダクトマネージャーなんだけど、Howの部分だったりマインドセットはEMと共通する部分が多いなーと感じました。

社内Slackでそんなことをつぶやいたら、プロダクトマネージャーの方もEMとの間に共通項があると感じているようでした。

プロジェクトマネージャーだってそうです。PMBOK7版の「テイラーリング」とかは、まさにグラデーションを意識しながらその時必要なアクションに身を捧げていくマネージャーそのものの行動です。

そして、スタッフエンジニア。私自身は未読なので多くを語ることはできませんが（今度読みます）、エンジニアというロールから越境していく姿がそこにはあります。（という話で盛り上がっていました。）

EM。プロダクトマネージャー。プロジェクトマネージャー。スタッフエンジニア。それぞれ軸足はあります。Accountabilityを持っている領域があります。それでも、その軸足の位置から一歩も動かないのではなく、隙間を埋めるようにフットワーク軽く動いていく。それがどのロールにおいても「よい動き」と考えられている。うすうすわかっていましたが、様々な職種の方と同じ勉強会で意見交換することで、やっぱりそこは重要なポイントなんだなーと確信しました。越境だ越境。

ボールを拾いにいける人がいる組織は強い

スポーツはやらないしみないしそんなに興味もないので想像で語りますが、「自分の守備範囲じゃないところにボールが落ちてきた」ときに「俺の範囲じゃないから」と動かないメンバーしかいないチームより、即座にそこに走り込んでいくメンバーが多いチームのほうが多いのは想像に難くありません。
1994年12月31日のX JAPAN東京ドーム公演「白い夜」、紅の演奏途中でYOSHIKIが失神したとき、TOSHIがアドリブでもう1コーラス繰り返したことがあります。「俺の出番じゃないし」ではなく、全員で最高のものをつくっていくという意識がなせるワザです。ピンとこない人は白い夜のライブ映像をみてください。

越境しあえる組織になろう

この勉強会を通して、「EMはスキマを埋める存在なんだ」という共通認識ができたように思えます。そして、エンジニア職に限らず「スキマを埋めることが必要になる場面は必ずやってくるんだ」と気づいた人も多いでしょう。
これってすごく大事なことで、「スキマは埋めたほうがいい」、つまり「スキマは埋めてもいい」ということにみんなが気づけるんです。
隣にボールが落ちてきそうなとき、取りたい気持ちはありながらも「自分の管掌じゃないから取っちゃわるいかな・・・」みたいなためらいがあったりするのが人間です。だからこそ、「越境はしたほうがいい、だからしてもいい」という発信を組織としてするのは大事だな〜と改めて思いました。

さいごに

今回、このnoteを書こうとおもったのは、しいばさんが同講演に参加して感じたことをブログに書かれていたからです。

あーいいたいことはだいたいしいばさんが書いてくれてるなー助かるー感はありつつ、今回の勉強会の主題である「エンジニアリングマネージャー」である自分の視点から学びを記しておくことにも意味があると思い、筆を執るに至りました。重複上等！重複を恐れるよりも越境を！

そろそろ子どもたちが作業部屋に突入してきそうな気配を感じるので、今日はここまで。

この記事が気に入ったらサポートをしてみませんか？