Save 37% off PRO during our Black Friday Sale! »

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

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

8a84031d6872ed7d2db6ce8b61f143a2?s=128

Yusuke Hisatsu

February 01, 2019
Tweet

Transcript

  1. エンジニアチーム ビルディングジャーニー 2019/2/1 Engineering Manager Meetup #4 久津 佑介

  2. 話したいこと ボロボロのチームとプロダクトを⽴て直した エンジニアリングマネージャーのお話

  3. 話したいこと

  4. 突然課せられたミッション 「あのアプリは今期戦略において重要なのに 品質がボロボロだから急いで直してこい」

  5. 1年前の惨状(客観的事実) üバグ・障害の発⽣頻度が多い üテストフェーズで機能不備が多発しリリース延期が続出 ü仕様がブラックボックスすぎて調査に時間がかる üiOSとAndroidの意図しない機能差が多い üエンジニアのモチベーション&⾃⼰肯定感がほぼ皆無 üエンジニア間のコミュニケーションがほぼ皆無(忘年会がお通夜…) üエンジニア間のスキル差による権威勾配が⼤きい üエンジニアがすぐ辞めてしまうためナレッジが貯まらない üプロダクトとエンジニアチームの状況を考慮せずに次々要望を出す

    ü「ネガティブな緊急の仕様変更」を多発する ü失敗はエンジニアチームの責任にする プロダクト エンジニアチーム ステークホルダ
  6. バッドサイクルが回っていた <バッドサイクル> 結果の質:成果が上がらない ↓ 関係の質:対⽴が⽣じ押し付けや命令が増える ↓ 思考の質:⾯⽩くなく受け⾝になる ↓ ⾏動の質:⾃発的・積極的な⾏動が起きない ↓

    結果の質:さらに成果が上がらない 『カイゼン・ジャーニー』より
  7. ⽬指す姿 プロダクト エンジニアチーム ステークホルダ プロダクト エンジニアチーム ステークホルダ

  8. グッドサイクルを回す <グッドサイクル> 関係の質:お互い尊重し⼀緒に考える ↓ 思考の質:気づきがあり⾯⽩い ↓ ⾏動の質:⾃分で考え⾃発的に⾏動する ↓ 結果の質:成果が得られる ↓

    関係の質:信頼関係が⾼まる 『カイゼン・ジャーニー』より
  9. ビルディングジャーニーロードマップ 1. 外部環境を整える A) 改⾰の宣⾔・ブランディング B) 情報の可視化 C) 技術的負債の可視化と解消のメリットの説明 2.

    内部環境を整える A) メンバーへの信頼を⽰す B) チームビジョンの再定義 C) モチベーション3.0と向き合ってくすぐる D) ⼼理的安全性の担保 3. 成⻑サイクルを回す A) 階段を刻み、踊り場で遊ばせる B) チームのカオスエンジニアリング C) 外部環境と内部環境のスピードを合わせる
  10. 1) 外部環境を整える <グッドサイクル> 関係の質:お互い尊重し⼀緒に考える ↓ 思考の質:気づきがあり⾯⽩い ↓ ⾏動の質:⾃分で考え⾃発的に⾏動する ↓ 結果の質:成果が得られる

    ↓ 関係の質:信頼関係が⾼まる ココ!
  11. 1-A) 改⾰の宣⾔・ブランディング • エンジニアチームの改⾰をステークホルダーに宣⾔する • 今まで以上に案件を受けられなくなることを伝える • 「改⾰に伴いご迷惑をおかけするかもしれませんがご協⼒くださいm(_ _)m」 •

    ⽬指すチームの⾔語化・ブランディング • 「継続的進化をするチーム」 • 「今後はどんどんアプリもチームも良くなって案件をたくさん受けられます」という、 改⾰による直接的なメリットのアピール
  12. 1-B) 情報の可視化 • 案件決定プロセスの可視化とシンプル化 • エンジニアのモチベーションを下げる「ネガティブな仕様変更」を削減する狙い • 個別で来ていた案件依頼のフローを⼀本化し「案件統括」を設置 • 検討内容や決定事項をエンジニアにも公開

    • エンジニアチームの状況の可視化 • キャパシティ以上の案件を受けることを防ぐ狙い • エンジニア⼀⼈⼀⼈の予定を公開することで、スコープ調整の説得⼒を持つ EM EM 案件統括 ⾒える ⾒える
  13. 1-C) 技術的負債の可視化と解消のメリット説明 • フルリニューアルの実施のための準備 • バグ地獄の最⼤の原因「技術的負債の肥⼤化+ブラックボックス化」 • ⼀定期間新しい案件を受けられなくなる(=ビジネス影響が⼤きい)ので丁寧な説明が必要 • 技術的負債解消の可視化とメリットの説明

    • 可視化は過去のバグ・不具合のうち技術的負債に起因するもの、それによる被害(コスト、 時間)を列挙するのみ → 説得⼒抜群w • このタイミングでのリニューアルが後の事業成⻑の最⼤化につながることを熱弁 • 「⼤きくジャンプする前にはしゃがみ込みが必要なんだ」 • 「リニューアルのついでに案件」は断固拒否することも宣⾔しておく
  14. 外部環境を整えた • 内部環境の改⾰に集中できるようになる • 外部環境が起因して発⽣する無駄な作業を減らすことができる • 周りの協⼒を得ることができる

  15. 2) 内部環境を整える <グッドサイクル> 関係の質:お互い尊重し⼀緒に考える ↓ 思考の質:気づきがあり⾯⽩い ↓ ⾏動の質:⾃分で考え⾃発的に⾏動する ↓ 結果の質:成果が得られる

    ↓ 関係の質:信頼関係が⾼まる ココ! ココ! ココ!
  16. 2-A) メンバーへの信頼を⽰す • 兎にも⾓にもメンバーのモチベーションと⾃⼰肯定感を上げる • 前任の強権政治マネージメントからの脱却 • 「エンジニアに意思決定をさせる」ことを⽬指す • 「組織に使われている」から「⾃分で決めている」への意識のシフトチェンジ

    • メンバーへの信頼を⽰し、メンバーの意思決定を尊重する • 具体的に期待していることを⼝にする(思っているだけだと伝わらない) • 逆に期待していないことも伝える(⾃尊⼼が傷つかない範囲で) • 「◦◦さんはドキュメント作成は苦⼿だから期待しないけど、コーディングは信頼してるよ」 • メンバーの仕事に極⼒⼝を出さない • 信頼していると宣⾔した後に、細かくチェックしていたら⾔⾏不⼀致になる • 最初は問題が起こりまくるが「産みの苦しみ」として我慢する
  17. 2-B) チームビジョンの再定義 • ⽬指すチームの⾔語化・ブランディング • 「継続的進化をするチーム」というビジョンをしつこいくらい語りまくる • 「俺はこうしたいんだ、だから協⼒してくれ」という姿勢で「求められている感」を醸成 • 歓迎される/されない⾏動の指針を⽰す

    • OK:バグの原因や改修⽅法をメンバーに共有しながら直す(=時間はかかる) • NG:⼀⼈で素早くバグを直す
  18. 2-C) モチベーション3.0と向き合ってくすぐる “<モチベーション3.0>には三つの重要な要素がある。 ⼀つは<⾃律性>。⾃分の⼈⽣を⾃ら導きたいという欲 求のこと。⼆番⽬は<マスタリー(熟達)>。⾃分に とって意味のあることを上達させたいという衝動のこと。 三番⽬は<⽬的>。⾃分よりも⼤きいこと、⾃分の利益 を超えたことのために活動したい、という切なる思いの ことだ。”

  19. • 1on1でどのタイプが⾒極めてインプットの仕⽅を変える • ⾃律性タイプ • "Why"をインプットして"What/When"に関してはある程度幅を持たせてメンバーが決め られるようにする • マスタリータイプ •

    "Why/What/When"をインプットして極上の"How"をアウトプットすることを期待する • ⽬的タイプ • "Why"を丁寧にインプットして"What"を⼀緒に考えてもらう 2-C) モチベーション3.0と向き合ってくすぐる
  20. 2-D) ⼼理的安全性の担保 • ミーティングではとにかく明るく振る舞う • メンバーの話を聞くときは顔を⾒て聞く(キーボード打ちながらは絶対NG) • 問題をチームで解決する場を作り「もしこれでも解決しなかったら◦◦さんに声かけて」「◦◦さ んはその時こう助けてあげて」と、具体的な解決への道筋まで提⽰してあげる •

    メールやチャットでは即レス • もし本当に忙しくて質問を受ける余裕がない場合は、その状態を正直に⾔う • メンバーから出てきた意⾒はしっかり拾って、必ず何かしらの答え(採⽤するか⾒送るか)とその 理由を伝える
  21. 内部環境を整えた • メンバーの顔⾊が明らかに良くなってきた • メンバーからの提案やメンバー同⼠のミーティングが増えた • それに伴いプロダクトの品質も少しずつ良くなってきた(=成果が出た)

  22. 3) 成⻑サイクルを回す <グッドサイクル> 関係の質:お互い尊重し⼀緒に考える ↓ 思考の質:気づきがあり⾯⽩い ↓ ⾏動の質:⾃分で考え⾃発的に⾏動する ↓ 結果の質:成果が得られる

    ↓ 関係の質:信頼関係が⾼まる
  23. 3-A) 階段を刻み、踊り場で遊ばせる • 成⻑への階段を刻んであげる • メンバーを1階から2階に上げる為に、 相⼿に合わせた⾼さ(=難易度)と、 歩幅(=導き⽅の丁寧さ)の階段を⽤ 意する •

    階段を上ったら踊り場で遊ばせる • Range(=⾃由に動いていい範囲)と Reason(=やる⽬的)を伝えて⾃由に やらせる 『無理・無意味から職場を救うマネジメントの基礎理論』より
  24. 3-B) チームのカオスエンジニアリング • 「役割と仕事分担」や「会議やミーティング設計」を意図的に壊してみる • 無駄が除去されてパフォーマンスが上がることがある • 突然1週間休んでみたり、EMが持っている仕事を丸投げしたりする • メンバーからも無駄の指摘が出やすくなる

    • 「無駄なものは変えていい」という意識が⽣まれる • マネージャーのボトルネックが無くなっていく • メンバーが⾃分たちだけでスピーディーに進められることが増えていく • マネージャーしかできないことなんて意外と少ない
  25. 3-C) 外部環境と内部環境のスピードを合わせる • エンジニアチームのスピードに、ステークホルダーがついてこれなくなった • WIP(Work in Progress)が増えてきた • メンバーの不満が外に向くようになった

    • 外部環境を整えて、再びグッドサイクルを回す • 業務の効率化の提案 • 情報共有や調整開始のタイミングの⾒直し
  26. 成⻑サイクルを回した • メンバーのパフォーマンスや信頼関係が⽬に⾒えて向上してきた • エンジニアチーム以外の組織も成⻑してきた • リリースできた機能が爆発的に増えた(=成果が⼤きくなってきた)

  27. 1年後 プロダクト エンジニアチーム ステークホルダ プロダクト エンジニアチーム ステークホルダ

  28. 1年前の惨状(客観的事実) üバグ・障害の発⽣頻度が多い üテストフェーズで機能不備が多発しリリース延期が続出 ü仕様がブラックボックスすぎて調査に時間がかる üiOSとAndroidの意図しない機能差が多い üエンジニアのモチベーション&⾃⼰肯定感がほぼ皆無 üエンジニア間のコミュニケーションがほぼ皆無(忘年会がお通夜…) üエンジニア間のスキル差による権威勾配が⼤きい üエンジニアがすぐ辞めてしまうためナレッジが貯まらない üプロダクトとエンジニアチームの状況を考慮せずに次々要望を出す

    ü「ネガティブな緊急の仕様変更」を多発する ü失敗はエンジニアチームの責任にする プロダクト エンジニアチーム ステークホルダ <再掲>
  29. 1年後の状態 üバグ・障害数9割減 ü仕様のブラックボックスは完璧に解消 üiOSとAndroidの機能差は「意図するもの」のみに üフルリニューアル⼤成功+その後新機能リリース3件連続成功 üエンジニアのモチベーションが⾶躍的向上 üエンジニア間のコミュニケーション活性化(忘年会が楽しい!) üエンジニア間のスキル差を埋めようとする活動(勉強会やモブプロなど) üエンジニアの離職率が劇的低下 üエンジニアチームと良好な関係を保ち、かつお互い刺激し合っている

    ü「緊急の仕様変更」はポジティブなもののみ üただし⼀部の組織はまだ改善しきれていない(今後の継続課題) プロダクト エンジニアチーム ステークホルダ
  30. エンジニアリングマネージャーの変化 1年前 • メンバーの顔⾊を伺いながら孤軍奮闘 • メンバーとの1on1で愚痴と向き合う • 朝会で⼀⽣懸命ファシリテート 1年後 •

    メンバーと⼀緒にチーム作り • メンバーとの1on1で希望と向き合う • 朝会で端っこでコーヒー飲みながらニヤニヤ
  31. ビルディングジャーニーをしてみて チームのビルディングには多くの時間と根気が必要 苦悩や葛藤も多いが⼀つずつ乗り越えていかなければならない でも乗り越えた先の「エンジニアが活き活き働く姿」を想像すれば 結構頑張れちゃうはず 今は朝会の最中にコーヒー飲んでニヤニヤしながら 次のジャーニープランを考えてる時間が幸せ

  32. 参考図書

  33. Next ジャーニー…

  34. まだ⼊社前だけど… ご応募ください or DMください

  35. ご静聴ありがとうございました