connpass
日付
2018/08/21
参加目的
- メルカリの開発組織体制の事例を知る
- エンジニアリングマネージャの業務を知る
スケジュール
時間 | スケジュール内容 |
---|---|
19:00~ | 開場 |
19:30~ | 挨拶&乾杯 |
19:35~ | VPoE挨拶 |
19:40~ | メルカリのEM/PM体制 |
19:50~ | パネルディスカッション |
20:30~ | フリータイム |
21:15 | 終了 |
VPoE(VP of Engineering)挨拶
- エンジニアの組織系マネジメントを担当。
- 30代になってから企業/CTO/など
- 技術者のテックカンパニーを目指す。
- 技術者を1000人とすると、エンジニアリングマネージャーはざっくり100人、VPoEは10人
- 1人のエンジニアリングマネージャーのカバー範囲はエンジニア8人が限度
- 今日の勉強会の狙い
- 組織の課題解決視点
- 知見を共有し、課題解決のタネを得て、明日からできるアクションを考えよう
- 自身のキャリア視点
- 同じ課題に立ち向かう仲間を得る
- 組織の課題解決視点
メルカリのEM/PM体制
EM/PM体制前の課題
- Project Ownerに全ての負荷が集中した
EM/PM体制の説明
目的
- 責務を明確し、スケールできる組織にする
- 専門性を特化させ、さらに組織や個人としての強みを強化する
構造
- PMがプロジェクト全体を見る
- Backend / iOS / Android / Frontend / 機械学習等、専門要素技術に対して、それぞれEMが存在
PM
- Whatのプロフェッショナル
- 何を作るのかを真剣に考える
- お客様のことを誰よりも知っていて満足させることができる
- お客様の体験を作る
Engineer
- Howのプロフェッショナル
- 実現手段を最もよく知っている
- お客様の体験を具現化する
EM(Engineering Manager)
- Howの最大化のプロフェッショナル
- エンジニアリング組織としての課題解決や成果に責任を持つ
- エンジニアの、以下に対して責任を持つ。
- 目標設定/評価/フィードバック
- 採用
- 育成やメンタリング
- プロジェクトへのアサイン
Tech Lead
- シンプルに役割と責任を定義して、個別の行動はプロジェクト次第で各自が考える
- 各プロジェクトに応じ、役割と責任を果たす上で必要な行動をとっていく
- 役割
- 技術力によってプロジェクトのエンジニアを同じ目標に束ねる
- PMと良きパートナーとなりプロジェクトを推進する
- 責任
- アーキテクチャ・設計
- チームの生産性
- 品質
EM/PM体制後の課題
- そもそもEM/PM/TLの役割が全体に伝わっていなかった
- 1四半期後に定義をアップデートして再度周知
- プロジェクトマネジメントのオーナーが不明確だった
- EMに判断が集中して、EMがブロッカーになることがあった
→ Engineering Manager Solutions Teamという組織課題の解決をサポートしていくチームを編成。
プロジェクトマネジメントや、開発組織全般に関わる課題の解決をサポート。 - EMとPMの間のコミュニケーションが薄かった
- 同じプロダクトを作っていく仲間なので、目線がずれないように相互理解のための時間をとる(1日オフサイトなど)
まとめ
- 会社の成長に合わせて組織体制もアップデートしていく。
パネルディスカッション
本日のお題:All about Engineering Manager in mercari
EMの日常
-
バックエンド
- Microservice Developmentチームの1プロジェクトに対して1人割り当てる。
- プロジェクトを横断しない形でアサインさせつつ、専門性を発揮していく。
- Microservice化を始めている。Microserviceの知識は全員知っておく必要がある。
- 内部向けのGopher道場、K8s勉強会など。
-
機械学習
- 機械学習はプロジェクトによって全然専門性が違う。
- EMとしてはポートフォリオみたいなものを需要に対して考えておく必要がある。
- アサインのバランスを考える必要がある。
- 日々手法やトレンドが変わるため、追っていく必要がある。
- 論文を読む時間・調査する時間をちゃんと確保してあげる。
- 基本的にはそれぞれの特性にあったアサインだが、特定個人にしかできないような状態にはしない。
- 自動化が進んでいる分野だが、簡単には全自動化などできない。いかにノウハウを受け継ぐかが重要。
- 誰でも出来ることは自動化して、エンジニアはより難しい課題にチャレンジする。
- 技術的負債を片付ける時間もちゃんと確保しましょう。
- 評価制度:OKR
- 50%ぐらいの確率で達成見込みのものについて、挑戦をさせる人事制度。
- その人にとってチャレンジングなタスクを認めてあげる。
- 機械学習はプロジェクトによって全然専門性が違う。
-
EMソリューションチーム
- 組織として必要なところを全部やっていくチーム。潤滑油的なチーム。
- EMソリューションチームが課題解決へ導かなくても、各チームが課題解決出来るようになるのがベスト。
- マイクロマネジメントは好ましくないが、メンバーが育成中の状態の時は、しかたなくマイクロマネジメントが必要になることがある。
- メルカリの3つのバリュー
- Go Bold:大胆にやろう。
- All for One:全ては成功のために。
- Be Professional:プロフェッショナルであれ
- メルカリのエンジニアリングバリュー : Be Professionalを細分化した感じ
- Ownership:自発的である
- Automationカラクリ:自動化する
- Progressive:先端の技術を取り込む
喜びと悲しみ・成果と課題
- EM1人体制→4人体制に変更。
- チームメンバーが増えるにつれて、1人に裂ける時間が減っていく。
- EMはエンジニアの成長に責任を持つ必要がある → EMをスケールした。
- 難しいと思うこと
- 組織が向かっていく方向に連れて、マネジメントがやることが変わる
- 最近はダイバーシティ
- 言葉の違いだけじゃなく、ゴール・成長に対する考え方、価値観が違う。
- それぞれのバックグラウンドを理解して接する必要がある。
- ワガママや輪を乱しているのではなく、ただの勘違い。
- 喜び
- メンバーが社内賞をとった時
- 悲しみ
- 給与改定で給料据え置きになったメンバーに伝える瞬間
- 何故もっと早くこのメンバーにフィードバック出来なかったのかという自責
- 給与改定で給料据え置きになったメンバーに伝える瞬間