Engineering Managerをエンジニアのマネージャーとするのはやめませんか？

この記事はEngineering Manager Advent Calendar 2018の9日目の記事です。 vol.2もあるので、是非こちらも見てください。

f:id:yunon_phys:20181003000204p:plain

私は常日頃、Engineering Manager(EM)がいない問題について危機感を覚えている。これはEMという役割が正しく認知されておらず、魅力が伝わっていないことが根本の原因にあると考えている。*1 だから、EMの魅力を伝えるPodcast EM.FMを広木さんと始めた。*2

このPodcastでは、EMが何を考えているのか、EMも人間だから悩みながらやっていること、EMが何に喜びを感じるのか、などを語っている。メインパーソナリティは広木さんと私だが、Quipper EMの大庭さん(id:ohbarye)、元Googleの及川さん(id:takoratta)、VOYAGE GROUP CTOの小賀さんにもゲストとして過去に出演いただいた。出演者全員に共通しているのは、EMとしての業務を楽しそうに語っていることだ。だから、EMは本来楽しい役割のはずなのだ。

なのにEMの業務が、エンジニアのマネージャーという言葉に置き換わった瞬間に、急激に魅力が失われる。この違和感は何からくるのだろうか。

マネージャーは不要である

EMについて話す前に、そもそもの私のスタンスを明らかにしておく。私はマネージャー(EMだけでなく、XXXマネージャーと名乗る役割)は本来不要だ、と考えている。正確には、マイナスをゼロに補完するマネージャーは不要だと考えている。

マイナスをゼロに補完するマネージメントの代表例は、マネージャーがコミュニケーションのハブになるというものだ。例えば、インフラエンジニアとアプリケーションエンジニアのコミュニケーションがうまく取れずにプロダクト開発がうまくいっていない、という状況を仮定する。その間を取り持つために、インフラ部門のEMとアプリケーション部門のEMをたてて、その2人で話し合うようにする。するとコミュニケーションがうまく取れるようになり、プロダクト開発が一時的にうまく進められる機運が高まる。しかし、次に待っているのは、そのEMがSPOFになる未来だ。つまり、コミュニケーションがうまく取れない、というマイナス課題をEMがゼロにしただけで、プロダクト開発がプラスになったわけではない。本来やるべきは、インフラエンジニアとアプリケーションエンジニアが直接対話出来るようなチーム構成を組み、それぞれの強みを活かせるように、より良いプロダクト開発を継続的に生み出せる環境を整えることなのに。

多くの"なりたくない"マネージャー像は、このマイナスをゼロに補完するマネージメントをしている人ではないだろうか。マイナスをゼロに補完する役割をすると、人と人との間に入り、神経をすり減らせながら、日々を過ごさなければならない。もしこれが毎日の仕事なら、私も到底魅力を語れないし、まるで魅力があるように語って引き込もうとする死神のようなことは出来ない。

Engineering Managerは何をする人なのか

良くEMと話すと、評価・1on1・採用の話題になる。

評価をどのようにすれば良いか
どうすれば1on1がうまくいくようになるか
どうすれば魅力的な人材を採用出来るか

などなど・・・。正直な話、これらを語っているだけではEMが魅力的な役割にうつらないだろうなと考えてしまう。まさにマイナスをゼロに補完するマネージメントをやっているように聞こえるからだ。

エンジニアは職業柄、ボトルネックを改善したり、ものごとを構造的に考えるのが得意だ。だから、エンジニアとしてのバックグラウンドを持っているEMは、そのスキルを対コンピューターではなく、対組織にフルに活用するべきなのだ。そういう意味で、組織のボトルネックを見定め、組織を構造化して捉えて最善な方向に導くのが、EMの役割とも言える。*3

もし組織課題がエンジニアのマネージメントであるなら、EMがそれにフルコミットするのが良い。裏を返すと、全員が評価に満足しているのなら評価の話題をしないで良いし、いつでも困ったことを相談出来る関係性を築けているのであれば1on1もやらなくて良いし、既存のメンバーで理想の未来を描けるのであれば採用も不要である。真の組織課題を見ずに、EMの仕事として評価・1on1・採用をもしやっているのだとしたら、危険信号かもしれない。

Engineering Managerは役割である

EMがエンジニアのマネージャーでないのだとしたら、そもそも上司という概念すら疑わしくなる。エンジニアがプログラムを書くように、UIデザイナーがUIデザインするように、EMも組織をマネージメントする役割を担っているだけである。そこに上司や部下という関係は存在しない。私がこの記事で一貫して、EMを役割と言ってきたのはこの思想があるからだ。

一般的なEngineering Manager像は職能別組織によって生み出された？

では、なぜEMがエンジニアのマネージャーだと一般的に言われているのだろうか。これは多くの組織で、エンジニア組織、デザイナー組織、マーケティング組織、のように職能別組織を構成していて、その職能別組織単位で権限の分断がされているからではないだろうか。もしそうだとしたら、職能別組織の中で出来ることが、スキルマネージメントとピープルマネージメントしかないので、EM = エンジニアのマネージャーとなるのは納得がいく。職能別組織は知の深化が進むことはメリットだがコンピテンシートラップ(イノベーションを引き起こす力が弱くなる)を引き起こす、と言われていて*4、そもそもその組織構造そのものがボトルネックになっている良い例かもしれない。