Download as PDF, PPTX
Uploaded byYusuke Hisatsu
エンジニアチームビルディングジャーニー
Engineering Manager Meetup #4のLT用資料です。 https://engineering-manager-meetup.connpass.com/event/116235/ 元ネタ https://productmanager55.hatenablog.com/entry/2018/12/15/012008
エンジニアチームビルディングジャーニー
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. ビルディングジャーニーロードマップ 1. 外部環境を整える A) 改⾰の宣⾔・ブランディング B)情報の可視化 C) 技術的負債の可視化と解消のメリットの説明 2. 内部環境を整える A) メンバーへの信頼を⽰す B) チームビジョンの再定義 C) モチベーション3.0と向き合ってくすぐる D) ⼼理的安全性の担保 3. 成⻑サイクルを回す A) 階段を刻み、踊り場で遊ばせる B) チームのカオスエンジニアリング C) 外部環境と内部環境のスピードを合わせる
- 10.
- 11. 1-A) 改⾰の宣⾔・ブランディング • エンジニアチームの改⾰をステークホルダーに宣⾔する •今まで以上に案件を受けられなくなることを伝える • 「改⾰に伴いご迷惑をおかけするかもしれませんがご協⼒くださいm(_ _)m」 • ⽬指すチームの⾔語化・ブランディング • 「継続的進化をするチーム」 • 「今後はどんどんアプリもチームも良くなって案件をたくさん受けられます」という、 改⾰による直接的なメリットのアピール
- 12. 1-B) 情報の可視化 • 案件決定プロセスの可視化とシンプル化 •エンジニアのモチベーションを下げる「ネガティブな仕様変更」を削減する狙い • 個別で来ていた案件依頼のフローを⼀本化し「案件統括」を設置 • 検討内容や決定事項をエンジニアにも公開 • エンジニアチームの状況の可視化 • キャパシティ以上の案件を受けることを防ぐ狙い • エンジニア⼀⼈⼀⼈の予定を公開することで、スコープ調整の説得⼒を持つ EM EM 案件統括 ⾒える ⾒える
- 13. 1-C) 技術的負債の可視化と解消のメリット説明 • フルリニューアルの実施のための準備 •バグ地獄の最⼤の原因「技術的負債の肥⼤化＋ブラックボックス化」 • ⼀定期間新しい案件を受けられなくなる（＝ビジネス影響が⼤きい）ので丁寧な説明が必要 • 技術的負債解消の可視化とメリットの説明 • 可視化は過去のバグ・不具合のうち技術的負債に起因するもの、それによる被害（コスト、 時間）を列挙するのみ → 説得⼒抜群w • このタイミングでのリニューアルが後の事業成⻑の最⼤化につながることを熱弁 • 「⼤きくジャンプする前にはしゃがみ込みが必要なんだ」 • 「リニューアルのついでに案件」は断固拒否することも宣⾔しておく
- 14.
- 15.
- 16. 2-A) メンバーへの信頼を⽰す • 兎にも⾓にもメンバーのモチベーションと⾃⼰肯定感を上げる •前任の強権政治マネージメントからの脱却 • 「エンジニアに意思決定をさせる」ことを⽬指す • 「組織に使われている」から「⾃分で決めている」への意識のシフトチェンジ • メンバーへの信頼を⽰し、メンバーの意思決定を尊重する • 具体的に期待していることを⼝にする（思っているだけだと伝わらない） • 逆に期待していないことも伝える（⾃尊⼼が傷つかない範囲で） • 「○○さんはドキュメント作成は苦⼿だから期待しないけど、コーディングは信頼してるよ」 • メンバーの仕事に極⼒⼝を出さない • 信頼していると宣⾔した後に、細かくチェックしていたら⾔⾏不⼀致になる • 最初は問題が起こりまくるが「産みの苦しみ」として我慢する
- 17. 2-B) チームビジョンの再定義 • ⽬指すチームの⾔語化・ブランディング •「継続的進化をするチーム」というビジョンをしつこいくらい語りまくる • 「俺はこうしたいんだ、だから協⼒してくれ」という姿勢で「求められている感」を醸成 • 歓迎される/されない⾏動の指針を⽰す • OK：バグの原因や改修⽅法をメンバーに共有しながら直す（＝時間はかかる） • NG：⼀⼈で素早くバグを直す
- 18.
- 19. • 1on1でどのタイプが⾒極めてインプットの仕⽅を変える • ⾃律性タイプ •"Why"をインプットして"What/When"に関してはある程度幅を持たせてメンバーが決め られるようにする • マスタリータイプ • "Why/What/When"をインプットして極上の"How"をアウトプットすることを期待する • ⽬的タイプ • "Why"を丁寧にインプットして"What"を⼀緒に考えてもらう 2-C) モチベーション3.0と向き合ってくすぐる
- 20. 2-D) ⼼理的安全性の担保 • ミーティングではとにかく明るく振る舞う •メンバーの話を聞くときは顔を⾒て聞く（キーボード打ちながらは絶対NG） • 問題をチームで解決する場を作り「もしこれでも解決しなかったら○○さんに声かけて」「○○さ んはその時こう助けてあげて」と、具体的な解決への道筋まで提⽰してあげる • メールやチャットでは即レス • もし本当に忙しくて質問を受ける余裕がない場合は、その状態を正直に⾔う • メンバーから出てきた意⾒はしっかり拾って、必ず何かしらの答え（採⽤するか⾒送るか）とその 理由を伝える
- 21. 内部環境を整えた • メンバーの顔⾊が明らかに良くなってきた • メンバーからの提案やメンバー同⼠のミーティングが増えた •それに伴いプロダクトの品質も少しずつ良くなってきた（＝成果が出た）
- 22.
- 23. 3-A) 階段を刻み、踊り場で遊ばせる • 成⻑への階段を刻んであげる •メンバーを１階から２階に上げる為に、 相⼿に合わせた⾼さ（＝難易度）と、 歩幅（＝導き⽅の丁寧さ）の階段を⽤ 意する • 階段を上ったら踊り場で遊ばせる • Range（＝⾃由に動いていい範囲）と Reason（＝やる⽬的）を伝えて⾃由に やらせる 『無理・無意味から職場を救うマネジメントの基礎理論』より
- 24. 3-B) チームのカオスエンジニアリング • 「役割と仕事分担」や「会議やミーティング設計」を意図的に壊してみる •無駄が除去されてパフォーマンスが上がることがある • 突然１週間休んでみたり、EMが持っている仕事を丸投げしたりする • メンバーからも無駄の指摘が出やすくなる • 「無駄なものは変えていい」という意識が⽣まれる • マネージャーのボトルネックが無くなっていく • メンバーが⾃分たちだけでスピーディーに進められることが増えていく • マネージャーしかできないことなんて意外と少ない
- 25. 3-C) 外部環境と内部環境のスピードを合わせる • エンジニアチームのスピードに、ステークホルダーがついてこれなくなった •WIP（Work in Progress）が増えてきた • メンバーの不満が外に向くようになった • 外部環境を整えて、再びグッドサイクルを回す • 業務の効率化の提案 • 情報共有や調整開始のタイミングの⾒直し
- 26. 成⻑サイクルを回した • メンバーのパフォーマンスや信頼関係が⽬に⾒えて向上してきた • エンジニアチーム以外の組織も成⻑してきた •リリースできた機能が爆発的に増えた（＝成果が⼤きくなってきた）
- 27.
- 28.
- 29.
- 30. エンジニアリングマネージャーの変化 １年前 • メンバーの顔⾊を伺いながら孤軍奮闘 • メンバーとの1on1で愚痴と向き合う •朝会で⼀⽣懸命ファシリテート １年後 • メンバーと⼀緒にチーム作り • メンバーとの1on1で希望と向き合う • 朝会で端っこでコーヒー飲みながらニヤニヤ
- 31.
- 32.
- 33.
- 34.
- 35.