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をスケールした。
難しいと思うこと
- 組織が向かっていく方向に連れて、マネジメントがやることが変わる
- 最近はダイバーシティ
  - 言葉の違いだけじゃなく、ゴール・成長に対する考え方、価値観が違う。
  - それぞれのバックグラウンドを理解して接する必要がある。
  - ワガママや輪を乱しているのではなく、ただの勘違い。
喜び
- メンバーが社内賞をとった時
悲しみ
- 給与改定で給料据え置きになったメンバーに伝える瞬間
  - 何故もっと早くこのメンバーにフィードバック出来なかったのかという自責