EMの役割とは何か、TLやICの役割と合わせての考察

Qiita Night エンジニアリングマネジメント編 登壇資料
https://increments.connpass.com/event/263990/

1. EMの役割とは何か、TLやICの役割と合わせての考察 Qiita Night エンジニアリングマネジメント編 登壇資料（2022/11/18） 株式会社ビットキー　佐藤 正大（ @m3hiro3 ）
2. 佐藤 正大 株式会社ビットキー - Manager of VPoE Office - Manager of bitkey platform @m3hiro3 | まさひろさん
3. 3 introduction こんな人に聴いてほしい（読んでほしい） - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人
4. 4 - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人 - EMって、やるべきこと多すぎない？ - と思っている人 introduction こんな人に聴いてほしい（読んでほしい）
5. 5 introduction こんな人に聴いてほしい（読んでほしい） - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人 - EMって、やるべきこと多すぎない？ - と思っている人 - 世の中、ロールがたくさんあって - ぶっちゃけよくわからんよという人
6. 6 introduction こんな人に聴いてほしい（読んでほしい） - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人 - EMって、やるべきこと多すぎない？ - と思っている人 - 世の中、ロールがたくさんあって - ぶっちゃけよくわからんよという人 2011年 2015年 2018年 NTTDATA ［10000人規模］ ・プログラマー、テスター ・システムエンジニア、業務アナリスト ・プロジェクトリーダー、PMO フロムスクラッチ(現データX) ［100人規模］ ・ITコンサルタント、マーケティングコンサルタント ・スクラムマスター、アジャイルコーチ ・開発マネージャー、QAマネージャー 農業スタートアップ ［10人規模］ ・CTO、VPoE …？ ・プロダクトオーナー、プロダクトマネージャー ・スクラムマスター、エンジニアリングマネージャー 2019年 ビットキー ［現在、約250人］ ・エンジニアリングマネージャー ・VPoE Office よくわからん例（まさひろのキャリア）
7. 7 introduction こんな人に聴いてほしい（読んでほしい） - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人 - EMって、やるべきこと多すぎない？ - と思っている人 - 世の中、ロールがたくさんあって - ぶっちゃけよくわからんよという人 2011年 2015年 2018年 NTTDATA ［10000人規模］ ・プログラマー、テスター ・システムエンジニア、業務アナリスト ・プロジェクトリーダー、PMO フロムスクラッチ(現データX) ［100人規模］ ・ITコンサルタント、マーケティングコンサルタント ・スクラムマスター、アジャイルコーチ ・開発マネージャー、QAマネージャー 農業スタートアップ ［10人規模］ ・CTO、VPoE …？ ・プロダクトオーナー、プロダクトマネージャー ・スクラムマスター、エンジニアリングマネージャー 2019年 ビットキー ［現在、約250人］ ・エンジニアリングマネージャー ・VPoE Office よくわからん例（まさひろのキャリア） 自分は一体、どんなロールなのか？ どんなキャリアパスを歩めば良いのか？ そんなみなさんへ、少しでもヒントになればと思います
8. 8 0. Approach ベースとなるアプローチ - あるものが何であるかを考える場合には、 - あるものが何でないかを考えると、 - 多くの示唆が生まれるかもしれない アプローチを紹介します
9. 9 0. Approach アプローチを紹介します ベースとなるアプローチ - あるものが何であるかを考える場合には、 - あるものが何でないかを考えると、 - 多くの示唆が生まれるかもしれない - （持論）
10. 10 0. Approach アプローチを紹介します ベースとなるアプローチ - あるものが何であるかを考える場合には、 - あるものが何でないかを考えると、 - 多くの示唆が生まれるかもしれない - （持論） 何であるか
11. 11 0. Approach アプローチを紹介します ベースとなるアプローチ - あるものが何であるかを考える場合には、 - あるものが何でないかを考えると、 - 多くの示唆が生まれるかもしれない - （持論） 何であるか 何でないか
12. 12 ガイドとなるアプローチ - Gooleのソフトウェアエンジニアリングを参照する - 2021年11月発行 - Google社内の多様なベストプラクティスを、 文化、プロセス、ツールの側面からこの一冊に凝縮 (O’REILLY Japan 紹介文より) 0. Approach アプローチを紹介します
13. 13 0. Approach アプローチを紹介します ガイドとなるアプローチ - 特に、”第５章 チームリーダー入門”を参照する - リーダーシップの役割 として、2つをあげている - EM（Engineering Manager） - 管理者、人員のリーダー、エンジニア経験者 - TM（Tech Lead） - 技術的取り組みを主導する者 - リーダーシップの役割以外 - IC（Individual Contributor） - 部下を持たずに個人としてチームに貢献する社員
14. 14 - これ以降、本書籍を”フラミンゴ先生”と呼びます - 正確には、”ベニイロフラミンゴ”とのことです - これ以降、書籍の引用が多くあります - 引用部分は、”イタリック体” で記載します - Googleが言ってるから正解という考えではなく アプローチとして有用かと思い、紹介します - もし、この本を熟読された方がいらっしゃれば 考察の部分だけ耳を傾けたいただけたら嬉しいです 0. Approach アプローチを紹介します
15. 15 Outline 1. 基本パターン　〜二人三脚でいこう〜 2. 応用パターン　〜小さいチーム、大きいチーム〜 3. 考察のまとめ
16. 16 Outline 1. 基本パターン　〜二人三脚でいこう〜 2. 応用パターン　〜小さいチーム、大きいチーム〜 3. 考察のまとめ
17. 17 - この本にある原則を超意訳すると、1人の人間じゃ大変だよ - TLとEMは”二人三脚”でいくべしと書いている 1. 基本パターン　〜二人三脚でいこう〜 フラミンゴ先生に学ぶ
18. 18 - この本にある原則を超意訳すると、1人の人間じゃ大変だよ - TLとEMは”二人三脚”でいくべしと書いている - TLの役割 - 製品の技術的側面を担当 - 技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般を含む - ICが自分達のスキルセットやスキルベルに最も見合ったタスクに取り掛かれるよう保証する 1. 基本パターン　〜二人三脚でいこう〜 フラミンゴ先生に学ぶ
19. 19 - この本にある原則を超意訳すると、1人の人間じゃ大変だよ - TLとEMは”二人三脚”でいくべしと書いている - TLの役割 - 製品の技術的側面を担当 - 技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般を含む - ICが自分達のスキルセットやスキルベルに最も見合ったタスクに取り掛かれるよう保証する - EMの役割 - チームが担当する製品がビジネス要件を満たすことを保証しつつ - その上でTLを含むチーム内の全ての人員の成績、生産性、満足度に責任を持つ 1. 基本パターン　〜二人三脚でいこう〜 フラミンゴ先生に学ぶ
20. 20 - ”二人三脚”とは？ - 1組のリーダー、つまり1人のTLと、1人のEMがパートナーとして連携して仕事をする - その理屈は、完全に燃え尽きることなく両方の業務を同時に(うまく)こなすのは 本当に難しいので、2人のスペシャリストが専任で各々の役割を攻略していく方がよいという もの 1. 基本パターン　〜二人三脚でいこう〜 フラミンゴ先生に学ぶ
21. 21 本当に難しいので、2人のスペシャリストが専任で各々の役割を攻略していく EM TL
22. 22 ちなみに、EMはさらに難しいと書いてあります EM TL
23. 23 - EMの役割（再掲） - チームが担当する製品がビジネス要件を満たすことを保証しつつ - その上でTLを含むチーム内の全ての人員の成績、生産性、満足度に責任を持つ 1. 基本パターン　〜二人三脚でいこう〜 フラミンゴ先生に学ぶ
24. 24 - EMの役割（再掲） - チームが担当する製品がビジネス要件を満たすことを保証しつつ - その上でTLを含むチーム内の全ての人員の成績、生産性、満足度に責任を持つ - 上記の文章のあと、こう続く - ビジネス要件と個々のチームメンバーの要求とは必ずしも相容れないため、 このことがマネージャーを難しい立場に置く可能性がある場合が多い 1. 基本パターン　〜二人三脚でいこう〜 フラミンゴ先生に学ぶ
25. 25 ビジネス要件と個々のチームメンバーの要求とは必ずしも相容れない
26. 26 ビジネス要件と個々のチームメンバーの要求とは必ずしも相容れない 本日、お集まりの皆様は、「ああ、わかるな・・・」という心境ではないでしょうか
27. 27 - 簡単にまとめると - EMとTLは、”二人三脚”で歩むべし - TLは、”製品の技術的側面”を担当する - EMは、”TLも含んだ”ピープルの側面と、”製品がビジネス要件を満たすこと”に責任を持つ 1. 基本パターン　〜二人三脚でいこう〜 ここで考察してみる
28. 28 1. 基本パターン　〜二人三脚でいこう〜 ここで考察してみる - 簡単にまとめると - EMとTLは、”二人三脚”で歩むべし - TLは、”製品の技術的側面”を担当する - EMは、”TLも含んだ”ピープルの側面と、”製品がビジネス要件を満たすこと”に責任を持つ - こう考えると、わかりやすいのでは？ - EMの仕事＝TLがやらない全て
29. 29 1. 基本パターン　〜二人三脚でいこう〜 TL EM こうではなくて、
30. 30 1. 基本パターン　〜二人三脚でいこう〜 こう TL EM
31. 31 EMの仕事＝TLがやらない全て、TLというAに対する、Aバー と捉えるのがいいかも 1. 基本パターン　〜二人三脚でいこう〜 こう TL EM
32. 32 - EMとは、TLというAに対する、Aバー - EMの仕事＝TLがやらない全て - TLを考えることで、EMが見えてくると思う 1. 基本パターン　〜二人三脚でいこう〜 つまり？ TL EM
33. 33 - EMとは、TLというAに対する、Aバー - EMの仕事＝TLがやらない全て - TLを考えることで、EMが見えてくると思う - ”技術的な側面を担う”というTLの役割の方が、”EMの仕事”よりも理解しやすいのではないか？ 特に、あなたにエンジニア経験があるならば、”TLの仕事”は大変さも、責任も理解できるはず (技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般は、どう考えても大 変) 1. 基本パターン　〜二人三脚でいこう〜 つまり？ TL EM
34. 34 - EMとは、TLというAに対する、Aバー - EMの仕事＝TLがやらない全て - TLを考えることで、EMが見えてくると思う - ”技術的な側面を担う”というTLの役割の方が、”EMの仕事”よりも理解しやすいのではないか？ 特に、あなたにエンジニア経験があるならば、”TLの仕事”は大変さも、責任も理解できるはず (技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般は、どう考えても大 変) - むしろ、TLの仕事の困難さを理解しているからこそ、”TLが願う状況を既に知っている”のではないか だからこそ、”TLがTL業務に集中するための全て”をEMは行うと考えるのが良いのではないか？ 1. 基本パターン　〜二人三脚でいこう〜 つまり？ TL EM
35. 35 - EMとは、TLというAに対する、Aバー - EMの仕事＝TLがやらない全て - TLを考えることで、EMが見えてくると思う - ”技術的な側面を担う”というTLの役割の方が、”EMの仕事”よりも理解しやすいのではないか？ 特に、あなたにエンジニア経験があるならば、”TLの仕事”は大変さも、責任も理解できるはず (技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般は、どう考えても大 変) - むしろ、TLの仕事の困難さを理解しているからこそ、”TLが願う状況を既に知っている”のではないか だからこそ、”TLがTL業務に集中するための全て”をEMは行うと考えるのが良いのではないか？ - さらに、”二人三脚”の原則があるとすれば、”大きくTLに頼って、任せてもいい”のではないか？ (TLが持っているテクノロジーの力こそが、プロダクトの価値を産む源泉となるはずだから) 1. 基本パターン　〜二人三脚でいこう〜 つまり？ TL EM
36. 36 TLが願う状況を、あなたは既に知っているはず。それを二人三脚で進める。
37. 37 Outline 1. 基本パターン　〜二人三脚でいこう〜 2. 応用パターン　〜小さいチーム、大きいチーム〜 3. 考察のまとめ
38. 38 二人三脚が原則だとすると、応用パターンが２つあると読み解くことができます 2. 応用パターン　〜小さいチーム、大きいチーム〜 フラミンゴ先生からの学びを再び
39. 39 二人三脚が原則だとすると、応用パターンが２つあると読み解くことができます ①TLM（テックリードマネージャー） - EMが強力な技術的スキルセットを持っている必要があるような、初期段階にある小規模チーム - TLMとは、チームでの人員面と技術面の要求の両方に対処できる1人の人物 - 比較的シニアな者がTLMであることもあるが、最近までICだったものがこの役職を務めている 2. 応用パターン　〜小さいチーム、大きいチーム〜 フラミンゴ先生からの学びを再び
40. 40 二人三脚が原則だとすると、応用パターンが２つあると読み解くことができます ①TLM（テックリードマネージャー） - EMが強力な技術的スキルセットを持っている必要があるような、初期段階にある小規模チーム - TLMとは、チームでの人員面と技術面の要求の両方に対処できる1人の人物 - 比較的シニアな者がTLMであることもあるが、最近までICだったものがこの役職を務めている ②ピープルマネージャー＆シニアなテックリード - より大きなチームだと、経験豊富なピープルマネージャーが管理職を担う立場で参加し、 - 幅広い経験を持つシニアエンジニアがテックリードの役職で参加することになる 2. 応用パターン　〜小さいチーム、大きいチーム〜 フラミンゴ先生からの学びを再び
41. 41 ①TLM（テックリードマネージャー） - TLMの仕事は入り組んでおり、 - 個別の作業、移譲、ピープルマネジメントのバランスを取る方法を学ばなければならないことが多い - 通常、TLMは、より熟練したTLMからの高度なメンタリングと支援を必要とする - 新しくTLMになった者に勧めるのは、この主題に対してGoogleが提供する複数の講習の受講に加え、役職 に慣れていく際に、定期的なアドバイスをくれるシニアなメンターを探し出すことである 2. 応用パターン　〜小さいチーム、大きいチーム〜 ①のパターンを深掘りして考えてみる
42. 42 ①TLM（テックリードマネージャー） - TLMの仕事は入り組んでおり、 - 個別の作業、移譲、ピープルマネジメントのバランスを取る方法を学ばなければならないことが多い - 通常、TLMは、より熟練したTLMからの高度なメンタリングと支援を必要とする - 新しくTLMになった者に勧めるのは、この主題に対してGoogleが提供する複数の講習の受講に加え、役職 に慣れていく際に、定期的なアドバイスをくれるシニアなメンターを探し出すことである メンタリングを受ける/メンターを探す - チームの外部に頼るという選択肢を、常に持ち続けると良いかも - 大企業の場合、社内Wiki・ポータルに社員紹介があるはず、他部署でも意外と親身になってくれる - スタートアップの場合、同じ悩み・境遇の人はいる、カジュアル面談などの機会は意外と多い 2. 応用パターン　〜小さいチーム、大きいチーム〜 ①のパターンを深掘りして考えてみる
43. 43 『エンジニアのためのマネジメントキャリアパス』 - 第８章 経営幹部にて、CTOとVPoEについて説明 - ”自己診断用の質問リスト”がある（以下一部を抜粋） - あなた(CTO)は社費もしくは自費でプロのコーチの指 導を受けていますか？たとえ「自腹」でも賢い投資と 言えます。コーチは助言も直言もしてくれますし、友 達と違ってあなたのどんな言葉にもきちんと耳を傾け てくれます。 - コーチの指導を仰ぐ以外に、社外で助け合える仲間の ネットワークを持っていますか？他社のあなたと同じ 分野の経営幹部の中に、親しい人がいますか？ - (上記以外の章で、どのキャリアラダーでもメンターの重要性が繰り返し記載) 2. 応用パターン　〜小さいチーム、大きいチーム〜 ここで別の先生を呼んでみる
44. 44 ②ピープルマネージャー＆シニアなテックリード - ピープルマネージャーとは、”人事管理を専門に行うマネージャー” - このパターンを採用する際の前提となる”より大きなチーム”の定義は特にされていない - また、”比較的大規模なチーム”では、”TLのプロジェクト管理を補佐するプログラムマネージャーがいるか もしれない”という記載がある（プロジェクトを束ねる単位をプログラムと呼ぶことがある） 2. 応用パターン　〜小さいチーム、大きいチーム〜 ②のパターンを深掘りして考えてみる
45. 45 ②ピープルマネージャー＆シニアなテックリード - ピープルマネージャーとは、”人事管理を専門に行うマネージャー” - このパターンを採用する際の前提となる”より大きなチーム”の定義は特にされていない - また、”比較的大規模なチーム”では、”TLのプロジェクト管理を補佐するプログラムマネージャーがいるか もしれない”という記載がある（プロジェクトを束ねる単位をプログラムと呼ぶことがある） チームにおける”大きい”・”小さい”とは何か？ - Google社内には、チームの大きさの基準があるのかもしれない（私はわからない） - あえて記載していないのは、必要に応じて（それこそマネージャーの才覚で）選択されているのかも 2. 応用パターン　〜小さいチーム、大きいチーム〜 ②のパターンを深掘りして考えてみる
46. 46 『チームトポロジー』 - 4つの基本的なチームタイプと3つのインタラクションパ ターンに基づく、組織設計とチームインタラクションのため の実践的な適応モデルを紹介した本（JMAM紹介文より） - ダンバー数という認知限界の理論を紹介している - 約5人：ワーキングメモリを保持できる限界 - 約15人：深く信頼できる限界 - 約50人：相互信頼できる限界 - 約150人：他人の能力を認識できる限界 - いま、自分から見て、誰がどこまでで、誰がどこに該当する だろうか？メンバーから見たらどうか？それを考察して設計 することが、チームの大小を考えるヒントになるかも 2. 応用パターン　〜小さいチーム、大きいチーム〜 ここで別の先生を呼んでみる
47. 47 1. 基本パターン　〜二人三脚でいこう〜 2. 応用パターン　〜小さいチーム、大きいチーム〜 3. 考察のまとめ Outline
48. 48 基本パターン　〜二人三脚でいこう〜 3. 考察のまとめ 二人三脚でいこう EMの仕事＝TLがやらない全て TLが願う状況をあなたは既に知っているかも 相容れない２つは大変だ TL EM
49. 49 TLMというパターンもある メンターを探そう ・社内でも ・社外でも ・どんな役割だとしても ・それは”上司”に限らない ・探そう！ 大規模ならロールは増える 認知限界(ダンバー数) ・身近な関係から 　振り返ってみよう ・深く信頼できる 　15人は誰なのか？ ・現在の状況に鑑みる ・メンバーについても 　ロールスイッチして 　考察してみよう！ 3. 考察のまとめ 応用パターン　〜小さいチーム、大きいチーム〜
50. 50 Outline 1. 基本パターン　〜二人三脚でいこう〜 2. 応用パターン　〜小さいチーム、大きいチーム〜 3. 考察のまとめ 4. おわりに ←New!
51. 51 4. おわりに 自分の会社のことを、何も話していませんでした。。。。引用と私見ばかりの発表ですいません。。。 Qiita Jobs にて、Devトークを公開しています。ビットキーの事例について、知りたい場合は是非にご登録ください 対象は、EMでも、TLでも、ICでも、何かしら情報がほしい方は、どなたでも。 ご紹介できるテーマ（例） - ハードウェアデバイスも絡んでの開発プロセス - スクラムのスケール（6つのスクラムチームで、1つのプロダクトを） - SLIモニタリングと、エラーバジェットによるメンテナビリティ向上 - 360度による評価制度の設計、導入したメリット/デメリット - エンジニアのスキル、スタートアップとしての文化醸成を評価する仕組み - OST（Open Space Technology）を活用した交流施策 - 他社さんとコラボして社外勉強会を進めた話と、技術広報の辛み - ぶっちゃけ、採用活動で、何を工夫してますか？ - テスティング、QAに関して ご清聴、ありがとうございました…！