20人のEMと話して見えてきた、エンジニアリングマネージャーの共通点と相違点
MIDAS Technology Reviewでは、主にエンジニアをマネジメントしている方を対象に、実践的なエンジニア組織マネジメントの事例を発信しています。
今回は、ミダスキャピタルの投資先企業である株式会社GENDAのVPoE 荒井勇輔氏（以下、荒井）と、以前から親交のある株式会社レアジョブのサービス開発部部長 羽田健太郎氏（以下、羽田）をお招きし、対談を通してEngineering Manager（以下、EM）のリアルな実態を探っていきます。
自己紹介をお願いします。
羽田：株式会社レアジョブ サービス開発部部長の羽田です。EMとして、開発だけでなく、デザインやUXを含めた全体のプロダクト体験の責任者をしています。デザイナー、フロントエンドエンジニア、アプリエンジニア、サーバーサイドエンジニアのマネジメントも行っています。
アプリエンジニアをメインとしつつ、徐々に取り組む範囲が広がっていきました。そのような役割の変化を経て、現在はEM・部長という立場でレアジョブで働いています。
これまで、プレイヤーやプレイングマネージャーの期間が長かったこともあり、現場の課題にメンバーと一緒に取り組んだり、時には任せたりしながら皆で課題解決に取り組むことを大事にしています。
荒井：株式会社GENDA VPoEの荒井です。GENDAでエンジニア組織の立ち上げに1から取り組んでいるところです。
私のキャリアは、新卒でヤフーにエンジニアとして入社したところから始まりました。そこでは、チームの人数が少なかったこともあり、PHPでサーバーサイドのコードを書いたり、JavaScriptを書いたり、DB構築やインフラ領域を担当するなど、全方位で仕事をしていました。
その後、株式会社VASILYに転職し、主にiOSアプリの開発を担当しました。その頃に勉強会で知り合ったのが、今回の対談相手の羽田さんです。
会社が大きくなるにつれて、事業部長という立場になり、マネジメントのキャリアを歩み始めました。株式会社VASILYが株式会社スタートトゥデイ（現 株式会社ZOZO）にM&Aされ、そこでテックリードを経験しました。在籍期間の後半は、iOSチームのリーダーとして主にマネジメントを行っていました。
大企業とスタートアップの両方を経験し、会社の規模や上司・チームメンバーとの関係によって、活躍できる人とそうでない人がいる状況を見てきました。そのため、どうマネジメントすれば、チームメンバー全員が活躍できる状態になるのか、そこに興味を持って取り組んできました。
羽田さんは最近20名近くのEMの方とお話をされたと伺いました。きっかけは何だったのでしょうか。
羽田：きっかけは、Meetyでカジュアル面談が流行っていたこと。そして、ちょうど時期的に下期が始まる頃だったので、ディスカッションを通して今取り組んでいる課題の有効な手立てを探したり、自身のやり方を振り返りたいと思ったからです。
「EM」は比較的新しい概念であり、自分自身でも手探りな状態です。他のEMはどういうところで悩んでいるのか、何が共通していて何が共通していないのか、そういったことに興味があり、お話を伺っていました。
共通していた点、共通していなかった点は見つかりましたか。
羽田：共通していた点は、「ピープルマネジメントは大変だが、効果がある」と多くの人が認識していたことです。一方、共通していなかった点は、EMの定義（会社からの期待値、個人の解釈、やり方など）でした。EMは、比較的大きな裁量を持つ場合が多いため、皆さんがそれぞれ自由度の高いアクションを取っていたことが分かりました。
共通点として挙がった「ピープルマネジメントは大変な反面、効果はある」という話題。ご自身の経験や取り組んでいることを教えてください。
羽田：「すべてを解決するような銀の弾丸はなく、当たり前のことをコツコツ続けていくことが大事である」と考えています。この考えも、多くのEMに共通していました。
しかし、その「当たり前」と考えている内容に違いがあった点は興味深い発見でした。個人的には、1on1は非常に効果的で重要だと考えており、誰でも当たり前に行う施策だと思っていました。ところが、中には「1on1はしない」という意見の人もいました。また、以前に読んだ「リーダーの仮面」という書籍の中でも、1on1に対する考え方が私とは逆の立場でした。このように、人によって色々な意見があることを知っておくことも重要です。
私は、1on1によりメンバーのパフォーマンスの最大化を狙いながらも、全体最適を意識したプロジェクトアサインが可能だと考えているため実施しています。1on1を通し、その人が業務をどう捉えているのかを知ることができます。また業務外のことを知ることもでき、その人の関心事も見えてきます。その結果、どのような時にパフォーマンスが上下するのかが分かってきます。私は、そのようなことを1on1を通して感じ取り、それを踏まえた上でアサインをするようにしています。しかし、最近はメンバーの増加もあり、また新たなやり方が求められていると感じています。
荒井：私もピープルマネジメントは非常に重要だと捉えており、1on1を積極的に活用しています。EMはメンバーやチームのアウトプットを最大化することを求められます。そのため、目標設定と評価・フィードバックに1on1を組み合わせて実施しています。
目標設定と評価に関して、よく発生する問題があります。それは、目標を決めるタイミングでは密にコミュニケーションを取るものの、期中になると目標に関するコミュニケーションがなくなり、期末になって急に目標を達成できたかどうかを評価することになる状況です。もし、メンバーが目標に対して未達成だった場合、チームやメンバーのアウトプットを最大化できなかったという面では、EMの責任であると言えます。そのため、期中にも1on1で目標に関する会話を実施し、その中で達成状況の確認や相談をしながら、目標達成に向けたチャレンジをサポートしています。仮に、目標を最終的に十分に達成できなかった場合でも、期中から常に話していることもあり、「来期はこうしていこう」といった未来に向かった前向きな話し合いができます。また、結果として悪い評価であったとしても、常に話し合ってきた過程があるので、結果を受け入れやすくもなります。
EMは「目標達成をチェックする役割」ではなく、「目標達成に向けて伴走する役割」ということですね。荒井さんも、目標には直接関係のない業務以外の話題も1on1で扱いますか。
荒井：はい、業務外の話もしています。ただし、そのような話題は、目標に関する1on1とは完全に分けた形で実施しています。そちらの1on1では、業務外の日常生活のことや会社に対して思うこと、キャリアのことなどを話しています。目標に関する1on1と分けているとはいえ、ここで話した内容が目標設定に繋がることも少なくありません。
エンジニアの目標設定でよくあるのが「〇〇機能を✕✕までにリリースする」といったものです。もちろん、会社や組織の目標に沿うことも大事なのですが、「機能を開発してリリースする」ことだけに目が向くのも健全ではありません。なによりも、個人の「will」や「want to」と、チームへの貢献を結びつけた目標設定にすることが重要です。例えば、技術的負債が溜まっていることに危機感を持っていて、システムの安定化のためにもリファクタリングをしたいと考えている人、本人のキャリア像に沿って勉強会への登壇にチャレンジしたい人、など様々なメンバーがいます。EMは、それらの個人の目標達成の支援をしながら、チーム全体をどのような状態にしていきたいかを考え、それをメンバーに浸透させていくことも重要です。
1on1の頻度はどのくらいに設定していますか。
荒井：基本的には1ヶ月に2回、先ほど述べた2種類の1on1を隔週で実施しています。また、入社したばかりのメンバーとは、最初の2週間は毎日実施しています。それ以降は、1日おきに実施し、2ヶ月目からは週に1度の頻度で実施しています。入社当初は特に気付きも多い時期です。業務を遂行する上で生じる「やりにくさ」にも敏感に気付けるので、そこで共有される内容は貴重なものです。
羽田：私の場合は、月に1回の頻度です。雑談メインで、基本的にはメンバーが話したいことを話す時間としています。トピックがないようであれば、事業の方向性について話したり、ヒアリングをしながら、伝えきれていない情報があると感じたら、それを補足するようにしています。
「1on1を効果的に実施することは難しい」といった声もよく耳にします。何か1on1を効果的にするために、工夫している点はありますか。
羽田：メンバーから話したい話題がなかった場合に備え、こちらから話すことを列挙したリストを事前に準備しています。また、1on1の終了後には、メンバーに議事録を共有しています。1on1の中で、「次はこういったことにチャレンジしよう」といった話も出てきます。そのため、マネージャーとのコミットメントとして、お互いの認識を合わせるためにも記録しています。議事録があれば、1on1実施時に前回の振り返りにも使えます。
荒井：羽田さんと同様に、1on1の時間はメンバーの時間であって、マネージャーがタスク進捗やプロジェクト状況をキャッチアップする情報収集の時間ではない、ということを意識しています。本来であれば、それらは常に可視化されているべきで、1on1を介さずとも把握できているべきです。その上で、1on1は日常では表に出てこない内容を扱うのがおすすめです。例えば、人間関係、キャリア、健康やメンタル面を意識的に聞いています。
また、マネージャーが一方的に話している状態になっていないか、という点にも気を付けましょう。問いを投げかけても相手が沈黙していたり、答えに窮している姿を見ると、つい自分の意見を出してしまいがちです。書籍にも「30秒の沈黙に耐えましょう」と書かれていたりしますが、それを実施することは最初はかなり難しいです。実際に測ってみると、30秒の沈黙はかなり長いと感じるでしょう。
羽田：マネージャーが喋り過ぎないように、というのは同感です。しかし、実際には結構喋ってしまうんですよね。特に久々に話しをするメンバーだと、つい嬉しくなってしまって。
荒井：分かります、「耐える」を意識し続けています。それでも、耐えた結果「思いつかないですね」という返答がくることもあります。例えば、「何か今困っていることある？」という聞き方をした時に、そのような返答がきた場合、本当に何もなければ健全なことなので良いのですが、「とりあえず無難に答えておこう」という結果かもしれません。その際に、問いかけを変えて「わがまま言うとしたら何がある？」と聞いたら、本人が困っている内容を聞き出せました。
このように、「問いかけの仕方を変える」ことを工夫しています。また、レアケースかもしれませんが、メンバーが相談した内容を、マネージャーがすべて解決したり行動したりし続けてしまうと、マネージャーに対する期待値が上がったり、依存する癖が付いてしまいます。その結果、「何でも解決してくれる、あの人がマネージャーじゃないと嫌だ」という状況になってしまうのは問題です。
羽田：そうですね、その状況になると「メンバーの課題解決力が上がっていかない」という別の課題にも発展すると思います。エンジニア出身のEMの場合、メンバーが相談してきた現場での課題を、マネージャー自身で解決できるケースが多いのではないでしょうか。しかし、そこでマネージャーが解決してしまうと、メンバーからしたら再現性がなくなってしまいます。EMは基本的には支援する側であるべきです。メンバーが課題と認識しているものが「本当に課題なのか」を深堀る手伝いはするものの、実際に行動するのはメンバー本人とするのが良いでしょう。
会社からの期待値、個人の解釈、やり方などの「EMの定義」について、どうお考えでしょうか。
羽田：会社によって、EMに期待されている役割や実際の責務は大きく違っていると思います。会社のフェーズ、組織の状態などによっても期待値は変わってくるため、人によって千差万別でした。そもそも、軽いフットワークで立ち回ることが期待されているポジションでもあります。私の場合、ピープルマネジメントや採用に注力する時期もあれば、大きなプロジェクトの初期段階ではメンバーと一緒にアーキテクチャ設計を行ったり、時期によっても異なっていました。お話を聞けた皆さんも、あまり役割を決め過ぎず、広く立ち回っている様子でした。
私は、どんな問題にも向き合い、周りを巻き込んで解決できるような、「問題解決ブルドーザー」のような人になりたいと思っています。そのため、日々発生するいろいろな方面の課題の中で、やる人がいないものがあれば、自ら引き受けて取り組むというスタンスでいます。そして、常に解決する手段を各方面の人と一緒に考えられる人でいたいと思っています。そのような立ち振舞は、EMらしい振る舞いと言えると考えています。
荒井：「問題解決ブルドーザー」、良いですね。EMは、やることを決め過ぎず、広く立ち回っているのが実態でしょう。一方で、それをEMのジョブディスクリプションに書いておくことも大事です。会社には、EMに限らず、リーダーやテックリードなど、いろいろな役職があります。ところが、新しく任命された人は、最初はどうすれば良いのか悩んでしまうケースが多いと感じています。というのも、「役職」は与えられるのですが、「役割の説明」がないんですよね。
羽田：確かに、説明されたことはないですね。
荒井：「役割をある程度決めて伝えること」が重要かと考えています。EMの場合であっても、同様です。結果的に「あらゆることをやる役割である」となったとしても、それを伝えることが大切です。
羽田：そうですね。一方で、EMは最近は注目されてきましたが、まだまだ新しい概念でもあります。EMというポジションを配置している会社は、そのタイムラインの中でできた新しい会社や、組織の体制を変えるタイミングで導入した会社に限られている印象があります。実は、弊社も10年以上の歴史があり、組織構造が全社に合わせたものになっているので、現時点では「EM」というポジション自体は配置していません。ただ、自分が担っている役割が、一般的に言われている「EM」なので、EMと名乗っています。EMの方々と話していても、管理職でなくても、プロジェクトにおける役割としてEMを名乗っている人もいましたし、管理職でエンジニアをマネジメントする立場でもあるからEMと名乗っている人もいました。会社に明確なEMポジションがなくても、担っている役割が該当するのであれば、EMと名乗って良いのではないでしょうか。
荒井：私も、前職では会社にEMというポジションはなかったので、自ら名乗っていました。
EMの理想的な姿はどのようなものでしょうか。
荒井：EMは、5W1Hの、Who（誰が）とWhy（なぜ）にフォーカスできると良いでしょう。「Who」は、どんな陣形で臨むのか考えます。「Why」に関しては、多くの人が「なぜそうするのか」は考えますが、EMはその先の「最終的にメンバーへの説明責任を負う」ところに注力すべきです。一方、How（どのように）やWhen（いつ）はテックリードを中心としたエンジニアメンバーが決めていくのが良いです。そして、そのような役割分担が明確になされたチームをEMが運営していくこと、これが1つの理想の姿ではないでしょうか。
羽田：私は、ソフトウェア開発と同じような粒度で、可能な限りデータやテクノロジーを使って、あらゆる問題と向き合い問題解決できると良いと感じています。しかし、EMが扱う対象は人だったりします。弊社の場合は、コンテンツも英会話の講師だったりするので、人をデジタルに扱うことは難しく、人同士のコミュニケーションで解決している箇所も多くあり、再現性の観点で課題があります。
これまでにソフトウェアエンジニアとして培ってきた技術力や問題解決力があるので、それらをマネジメント領域でも駆使しながら、さらに探求していきたいと思っています。
EMの面白さや難しさはどのような点でしょうか。
羽田：今回、20名近くのEMや荒井さんとお話ししました。そこで、ほぼ共通していたのは、元々エンジニアとして評価された後にEMになった、というバックグラウンドです。そのため、皆さん、問題の発見や解決への関心が高く、手段へのこだわりも強い方が多かったです。EMになったタイミングで、解決範囲が人に移ったり、組織に移ったりし、これまでの解決の仕方が直接活かせなくなったり、分からないことが多くて難しい、そのように苦労されている方もいました。
しかし、「解決する」ということに変わりはありません。ソフトウェア思考であったり、問題の解決の仕方は、これまでのキャリアの中で我々は非常に鍛えてきているはずです。向き合う対象が人や組織になり、変数の種類や数も変わったとしても難しく考え過ぎなくても良いのではないでしょうか。悩んでいるのは、シンプルに知らないことが多いだけなのかもしれません。その場合、整理して学んでいけば良いだけです。ただし、ソフトスキルに近しい部分は、大人になったり、社会人経験が長くなったりすることで自然と身に付くというのは幻想だと思っています。実際には、考えて勉強したり、トライアンドエラーしないと培うことは難しいでしょう。そこに気付いたり、向き合っていく難しさは当然あると思います。エンジニアとして培った部分と掛け算し、自身のマネジメントスタイルを探求することを「面白さ」として捉えて取り組んでいくのが良いのではないでしょうか。
荒井：マネジメントに関する書籍はたくさんあります。そして、毎年新たに出版され続けています。それはつまり、この領域がそれだけ難しい、ということを表しているとも言えます。課題の解決法や考え方がたくさんある分野だと考えています。1on1に関しても、書籍によっては「頻度は週1回が良い」と書かれていたりしますが、それが必ずしも正解とは限りません。事実、私と羽田さんの1on1の頻度や、そのやり方は異なっていました。我々2人の間でも、おすすめ書籍の情報交換を行い、似たような書籍を読んできているのですが、それぞれのスタイルは異なっていました。正解がない中で探求を怠らず、自身にとって最適な方法を見つけていくこと、そしてアウトプットが最大化しているのかを確認していく。この点が難しくもあり面白い点だと私は感じています。
羽田：本当にそうですね。書籍を読むことも大事なのですが、1on1や目標設定・評価の仕方は、「自分自身がされてきた体験」の方がどうしても影響力は大きいと感じています。私の配下にも、マネージャーをしているメンバーや、将来マネージャーキャリアを目指したいと言っているメンバーがいるのですが、彼らから真似されるような接し方をしないといけないな、と常々意識しています。
おわりに
EMとして豊富な経験を持つお二人をお迎えし、多くのEMに共通していた点・共通していなかった点をテーマに語っていただきました。
対談の中に出てきた具体的な施策や考え方の多くは、読者の皆さんも明日から取り入れられるものが多くあったのではないでしょうか。
EMとして現場に向き合ってきたお二人の対談だったからこそ、「実態が分かりづらい」と言われることもあるEMのリアルに迫ることができました。
今後も、MIDAS Technology Reviewでは、エンジニアをマネジメントしている方の役に立つ、実践的なエンジニア組織マネジメントの事例を発信していきますので、フォローよろしくおねがいします。