More Related Content Similar to エンジニアチームビルディングジャーニー (20) More from Yusuke Hisatsu (7) エンジニアチームビルディングジャーニー12. 1-B) 情報の可視化
• 案件決定プロセスの可視化とシンプル化
• エンジニアのモチベーションを下げる「ネガティブな仕様変更」を削減する狙い
• 個別で来ていた案件依頼のフローを⼀本化し「案件統括」を設置
• 検討内容や決定事項をエンジニアにも公開
• エンジニアチームの状況の可視化
• キャパシティ以上の案件を受けることを防ぐ狙い
• エンジニア⼀⼈⼀⼈の予定を公開することで、スコープ調整の説得⼒を持つ
EM
EM
案件統括
⾒える ⾒える
13. 1-C) 技術的負債の可視化と解消のメリット説明
• フルリニューアルの実施のための準備
• バグ地獄の最⼤の原因「技術的負債の肥⼤化+ブラックボックス化」
• ⼀定期間新しい案件を受けられなくなる(=ビジネス影響が⼤きい)ので丁寧な説明が必要
• 技術的負債解消の可視化とメリットの説明
• 可視化は過去のバグ・不具合のうち技術的負債に起因するもの、それによる被害(コスト、
時間)を列挙するのみ → 説得⼒抜群w
• このタイミングでのリニューアルが後の事業成⻑の最⼤化につながることを熱弁
• 「⼤きくジャンプする前にはしゃがみ込みが必要なんだ」
• 「リニューアルのついでに案件」は断固拒否することも宣⾔しておく
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)
• 問題をチームで解決する場を作り「もしこれでも解決しなかったら○○さんに声かけて」「○○さ
んはその時こう助けてあげて」と、具体的な解決への道筋まで提⽰してあげる
• メールやチャットでは即レス
• もし本当に忙しくて質問を受ける余裕がない場合は、その状態を正直に⾔う
• メンバーから出てきた意⾒はしっかり拾って、必ず何かしらの答え(採⽤するか⾒送るか)とその
理由を伝える
23. 3-A) 階段を刻み、踊り場で遊ばせる
• 成⻑への階段を刻んであげる
• メンバーを1階から2階に上げる為に、
相⼿に合わせた⾼さ(=難易度)と、
歩幅(=導き⽅の丁寧さ)の階段を⽤
意する
• 階段を上ったら踊り場で遊ばせる
• Range(=⾃由に動いていい範囲)と
Reason(=やる⽬的)を伝えて⾃由に
やらせる
『無理・無意味から職場を救うマネジメントの基礎理論』より