「スタートアップ〜メガベンチャーのEMが語る、強い開発組織づくりとキャリア戦略」 イベントレポート

優れたプロダクトを生み出すためには、強い開発組織を作ることが必要不可欠です。こうした背景から、近年ではエンジニアリングマネージャー（EM）の需要が高まっています。

他方で、エンジニア組織の強化やマネジメントに関われるEMに挑戦したいと考える人もいる一方、手を動かしたり最新技術をキャッチアップする機会の減少や、メンバーの1on1面談に追われるといった不安から、EMとしてのキャリアを踏み出せずに悩む人も少なくありません。

そんななか、トラックレコードでは去る6月28日に「スタートアップ〜メガベンチャーのEMが語る、強い開発組織づくりとキャリア戦略」と題したイベントを開催。

EMとしてのキャリアパスの可能性や市場価値の見出し方、EMに必要な技術やマインドセットなどをテーマに、組織フェーズや事業規模が異なる会社のEMを担う登壇者らを招き、LTとクロストークセッションを実施しました。

LT#1「環境変化に合わせた開発組織とEM期待の変化」

新田 智啓氏
株式会社カケハシ
Musubi AI在庫管理サービス・エンジニアリングマネージャー

私はSIerからエンジニアのキャリアをスタートし、複数の事業会社を経て2020年にカケハシへジョインしました。EMとしては10年近くの経験を持っています。

カケハシは創業7年で正社員が300人を超える規模になり、まさに急成長を遂げているスタートアップですが、それゆえに環境変化への対応が必要になってくるわけです。

会社のフェーズやプロダクトの成長によって、開発の環境は常に変化するため、いつも同じマネジメントをしていても上手くいかなくなる。なので、「環境に合わせた最適なチームの状態」と「働きやすい環境づくり」の両面が大事になってくるんです。

弊社の場合、2021年9月に「Musubi AI在庫管理」をリリースし、そこから規模の大きい企業への導入実績が増え、ビジネスとしてスケールしていく事業状況の変化がありました。それに伴い、開発メンバーも当初の5人から50人に増加し、さらには技術的負債も溜まっていく状況へと変わっていきました。

こうしたスタートアップならではの変化に素早く対応し、開発組織としてしっかりと回していくのがEMの仕事だと言えるでしょう。

プロダクトリリース前では、最短リリースを意識しつつ、ゼロからプロセスを構築し、開発の土台づくりや方向性を定めました。次いでPMF前は、技術的負債よりもユーザーに価値提供できる機能の検証を優先し、加えて運用の差し込みと開発を並行して進めるバランスを意識しました。

そしてPMF後は、エンジニアが技術的負債の解消やアーキテクチャの再考、チームの価値観を見直すなど、システム面と組織面の両軸で成長に向けた仕組み化を強化し、中長期を見据えた視野を持つことを大事にしていました。

また、開発組織におけるメンバー数の変化も、人数規模が少ないときは、事業スピードに合わせた開発力を備えるために採用活動を行い、組織が10人以上になり、複数チームが組成されるフェーズでは、各チームが安定して開発に集中できるようなメンバーの採用に注力しました。

さらに組織が大きくなったタイミングでは、チームごとの主体性を担保するために、軸となるメンバーの採用を意識していました。

また、環境変化のスピードが早ければ、そのぶんだけ「既存プロセスの陳腐化」も早く、今まで通りのプロセスでは上手くいかなくなります。

そうした状況をいかにアンラーンし、違う進め方に変えるかをマネージャー自身が意識する必要があるでしょう。

素早く変化に対応していくためには、「全体と個」の最適化の変化スピードが重要になるわけです。組織が大きくなると、全体最適との距離が遠くなっていくので、「個々の目線合わせ」と「情報を自分でプルできる体制」が大切になります。

加えて、EMとして大事になるのが「採用、方針、専門性」の3つになります。

規模が大きくなれば、1人でマネジメントするのに限界を感じやすくなるでしょう。なので、1チーム1人は「チームの文化（変化力）を作るメンバー」を配置し、個人が活躍しやすい組織づくりを行うのが重要だと思います。

また、細かいマネジメントよりも方向性を示し、目線を揃えるためのルールメイクも大事になります。単にOKRやスクラム、プロジェクト管理手法といったツールを使っての目標達成を目指すだけでなく、EMがチームの価値観を、メンバーに浸透させていく役割を担うことが必要だと思います。

今回LTでお話した内容をまとめると、まず開発組織の環境は常に変化していくため、通り一辺倒なマネジメントではなく、状況に応じて「アンラーン」したマネジメントが求められます。

そして、強いチームづくりには採用・方針・専門性が大事になり、さらには「ジェネラルスキル」ではなく「専門スキル」も必要になります。

特にアジャイル型組織では、グラデーション的に上位マネジメント領域の役割や知識の深さが必要だと、自分がEMを経験してあらためて感じるきっかけになりました。

※登壇時のスライドはこちら

LT#2「マルチプロダクト開発体制におけるエンジニアリングマネジメント」

株式会社プレイド
野田 陽平氏
Head of Engineering Management Team / KARTE Blocks dev lead

2015年1月にプレイドへ入社し、プロダクトにおける管理画面の開発を主な業務としつつ、採用やオンボーディング、プロダクトの国際化やKARTE Blocksの開発など、さまざまなプロジェクトに関わっています。

EMのチームは6月に正式発足したばかりですが、その中でシェアできることをLTで発表していこうと思います。

プレイドはメインのプロダクトとなるCX（顧客体験）プラットフォーム「KARTE」を軸に、近年はその周辺領域におけるマルチプロダクト戦略のもと、さまざまなサービスを提供しています。

事業拡大に伴い、年を追うごとに開発組織のメンバーも増えてきており、現在はデザイナーとエンジニア合わせて100名規模の組織になっています。

アーキテクチャや開発の進め方の変遷について、初期の頃は個人やチームごとにそれぞれのイシューに取り組み、KARTEの各機能をプラグインのような形で実装していました。

それがプロダクトの成長とともに、チームを分割してマイクロサービス化させ、各チームごとに進め方やテーマを決めながら、3ヶ月ごとに開発サイクルを区切って開発するようになりました。

今では、それぞれの機能が一つの事業として成り立つような性質になってきたため、マルチプロダクト戦略を推進しています。以前よりも永続的なチーム運営ができるように、3ヶ月という開発サイクルは区切らず、自律分散的に動けるような体制づくりを意識しています。

弊社がEMを置いたのは「悩むメンバーが増えた時期」があったからでした。

リモートワークの普及によるつながりの希薄化、会社のミッションとチームの接続性のなさ、PMF後にプロダクト成長の深化と探索が入り混じった状況の捉え方など、色々な悩みが出てきたのです。

ただ、場当たり的にアプローチしても、構造的な見直しをしないと、また繰り返すのではと感じていました。そこで、EMチームを新たに立ち上げたのです。

EMチームが取り扱う課題としては、能力やWillに応じた人員配置がなされていないチームや個人のパフォーマンスが十分に発揮されない問題を、組織的に防ぐ仕組みがないこと。

組織間に落ちるボールを見極め、最適なチームへ割り振りができていないことの2つを掲げ、さらなる組織拡大を見据えた改善をしている段階です。

EMチームとして具体的に行っているのは、「横串を通す」ためにロールごとの学習やフィードバックサイクルの醸成、報酬設計や等級制度の仕組みづくりなどを行っています。

加えて、事業型（Product Department）と機能型（Core Platform Department）のトップと、開発組織の各チームのリーダーが膝を突き合わせ、チームや個人の状態を把握する機会を設けるといった「縦をつなぐ」ことも重要視しています。

横と縦を繋ぐことで、会社の掲げた戦略に対し、現場の日々の活動の結びつきを強めることができます。

まだ組成したばかりのEMチームですが、個別の問題解決に関わりつつ、構造やコミュニケーションのパスを変えるようなアプローチを取るのが、現時点でやるべきことだと捉えています。

また、ミドルマネジメントが組織にとって重要なので、これからもマネジメントについて学習しながら、専門性を身につけること。EMだけで問題を解決しようとせず、各組織と密に連携をしつつも、絶妙な距離感を保ったカウンターパートの存在になれるように、これからもEMとして頑張っていきたいと思っています。

※登壇時のスライドはこちら

LT#3「一方、私はなぜEMでありつづけるか」

酒井 篤氏
株式会社エス・エム・エス
フロントエンドチーム EM 兼 プロダクトデザイナーグループ マネージャー

2022年10月にエス・エム・エスへ入り、現在は介護事業者向け経営支援サービス「カイポケ」の開発に関わっています。

役割としては、エンジニアリングマネージャーと、プロダクトデザイナーグループのマネージャーも務めています。

カイポケは多面的な経営支援とICT活用による業務効率化を介護事業者向けに提供するSaaSです。

介護事業者の経営改善とサービス品質向上により、質の高い介護サービスの継続提供に貢献するようなプロダクトの開発に従事しています。

LTのテーマである「一方、私はなぜEMでありつづけるか」というのは、自分のキャリア感やEMとしての考えについてシェアできればと思い、このようなタイトルをつけてみました。

私の周囲にもマネジメントに関わる人が多かったんですが、エンジニアというプレイヤーに戻る決断をする人もたくさん見てきました。さらにCxOの役職を持つ経営層すらもプレイヤーに戻る事例が増えていると感じています。では、なぜ私がEMとしてのキャリアを選んだのか。

それは、「人材市場でEMが求められているのを、改めて実感した」からです。

関連リンク：39歳EMの転職活動の現実

プレイヤーではなく、明確に開発組織を作る役割を担うEMにフォーカスした人材の希少価値を感じ、自分もやってみたかったのが、EMのキャリアを選んだ背景になっています。

マネジメントをずっとやっていると、「プレイヤーに戻りたいか？」というのをよく聞かれたり、自分でも考えたりします。

私自身、あまり「プレイヤー」と「マネジメント」という発想自体にそれほど重要性を感じていません。基本的には何でもやるマインドで、“共感するプロダクトをグロースさせる”ためには、一番レバレッジの効く役割にフォーカスしたいという考えを持っているんですね。

ただ「マネジメント」をする中でも、事業への影響度が高い特定の領域ではソフトウェアを深く理解し、人に説明できたり自ら意識決定できたりする水準の解像度を持つための知識は維持するように心がけています。

私が常に焦点を当てているのは「ユーザーの問題を解決する」ということです。

その問題解決のツールとしてマネジメントを捉えていて、専門性の高いメンバーがボトムアップに学習を繰り返し、組織として成長しながら問題解決していくことを支援しています。

「ツールとしてのマネジメントは楽しいのか？」という見方もありますが、個人的にはマネジメントをやればやるほど上手くなっていくのを感じ、自分なりの問題解決ができるようになっていくことがやる気や楽しさにつながっています。

また、マネジメントは特定の組織に依存した技術ではなく、再現性のある技術だと思っています。

今の会社では、規模の大きな組織ならではの課題と向き合ったり、エンジニアリング領域以外のデザインチームのマネジメントも行ったりと、チャレンジングな環境で日々学ぶことも多くあります。

「EMとしての学びを深め、自分なりのスタイルでプロダクトに貢献したい」

このような思いをもとに、今後もEMとしてのキャリア形成を図っていければと思います。

※登壇時のスライドはこちら

LT#4「最速でEMもメンバーも成長するチーム」

高山 湧気氏
freee株式会社
個人・小規模法人会計事業 Head Of Engineering

freeeでは「スモールビジネスを、世界の主役に。」をミッションに掲げ、統合型経営プラットフォームを開発しています。

そんな弊社には多くのエンジニアが在籍していますが、自分からマネージャーになりたいと挙手する人は少ないという所感を抱いています。

今回のLTでは、マネージャーになっても技術的な面も含めて結構成長できるので、EMは意外と悪くないという話ができればと思っています。

実を言うと、私は今まで一度もEMになりたいと思ったことはありません。

他方、大きなインパクトを出せるやりがいのあるポジションだと感じている部分もあります

とはいえ、一番楽しいのはコードを書くことなので、一人のエンジニアとして技術から離れるのは怖いという側面もありました。

でも振り返ってみると、EMになってからの方が技術的に成長していると気づいたのです。

まず、誤解を恐れずに言えば、EMは自分が一番成長できる環境を自ら作れるというメリットがあります。

私の場合、プレイヤーとマネージャー目線で実現したかった環境づくりを意識しています。

前者であれば、何でもやり方を変えていける柔軟性や仕事の裁量度合い、周囲からフィードバックをもらうなどで、後者はマネージャーとしての仕事量を少なくし、EMがいなくても仕事が回るという状況を作ることです。

これらを実現するための手段として、「スクラム」と「当番制」を作りました。

メンバーそれぞれが当事者意識を持って、開発に取り組めるような組織風土を醸成する。

特に弊社のエンジニアは、優秀な人材を採ることにこだわっているので、管理するよりも任せた方が圧倒的にパフォーマンスが出るんです。

このように、自分が働きたいと思うチームを自分で作れるのがEMの魅力だと言えます。

次に社内のエンジニアと議論する場を作っていくのもEMの役割で、これも自分の成長に大きく寄与しました。

スクラムの概念の手段のひとつであるプランニングポーカーを取り入れたりと、具体から抽象までさまざまな手段で議論することで、自分にはない発想を得ることができました。

また、社外のエンジニアと議論（面接）するのも良い経験になっています。

面接の場では、イベントで知り合った人と話すより何倍もお互いのことを理解しようとするので、話す内容や質問の深さも異なり、総じて多くの学びにつながっています。

社内だけに閉じこもっていると技術領域が偏ってしまいがちですが、他の会社がどんな技術を使っていて、どういうことを大切にしているのかを聞くのは自分の視野も広がります。

あとは社内のエンジニア以外の職種と議論する機会もあり、エンジニアには伝わる内容でもビジネスサイドには伝わらず、逆に新しい観点でフィードバックをもらうことも多くありました。

その一方、EMはやはり自然とコードを書く機会が減ってしまうので、手を動かす環境も用意しておくといいと思います。

私は面接で気になった技術や社内での技術議論など、何か仕様で気になったらコードを見にいくように意識しているのに加え、副業でもコードを書くようにしています。

マネージャーをやっている人は自己犠牲やメンバーのために働こうと考えている人がとても多いし、それが大事とされる雰囲気もある気はしていますが、チームの成長のためにはマネージャーの成長は不可欠なので、自信を持って自分自身の成長のために行動をとっていって良いと思います。

EMというポジションは、マネージャーとして、エンジニアとして成長していくことは本気でやっていけると思うので、マネジメントに興味ある人はチャレンジしてみるといいかもしれません。

LT#5「エンジニアリングマネージャーのための、“STAFF ENGINEER”のすゝめ」

増井 雄一郎氏
Engineer / Product Founder
『スタッフエンジニア　マネジメントを超えるリーダーシップ』解説者

私は元々ものづくりが好きで、ソフトウェアやハードウェア、最近ではAI絡みのプロダクトを作っています。現在では、マーケティングリサーチのコンサルを行うBloom ＆ Co.でCTOとして働いています。

また、趣味でもアプリケーションを作ったりと、仕事やプライベート関係なく、起きている時間の大半はプログラムを書いているような生活を送っています。

今回のLTの主題である『スタッフエンジニア　マネジメントを超えるリーダーシップ』は、私が監修と解説、日本版向けの追加インタビューのお手伝いをさせていただいた日本初のスタッフエンジニアの解説本です。

スタッフエンジニアという言葉自体、あまり聞いたことがないかもしれません。

“スタッフ”と聞くと、一般クラスや中間より下のクラスというイメージを想像しがちですが、「スタッフ=参謀」という軍の指揮官を補佐する軍用語からきており、「技術を持ってプロジェクトの参謀になるという意味からスタッフエンジニア」と呼ばれています。

エンジニアリングのキャリアラダーには、マネージャーやディレクター、VPoEといった「ピープルマネジメント」方面にキャリアを進んでいくものと、会社の上流部分をテクニカルな側面から支える上級職として、チームやプロジェクトをリードする「スタッフプラス」方面の2つの路線があります。

スタッフエンジニアはその後者にあたる職種です。

私自身、エンジニアリングマネージャーとスタッフエンジニアはすごく近いところがあると思っています。

エンジニアとしてキャリアを始め、そこからシニアエンジニアまでは自分の能力をプロジェクトを「足し算」していく形になる一方、スタッフエンジニアやエンジニアリングマネージャーは、開発メンバーやプロジェクト全体に対して「掛け算」していく役割を担います。

つまり、開発に関わる人たちの能力をブーストしていくのが、スタッフエンジニアだと言えるでしょう。

スタッフエンジニアが具体的にやることとして、大きく4つの種類があります。

①テックリード

チームの技術的なビジョンを決め、技術選定やコードレビュー、PMと共にロードマップを策定したりと、開発組織の中心人物としてチームを引っ張っていく役割になります。

②アーキテクト

インフラやデータベース、APIなどは、特定の部署やプロダクトではなく複数のセクションにまたがるものであり、複雑かつ変化し続けるアーキテクチャを考えていくこと。また、ビジネスや顧客ニーズなどとも照らし合わせ、技術負債の解消やその実行タイミングの意思決定者として振る舞う必要があります。

③ソルバー

急激なトラフィック増、AIのような技術革新など、経営トップから降りてくる重要な技術課題の「火消し」としての役割をスタッフエンジニアは負います。

④ライトハンド（右腕）

企業によっては「CTO室」として存在することもあり、CTO直下やCTO代理として社内のいろんな問題を解決していく役目を担います。

ソルバーに対して、ライトハンドは組織間のコンフリクトを解決するような、組織構造の「火消し」を担当します。

これらに加え、スタッフエンジニアの活動内容で大きな役割を占めるのが「後進を育てること」と「メンタリング」です。

• エンジニアとしてのどんなキャリア形成をしていけばいいのか。

• スタッフエンジニアになりたい人に対して、組織にどう貢献していけばいいのか。

など、1on1やメンタリングを通して目線合わせをしていき、組織に貢献できるエンジニアを育てるのがスタッフエンジニアの活動のひとつであり、これはマネージャー職とも近しいとも言えます。

スタッフエンジニアは、技術を持って導く「テックリーダー」という立場で、会社へ貢献していくわけで、EMと似ている部分もありますが、実際の活動内容は異なっています。

EMはプロダクト開発における「プロセス」をどう改善し、仕組み化し、PDCAサイクルを回していくかにフォーカスしているの対し、スタッフエンジニアは「技術」を応用して価値を見出し、技術的なビジョンや目標を定め、組織を導いていく役回りを担います。

もし、私が若い頃に技術を中心にキャリアを進めていくスタッフエンジニアのような職種があれば、スタッフエンジニアを目指していたかもしれないと思うんですね。

エンジニアのキャリアパスを考える上で、スタッフエンジニアという働き方があるというのを知るだけでも、キャリアの可能性が広がるのではと感じています。

メンバーとの「壁」、給与査定に対する責任の有無.....。クロストークで議論するEMのあり方

イベントの後半ではクロストークセッションが行われました。

──ビジネス職出身のエンジニア採用担当はどのように開発組織作りに貢献できるのか。

野田：採用は会社の楽しさや将来性などの価値を、極限まで伝えることが大事になっています。それで言えば、営業職だと価値を伝えるのが得意だと思うんですよ。採用は言うなれば、人の人生の一部に関係するところなので、会社の説明やプレゼンを最初に抑えておくと採用面談も進めやすいのではないでしょうか。私もエンジニア採用に関わっていますが、ビジネスサイドの方の視点も非常に参考になると思う場面もあって。お互い情報を揃えながら採用面談を行うと、良い連携が生まれると思っています。

新田：弊社では技術広報というのを始めていて、私以外はビジネス職出身のメンバーで構成されています。その方たちがよく言うのが「エンジニアの感覚は全然違う」ということ。イベント一つ開催するにしても、ビジネスサイドと考え方が異なるわけで、まず最初にエンジニアの感覚を理解するために、エンジニアへひたすらヒアリングするといいでしょう。

その上で、エンジニアは開発の知識に寄っている部分もあるので、マーケやHR、セールスなどの外の世界とエンジニアリングをつなげていってもらうと、エンジニア採用にも生かされていくのではないでしょうか。

──意識的にも無意識的にもマネージャー、管理職という肩書きに対して、メンバーとの壁を感じることがあると思うが、その壁とどう向き合っているのか。

酒井：メンバーとマネージャーは、向き合っている課題が違うので、当然ながら壁を感じることもあります。ただ、マネージャーだからと言って、合理的な結論や意思決定をし続けられるわけではありません。そこはあえて弱みを見せるというか、あらかじめ完璧にはこなせないことを宣言し、その上でマネージャーとしての役割を果たすことを、私はずっとやってきました。

変に責任感を持ちすぎてしまっても、失敗したときのロールバックが難しくなってしまうので、そこはメンバーとマネージャーがときどき失敗を経験しながらも、一緒の目標に向かっていくのを意識することが大事だと考えています。

高山：弊社だとマネージャーではなく“ジャーマネ”と呼ぶように留意しています。芸能界などの業界用語を由来にしているんですが、「タレントを輝かせるサポーターのような役割でありたい」という思いがあるんです。あとは組織構造を説明する際も「逆ピラミッド型」であると伝えていて、メンバーがいかに働きやすい環境にしていくかを一緒に作っていくというのを組織カルチャーとして醸成しています。

とはいえ、理想通りにいかないこともあるので、一緒に失敗を重ねながら進めていくのを前提に、1チームだいたい3~7人くらいのメンバーで構成し、あまり人数が増えないように心がけていますね。

──EMになる前に考えていたイメージと、実際のギャップは何かあるか？

新田：エンジニアの頃、EMは「プロジェクトマネジメントをする人」というイメージを持っていました。それが、実際になってみると解像度が全然違うというか。プロダクトマネジメント、プロジェクトマネジメント、ピープルマネジメント、テクノロジーマネジメントなど、マネジメントの種類って、本当に色々あると感じています。今思えば、エンジニアのメンバーとして見えていたEMの姿って、ほんのごく一部だったなと。

また、アジャイル型でフラットな組織になっていくと、分解したマネジメントを誰がどう担当するかを考えなくてはいけないと思っています。弊社では開発ディレクターやテックリードなど、EM以外のポジションもマネジメントに携わっているので、EMだけが開発組織のマネジメントを担っているわけではなく、その点がエンジニアだった頃にEMへ抱いていたイメージの差分になっていますね。

──現在エンジニアが10名ほどの規模だが、エンジニアのメンバーが何人くらいになったら専任のEMを置くのが良いか。

酒井：5〜10人の間くらいですかね。自分の場合は、早い段階からEMがいた方が良かったなと思っています。

新田：私も酒井さんと同様に5～10人くらいが目安だと思います。組織や環境の変化の度合いが激しい場合、そこに対応できるメンバーがいないと、チーム全員の足が遅くなってしまうので、そういった際はEMを配置した方がいいでしょう。

野田：人数というよりも、階層がどれくらいできたのか。あるいは、事業がどのように多角化したかを考えていけばいいと思っています。事業が多角化すると目線がぶれたり、複数の階層ができるとコミュニケーションのギャップが生まれたりと、構造に合わせてEMを置くかどうかを決めるのがいいのではないでしょうか。

高山：難しい質問ですが、特に何か問題が生じるまではフラットな組織のままでいると思っていて。

組織のミッションやカルチャーを作っていけるのは、少人数ならではのメリットなので、あえて組織化しなくてもいいのかなと思う部分もあります。一方で、大所帯のエンジニアメンバーになった際には、1チームの人数を多くするのではなく、少人数にすることで、一人ひとりに裁量を与えていくのが最適だと考えています。

増井：経営側にいる立場としては、EMを1人入れることで、既存メンバーにおける全体の生産性が上がるのであれば、EMを置くのがいいと判断します。今のメンバーと掛け算をして、そのコストに見合うならEMを入れるべきですし、シニアクラスのメンバーが中心に在籍していて、自律的に動ける人が多いのであれば、EMを入れる必要はないと思うんです。

──EMは評価にも深く関わると思うが、給与査定にも関わっているか？

野田：弊社では給与査定や等級評価に関わり、責任を有しているのがEMの役割になっています。各デパートメントで、それぞれ目的を持って開発していますが、それを評価軸にしようとすると「タコツボ化」しやすいと思っていて。タレントのポートフォリオで考えるときに、もう少し会社の中長期的なところを鑑みて、全体のバランスを考慮する必要があるため、EMが給与査定に責任を持っているんです。

新田：自分も給与査定には関わっています。スタートアップの初期の頃は、プロダクトの成果や顧客への価値が届いたという視点で、査定に反映していく形でいいと思うんですが、人数が増えた段階でエンジニアの専門性を評価する際に、「エンジニアの頑張り＝プロダクトの成果」には必ずしも一致しないわけです。その専門性における能力を評価するためにはEMが見ていく必要があり、弊社の場合はCTOからEMへその役割が移譲されていったという流れになっています。

──（新田さんへの質問）ここ2年ほどはマネジメントに専念という話だが、技術から離れてしまうことに心配はあるのか？

新田：EMは「技術×マネジメント」の掛け算であって、マネジメントだけないんですね。EMの面白さを理解するのを野球に例えると、ルールブックを読み込んでも野球の醍醐味は掴めず、実際にバットを振ってボールに当たった。ヒットになったと体験することで、自分にとって野球が合うか合わないかを見極めることができるわけです。同様に、EMのキャリアに興味があれば、チャレンジしてみて、そこでしっくりくれば続ければいいですし、そうでなければプレイヤーに戻ればいい。EMとしての目線や視野、そこで得た学びは、現場のプレイヤーに戻っても生かされる部分です。

──（高山さんへの質問）私の会社では、EMをやりたいと思ってくれる人が少なく悩んでいる。やりたいと思ってもらえる人を増やすために工夫していることがあれば教えていただきたい。

高山：私はどちらかと言うと、EMをやりたいと思ってくれる人を増やすのではなく、EMになってくれたらいいなと思う人を口説きにいくのを行っています。先ほど、ジャーマネという呼び名を話しましたが、その手前にアソシエイトジャーマネというポジションもあり、まずはそのお試しポジションからやってみることも可能になっています。

──EM業務で2周目があれば、これはやる、やらないというネタがあれば聞いてみたい。

酒井：自分が半年前に転職したときに思っていたことを話したいと思います。前職は0→1の規模感からマネージャーになり、組織的にも50人規模に成長した経験を積んできましたが、もう一度0→1がやりたいかと言うと、組織づくりという観点で見ればまた同じことをやるわけなので、一旦そのフェーズはやらなくてもいいと考えたんです。

EMをやるなら、100人から200人、300人へと成長していく過程を経験してみたいという思いがあり、そこで今の会社へ転職する運びになりました。

──（増井さんへの質問）EMとして市場価値をあげるために必要なビジネス面でのテクニカルスキルとして、何を身につけるべきか？

増井：私が話してきた「掛け算」に必要なテクニカルスキルは2つありまして、まずは「ソフトスキル」が大事になってきます。EMは他部署の人たちに対し、エンジニア組織として何をやっていて、どんな課題を持っているのかを、噛み砕いて伝える話術が必要になってきます。もうひとつは「数字を読める能力」です。

会社のビジネス計画や予算、収支計画といった数字に関するものを把握しておかなければなりません。特にエンジニア組織はコストセンターとも言えるわけで、自部署のビジネス計画に関連する数字周りを読めるようにしておくことが求められるでしょう。

スタートアップからメガベンチャーまで、それぞれのフェーズごとにおけるEMの役割や各社の取り組みが一様に話される貴重な機会となりました。ぜひエンジニアのキャリアに参考になれば幸いです。

■挑戦する企業の採用活動を支援する「TECH HIRE」について

魅力的なミッション、イシュー、ケイパビリティを有しているのに、採用や広報活動が十分でなく、埋もれている優良企業が世の中には多数存在します。またエンジニアの力によってさらなる成長が期待できるのに、開発力を担保しきれずに、思うような成長を実現できていない企業も多く存在します。このような課題感をもつチームに対し、エンジニア採用領域に特化してサービス提供をしてきた実績、ノウハウ、ナレッジをもとに組織設計・母集団形成の戦略策定から実行をパートナーとして推進します。