EMの役割、成果、キャリアの正解って?
現職EMたちのリアルやるべきことの多さに比例して、悩みも増えがちなEM。にも関わらず、参考になる打ち手やお手本になるロールモデルがまだまだ少ないのが現状だ。そこで本特集では、複数名の現職EMにインタビュー。所属する開発組織の規模や成長フェーズ、扱うプロダクトによって、その役割も千差万別な現職EMのリアルを紹介。EMはどんな役割を担い、どのように成果を出しているのか。また、'EMその後”のキャリアをどう見据えているのか。そんな実態に迫ってみた。
EMの役割、成果、キャリアの正解って?
現職EMたちのリアルやるべきことの多さに比例して、悩みも増えがちなEM。にも関わらず、参考になる打ち手やお手本になるロールモデルがまだまだ少ないのが現状だ。そこで本特集では、複数名の現職EMにインタビュー。所属する開発組織の規模や成長フェーズ、扱うプロダクトによって、その役割も千差万別な現職EMのリアルを紹介。EMはどんな役割を担い、どのように成果を出しているのか。また、'EMその後”のキャリアをどう見据えているのか。そんな実態に迫ってみた。
「ものづくりがしたかった」「コードを書くのが好きだった」…そんな志望理由からエンジニアになる人が多いだけに、マネジメント志向を持つエンジニアというのは案外少ない。
そんな中、「自分のマネジメント力が他の会社でも通用するのかチャレンジしたかった」とエンジニアリングマネージャー(以下、EM)から別企業のEMへ転職し、自身のマネジメント力の向上を図っている人がいる。
それが、note株式会社でEMをしている海野 拓さんだ。前職で約4年、noteに来てからは約1年EMを経験している海野さん。果たして前職で築いたEM経験は新しい環境でも通用したのか。通用しなかった部分があるとすれば、それは何だったのか。EM歴6年目に突入する海野さんに話を聞いた。
note株式会社
エンジニアリングマネージャー
海野 拓さん(@boscoworks)
2008年にヤフー株式会社に入社し、バックエンド開発に従事した後、12年に株式会社ドワンゴに転職しログ分析基盤システムのテクニカルリードを務める。14年に株式会社リブセンスに入社し、エンジニアからEMにキャリアチェンジ。22年7月にnote株式会社にEMとして入社し、現在に至る
ーーまずはじめに、noteの開発組織の構成を教えてください。
noteには50名のエンジニアが在籍していて、ミッションごとに二つの組織に分かれています。一つはnoteのプロダクト成長を担う施策の設計・実装などを行う組織。
もう一つはnoteのシステム全体を支える基盤開発の組織で、私がEMを務めています。
ーーその中でEMはどのような役割を担っているのでしょう?
役割としては大きく三つあります。一つは組織のマネージャーや経営層と連携した、エンジ
ニアが生産性高く事業成長にコミットするための組織作りです。
具体的には、エンジニアが開発に専念できる環境にするため、エンジニア組織のリーダーから要望を伺いながら組織のマネージャーと施策を検討して遂行します。
また、「新たな技術に触れたい」などのエンジニアの希望をかなえる異動や、チーム編成の変更をよりスムーズに実現するための組織デザインを行っています。
二つめはエンジニア組織が目標を達成するためのサポートです。エンジニアメンバーとの目標設定や評価はエンジニア組織のリーダーが担当しているので、EMはそのサポートを担っています。
エンジニアがパフォーマンスを発揮するために何が足りないか、評価をあげるためにどんな努力が必要かを言語化するサポートも行っています。
三つ目は人事と連携した組織課題の解決です。課題が人員不足であれば採用活動のリードや運用などを行います。
また、noteはフルリモートで業務を行っているため、入社したエンジニアがスムーズに業務に入れるよう、1on1を行って後方支援をしています。
ーーEMの成果はどのように測るのでしょう?
エンジニア採用など定量的に測れる場合は、数値目標を置くこともあります。ただ、組織課題の解決は「状態の変化」を目標としているので、EMとしていかに変化を起こしたか、影響の度合いなどを評価対象にしてもらっています。
定性的な面が強いので、上長であるCTOといかに納得感をもって合意形成をするかが重要だと考えています。
ーーピープルマネジメント寄りの業務割合が多いのですね。
そうですね。ただ、まさに今解消に向けて動いている課題としてはテクニカル領域の業務になります。
具体的には、リリース業務に時間がかかっている状態の改善です。
ありがたいことにユーザーが順調に増加しており、プロダクトをリリースした2014年当時と比べると機能もかなり増えました。ユーザーの数の増加によりサーバー負荷も増したため、その分散を処理するためアーキテクチャも複雑化。
ユニットテストにも時間を要してしまう現状を解消すべく、バックエンド技術に特化したチームがアーキテクチャの変更に取り組んでいます。過渡期である今は、EMも定期リリースを持ち回りで担当しています。
また、noteを利用しているユーザーからの問い合わせ業務もエンジニアが行っていたのですが、ユーザーが増え、負荷も増大しているので一次窓口を別で設けることに。カスタマーサポートチームを挟む体制を提案し、今年の秋から冬には実現できるよう動いています。
ーーそうした組織課題や「次に取り組むべきこと」はどのように見つけるのでしょう?
エンジニアと日々対話しながら「ここが課題なのではないか」という事象をキャッチアップし、その課題について組織マネージャーと相談しながら、仮説を立てて解決に向けて進めています。
私は22年7月に入社したのですが、最初の約2か月はさまざまなエンジニアに1on1をお願いし、ひたすらヒアリングしました。
どんな仕事をしているのか、どんな事に困っているのか。組織や会社に対してどんな課題意識があるのか。HRや他部門も含めると60人ほどと話しました。
ーー海野さんは前職でもEMをされていました。EMとして別企業へ転職した理由は何だったのでしょうか?
前職はHR系のプロダクトを扱う企業に7年半勤めていて、後半の4年でEMを経験しました。
長く勤めていたこともあり、プロダクトへの理解はもちろん、社内の従業員の人となりも十分分かるようになっていました。すると徐々に「自分はこの会社でしかEMをできないのではないか」という思いが募るようになってきた。
他の会社でもEMとして組織課題を解決できるか試してみたいと考えるようになり、転職を決意しました。
ーーnoteに来て1年がたちました。前職からのEM経験が生きた部分とそうでない部分はありましたか?
エンジニア採用やエンジニア組織の生産性改善は、会社が違っても(どのエンジニア組織でも)本質的な課題は同じです。取るべきアプローチはあまり変わらないので、前職までに築いた経験が生きていると感じますね。
逆に難しいのは、開発そのものに携わらない立場で、精度高く組織課題を見つけていくことです。
大前提、開発組織の課題を見つけるにはエンジニアとの協力が欠かせません。私の場合、noteに入社した時点で即EMに就いたので、noteでは開発実務に携わった期間がないわけです。
いちメンバーとして仲間と切磋琢磨しながら関係性を積み上げた上でEMになった前職とは異なり、「はじめまして」の状態からマネジメントを担う立場に。
前職の経験は横スライドできませんから、時間をかけて信頼関係を築いていく覚悟みたいなものが求められるなと感じています。
ーーエンジニアと信頼を築くために取り組んだことはありますか?
noteに限らず、目標設定や評価に悩むエンジニアは多いですよね。評価を受け止められなかったり、どうアピールしていいかわからなかったりするケースが多いので、そのサポートには力を入れています。
また、『エンジニアリングマネージャーのしごと』という本を題材に、読書会を開催したことも。輪読形式で本を読み、参加したエンジニアからの疑問や質問にも答えながら、私ともう一人のEMが普段考えていることにも触れるように意識しました。
読書会をきっかけにエンジニアとコミュニケーションを取る機会を増やしながら、EMの仕事を理解してもらう場にもしたかったんです。
「EMはこういうことをやろうとしていたのか」と少しでも理解してもらえると、お互いに仕事がしやすくなりますからね。
ーーEMとして、やりがいを感じるのはどんな時でしょうか?
エンジニア一人ひとりが抱えている課題を伴走し、支援する中でエンジニアが納得感をもって選択をできた時です。
例えば、プロジェクトへの自分の関わり方、リーダーがメンバーとどう接してチーム運営をしたらいいか。エンジニアのメンバーやリーダー、PMそれぞれと対話しながら、よりよい選択肢を一緒に考えています。
ーーさまざまな立場の人の意見が食い違うときもあると思いますが、どのように解決策を導いていますか?
前職の上司から学んだ「自分より二つ上の上長の視点をもつ」という考え方を大事にしています。
当事者そのものに焦点を合わせると問題がミクロになりすぎてしまいます。一つ上の視点でも全体を俯瞰しているとは言えない。だから、さらに上の視点で見るのです。
そうすることで一人の悩みとしてではなく組織課題として本質的に見定めることができる。俯瞰するからこそ、全員が納得できるような解決策にたどり着くことができるのです。
私自身もこの視点を大事にしていて、メンバーにも「二つ上の上司ならどう考えると思いますか?」とよく問いかけています。
ーー海野さん自身は、今後どのようなキャリアパスを描いていますか?
私はプロダクトや技術よりも、エンジニアや組織が抱えている課題の解消に関心があるタイプなので、エンジニアの成長にコミットしていきたいです。
私が介在することで、エンジニアが成長し、より大きなプロダクトを育てられるようになるサイクルを実現することが理想です。その延長線上で考えると、さらに高い視点で組織課題を解決するVPoEや、経営視点で物事を考える経験を積むことも良い選択肢の一つだと思っています。
CTOと話していると「自分もそう思っていた」という時もあれば、考えが及ばなかった回答をもらうこともあるので、自分にはない要素や考え方を積極的にインストールしながら成長していけたらと思っています。
文/久保佳那 写真/note提供 編集/玉城智子(編集部)
NEW!
NEW!
タグ