【勉強会参加記録】Engineering Manager Drink Meetup #1 @メルカリ

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