Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Masahiro Sato
November 18, 2022
280

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

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

Masahiro Sato

November 18, 2022
Tweet

Transcript

  1. 佐藤 正大 株式会社ビットキー - Manager of VPoE Office - Manager

    of bitkey platform @m3hiro3 | まさひろさん
  2. 4 - EMになりたい人 - EMになりたての人 - EMになったけど、悩んでいる人 - EMとの関係性に悩んでいる人 -

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

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

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

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

    として、2つをあげている - EM(Engineering Manager) - 管理者、人員のリーダー、エンジニア経験者 - TM(Tech Lead) - 技術的取り組みを主導する者 - リーダーシップの役割以外 - IC(Individual Contributor) - 部下を持たずに個人としてチームに貢献する社員
  7. 14 - これ以降、本書籍を”フラミンゴ先生”と呼びます - 正確には、”ベニイロフラミンゴ”とのことです - これ以降、書籍の引用が多くあります - 引用部分は、”イタリック体” で記載します

    - Googleが言ってるから正解という考えではなく アプローチとして有用かと思い、紹介します - もし、この本を熟読された方がいらっしゃれば 考察の部分だけ耳を傾けたいただけたら嬉しいです 0. Approach アプローチを紹介します
  8. 18 - この本にある原則を超意訳すると、1人の人間じゃ大変だよ - TLとEMは”二人三脚”でいくべしと書いている - TLの役割 - 製品の技術的側面を担当 -

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

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

    ビジネス要件と個々のチームメンバーの要求とは必ずしも相容れないため、 このことがマネージャーを難しい立場に置く可能性がある場合が多い 1. 基本パターン 〜二人三脚でいこう〜 フラミンゴ先生に学ぶ
  11. 28 1. 基本パターン 〜二人三脚でいこう〜 ここで考察してみる - 簡単にまとめると - EMとTLは、”二人三脚”で歩むべし - TLは、”製品の技術的側面”を担当する

    - EMは、”TLも含んだ”ピープルの側面と、”製品がビジネス要件を満たすこと”に責任を持つ - こう考えると、わかりやすいのでは? - EMの仕事=TLがやらない全て
  12. 34 - EMとは、TLというAに対する、Aバー - EMの仕事=TLがやらない全て - TLを考えることで、EMが見えてくると思う - ”技術的な側面を担う”というTLの役割の方が、”EMの仕事”よりも理解しやすいのではないか? 特に、あなたにエンジニア経験があるならば、”TLの仕事”は大変さも、責任も理解できるはず

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

    (技術的な決定と選択、アーキテクチャー、優先度、開発速度、プロジェクト管理一般は、どう考えても大 変) - むしろ、TLの仕事の困難さを理解しているからこそ、”TLが願う状況を既に知っている”のではないか だからこそ、”TLがTL業務に集中するための全て”をEMは行うと考えるのが良いのではないか? - さらに、”二人三脚”の原則があるとすれば、”大きくTLに頼って、任せてもいい”のではないか? (TLが持っているテクノロジーの力こそが、プロダクトの価値を産む源泉となるはずだから) 1. 基本パターン 〜二人三脚でいこう〜 つまり? TL EM
  14. 42 ①TLM(テックリードマネージャー) - TLMの仕事は入り組んでおり、 - 個別の作業、移譲、ピープルマネジメントのバランスを取る方法を学ばなければならないことが多い - 通常、TLMは、より熟練したTLMからの高度なメンタリングと支援を必要とする - 新しくTLMになった者に勧めるのは、この主題に対してGoogleが提供する複数の講習の受講に加え、役職

    に慣れていく際に、定期的なアドバイスをくれるシニアなメンターを探し出すことである メンタリングを受ける/メンターを探す - チームの外部に頼るという選択肢を、常に持ち続けると良いかも - 大企業の場合、社内Wiki・ポータルに社員紹介があるはず、他部署でも意外と親身になってくれる - スタートアップの場合、同じ悩み・境遇の人はいる、カジュアル面談などの機会は意外と多い 2. 応用パターン 〜小さいチーム、大きいチーム〜 ①のパターンを深掘りして考えてみる
  15. 43 『エンジニアのためのマネジメントキャリアパス』 - 第8章 経営幹部にて、CTOとVPoEについて説明 - ”自己診断用の質問リスト”がある(以下一部を抜粋) - あなた(CTO)は社費もしくは自費でプロのコーチの指 導を受けていますか?たとえ「自腹」でも賢い投資と

    言えます。コーチは助言も直言もしてくれますし、友 達と違ってあなたのどんな言葉にもきちんと耳を傾け てくれます。 - コーチの指導を仰ぐ以外に、社外で助け合える仲間の ネットワークを持っていますか?他社のあなたと同じ 分野の経営幹部の中に、親しい人がいますか? - (上記以外の章で、どのキャリアラダーでもメンターの重要性が繰り返し記載) 2. 応用パターン 〜小さいチーム、大きいチーム〜 ここで別の先生を呼んでみる
  16. 46 『チームトポロジー』 - 4つの基本的なチームタイプと3つのインタラクションパ ターンに基づく、組織設計とチームインタラクションのため の実践的な適応モデルを紹介した本(JMAM紹介文より) - ダンバー数という認知限界の理論を紹介している - 約5人:ワーキングメモリを保持できる限界

    - 約15人:深く信頼できる限界 - 約50人:相互信頼できる限界 - 約150人:他人の能力を認識できる限界 - いま、自分から見て、誰がどこまでで、誰がどこに該当する だろうか?メンバーから見たらどうか?それを考察して設計 することが、チームの大小を考えるヒントになるかも 2. 応用パターン 〜小さいチーム、大きいチーム〜 ここで別の先生を呼んでみる
  17. 49 TLMというパターンもある メンターを探そう ・社内でも ・社外でも ・どんな役割だとしても ・それは”上司”に限らない ・探そう! 大規模ならロールは増える 認知限界(ダンバー数)

    ・身近な関係から  振り返ってみよう ・深く信頼できる  15人は誰なのか? ・現在の状況に鑑みる ・メンバーについても  ロールスイッチして  考察してみよう! 3. 考察のまとめ 応用パターン 〜小さいチーム、大きいチーム〜
  18. 51 4. おわりに 自分の会社のことを、何も話していませんでした。。。。引用と私見ばかりの発表ですいません。。。 Qiita Jobs にて、Devトークを公開しています。ビットキーの事例について、知りたい場合は是非にご登録ください 対象は、EMでも、TLでも、ICでも、何かしら情報がほしい方は、どなたでも。 ご紹介できるテーマ(例) -

    ハードウェアデバイスも絡んでの開発プロセス - スクラムのスケール(6つのスクラムチームで、1つのプロダクトを) - SLIモニタリングと、エラーバジェットによるメンテナビリティ向上 - 360度による評価制度の設計、導入したメリット/デメリット - エンジニアのスキル、スタートアップとしての文化醸成を評価する仕組み - OST(Open Space Technology)を活用した交流施策 - 他社さんとコラボして社外勉強会を進めた話と、技術広報の辛み - ぶっちゃけ、採用活動で、何を工夫してますか? - テスティング、QAに関して ご清聴、ありがとうございました…!