Slide 1

Slide 1 text

EMの役割とは何か、TLやICの役割と合わせての考察 Qiita Night エンジニアリングマネジメント編 登壇資料(2022/11/18) 株式会社ビットキー 佐藤 正大( @m3hiro3 )

Slide 2

Slide 2 text

佐藤 正大 株式会社ビットキー - Manager of VPoE Office - Manager of bitkey platform @m3hiro3 | まさひろさん

Slide 3

Slide 3 text

3 introduction こんな人に聴いてほしい(読んでほしい) - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人

Slide 4

Slide 4 text

4 - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人 - EMって、やるべきこと多すぎない? - と思っている人 introduction こんな人に聴いてほしい(読んでほしい)

Slide 5

Slide 5 text

5 introduction こんな人に聴いてほしい(読んでほしい) - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人 - EMって、やるべきこと多すぎない? - と思っている人 - 世の中、ロールがたくさんあって - ぶっちゃけよくわからんよという人

Slide 6

Slide 6 text

6 introduction こんな人に聴いてほしい(読んでほしい) - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人 - EMって、やるべきこと多すぎない? - と思っている人 - 世の中、ロールがたくさんあって - ぶっちゃけよくわからんよという人 2011年 2015年 2018年 NTTDATA [10000人規模] ・プログラマー、テスター ・システムエンジニア、業務アナリスト ・プロジェクトリーダー、PMO フロムスクラッチ(現データX) [100人規模] ・ITコンサルタント、マーケティングコンサルタント ・スクラムマスター、アジャイルコーチ ・開発マネージャー、QAマネージャー 農業スタートアップ [10人規模] ・CTO、VPoE …? ・プロダクトオーナー、プロダクトマネージャー ・スクラムマスター、エンジニアリングマネージャー 2019年 ビットキー [現在、約250人] ・エンジニアリングマネージャー ・VPoE Office よくわからん例(まさひろのキャリア)

Slide 7

Slide 7 text

7 introduction こんな人に聴いてほしい(読んでほしい) - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人 - EMって、やるべきこと多すぎない? - と思っている人 - 世の中、ロールがたくさんあって - ぶっちゃけよくわからんよという人 2011年 2015年 2018年 NTTDATA [10000人規模] ・プログラマー、テスター ・システムエンジニア、業務アナリスト ・プロジェクトリーダー、PMO フロムスクラッチ(現データX) [100人規模] ・ITコンサルタント、マーケティングコンサルタント ・スクラムマスター、アジャイルコーチ ・開発マネージャー、QAマネージャー 農業スタートアップ [10人規模] ・CTO、VPoE …? ・プロダクトオーナー、プロダクトマネージャー ・スクラムマスター、エンジニアリングマネージャー 2019年 ビットキー [現在、約250人] ・エンジニアリングマネージャー ・VPoE Office よくわからん例(まさひろのキャリア) 自分は一体、どんなロールなのか? どんなキャリアパスを歩めば良いのか? そんなみなさんへ、少しでもヒントになればと思います

Slide 8

Slide 8 text

8 0. Approach ベースとなるアプローチ - あるものが何であるかを考える場合には、 - あるものが何でないかを考えると、 - 多くの示唆が生まれるかもしれない アプローチを紹介します

Slide 9

Slide 9 text

9 0. Approach アプローチを紹介します ベースとなるアプローチ - あるものが何であるかを考える場合には、 - あるものが何でないかを考えると、 - 多くの示唆が生まれるかもしれない - (持論)

Slide 10

Slide 10 text

10 0. Approach アプローチを紹介します ベースとなるアプローチ - あるものが何であるかを考える場合には、 - あるものが何でないかを考えると、 - 多くの示唆が生まれるかもしれない - (持論) 何であるか

Slide 11

Slide 11 text

11 0. Approach アプローチを紹介します ベースとなるアプローチ - あるものが何であるかを考える場合には、 - あるものが何でないかを考えると、 - 多くの示唆が生まれるかもしれない - (持論) 何であるか 何でないか

Slide 12

Slide 12 text

12 ガイドとなるアプローチ - Gooleのソフトウェアエンジニアリングを参照する - 2021年11月発行 - Google社内の多様なベストプラクティスを、 文化、プロセス、ツールの側面からこの一冊に凝縮 (O’REILLY Japan 紹介文より) 0. Approach アプローチを紹介します

Slide 13

Slide 13 text

13 0. Approach アプローチを紹介します ガイドとなるアプローチ - 特に、”第5章 チームリーダー入門”を参照する - リーダーシップの役割 として、2つをあげている - EM(Engineering Manager) - 管理者、人員のリーダー、エンジニア経験者 - TM(Tech Lead) - 技術的取り組みを主導する者 - リーダーシップの役割以外 - IC(Individual Contributor) - 部下を持たずに個人としてチームに貢献する社員

Slide 14

Slide 14 text

14 - これ以降、本書籍を”フラミンゴ先生”と呼びます - 正確には、”ベニイロフラミンゴ”とのことです - これ以降、書籍の引用が多くあります - 引用部分は、”イタリック体” で記載します - Googleが言ってるから正解という考えではなく アプローチとして有用かと思い、紹介します - もし、この本を熟読された方がいらっしゃれば 考察の部分だけ耳を傾けたいただけたら嬉しいです 0. Approach アプローチを紹介します

Slide 15

Slide 15 text

15 Outline 1. 基本パターン 〜二人三脚でいこう〜 2. 応用パターン 〜小さいチーム、大きいチーム〜 3. 考察のまとめ

Slide 16

Slide 16 text

16 Outline 1. 基本パターン 〜二人三脚でいこう〜 2. 応用パターン 〜小さいチーム、大きいチーム〜 3. 考察のまとめ

Slide 17

Slide 17 text

17 - この本にある原則を超意訳すると、1人の人間じゃ大変だよ - TLとEMは”二人三脚”でいくべしと書いている 1. 基本パターン 〜二人三脚でいこう〜 フラミンゴ先生に学ぶ

Slide 18

Slide 18 text

18 - この本にある原則を超意訳すると、1人の人間じゃ大変だよ - TLとEMは”二人三脚”でいくべしと書いている - TLの役割 - 製品の技術的側面を担当 - 技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般を含む - ICが自分達のスキルセットやスキルベルに最も見合ったタスクに取り掛かれるよう保証する 1. 基本パターン 〜二人三脚でいこう〜 フラミンゴ先生に学ぶ

Slide 19

Slide 19 text

19 - この本にある原則を超意訳すると、1人の人間じゃ大変だよ - TLとEMは”二人三脚”でいくべしと書いている - TLの役割 - 製品の技術的側面を担当 - 技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般を含む - ICが自分達のスキルセットやスキルベルに最も見合ったタスクに取り掛かれるよう保証する - EMの役割 - チームが担当する製品がビジネス要件を満たすことを保証しつつ - その上でTLを含むチーム内の全ての人員の成績、生産性、満足度に責任を持つ 1. 基本パターン 〜二人三脚でいこう〜 フラミンゴ先生に学ぶ

Slide 20

Slide 20 text

20 - ”二人三脚”とは? - 1組のリーダー、つまり1人のTLと、1人のEMがパートナーとして連携して仕事をする - その理屈は、完全に燃え尽きることなく両方の業務を同時に(うまく)こなすのは 本当に難しいので、2人のスペシャリストが専任で各々の役割を攻略していく方がよいという もの 1. 基本パターン 〜二人三脚でいこう〜 フラミンゴ先生に学ぶ

Slide 21

Slide 21 text

21 本当に難しいので、2人のスペシャリストが専任で各々の役割を攻略していく EM TL

Slide 22

Slide 22 text

22 ちなみに、EMはさらに難しいと書いてあります EM TL

Slide 23

Slide 23 text

23 - EMの役割(再掲) - チームが担当する製品がビジネス要件を満たすことを保証しつつ - その上でTLを含むチーム内の全ての人員の成績、生産性、満足度に責任を持つ 1. 基本パターン 〜二人三脚でいこう〜 フラミンゴ先生に学ぶ

Slide 24

Slide 24 text

24 - EMの役割(再掲) - チームが担当する製品がビジネス要件を満たすことを保証しつつ - その上でTLを含むチーム内の全ての人員の成績、生産性、満足度に責任を持つ - 上記の文章のあと、こう続く - ビジネス要件と個々のチームメンバーの要求とは必ずしも相容れないため、 このことがマネージャーを難しい立場に置く可能性がある場合が多い 1. 基本パターン 〜二人三脚でいこう〜 フラミンゴ先生に学ぶ

Slide 25

Slide 25 text

25 ビジネス要件と個々のチームメンバーの要求とは必ずしも相容れない

Slide 26

Slide 26 text

26 ビジネス要件と個々のチームメンバーの要求とは必ずしも相容れない 本日、お集まりの皆様は、「ああ、わかるな・・・」という心境ではないでしょうか

Slide 27

Slide 27 text

27 - 簡単にまとめると - EMとTLは、”二人三脚”で歩むべし - TLは、”製品の技術的側面”を担当する - EMは、”TLも含んだ”ピープルの側面と、”製品がビジネス要件を満たすこと”に責任を持つ 1. 基本パターン 〜二人三脚でいこう〜 ここで考察してみる

Slide 28

Slide 28 text

28 1. 基本パターン 〜二人三脚でいこう〜 ここで考察してみる - 簡単にまとめると - EMとTLは、”二人三脚”で歩むべし - TLは、”製品の技術的側面”を担当する - EMは、”TLも含んだ”ピープルの側面と、”製品がビジネス要件を満たすこと”に責任を持つ - こう考えると、わかりやすいのでは? - EMの仕事=TLがやらない全て

Slide 29

Slide 29 text

29 1. 基本パターン 〜二人三脚でいこう〜 TL EM こうではなくて、

Slide 30

Slide 30 text

30 1. 基本パターン 〜二人三脚でいこう〜 こう TL EM

Slide 31

Slide 31 text

31 EMの仕事=TLがやらない全て、TLというAに対する、Aバー と捉えるのがいいかも 1. 基本パターン 〜二人三脚でいこう〜 こう TL EM

Slide 32

Slide 32 text

32 - EMとは、TLというAに対する、Aバー - EMの仕事=TLがやらない全て - TLを考えることで、EMが見えてくると思う 1. 基本パターン 〜二人三脚でいこう〜 つまり? TL EM

Slide 33

Slide 33 text

33 - EMとは、TLというAに対する、Aバー - EMの仕事=TLがやらない全て - TLを考えることで、EMが見えてくると思う - ”技術的な側面を担う”というTLの役割の方が、”EMの仕事”よりも理解しやすいのではないか? 特に、あなたにエンジニア経験があるならば、”TLの仕事”は大変さも、責任も理解できるはず (技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般は、どう考えても大 変) 1. 基本パターン 〜二人三脚でいこう〜 つまり? TL EM

Slide 34

Slide 34 text

34 - EMとは、TLというAに対する、Aバー - EMの仕事=TLがやらない全て - TLを考えることで、EMが見えてくると思う - ”技術的な側面を担う”というTLの役割の方が、”EMの仕事”よりも理解しやすいのではないか? 特に、あなたにエンジニア経験があるならば、”TLの仕事”は大変さも、責任も理解できるはず (技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般は、どう考えても大 変) - むしろ、TLの仕事の困難さを理解しているからこそ、”TLが願う状況を既に知っている”のではないか だからこそ、”TLがTL業務に集中するための全て”をEMは行うと考えるのが良いのではないか? 1. 基本パターン 〜二人三脚でいこう〜 つまり? TL EM

Slide 35

Slide 35 text

35 - EMとは、TLというAに対する、Aバー - EMの仕事=TLがやらない全て - TLを考えることで、EMが見えてくると思う - ”技術的な側面を担う”というTLの役割の方が、”EMの仕事”よりも理解しやすいのではないか? 特に、あなたにエンジニア経験があるならば、”TLの仕事”は大変さも、責任も理解できるはず (技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般は、どう考えても大 変) - むしろ、TLの仕事の困難さを理解しているからこそ、”TLが願う状況を既に知っている”のではないか だからこそ、”TLがTL業務に集中するための全て”をEMは行うと考えるのが良いのではないか? - さらに、”二人三脚”の原則があるとすれば、”大きくTLに頼って、任せてもいい”のではないか? (TLが持っているテクノロジーの力こそが、プロダクトの価値を産む源泉となるはずだから) 1. 基本パターン 〜二人三脚でいこう〜 つまり? TL EM

Slide 36

Slide 36 text

36 TLが願う状況を、あなたは既に知っているはず。それを二人三脚で進める。

Slide 37

Slide 37 text

37 Outline 1. 基本パターン 〜二人三脚でいこう〜 2. 応用パターン 〜小さいチーム、大きいチーム〜 3. 考察のまとめ

Slide 38

Slide 38 text

38 二人三脚が原則だとすると、応用パターンが2つあると読み解くことができます 2. 応用パターン 〜小さいチーム、大きいチーム〜 フラミンゴ先生からの学びを再び

Slide 39

Slide 39 text

39 二人三脚が原則だとすると、応用パターンが2つあると読み解くことができます ①TLM(テックリードマネージャー) - EMが強力な技術的スキルセットを持っている必要があるような、初期段階にある小規模チーム - TLMとは、チームでの人員面と技術面の要求の両方に対処できる1人の人物 - 比較的シニアな者がTLMであることもあるが、最近までICだったものがこの役職を務めている 2. 応用パターン 〜小さいチーム、大きいチーム〜 フラミンゴ先生からの学びを再び

Slide 40

Slide 40 text

40 二人三脚が原則だとすると、応用パターンが2つあると読み解くことができます ①TLM(テックリードマネージャー) - EMが強力な技術的スキルセットを持っている必要があるような、初期段階にある小規模チーム - TLMとは、チームでの人員面と技術面の要求の両方に対処できる1人の人物 - 比較的シニアな者がTLMであることもあるが、最近までICだったものがこの役職を務めている ②ピープルマネージャー&シニアなテックリード - より大きなチームだと、経験豊富なピープルマネージャーが管理職を担う立場で参加し、 - 幅広い経験を持つシニアエンジニアがテックリードの役職で参加することになる 2. 応用パターン 〜小さいチーム、大きいチーム〜 フラミンゴ先生からの学びを再び

Slide 41

Slide 41 text

41 ①TLM(テックリードマネージャー) - TLMの仕事は入り組んでおり、 - 個別の作業、移譲、ピープルマネジメントのバランスを取る方法を学ばなければならないことが多い - 通常、TLMは、より熟練したTLMからの高度なメンタリングと支援を必要とする - 新しくTLMになった者に勧めるのは、この主題に対してGoogleが提供する複数の講習の受講に加え、役職 に慣れていく際に、定期的なアドバイスをくれるシニアなメンターを探し出すことである 2. 応用パターン 〜小さいチーム、大きいチーム〜 ①のパターンを深掘りして考えてみる

Slide 42

Slide 42 text

42 ①TLM(テックリードマネージャー) - TLMの仕事は入り組んでおり、 - 個別の作業、移譲、ピープルマネジメントのバランスを取る方法を学ばなければならないことが多い - 通常、TLMは、より熟練したTLMからの高度なメンタリングと支援を必要とする - 新しくTLMになった者に勧めるのは、この主題に対してGoogleが提供する複数の講習の受講に加え、役職 に慣れていく際に、定期的なアドバイスをくれるシニアなメンターを探し出すことである メンタリングを受ける/メンターを探す - チームの外部に頼るという選択肢を、常に持ち続けると良いかも - 大企業の場合、社内Wiki・ポータルに社員紹介があるはず、他部署でも意外と親身になってくれる - スタートアップの場合、同じ悩み・境遇の人はいる、カジュアル面談などの機会は意外と多い 2. 応用パターン 〜小さいチーム、大きいチーム〜 ①のパターンを深掘りして考えてみる

Slide 43

Slide 43 text

43 『エンジニアのためのマネジメントキャリアパス』 - 第8章 経営幹部にて、CTOとVPoEについて説明 - ”自己診断用の質問リスト”がある(以下一部を抜粋) - あなた(CTO)は社費もしくは自費でプロのコーチの指 導を受けていますか?たとえ「自腹」でも賢い投資と 言えます。コーチは助言も直言もしてくれますし、友 達と違ってあなたのどんな言葉にもきちんと耳を傾け てくれます。 - コーチの指導を仰ぐ以外に、社外で助け合える仲間の ネットワークを持っていますか?他社のあなたと同じ 分野の経営幹部の中に、親しい人がいますか? - (上記以外の章で、どのキャリアラダーでもメンターの重要性が繰り返し記載) 2. 応用パターン 〜小さいチーム、大きいチーム〜 ここで別の先生を呼んでみる

Slide 44

Slide 44 text

44 ②ピープルマネージャー&シニアなテックリード - ピープルマネージャーとは、”人事管理を専門に行うマネージャー” - このパターンを採用する際の前提となる”より大きなチーム”の定義は特にされていない - また、”比較的大規模なチーム”では、”TLのプロジェクト管理を補佐するプログラムマネージャーがいるか もしれない”という記載がある(プロジェクトを束ねる単位をプログラムと呼ぶことがある) 2. 応用パターン 〜小さいチーム、大きいチーム〜 ②のパターンを深掘りして考えてみる

Slide 45

Slide 45 text

45 ②ピープルマネージャー&シニアなテックリード - ピープルマネージャーとは、”人事管理を専門に行うマネージャー” - このパターンを採用する際の前提となる”より大きなチーム”の定義は特にされていない - また、”比較的大規模なチーム”では、”TLのプロジェクト管理を補佐するプログラムマネージャーがいるか もしれない”という記載がある(プロジェクトを束ねる単位をプログラムと呼ぶことがある) チームにおける”大きい”・”小さい”とは何か? - Google社内には、チームの大きさの基準があるのかもしれない(私はわからない) - あえて記載していないのは、必要に応じて(それこそマネージャーの才覚で)選択されているのかも 2. 応用パターン 〜小さいチーム、大きいチーム〜 ②のパターンを深掘りして考えてみる

Slide 46

Slide 46 text

46 『チームトポロジー』 - 4つの基本的なチームタイプと3つのインタラクションパ ターンに基づく、組織設計とチームインタラクションのため の実践的な適応モデルを紹介した本(JMAM紹介文より) - ダンバー数という認知限界の理論を紹介している - 約5人:ワーキングメモリを保持できる限界 - 約15人:深く信頼できる限界 - 約50人:相互信頼できる限界 - 約150人:他人の能力を認識できる限界 - いま、自分から見て、誰がどこまでで、誰がどこに該当する だろうか?メンバーから見たらどうか?それを考察して設計 することが、チームの大小を考えるヒントになるかも 2. 応用パターン 〜小さいチーム、大きいチーム〜 ここで別の先生を呼んでみる

Slide 47

Slide 47 text

47 1. 基本パターン 〜二人三脚でいこう〜 2. 応用パターン 〜小さいチーム、大きいチーム〜 3. 考察のまとめ Outline

Slide 48

Slide 48 text

48 基本パターン 〜二人三脚でいこう〜 3. 考察のまとめ 二人三脚でいこう EMの仕事=TLがやらない全て TLが願う状況をあなたは既に知っているかも 相容れない2つは大変だ TL EM

Slide 49

Slide 49 text

49 TLMというパターンもある メンターを探そう ・社内でも ・社外でも ・どんな役割だとしても ・それは”上司”に限らない ・探そう! 大規模ならロールは増える 認知限界(ダンバー数) ・身近な関係から  振り返ってみよう ・深く信頼できる  15人は誰なのか? ・現在の状況に鑑みる ・メンバーについても  ロールスイッチして  考察してみよう! 3. 考察のまとめ 応用パターン 〜小さいチーム、大きいチーム〜

Slide 50

Slide 50 text

50 Outline 1. 基本パターン 〜二人三脚でいこう〜 2. 応用パターン 〜小さいチーム、大きいチーム〜 3. 考察のまとめ 4. おわりに ←New!

Slide 51

Slide 51 text

51 4. おわりに 自分の会社のことを、何も話していませんでした。。。。引用と私見ばかりの発表ですいません。。。 Qiita Jobs にて、Devトークを公開しています。ビットキーの事例について、知りたい場合は是非にご登録ください 対象は、EMでも、TLでも、ICでも、何かしら情報がほしい方は、どなたでも。 ご紹介できるテーマ(例) - ハードウェアデバイスも絡んでの開発プロセス - スクラムのスケール(6つのスクラムチームで、1つのプロダクトを) - SLIモニタリングと、エラーバジェットによるメンテナビリティ向上 - 360度による評価制度の設計、導入したメリット/デメリット - エンジニアのスキル、スタートアップとしての文化醸成を評価する仕組み - OST(Open Space Technology)を活用した交流施策 - 他社さんとコラボして社外勉強会を進めた話と、技術広報の辛み - ぶっちゃけ、採用活動で、何を工夫してますか? - テスティング、QAに関して ご清聴、ありがとうございました…!