エンジニアリングマネージャーとしてどんなことをしているのか？

はじめに
エンジニアリングマネージャーとは?
メンバーのサポート・育成・評価
開発
- プロダクトマネジメント
- エンジニアリングのリーダーシップ
採用・採用広報・アドバイザーの招聘
終わりに

はじめに

今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。

私はRetty株式会社でtoC Web開発/toB Web開発両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が経ちました。

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

いろんな議論・定義がありますが、Engineering Managerは何をする人なのかが網羅されていると思います。個人的には「エンジニアリングのマネジメント」であり、開発で生じる様々な問題を監督し、組織が期待する開発力を用意することが一番の役割だと考えています。開発力は分解すると"プロダクトを生み出す力"、"デリバリーのスピード"、"プロダクト品質"など様々な側面があると思いますが、その時々で組織の弱いところを補うように動かざるをえないことが多い結果、各社・各自でエンジニアリングマネージャーの役割の差が生じているのかと考えます。

いくつかの軸でまとめるにあたりラクスルVPoEの高橋さんがまとめた下記資料を思い出しました。この中でも"やってるもの"と、"やってないもの"と、"書かれてないけどやっているもの"があり、本当に領域が広いのだなと改めて感じました。

メンバーのサポート・育成・評価

メンバーの状態観察

週1回〜隔週1回のペースで1on1を1回30分行っています。社内の他部門や他社の話を伺うに、開催頻度は多いようです。結構な時間が1on1で割かれてしまいますが、問題の芽が小さいうちに拾えることが多く、実施は大変ですがこのペースでやっています。

1on1は相手のための時間とし、何を話すかは基本相手に委ねています。入社以来使っている1on1テンプレートには先頭に目的が記載してあり、短くまとまっていてとても気に入っています。

[1on1について]
- 1on1される側のための時間であって、進捗確認や伝達命令のためのものではない
- 問題解決ではなく、課題発見をするためのもの
    - 解決は自分で考えて自主的に行っていってほしいです
    - 解決のための相談、アドバイス等の協力は積極的に行います
- お互いの期待値のすり合わせとFBの場

[Topics テンプレート]
- 目標達成の上でもやもやしていること、困っていること
- 業務上での気付き(前回から今回までで学んだこと、うまくいったこと、いかなかったこと)
- チームがもっと良くなるためのアイデア、改善点
- MGR/EM/ボードメンバーへのリクエスト
- プライベートについて(家族や自分の病気、イベントなど仕事に影響があることがあれば。結婚、出産、介護等)
- 将来のキャリアについて(変更や悩みがあれば)

目標設定・人事評価

会社の仕組みとして「3ヶ月単位で目標を建て、評価を行うMBO(Management By Objectives)」を採用しているため、それを実施しています。

プロダクト開発はスクラムで進めていますが、"チームで開発する"・"優先順位に従って開発する”・"やることは適宜見直す"というスクラムの性質から、やりきり目標や個人ごとの開発項目を建てると都度見直しが発生して運用が大変です。そこで組織目標・個人目標・個人課題に分けて設定しています。

組織目標(部門目標)
- 複数チームで共通
- 3ヶ月毎に見直す、大きくは変わらない
個人目標
- 全員ほぼ共通、公開する
- 3ヶ月毎に見直す、あまり変わらない
個人課題
- 個人ごとに固有、非公開
- 業務グレードが変わらない限り変わらない

目標の難易度設定が難しかったり、評価の時期と成果が出る時期がずれたり、評価の時期は毎回悩み事が発生しますが、マネージャーとして重要な職務だと考えて丁寧に説明することを心がけています。

評価の話は2020年のスクラムフェス大阪でも話をしました。

dev.classmethod.jp

後進の育成

新卒1〜3年目くらいのジュニアエンジニアは1on1を通じて成長を阻害している要因を突き止め、アドバイスをしています。成長曲線や壁を乗り越えるタイミングは人によって異なるため、取り組み姿勢が間違っていなければ焦らず目の前のタスクに取り組むよう話すことが多いです。

中堅・シニアエンジニアになると、複数の人を巻き込んで大きい成果を出してもらいたいことが増えるため、大きな開発の取りまとめや推進役をお願いしたり、ジュニアエンジニアのメンターを依頼したりします。役割の数がどうしても少ないため、機会提供が偏ることが無いよう、乗り換えられそうなちょうど良い難易度になるよう、3ヶ月〜半年ぐらい前から考えることが多いです。

マネージャーの育成は最も時間がかかります。開発とマネジメントは求められるスキルや振る舞いが異なるため、開発タスクを減らし、マネージャーとしての振る舞いを考え・学ぶための余裕を意図的に作ってあげる必要があります。自分が抱えている問題を移譲して代わりに解決に取り組んでもらったり、実際に起きてしまった問題を題材として「今から戻ってやり直せるならどうしたら良いか」を議論するなど、時間をかけて考え方やアプローチを伝えています。

日常の労務管理

いわゆる勤怠管理ですが、忙しさの山や谷を作らず、一定のペースで働けるように業務量を気をつけて見ています。より具体的には残業が常態化していないか、残業が一時的に増えた場合はそれが開発の山場として妥当なものかをチェックしています。

開発

プロダクトマネジメント

企画に責任を持つプロダクト部門が別途あり、施策や方針決めは基本委ねています。アイデアや機能提案をすることはありますが、それよりも技術負債やセキュリティ問題などエンジニアでないと判断がつかないものについて開発優先順位の強めの提言をすることが多いです。

開発タスクを分解したり、メンバーにアサインすることは基本していません。プロダクトオーナーにより優先順位で並べられたプロダクトバックログを、開発チームが毎週開発できると考える分だけとっていきます。自分は四半期・半年・2〜3年といったスパンで、"何をやっていきたいか"を社内のいろいろな立場の人から聞き、どう実現していくのが良さそうかを考えることが多いです。

エンジニアリングのリーダーシップ

機能追加や不具合修正関して、プロダクトコードを直接書くことはしていません。技術採用や開発方針の決定、細かな設計も開発チームに委ねています。

開発への関与としては、チームが将来取り組むであろうふわっとした課題を先に調査しておくことを手が空いた時にしています。また現場では決められないような「決めの問題」が生じた時に、開発責任者として意思決定したりしますが極めて稀です。障害・インシデントが発生したときはその影響範囲の大きさによって、対応の陣頭指揮をとったりします。

開発を広く見てはいますが、自身の役割は技術でプロダクトを引っ張ることを期待されるテックリードとは異なるもので、エンジニアリングマネージャーのキャリアの先にCTOがあるとも考えていません。

採用・採用広報・アドバイザーの招聘

上位の目的としては「今の開発体制で足りない人を連れてくる」だと考えています。

採用

採用チームと定例を持ちながら、採用活動に広く協力をしています。スカウトのフィルタリング、スカウト文面の送信、カジュアル面談の実施、コーディング試験の評価、技術面接など。

またインターンコンテンツを考えたり、採用イベントを準備したりします。ここ半年だと下記のイベントに携わりました。

採用広報

勉強会の開催、カンファレンス登壇、テックブログ執筆などの活動です。自分自身の知名度を上げキャリア形成をやりやすくする目的もありますが、組織としても採用活動に遅れて効果が出てくると考えています。直近だとスクラムフェス三河に会社から5件のプロポーザルをだし全て通過、Go Conference Autumnに会社から7件のプロポーザルを出すことができました。ノルマや金銭的なメリットを設定しているわけではないため、普段の業務で学んだことを対外的にアウトプットし、学びにつなげるメリットを広く組織に浸透できているのだと思っています。

また定期的に対外アウトプットをしておくと、一定期間の自分の活動をまとめるきっかけになるだけでなく、「口だけにならない」と言う自分への戒めにもなるなと感じています。

アドバイザーの招聘

自分が詳しくなく組織としても弱い領域、自分ができるけど手が回らない領域で外部の識者の方にアドバイザー・相談役をお願いしています。どの方にも豊富な経験に基づいた適切なアドバイスをいただけており、組織として悩む時間を減らせたり、自信を持って取り組む後押しになっています。

社内勉強会での講演や、単発のワークショップももっとやっていけたらなと思っているのですが、開発の状況・予算・開催タイミングなどあり、声はかけながらも開催にいたってないものがいくつもあります。これは私の力不足が大きく、ただ申し訳ないです。

他社との情報交換

エンジニアリングマネージャーとしての打ち手は組織や置かれた状況のコンテキストによって効果があるものもないものもあり、引き出しを増やすことが大事だと考えています。なので他社の方から相談をいただいた場合は基本的に引き受け、積極的に自分たちの経験を共有しています。相談を持ち込んだ側は同じ問題で時間を取られることなく、壁を乗り越えた先にあった新しい問題も次回に共有してくれるためどの会社とも学びのある情報交換をさせていただいております。

他にも「自社で起きている問題が一般的なのか、自社固有の問題なのかを切り分ける判断材料になる」「他社の相談を先に受けておくことで、自社で別の相談が出てきた時に相談しやすい」というメリットもあります。

終わりに

会社から与えられた仕事や目標はあるようであまりありません。会社やプロダクトの様子を見ながら社内を広く見渡し、自分で考えて作っています。直接的な仕事はなく、自分が居なくても開発業務は回ると考えています。 1週間居なくても全く問題ないでしょう。事前に準備しておけば1ヶ月居なくても多分大丈夫だと思います。ただし3ヶ月居なくなると開発でうまくいかないことが増えてきたとメンバーが感じることが増えるのではないかなと思っています。エンジニアリングマネージャーとしての貢献はこれぐらい長期で効いてくると考えています。

大変なことが多い、直接的な達成感も得にくいエンジニアリングマネージャーですが、下記が面白さかと考えています。

プロダクトの成長 : なんだかんだ方向性に関与できる裁量が大きい。
組織の成長 : 同じメンバーでも雰囲気や成果は異なる。
メンバーの成長 : 突然殻を破るような成長を身近で見れるのは嬉しい。

この記事を読んでもっと聞いてみたいと思った方、ディスカッションしたいと思った方、Rettyのエンジニアリングマネージャー職に興味が沸いた方は是非Meetyでお話ししましょう。

meety.net

tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録