2024年05月09日、株式会社overflowが主催するイベント「評価、1on1だけやってていいの？ こにふぁーさん、あらたまさんに聞く EMが担うべき役割とは」がオンラインにて開催されました。
現在、エンジニアリングマネージャー(EM)は、開発組織で重要な役割を担っております。
その業務は、技術マネジメントやプロダクト、プロジェクトマネジメントなど多岐にわたりますが、実際には評価や1on1といったマネジメント業務に比重が置かれて語られることが多いのが実情です。
そこで本イベントでは、ゲストにKyash 執行役員VPoE konifar(こにふぁー)さんとLayerX（元ベンチャー企業CTO）のあらたまさんをお迎えし、「EMの業務範囲と、企業のフェーズや組織によって異なる役割をどのように考え対応されてきたか」や、「konifar(こにふぁー)さん、あらたまさんが考える本来担うべきEMの役割」などについてお伺いします。また加えて、誰もが悩むテーマである1on1や評価制度などをもとに、「メンバーに期待を超えた動きをしてもらうために何をしていくべきか？」についても、お二人のディスカッションを交えて深掘りします。
株式会社Kyashの執行役員VP of Engineeringを務め、開発組織全体のマネジメントをしています。現在、EM（エンジニアリングマネージャー）というポジションではありませんが、2年前までモバイル、サーバーサイド、QAの3チームをまたいでEMを担っていました。その際に、評価や1on1を担当していましたが、うまくやれていた自信がありません。現在も試行錯誤中ですので、理想と現実のギャップについてもお話しできればと思います。
株式会社株式会社LayerXでエンジニアをしています。前職ではCTOを務め、その際にEM（エンジニアリングマネージャー）の役割も担っていました。LayerXに入社以降は、マネージャーとメンバーを担当しており、現在は「バクラク申請」「バクラク経費精算」というプロダクトのエンジニアとして開発を行っています。本日はマネジメントされる側とする側の両方の視点を持って、フレッシュな視点でお話できればと思います。
――EMの役割やその範囲について、どのように考えていますか。
konifar氏：こうあるべきというものは、あまりないなと思い始めているのが現状です。フェーズや状況によってやるべきことが変化するため、その変化に対応しながら組織をつないでいくことがEMの重要な役割だと感じています。
あらたま氏：今年2024年の2月にカンファレンスで登壇した際、マネージャーの役割について話をしました。
引用：新任エンジニアリングマネージャーのための「ぼうけんのしょ」https://speakerdeck.com/ar_tama/yapc-hiroshima-engineering-manager-day1[/caption]その際に、マネージャーは、プロダクトやチームをうまく活かすために必要なことを全部やる人とざっくりと話しました。業務範囲についてはスライドの通りですが、これらの業務を全て担うべきという話ではなく、チーム全体でその役割を満たせれば良いと考えています。
中でも、ピープルマネジメントはよく挙げられるEMの役割の一つではありますが、他にもテックリードがいない場合には、技術的な方向付けを行うことが必要です。それを他の人にお願いするか、自分が担当するかを決めて動かすことがマネージャーの役割だと考えています。
konifar氏：役割については本や記事が多く出ていて、私がEMになった際も参考にしました。例えば、広木大地さん著作の「エンジニアリング組織論への招待」（https://amzn.asia/d/320w1s1）、そして「エンジニアリングマネージャーのしごと」（https://www.oreilly.co.jp/books/9784873119946/）などです。これらのように、以前よりもマネジメントの基本を学ぶ環境が整ってきていると感じます。
――役割が変わると、ピープルマネジメントや技術マネジメント、テクノロジーなどを含むさまざまな要素を考慮し、判断する必要があるかと思いますが、その辺りはどのように判断されていますか。
konifar氏：メンバーとの1on1の場で、現状や課題について情報を共有し、そこから次の行動方針や方向性を決定することが多いです。
一方、ドラスティックな変化を伴う提案は、四半期や事業計画が決まったタイミングで、組織を変更したり、自分自身の動き方も含めて変えていますね。
あらたま氏：konifarさんの感覚、よくわかります。
私は、会社や事業、プロダクトの方向性などを、社内にある様々な資料や取締役と話すなどして情報を収集し、現状と未来とのギャップを埋めるために自分たちがどう行動できるか、といったことを思い巡らせながら考えています。それを、誰にどう動いてもらうのかというところまで落とし込んで、それをサポートするためには自分がどう動くべきかを逆算しながら組み立て、自分が今担うべき役割を変えています。
konifar氏：確かに、ギャップとの乖離は私もよく考えます。あと一つ思うのは、EMがいない組織や、EMという名称がついていない組織もある中で、あえてEMというロールをその組織に配置したという背景があるべき役割の源であるように思います。こちらについては、是非あらたまさんに聞いてみたいんですが、LayerXでEMという役割を置いている背景はどういう意図があるのでしょうか。
あらたま氏：一つは「ピープルマネジメント」の移譲です。プロダクトごとにチームを立てており、バクラク事業部だけでも7つほどのプロダクトが存在しています。プロダクトごとの意思決定をより迅速に行うために少人数のチームで構成されていますが、そこに評価者も入るべきだと考えマネージャーを置いています。
マネージャー側も見るメンバーの数を減らすことで、ピープルマネジメントのコストが高くなりすぎないようにしています。そうすることで、よりチームが向かうべき方向性を解像度高く捉え続けるようにしようというのを理想の状態としています。そのため、プロダクトマネジメントはPdMだけに任せるのではなく、自分たちも腹落ちさせるための動きをしますし、場合によってはその役割を担うこともある、というような形で動いています。
konifar氏：EMが見る範囲を限定しているというのは、逆にエンジニア組織の全体設計は誰が担っているのでしょうか。
あらたま氏：全体設計は事業部のVPoEが担当しています。ただ、チームにメンバーが充足しているかどうかなどの判断はEMに委ねられている部分が大きいです。
そもそもチームを少人数で運営しているのは、EMにコーディングなどの開発業務を任せたいという意図ではなく、プロダクトが増えていく中でも、迅速にプロダクトに関する意思決定ができるような体制を維持したいという意図があります。そのため、マネージャーを各チームに配置することでそれを担保しようという考えです。
konifar氏：なるほど。Kyashでは最初、EMを置いていませんでした。2017年頃に私が入社してしばらく経った頃は、人が次々と辞めていく時期がありました。その翌年から、これはピープルマネジメントなどの組織課題にきちんと向き合わないといけないと思い、EMだけでなく初めてマネージャーを置こうという流れになり、ピープルマネジメントの移譲が始まって行ったのがきっかけです。
現在は、私の他にモバイルとサーバーサイドにEMを1名ずつ配置し、マネジメントを移譲しています。というのも自分が全てを見るより、その分野に詳しい人に任せ、マネージャーという役割をちょっとずつ分担するようにしています。極端な話、「ティール組織」のようなやり方もあるかと思いますが、結局認知負荷が高くなりすぎたり、ワークしないような気がしていて。今のやり方であれば、ボールが落ちそうな航路を守っていくみたいな役割が生まれやすい組織体制になっているため、続けています。
あらたま氏：ありがとうございます。答えにくいかもしれませんが、EMに対してどのような期待をセットでお渡しするようにしていますか？
konifar氏：何名かの方にEMをお願いしてきた時は、30分程度の1on1で伝えるためのテンプレートを用意していて、そこに期待値を合わせて伝えるようにしていました。
今お願いしているEMの2名に関しては、例えばモバイルの方であればモバイルチームでは今こういう課題があって、ここを解決してほしいという具体的な課題ベースの話を書いて、短期的にはこれを解決してほしく、その後でどういう組織にするかなどは考えてほしい、みたいな感じでお願いするようにしています。その際に、今までやってきてくれたことをベースにあなたならこういう部分がその解決に生きるんじゃないかという伝え方をしたりします。
あらたま氏：なるほど。具体的な課題や役割もセットで伝えていたという感じなんですね。
konifar氏：短期的な解決に関してはそうですね。中期的には丸投げに近いと思います。自分自身も答えがないというか。
あらたま氏：そうですね。そこを一緒に考えるのを手伝ってほしい、それをEMに期待しますよっていうのがお伝えの仕方かなと思いました。
konifar氏：まさしくそうですね。あるべき役割でいうと、あるべき役割を決めていくことがあるべき役割という考え方もあります。
――「EMがコードを書く時間がないや、意思決定の時間が取れないなどの印象がありますが、その辺りの時間配分などは役割によって変わっていくのでしょうか？」と質問が来ていますが、お二人はいかがでしょうか。
あらたま氏：バクラク事業部においてEMが期待されていることは、自分がどのくらいコードを書くのかという配分を自分で決めてくださいというイメージです。
少し冷たい印象を持つかもしれませんが、そこも含めて裁量を与えてもらっていると理解しています。また、そのようにしているのはチームによってフェーズが異なるという側面もあります。
例えば、チームの中には大所帯の組織もあります。私たちは「バクラク申請」「バクラク経費精算」というサービスを作っているチームに所属していますが、プロダクトはアプリとwebどちらもあります。そのため、大所帯のチームではどのくらいEMがコードを書くべきなんだっけ。というのは、色々と試行錯誤しながら、今はできるだけ手放したほうがいいのかも、みたいなことを言っていたりしますね。
なので、質問への回答としては、やるべきだと判断するのであればそれが捻出できるようなコミュニケーションを各所と取れていればいいのではないでしょうか。
――konifarさんはいかがでしょうか。
konifar氏：とてもいい質問で、実際に私も困っているかもしれません。私は今でもかなりコードを書いています。というのも、短期的に見た時に、コストの最適化や事業上のインパクトの大きいものを一気に着手したほうがいいというタイミングが続いていて、そんな中で自分は、AndroidもiOSもサーバーも平均的に書けるため、一気に対応しちゃおうということをこれまで何度か繰り返してきました。
ですがご質問の通り、プロダクト全体の技術的負債の解消やマネジメント、全体の設計、戦略というところにあまり時間を使えていないという状況です。何度か繰り返していて、その度にやっぱり良くなかった、でもあの時は必要だったみたいなことを繰り返しています。
ただその中で一つやってて良かったと思うのは今から自分は行動期間に入る、もしくは自分はもう書かない、みたいなことを周囲に宣言するようにしていたことですね。その際に、あの時はこう考えてたというのはログにも残しつつ、周知するようにしていました。
あらたま氏：ログやスナップショットに残し続けるのは素晴らしいですね。なかなか意識しないとできないことですし、結果だけ見てしまうと、例えばそれがコードの集中期間だとしたら、konifarさん全然自分たちを見てくれない！となり、メンバーとの期待の掛け違いを防げているのはとてもいいことだなと思いました。
――事業インパクトを重視して意思決定をしているのでしょうか。その辺りの意思決定のファクターになるものはありますか？
konifar氏：個人の能力だけ見た時に、自分がコードを書いたほうが早いとは思っていません。特に、SREやサーバーなどの領域ではそうですね。ただ、限られた人数の中でやりたいことが多く、色々と削ってみたりしていますが、どうしてもこれ以上ガチャガチャ動かしたくないからえいやでやってしまおう、みたいな形で動いたりしています。ただ、これが良いかどうかというのは常に苦悩があるところです。
あらたま氏：平時なら3人連れてくるところを、konifarさん1人で賄うことで、人の調整にかかるコストと3人を集めてやる時のコミュニケーションコストが意思決定の裏にあったものなのかなと思いながら聞いていました。
konifar氏：綺麗にまとめていただきありがとうございます。
