2025年8月7日に開催されたイベント「EMの実践知 ー開発組織フェーズの変化にともなう課題と打ち手ー」にて、株式会社マイベストのnaoprさんが「メガベンチャーのEMからスタートアップの1人目EMになって変わったこと、変わらないこと」をテーマに登壇しました。

このレポートでは、naoprさんの発表内容について詳しくご紹介し、組織フェーズの違いがEMに求められる役割にどのような影響を与えるのか、そして、EMにとって普遍的に重要な要素について探っていきます。

イベント詳細はこちら▼
https://tenshoku-draft.connpass.com/event/361976/

目次
1,発表者紹介：naoprさんのEMとしての軌跡
2,組織規模の比較：メルカリとマイベスト
3,メガベンチャーでのEMの仕事：メルカリでの経験
4,スタートアップでのEMの仕事：マイベストでの挑戦
5,EMの役割で「変わったこと」：メガベンチャーからスタートアップへの変化
6,EMの役割で「変わらないこと」：普遍的な要素
7,まとめ：変化への柔軟さと普遍的なスキルの研鑽の重要性

発表者紹介：naoprさんのEMとしての軌跡

株式会社マイベスト 開発部 Engineering Manager naoprさん（X：@naopr）

前職のメルカリでTech Leadとしてテクノロジーマネジメントからキャリアをスタートさせ、その後EMへ。メルカリの子会社であるソウゾウでの事業立ち上げとEMを経て、2年前にマイベストに1人目のEMとして入社。
EMとしての経験は合計で5〜6年ほど。自身のEMとしての業務の肌感としては、ピープルマネジメントが半分以上を占め、テクノロジーマネジメントはほとんど行わないといった特徴を挙げています。

組織規模の比較：メルカリとマイベスト

naoprさんが経験した株式会社メルカリ（在籍当時）と現在所属している株式会社マイベストでは、組織の規模が大きく異なります。事前情報として、まずは両社の組織規模について確認しておきましょう。

会社全体で約10倍、開発組織においては約20〜30倍もの人数差があり、この規模感の違いが、EMに求められる役割や動き方に影響を与えています。

メガベンチャーでのEMの仕事：メルカリでの経験

naoprさんがメルカリに在籍していた当時の開発組織は「Camp System」を採用していました。これは、メルカリというプロダクトの領域を「Camp」という単位で分割し、そのCampの中に複数のチームが存在する体制です。naoprさんは、このCampのうちの一つで、2チームを担当するEMとして働いていました。

当時の開発組織と自身の状況について、以下の通りです。

自立的に業務できるメンバーがほとんどで、開発スタイルのベースも確立されている安定感のあるチームだったことや、naoprさん自身がチームメンバーからマネージャーになったこともあり、ドメイン知識もメンバーに対する知識もある状態でのマネジメントでした。

メルカリで行った具体的な取り組みの1つ目は「開発ロードマップの遵守の課題解決」です。
カスタマーサポート向けの社内ツール（CSツール）開発チームにおいて、Campをまたいだ複数のチームから開発依頼が多く寄せられ、チームのロードマップ通りに開発が進まないという状況がありました。
その際、ステークホルダーとの調整や、チームの開発ポリシー策定（開発案件の優先順位とリソース割合の明確化）を行いました。また、他チームでもCSツールを開発できるようドキュメント整備を進めたそうです。

2つ目の具体的な取り組みとして紹介されたのは、「マイクロサービス化によるCS業務の支障への対応」です。
当時、全社のマイクロサービス化により、アクセスログやDBが分散し、CS業務に支障が出始めていました。その際、CS・BI・AI/MLなど全社横断での情報共有グループを作成し、CSオペレーションのヒアリングを実施。さらに、DB移行時のチェックリストを作成し、リリースフローに導入するなどの対策も講じました。

メルカリでのEM経験について「各技術領域に専門家がいるからこそ、自分の役割に集中して、マネジメントの専門性を高められる環境だった」とnaoprさんは振り返ります。

スタートアップでのEMの仕事：マイベストでの挑戦

マイベストの開発組織は、3つの事業領域・5つのチームからなるCross Functionalなプロダクトチームと、チーム横断で技術をサポートするイネーブリングチームに分かれています。
現在の開発組織とnaoprさんの状況については以下の通りです。

若手メンバーが多く、アジャイル開発に関する知識レベルは様々でした。また、スクラムマスターの経験者はほぼいなかったため、手探りで開発を進めていました。

この状態からnaoprさんが行った施策は大きく分けて4つあります。

1つ目は「社内メンバーとのコミュニケーションと関係構築」です。
入社後1ヶ月をかけて全エンジニアと対面で1on1を実施し、自己紹介や自身がこれから目指すところや取り組みたいことをメンバーに共有していきました。また、Slackの分報チャンネルへの積極的な投稿（Working Out Loud）や日報の活用、社内飲み会への参加を通じて、泥臭くも地道に信頼関係を築くことに注力しました。

2つ目は「エンジニア採用・採用広報の推進」です。
naoprさん自身が積極的にスカウト送付、カジュアル面談、面接、新規募集枠の提案、求人票作成といったエンジニア採用業務を担当しました。それに加えて、前職の経験を活かし、ブログ連載や勉強会の企画・運営といった採用広報活動にも力を入れました。

そして3つ目の施策は「デザイナー・PdM向け社外勉強会の開催」です。
当時、デザイナー・PdMはジュニア層が多かったため、社外交流や発表機会に乏しく、自身の業務を客観的に見にくいという課題がありました。そこで、4社を巻き込んだクローズドな勉強会を企画・開催しました。これにより、社外の知り合いができたり、登壇機会を得られたり、自身の業務が社外の人から承認される機会が生まれました。

最後は「大規模開発プロジェクトのPjM（プロジェクトマネージャー）」です。
戦略転換に伴い、難易度の高い大規模な新規開発プロジェクトのプロジェクトマネージャーを務めることになったnaoprさん。
しかし、プロジェクト発足時点で要件が不明確（インセプションデッキレベル）、組織改編直後でメンバー間の関係性が未構築、スケジュールが非常に重要という厳しい状況でした。この難題に対して、チーム編成を調整したり、ガントチャートを作成し週次でのメンテナンスを行ったり、各種会議体の設定とファシリテーションを主導してプロジェクトを着実に進めていきました。

このときの激闘はブログにもまとめられていますので、ぜひご覧ください！
https://naopr.hatenablog.com/entry/2023/12/05/235013

EMの役割で「変わったこと」：メガベンチャーからスタートアップへの変化

メルカリからマイベストへの移行を経て、自身のEMとしての役割は大きく変化したとnaoprさんは語っています。

1つ目は「主語」の変化です。担当範囲が「チーム・エンジニア」から「プロダクト組織・エンジニア組織」全体へと広がり、より広範な視点と責任が求められるようになりました。

また「役割の比重」も変化したことの一つです。特にピープルマネジメントの比重が増し、技術的な側面よりもマネジメント業務への集中が求められるようになりました。

3つ目の変化は「志向」です。 「アウトプット志向」から「アウトカム志向」へと転換しました。単に成果物を生み出すだけでなく、それが組織や事業にどのような価値をもたらすか、結果にコミットすることが重視されるようになったのです。

そして最後に「課題解決のアプローチ」についてです。目の前の課題を解決するだけでなく、課題そのものを明確に定義し、他者と協力して解決できる形にすることを意識するようになったとnaoprさんは語っていました。

EMの役割で「変わらないこと」：普遍的な要素

転職をして役割に大きな変化があった一方で、組織の規模やフェーズが変わっても、EMの役割において普遍的に重要な要素も存在することがわかってきました。
今回はミクロとマクロそれぞれの視点で紹介しています。

ミクロな視点

変わらなかったことの1つ目は、エンジニア採用業務です。入社して最初に組織にバリューを出せる業務であり、面接官だけでなく採用に関わる一連の業務の経験は、組織が変わっても活かせる重要なスキルでした。

また、採用広報業務についても、会社規模の大小に関わらず、技術ブランディングの重要性は変わらないとのこと。常に社内の技術ネタにアンテナを張り、メンバーの発表や発信を促すことが求められます。

そして、ピープルマネジメントも変わらないことの一つです。エンジニア以外の職種（例：デザイン組織）をマネジメントする場合でも、ピープルマネジメントの根本的なスキルは変わりません。

マクロな視点

マクロな視点から見ると、マネージャーのアウトプットも役割としては変わりません。これはアンドリュー・S・グローブ著の『HIGH OUTPUT MANAGEMENT』で定義されている「マネージャーのアウトプット = 自分の組織のアウトプット + 自分の影響力が及ぶ隣接組織のアウトプット」という考え方に裏打ちされています。

最後は問題解決の本質とプロセスです。「問題 = あるべき姿 - 現状」という問題定義の基本や、「問題発見 → 原因分析 → 解決策の選定 → 計画の策定」という問題解決のステップは、抽象度が変わっても普遍だとnaoprさんは語りました。

まとめ：変化への柔軟さと普遍的なスキルの研鑽の重要性

naoprさんの発表は、メガベンチャーとスタートアップという異なる組織フェーズでEMを務める中で得られた貴重な知見が詰まっていました。

組織のフェーズが変化することで、EMに求められる守備範囲や業務の比重は大きく変わります。しかし、エンジニア採用やピープルマネジメント、そして問題解決の本質といった根幹となるスキルや考え方は、組織規模に関わらず普遍的です。

EMとしてのキャリアを考える上で、自身の置かれた組織のフェーズを深く理解し、その時々に求められる役割の変化に柔軟に対応しつつ、同時に普遍的なマネジメントスキルを磨き続けることの大切さを感じられる、とても有意義な発表でした。

各発表記事へのリンク

今回のイベントはさまざまなフェーズのエンジニア組織に責任を持つ方々（EM, VPoE etc…）が集まり、各フェーズにおける成功・失敗事例や今まさに当たっている課題などをセッション・懇親会を通じて知り、深め合う目的で開催されました。

他の発表についても、記事にまとめてありますので、以下のリンクよりご覧ください。

• 株式会社コドモン エンジニアリングマネージャー いちかわさん
• フリー株式会社 統合flow開発基盤本部 統合モジュール部 部長 友澤 啓太さん
• パイオニア株式会社 Cross Technology Center サービス事業本部 共通基盤開発部 部長 坂根 秀幸さん