葛藤しなか?ら成长苦を楽しむ贰惭业.辫诲蹿
- 1. 1 葛藤しながら成長苦を楽しむEM業 Mercari JP, Backend EM Shin Ohno 12/14/2022
- 2. 2 IC から EM へキャリア選択をした人の話 ● 私も同じ悩みを抱えながら、EMを選択し、約1年半が経ちました。 ○ 経緯 ○ 失敗 ○ 葛藤 ○ 成長 ● ● 最初に選択した際に知っておけば良かったこと、もしくは後々になって自分で気 づいたことなどを話せる機会だと思い、今回のイベントに登壇することになりまし た。 ソフトウェアエンジニアからのキャリア選択という点で、ICのパスを続けていくのか、 マネージャーのパスに変わるのか、というのはよくある悩みです。
- 3. 3 Mercari JP, Backend - from 2020/6 - As an EM from 2021/6 Shin Ohno(ganchiku)
- 6. 6 EM のおさらい（私が普段に考えていること） People/Team Management ● 1on1 ● キャリア相談 ● チームメンバー採用 ● パフォーマンス評価 ● 長期的なチーム成長 ● マネージャーのアウトプット ○ チームのアウトプット＋影響を与えた他 チームのアウトプット ○ チームのアウトプットのために権限委譲や メンタリング、コーチングなどを行う ○ 他チームにおいても良い影響を与える行 動をする ● 短期的な個々のプロジェクトの成功よりも、長 期的にチームが組織に貢献 With Leadership ● チームの目標 ● チームの優先順位 ● チームを超えた問題発見
- 7. 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. 8 メルカリのEM事情（キャリアラダー） ● GitHub で公開されています ○ グレードMG1, MG2 はICのみで、MG3から分かれる ● EM のラダーと求められていること ○ 1人のEM が2?8人のエンジニアを見ている ○ さらにMoM、Director、VPなど ● ラダーが上に行くほど、チーム内、複数チーム間、より上位のキャンプ、各カン パニー、全社へのインパクトの大きさが重要になる メルカリのキャリアラダー マネジメントパス、ICパスが定義されている https://engineering.mercari.com/ladder/
- 9. 9 メルカリのEM事情（EMの多様性） ● EM は技術をどこまで知るべきか ○ 解答はないけど、「私」はチームが関わる技術や課題をある程度理解して ほしい ● 個々の問題は知る必要はない。そもそも相談しても唯一解はない ○ ただ、決定をするためには、何が問題で、何が解決されて、何がうれしいか で判断する必要がある ○ チームやメンバーの成熟度によるので、見極め大事 ■ メンバーに任せた方がいいとき ■ リードして決定を自分がした方がいいとき メルカリの開発事情に詳しくないマネージャーもいれば、メルカリのエンジニアから上 がってきたマネージャーもいる
- 10. 10 EMになるべき？ ● チームメンバーや人や組織といったことに興味があるならあり ○ ソフトウェアの問題解決のみであれば、EMは辛そう ● 自チームの成果と関連したチームの成果がマネージャーの成果となるので、会 社へのインパクトは自ずと大きくなる ○ より上のラダーで求められていることにマッチしやすくなる ● より上のラダーの登竜門 ○ MoM, Director, VP, CTO? 「私」は、ICよりもEMの方が、より大きなインパクトを作れる気がします 一方で
- 11. 11 EM から IC ● EM になると IC に戻れないんじゃないか、という不安 ○ IC の方がいろんな持ち運べる技術が獲得できる？ ○ IC の頃と比べて、純粋なコーディング力は落ちないか ● ソフトウェアエンジニアはコーディングだけが仕事ではない ○ タスクの優先順位、インパクトのありそうな仕事の協力 ○ DesignDoc や利害関係者を技術的に説得することもある ● IC の方が報酬が少ない？（実はそんなことはない！） メルカリでもよくある。EM の経験が ICで生きることがよくある EMの経験を持ったICは、仕事の勘所を理解してくれ、とてもありがたい
- 12. 12 失敗１：プレイングマネージャー ● プレイヤーとして集中できる時間を作るのが難しい ○ 働き過ぎになってしまうことが多い ○ マネージャーとしてやるべきことが中途半端なときも ■ プレイヤーする時間を減らした ● 俺TUEEEEEEになってしまいがち ○ 仕事を手放さなくて、自分がボトルネック ■ プレイヤーする時間を減らした ● プレイングマネージャーをすると、自分の考えている方法とは違うやり方に介入しがち（マイクロマ ネージ） ○ チームに入りたてのメンバーにはあり ○ しかし、次のステップに行ってほしいメンバーにはなし。状況による ■ 我慢して任せる。そして、正解はないので、自信を持ってやってほしいと伝える 今は、マネージャー：プレイヤー＝９：１ 以前は、７：７くらい（え？）
- 13. 13 失敗２：EMのリーダーシップ ● 現場の課題感を一番理解し、リーダーシップを発揮できるのはEMの特権 ○ 方向性を決めたら、意志と責任は持つが方法は委譲 ○ EMより上が決めてくれない、と嘆いていた。。。 ■ 決めさせるのは自分（マネージャー）の役割 ● 正解は一つではない ○ 選択肢を提供するのみで止まっていた。。。 ■ 唯一解はないし、間違っている可能性はある ■ それでも、自分の責任で選択し、決定に責任を持つ 現場の感覚と経営層の感覚を合わせる重要な役割 中間管理職だからこそのリーダーシップ発揮の機会
- 15. 15 失敗と内省と行動のメタ認知 ● メタ認知的知識 ○ 現在の自分の強み弱みなど、立ち位置 ● メタ認知的活動 ○ メタ認知的モニタリング ■ 自分が改善したいと思うところ ■ 自分が苦手でもよいと思うところ ■ うまくできていること ○ メタ認知的コントロール ■ 改善したいなら、どうする？ ■ 苦手なら、どうする？ メタ認知的に考える モニタリング コントロール
- 16. 16 失敗１:プレイングマネージャー ● メタ認知的知識 ○ 自分は、エンジニアリング的なバックグラウンドを持っている ○ 自分は、チームがやるべきタスクを知っている ● メタ認知的活動 ○ メタ認知的モニタリング ■ 自分で開発タスクを抱え過ぎだった ■ タスクをメンバーに仕事をお願いできていなかった ■ 自分が考えた方法と違った際に、人の仕事に介入してしまってた ■ 新しいメンバーにと一緒にタスクをやって方法を伝授できた ○ メタ認知的コントロール ■ 重要性とかを共有して、メンバーが拾うようにしよう ■ 良い活動をしたメンバーを讃え、他のメンバーにも良い影響を与えよう ■ 新しいメンバーは、任せるよりも詰め込んだ方が良さそうだったので、次回もため そう
- 17. 17 失敗２：EMのリーダーシップ ● メタ認知的知識 ○ 現場でみんなが困っている問題がある ○ 自分はマネージャーという立場でこの現場に関わっている ● メタ認知的活動 ○ メタ認知的モニタリング ■ 問題だと思っていても、誰もそれを対応しようとしない ■ リーダーシップを発揮して課題を解決できた ○ メタ認知的コントロール ■ 対応しないなら、自分が課題解決提案者になろう ● プロポーザルを書こう ● 問題だと思っている仲間から聞き取りしよう ■ リーダーシップを発揮できて、実際にチームで取り組めて、チームも強くなった。 もっと発揮していこう
- 18. 18 マネージャーとして意識していること ● 失敗自体は問題ではないことを意識づける ○ 失敗から学ぶことは重要で、失敗がないと学ぶ機会を失ってしまう ● メルカリの大事な指標の一つにFail Fastがある。 ○ 早く失敗をすることで、不確実なことを減らすことができる ● メルカリのバリューの一つ、Go Bold ○ 失敗を恐れて、挑戦しないのは NG ● 「私」は、良い意味での「ナイーブ性」を求めている ○ 知り過ぎると尻込みしてしまう難易度の高そうな課題も、純粋な心で挑戦す ることを推奨 失敗から学び、修正し、改善するサイクル