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