Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

エンジニアチームビルディングジャーニー

3,769 views

Published on

Engineering Manager Meetup #4のLT用資料です。

https://engineering-manager-meetup.connpass.com/event/116235/

元ネタ
https://productmanager55.hatenablog.com/entry/2018/12/15/012008

Published in: Engineering
  • Be the first to comment

エンジニアチームビルディングジャーニー

  1. 1. エンジニアチーム ビルディングジャーニー 2019/2/1 Engineering Manager Meetup #4 久津 佑介
  2. 2. 話したいこと ボロボロのチームとプロダクトを⽴て直した エンジニアリングマネージャーのお話
  3. 3. 話したいこと
  4. 4. 突然課せられたミッション 「あのアプリは今期戦略において重要なのに 品質がボロボロだから急いで直してこい」
  5. 5. 1年前の惨状(客観的事実) üバグ・障害の発⽣頻度が多い üテストフェーズで機能不備が多発しリリース延期が続出 ü仕様がブラックボックスすぎて調査に時間がかる üiOSとAndroidの意図しない機能差が多い üエンジニアのモチベーション&⾃⼰肯定感がほぼ皆無 üエンジニア間のコミュニケーションがほぼ皆無(忘年会がお通夜…) üエンジニア間のスキル差による権威勾配が⼤きい üエンジニアがすぐ辞めてしまうためナレッジが貯まらない üプロダクトとエンジニアチームの状況を考慮せずに次々要望を出す ü「ネガティブな緊急の仕様変更」を多発する ü失敗はエンジニアチームの責任にする プロダクト エンジニアチーム ステークホルダ
  6. 6. バッドサイクルが回っていた <バッドサイクル> 結果の質:成果が上がらない ↓ 関係の質:対⽴が⽣じ押し付けや命令が増える ↓ 思考の質:⾯⽩くなく受け⾝になる ↓ ⾏動の質:⾃発的・積極的な⾏動が起きない ↓ 結果の質:さらに成果が上がらない 『カイゼン・ジャーニー』より
  7. 7. ⽬指す姿 プロダクト エンジニアチーム ステークホルダ プロダクト エンジニアチーム ステークホルダ
  8. 8. グッドサイクルを回す <グッドサイクル> 関係の質:お互い尊重し⼀緒に考える ↓ 思考の質:気づきがあり⾯⽩い ↓ ⾏動の質:⾃分で考え⾃発的に⾏動する ↓ 結果の質:成果が得られる ↓ 関係の質:信頼関係が⾼まる 『カイゼン・ジャーニー』より
  9. 9. ビルディングジャーニーロードマップ 1. 外部環境を整える A) 改⾰の宣⾔・ブランディング B) 情報の可視化 C) 技術的負債の可視化と解消のメリットの説明 2. 内部環境を整える A) メンバーへの信頼を⽰す B) チームビジョンの再定義 C) モチベーション3.0と向き合ってくすぐる D) ⼼理的安全性の担保 3. 成⻑サイクルを回す A) 階段を刻み、踊り場で遊ばせる B) チームのカオスエンジニアリング C) 外部環境と内部環境のスピードを合わせる
  10. 10. 1) 外部環境を整える <グッドサイクル> 関係の質:お互い尊重し⼀緒に考える ↓ 思考の質:気づきがあり⾯⽩い ↓ ⾏動の質:⾃分で考え⾃発的に⾏動する ↓ 結果の質:成果が得られる ↓ 関係の質:信頼関係が⾼まる ココ!
  11. 11. 1-A) 改⾰の宣⾔・ブランディング • エンジニアチームの改⾰をステークホルダーに宣⾔する • 今まで以上に案件を受けられなくなることを伝える • 「改⾰に伴いご迷惑をおかけするかもしれませんがご協⼒くださいm(_ _)m」 • ⽬指すチームの⾔語化・ブランディング • 「継続的進化をするチーム」 • 「今後はどんどんアプリもチームも良くなって案件をたくさん受けられます」という、 改⾰による直接的なメリットのアピール
  12. 12. 1-B) 情報の可視化 • 案件決定プロセスの可視化とシンプル化 • エンジニアのモチベーションを下げる「ネガティブな仕様変更」を削減する狙い • 個別で来ていた案件依頼のフローを⼀本化し「案件統括」を設置 • 検討内容や決定事項をエンジニアにも公開 • エンジニアチームの状況の可視化 • キャパシティ以上の案件を受けることを防ぐ狙い • エンジニア⼀⼈⼀⼈の予定を公開することで、スコープ調整の説得⼒を持つ EM EM 案件統括 ⾒える ⾒える
  13. 13. 1-C) 技術的負債の可視化と解消のメリット説明 • フルリニューアルの実施のための準備 • バグ地獄の最⼤の原因「技術的負債の肥⼤化+ブラックボックス化」 • ⼀定期間新しい案件を受けられなくなる(=ビジネス影響が⼤きい)ので丁寧な説明が必要 • 技術的負債解消の可視化とメリットの説明 • 可視化は過去のバグ・不具合のうち技術的負債に起因するもの、それによる被害(コスト、 時間)を列挙するのみ → 説得⼒抜群w • このタイミングでのリニューアルが後の事業成⻑の最⼤化につながることを熱弁 • 「⼤きくジャンプする前にはしゃがみ込みが必要なんだ」 • 「リニューアルのついでに案件」は断固拒否することも宣⾔しておく
  14. 14. 外部環境を整えた • 内部環境の改⾰に集中できるようになる • 外部環境が起因して発⽣する無駄な作業を減らすことができる • 周りの協⼒を得ることができる
  15. 15. 2) 内部環境を整える <グッドサイクル> 関係の質:お互い尊重し⼀緒に考える ↓ 思考の質:気づきがあり⾯⽩い ↓ ⾏動の質:⾃分で考え⾃発的に⾏動する ↓ 結果の質:成果が得られる ↓ 関係の質:信頼関係が⾼まる ココ! ココ! ココ!
  16. 16. 2-A) メンバーへの信頼を⽰す • 兎にも⾓にもメンバーのモチベーションと⾃⼰肯定感を上げる • 前任の強権政治マネージメントからの脱却 • 「エンジニアに意思決定をさせる」ことを⽬指す • 「組織に使われている」から「⾃分で決めている」への意識のシフトチェンジ • メンバーへの信頼を⽰し、メンバーの意思決定を尊重する • 具体的に期待していることを⼝にする(思っているだけだと伝わらない) • 逆に期待していないことも伝える(⾃尊⼼が傷つかない範囲で) • 「○○さんはドキュメント作成は苦⼿だから期待しないけど、コーディングは信頼してるよ」 • メンバーの仕事に極⼒⼝を出さない • 信頼していると宣⾔した後に、細かくチェックしていたら⾔⾏不⼀致になる • 最初は問題が起こりまくるが「産みの苦しみ」として我慢する
  17. 17. 2-B) チームビジョンの再定義 • ⽬指すチームの⾔語化・ブランディング • 「継続的進化をするチーム」というビジョンをしつこいくらい語りまくる • 「俺はこうしたいんだ、だから協⼒してくれ」という姿勢で「求められている感」を醸成 • 歓迎される/されない⾏動の指針を⽰す • OK:バグの原因や改修⽅法をメンバーに共有しながら直す(=時間はかかる) • NG:⼀⼈で素早くバグを直す
  18. 18. 2-C) モチベーション3.0と向き合ってくすぐる “<モチベーション3.0>には三つの重要な要素がある。 ⼀つは<⾃律性>。⾃分の⼈⽣を⾃ら導きたいという欲 求のこと。⼆番⽬は<マスタリー(熟達)>。⾃分に とって意味のあることを上達させたいという衝動のこと。 三番⽬は<⽬的>。⾃分よりも⼤きいこと、⾃分の利益 を超えたことのために活動したい、という切なる思いの ことだ。”
  19. 19. • 1on1でどのタイプが⾒極めてインプットの仕⽅を変える • ⾃律性タイプ • "Why"をインプットして"What/When"に関してはある程度幅を持たせてメンバーが決め られるようにする • マスタリータイプ • "Why/What/When"をインプットして極上の"How"をアウトプットすることを期待する • ⽬的タイプ • "Why"を丁寧にインプットして"What"を⼀緒に考えてもらう 2-C) モチベーション3.0と向き合ってくすぐる
  20. 20. 2-D) ⼼理的安全性の担保 • ミーティングではとにかく明るく振る舞う • メンバーの話を聞くときは顔を⾒て聞く(キーボード打ちながらは絶対NG) • 問題をチームで解決する場を作り「もしこれでも解決しなかったら○○さんに声かけて」「○○さ んはその時こう助けてあげて」と、具体的な解決への道筋まで提⽰してあげる • メールやチャットでは即レス • もし本当に忙しくて質問を受ける余裕がない場合は、その状態を正直に⾔う • メンバーから出てきた意⾒はしっかり拾って、必ず何かしらの答え(採⽤するか⾒送るか)とその 理由を伝える
  21. 21. 内部環境を整えた • メンバーの顔⾊が明らかに良くなってきた • メンバーからの提案やメンバー同⼠のミーティングが増えた • それに伴いプロダクトの品質も少しずつ良くなってきた(=成果が出た)
  22. 22. 3) 成⻑サイクルを回す <グッドサイクル> 関係の質:お互い尊重し⼀緒に考える ↓ 思考の質:気づきがあり⾯⽩い ↓ ⾏動の質:⾃分で考え⾃発的に⾏動する ↓ 結果の質:成果が得られる ↓ 関係の質:信頼関係が⾼まる
  23. 23. 3-A) 階段を刻み、踊り場で遊ばせる • 成⻑への階段を刻んであげる • メンバーを1階から2階に上げる為に、 相⼿に合わせた⾼さ(=難易度)と、 歩幅(=導き⽅の丁寧さ)の階段を⽤ 意する • 階段を上ったら踊り場で遊ばせる • Range(=⾃由に動いていい範囲)と Reason(=やる⽬的)を伝えて⾃由に やらせる 『無理・無意味から職場を救うマネジメントの基礎理論』より
  24. 24. 3-B) チームのカオスエンジニアリング • 「役割と仕事分担」や「会議やミーティング設計」を意図的に壊してみる • 無駄が除去されてパフォーマンスが上がることがある • 突然1週間休んでみたり、EMが持っている仕事を丸投げしたりする • メンバーからも無駄の指摘が出やすくなる • 「無駄なものは変えていい」という意識が⽣まれる • マネージャーのボトルネックが無くなっていく • メンバーが⾃分たちだけでスピーディーに進められることが増えていく • マネージャーしかできないことなんて意外と少ない
  25. 25. 3-C) 外部環境と内部環境のスピードを合わせる • エンジニアチームのスピードに、ステークホルダーがついてこれなくなった • WIP(Work in Progress)が増えてきた • メンバーの不満が外に向くようになった • 外部環境を整えて、再びグッドサイクルを回す • 業務の効率化の提案 • 情報共有や調整開始のタイミングの⾒直し
  26. 26. 成⻑サイクルを回した • メンバーのパフォーマンスや信頼関係が⽬に⾒えて向上してきた • エンジニアチーム以外の組織も成⻑してきた • リリースできた機能が爆発的に増えた(=成果が⼤きくなってきた)
  27. 27. 1年後 プロダクト エンジニアチーム ステークホルダ プロダクト エンジニアチーム ステークホルダ
  28. 28. 1年前の惨状(客観的事実) üバグ・障害の発⽣頻度が多い üテストフェーズで機能不備が多発しリリース延期が続出 ü仕様がブラックボックスすぎて調査に時間がかる üiOSとAndroidの意図しない機能差が多い üエンジニアのモチベーション&⾃⼰肯定感がほぼ皆無 üエンジニア間のコミュニケーションがほぼ皆無(忘年会がお通夜…) üエンジニア間のスキル差による権威勾配が⼤きい üエンジニアがすぐ辞めてしまうためナレッジが貯まらない üプロダクトとエンジニアチームの状況を考慮せずに次々要望を出す ü「ネガティブな緊急の仕様変更」を多発する ü失敗はエンジニアチームの責任にする プロダクト エンジニアチーム ステークホルダ <再掲>
  29. 29. 1年後の状態 üバグ・障害数9割減 ü仕様のブラックボックスは完璧に解消 üiOSとAndroidの機能差は「意図するもの」のみに üフルリニューアル⼤成功+その後新機能リリース3件連続成功 üエンジニアのモチベーションが⾶躍的向上 üエンジニア間のコミュニケーション活性化(忘年会が楽しい!) üエンジニア間のスキル差を埋めようとする活動(勉強会やモブプロなど) üエンジニアの離職率が劇的低下 üエンジニアチームと良好な関係を保ち、かつお互い刺激し合っている ü「緊急の仕様変更」はポジティブなもののみ üただし⼀部の組織はまだ改善しきれていない(今後の継続課題) プロダクト エンジニアチーム ステークホルダ
  30. 30. エンジニアリングマネージャーの変化 1年前 • メンバーの顔⾊を伺いながら孤軍奮闘 • メンバーとの1on1で愚痴と向き合う • 朝会で⼀⽣懸命ファシリテート 1年後 • メンバーと⼀緒にチーム作り • メンバーとの1on1で希望と向き合う • 朝会で端っこでコーヒー飲みながらニヤニヤ
  31. 31. ビルディングジャーニーをしてみて チームのビルディングには多くの時間と根気が必要 苦悩や葛藤も多いが⼀つずつ乗り越えていかなければならない でも乗り越えた先の「エンジニアが活き活き働く姿」を想像すれば 結構頑張れちゃうはず 今は朝会の最中にコーヒー飲んでニヤニヤしながら 次のジャーニープランを考えてる時間が幸せ
  32. 32. 参考図書
  33. 33. Next ジャーニー…
  34. 34. まだ⼊社前だけど… ご応募ください or DMください
  35. 35. ご静聴ありがとうございました

×