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

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

Yusuke Hisatsu
February 01, 2019

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

Yusuke Hisatsu

February 01, 2019
Tweet

More Decks by Yusuke Hisatsu

Other Decks in Business

Transcript

  1. ビルディングジャーニーロードマップ 1. 外部環境を整える A) 改⾰の宣⾔・ブランディング B) 情報の可視化 C) 技術的負債の可視化と解消のメリットの説明 2.

    内部環境を整える A) メンバーへの信頼を⽰す B) チームビジョンの再定義 C) モチベーション3.0と向き合ってくすぐる D) ⼼理的安全性の担保 3. 成⻑サイクルを回す A) 階段を刻み、踊り場で遊ばせる B) チームのカオスエンジニアリング C) 外部環境と内部環境のスピードを合わせる
  2. 1-A) 改⾰の宣⾔・ブランディング • エンジニアチームの改⾰をステークホルダーに宣⾔する • 今まで以上に案件を受けられなくなることを伝える • 「改⾰に伴いご迷惑をおかけするかもしれませんがご協⼒くださいm(_ _)m」 •

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

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

    • 可視化は過去のバグ・不具合のうち技術的負債に起因するもの、それによる被害(コスト、 時間)を列挙するのみ → 説得⼒抜群w • このタイミングでのリニューアルが後の事業成⻑の最⼤化につながることを熱弁 • 「⼤きくジャンプする前にはしゃがみ込みが必要なんだ」 • 「リニューアルのついでに案件」は断固拒否することも宣⾔しておく
  5. 2-A) メンバーへの信頼を⽰す • 兎にも⾓にもメンバーのモチベーションと⾃⼰肯定感を上げる • 前任の強権政治マネージメントからの脱却 • 「エンジニアに意思決定をさせる」ことを⽬指す • 「組織に使われている」から「⾃分で決めている」への意識のシフトチェンジ

    • メンバーへの信頼を⽰し、メンバーの意思決定を尊重する • 具体的に期待していることを⼝にする(思っているだけだと伝わらない) • 逆に期待していないことも伝える(⾃尊⼼が傷つかない範囲で) • 「◦◦さんはドキュメント作成は苦⼿だから期待しないけど、コーディングは信頼してるよ」 • メンバーの仕事に極⼒⼝を出さない • 信頼していると宣⾔した後に、細かくチェックしていたら⾔⾏不⼀致になる • 最初は問題が起こりまくるが「産みの苦しみ」として我慢する
  6. • 1on1でどのタイプが⾒極めてインプットの仕⽅を変える • ⾃律性タイプ • "Why"をインプットして"What/When"に関してはある程度幅を持たせてメンバーが決め られるようにする • マスタリータイプ •

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

    メールやチャットでは即レス • もし本当に忙しくて質問を受ける余裕がない場合は、その状態を正直に⾔う • メンバーから出てきた意⾒はしっかり拾って、必ず何かしらの答え(採⽤するか⾒送るか)とその 理由を伝える
  8. 3-A) 階段を刻み、踊り場で遊ばせる • 成⻑への階段を刻んであげる • メンバーを1階から2階に上げる為に、 相⼿に合わせた⾼さ(=難易度)と、 歩幅(=導き⽅の丁寧さ)の階段を⽤ 意する •

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

    • 「無駄なものは変えていい」という意識が⽣まれる • マネージャーのボトルネックが無くなっていく • メンバーが⾃分たちだけでスピーディーに進められることが増えていく • マネージャーしかできないことなんて意外と少ない
  10. エンジニアリングマネージャーの変化 1年前 • メンバーの顔⾊を伺いながら孤軍奮闘 • メンバーとの1on1で愚痴と向き合う • 朝会で⼀⽣懸命ファシリテート 1年後 •

    メンバーと⼀緒にチーム作り • メンバーとの1on1で希望と向き合う • 朝会で端っこでコーヒー飲みながらニヤニヤ