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

# connpass
https://mercari.connpass.com/event/94467/

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