1
葛藤しながら成長苦を楽しむEM業
Mercari JP, Backend EM
Shin Ohno 12/14/2022

2
IC から EM へキャリア選択をした人の話
● 私も同じ悩みを抱えながら、EMを選択し、約1年半が経ちました。
○ 経緯
○ 失敗
○ 葛藤
○ 成長
●
● 最初に選択した際に知っておけば良かったこと、もしくは後々になって自分で気
づいたことなどを話せる機会だと思い、今回のイベントに登壇することになりまし
た。
ソフトウェアエンジニアからのキャリア選択という点で、ICのパスを続けていくのか、
マネージャーのパスに変わるのか、というのはよくある悩みです。

3
Mercari JP, Backend
- from 2020/6
- As an EM from 2021/6
Shin Ohno(ganchiku)

4
EM のおさらい
今日のお話
自分のメルカリでの役割変遷
メルカリのEM事情
失敗とメタ認知
02
03
04
01

5
EMのおさらい
基本的には「エンジニアリングマネージャーのしごと」を読めば、書いてあります。さら
に入りとして、Forkwell さん主催の吉羽さんの回を見てください
情報収集
意思決定
ナッジング
ロールモデル

6
EM のおさらい（私が普段に考えていること）
People/Team Management
● 1on1
● キャリア相談
● チームメンバー採用
● パフォーマンス評価
● 長期的なチーム成長
● マネージャーのアウトプット
○ チームのアウトプット＋影響を与えた他
チームのアウトプット
○ チームのアウトプットのために権限委譲や
メンタリング、コーチングなどを行う
○ 他チームにおいても良い影響を与える行
動をする
● 短期的な個々のプロジェクトの成功よりも、長
期的にチームが組織に貢献
With Leadership
● チームの目標
● チームの優先順位
● チームを超えた問題発見

7
自分のメルカリでの役割変遷
時期 イベント チーム
2020年6月 入社、item チーム(商品の基本情報を扱うマイクロサービスチーム )
Backend Engineer
3人
2021年1月 Itemチームの TL に 2人
2021年4月 非日本語話者メンバーのオンボーディング、リモート メンターへ 3人
2021年6月 item チームのEMに
モノリスの基盤の Kubernetes 移行開始（リーダーシップ）
3人
2021年7月 非日本語話者メンバーのオンボーディング、リモート メンターへ
担当するサービスを増やす（ リーダーシップ）
4人
2022年2月 item チームからモノリスの基盤を見るチームの EMへチーム変更 4人
2022年12月 モノリスの基盤の改善目標の旗振りをはじめた（ リーダーシップ） 7人

8
メルカリのEM事情（キャリアラダー）
● GitHub で公開されています
○ グレードMG1, MG2 はICのみで、MG3から分かれる
● EM のラダーと求められていること
○ 1人のEM が2〜8人のエンジニアを見ている
○ さらにMoM、Director、VPなど
● ラダーが上に行くほど、チーム内、複数チーム間、より上位のキャンプ、各カン
パニー、全社へのインパクトの大きさが重要になる
メルカリのキャリアラダー
マネジメントパス、ICパスが定義されている
https://engineering.mercari.com/ladder/

9
メルカリのEM事情（EMの多様性）
● EM は技術をどこまで知るべきか
○ 解答はないけど、「私」はチームが関わる技術や課題をある程度理解して
ほしい
● 個々の問題は知る必要はない。そもそも相談しても唯一解はない
○ ただ、決定をするためには、何が問題で、何が解決されて、何がうれしいか
で判断する必要がある
○ チームやメンバーの成熟度によるので、見極め大事
■ メンバーに任せた方がいいとき
■ リードして決定を自分がした方がいいとき
メルカリの開発事情に詳しくないマネージャーもいれば、メルカリのエンジニアから上
がってきたマネージャーもいる

10
EMになるべき？
● チームメンバーや人や組織といったことに興味があるならあり
○ ソフトウェアの問題解決のみであれば、EMは辛そう
● 自チームの成果と関連したチームの成果がマネージャーの成果となるので、会
社へのインパクトは自ずと大きくなる
○ より上のラダーで求められていることにマッチしやすくなる
● より上のラダーの登竜門
○ MoM, Director, VP, CTO?
「私」は、ICよりもEMの方が、より大きなインパクトを作れる気がします
一方で

11
EM から IC
● EM になると IC に戻れないんじゃないか、という不安
○ IC の方がいろんな持ち運べる技術が獲得できる？
○ IC の頃と比べて、純粋なコーディング力は落ちないか
● ソフトウェアエンジニアはコーディングだけが仕事ではない
○ タスクの優先順位、インパクトのありそうな仕事の協力
○ DesignDoc や利害関係者を技術的に説得することもある
● IC の方が報酬が少ない？（実はそんなことはない！）
メルカリでもよくある。EM の経験が ICで生きることがよくある
EMの経験を持ったICは、仕事の勘所を理解してくれ、とてもありがたい

12
失敗１：プレイングマネージャー
● プレイヤーとして集中できる時間を作るのが難しい
○ 働き過ぎになってしまうことが多い
○ マネージャーとしてやるべきことが中途半端なときも
■ プレイヤーする時間を減らした
● 俺TUEEEEEEになってしまいがち
○ 仕事を手放さなくて、自分がボトルネック
■ プレイヤーする時間を減らした
● プレイングマネージャーをすると、自分の考えている方法とは違うやり方に介入しがち（マイクロマ
ネージ）
○ チームに入りたてのメンバーにはあり
○ しかし、次のステップに行ってほしいメンバーにはなし。状況による
■ 我慢して任せる。そして、正解はないので、自信を持ってやってほしいと伝える
今は、マネージャー：プレイヤー＝９：１
以前は、７：７くらい（え？）

13
失敗２：EMのリーダーシップ
● 現場の課題感を一番理解し、リーダーシップを発揮できるのはEMの特権
○ 方向性を決めたら、意志と責任は持つが方法は委譲
○ EMより上が決めてくれない、と嘆いていた。。。
■ 決めさせるのは自分（マネージャー）の役割
● 正解は一つではない
○ 選択肢を提供するのみで止まっていた。。。
■ 唯一解はないし、間違っている可能性はある
■ それでも、自分の責任で選択し、決定に責任を持つ
現場の感覚と経営層の感覚を合わせる重要な役割
中間管理職だからこそのリーダーシップ発揮の機会

14
失敗をメタ認知から捉えてみる

15
失敗と内省と行動のメタ認知
● メタ認知的知識
○ 現在の自分の強み弱みなど、立ち位置
● メタ認知的活動
○ メタ認知的モニタリング
■ 自分が改善したいと思うところ
■ 自分が苦手でもよいと思うところ
■ うまくできていること
○ メタ認知的コントロール
■ 改善したいなら、どうする？
■ 苦手なら、どうする？
メタ認知的に考える
モニタリング
コントロール

16
失敗１:プレイングマネージャー
● メタ認知的知識
○ 自分は、エンジニアリング的なバックグラウンドを持っている
○ 自分は、チームがやるべきタスクを知っている
● メタ認知的活動
○ メタ認知的モニタリング
■ 自分で開発タスクを抱え過ぎだった
■ タスクをメンバーに仕事をお願いできていなかった
■ 自分が考えた方法と違った際に、人の仕事に介入してしまってた
■ 新しいメンバーにと一緒にタスクをやって方法を伝授できた
○ メタ認知的コントロール
■ 重要性とかを共有して、メンバーが拾うようにしよう
■ 良い活動をしたメンバーを讃え、他のメンバーにも良い影響を与えよう
■ 新しいメンバーは、任せるよりも詰め込んだ方が良さそうだったので、次回もため
そう

17
失敗２：EMのリーダーシップ
● メタ認知的知識
○ 現場でみんなが困っている問題がある
○ 自分はマネージャーという立場でこの現場に関わっている
● メタ認知的活動
○ メタ認知的モニタリング
■ 問題だと思っていても、誰もそれを対応しようとしない
■ リーダーシップを発揮して課題を解決できた
○ メタ認知的コントロール
■ 対応しないなら、自分が課題解決提案者になろう
● プロポーザルを書こう
● 問題だと思っている仲間から聞き取りしよう
■ リーダーシップを発揮できて、実際にチームで取り組めて、チームも強くなった。
もっと発揮していこう

18
マネージャーとして意識していること
● 失敗自体は問題ではないことを意識づける
○ 失敗から学ぶことは重要で、失敗がないと学ぶ機会を失ってしまう
● メルカリの大事な指標の一つにFail Fastがある。
○ 早く失敗をすることで、不確実なことを減らすことができる
● メルカリのバリューの一つ、Go Bold
○ 失敗を恐れて、挑戦しないのは NG
● 「私」は、良い意味での「ナイーブ性」を求めている
○ 知り過ぎると尻込みしてしまう難易度の高そうな課題も、純粋な心で挑戦す
ることを推奨
失敗から学び、修正し、改善するサイクル