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

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

話したいこと

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

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

バッドサイクルが回っていた ＜バッドサイクル＞ 結果の質：成果が上がらない ↓ 関係の質：対⽴が⽣じ押し付けや命令が増える ↓ 思考の質：⾯⽩くなく受け⾝になる ↓ ⾏動の質：⾃発的・積極的な⾏動が起きない ↓ 結果の質：さらに成果が上がらない 『カイゼン・ジャーニー』より

⽬指す姿 プロダクト エンジニアチーム ステークホルダ プロダクト エンジニアチーム ステークホルダ

グッドサイクルを回す ＜グッドサイクル＞ 関係の質：お互い尊重し⼀緒に考える ↓ 思考の質：気づきがあり⾯⽩い ↓ ⾏動の質：⾃分で考え⾃発的に⾏動する ↓ 結果の質：成果が得られる ↓ 関係の質：信頼関係が⾼まる 『カイゼン・ジャーニー』より

ビルディングジャーニーロードマップ 1. 外部環境を整える A) 改⾰の宣⾔・ブランディング B) 情報の可視化 C) 技術的負債の可視化と解消のメリットの説明 2. 内部環境を整える A) メンバーへの信頼を⽰す B) チームビジョンの再定義 C) モチベーション3.0と向き合ってくすぐる D) ⼼理的安全性の担保 3. 成⻑サイクルを回す A) 階段を刻み、踊り場で遊ばせる B) チームのカオスエンジニアリング C) 外部環境と内部環境のスピードを合わせる

1) 外部環境を整える ＜グッドサイクル＞ 関係の質：お互い尊重し⼀緒に考える ↓ 思考の質：気づきがあり⾯⽩い ↓ ⾏動の質：⾃分で考え⾃発的に⾏動する ↓ 結果の質：成果が得られる ↓ 関係の質：信頼関係が⾼まる ココ！

1-A) 改⾰の宣⾔・ブランディング • エンジニアチームの改⾰をステークホルダーに宣⾔する • 今まで以上に案件を受けられなくなることを伝える • 「改⾰に伴いご迷惑をおかけするかもしれませんがご協⼒くださいm(_ _)m」 • ⽬指すチームの⾔語化・ブランディング • 「継続的進化をするチーム」 • 「今後はどんどんアプリもチームも良くなって案件をたくさん受けられます」という、 改⾰による直接的なメリットのアピール

1-B) 情報の可視化 • 案件決定プロセスの可視化とシンプル化 • エンジニアのモチベーションを下げる「ネガティブな仕様変更」を削減する狙い • 個別で来ていた案件依頼のフローを⼀本化し「案件統括」を設置 • 検討内容や決定事項をエンジニアにも公開 • エンジニアチームの状況の可視化 • キャパシティ以上の案件を受けることを防ぐ狙い • エンジニア⼀⼈⼀⼈の予定を公開することで、スコープ調整の説得⼒を持つ EM EM 案件統括 ⾒える ⾒える

1-C) 技術的負債の可視化と解消のメリット説明 • フルリニューアルの実施のための準備 • バグ地獄の最⼤の原因「技術的負債の肥⼤化＋ブラックボックス化」 • ⼀定期間新しい案件を受けられなくなる（＝ビジネス影響が⼤きい）ので丁寧な説明が必要 • 技術的負債解消の可視化とメリットの説明 • 可視化は過去のバグ・不具合のうち技術的負債に起因するもの、それによる被害（コスト、 時間）を列挙するのみ → 説得⼒抜群w • このタイミングでのリニューアルが後の事業成⻑の最⼤化につながることを熱弁 • 「⼤きくジャンプする前にはしゃがみ込みが必要なんだ」 • 「リニューアルのついでに案件」は断固拒否することも宣⾔しておく

外部環境を整えた • 内部環境の改⾰に集中できるようになる • 外部環境が起因して発⽣する無駄な作業を減らすことができる • 周りの協⼒を得ることができる

2) 内部環境を整える ＜グッドサイクル＞ 関係の質：お互い尊重し⼀緒に考える ↓ 思考の質：気づきがあり⾯⽩い ↓ ⾏動の質：⾃分で考え⾃発的に⾏動する ↓ 結果の質：成果が得られる ↓ 関係の質：信頼関係が⾼まる ココ！ ココ！ ココ！

2-A) メンバーへの信頼を⽰す • 兎にも⾓にもメンバーのモチベーションと⾃⼰肯定感を上げる • 前任の強権政治マネージメントからの脱却 • 「エンジニアに意思決定をさせる」ことを⽬指す • 「組織に使われている」から「⾃分で決めている」への意識のシフトチェンジ • メンバーへの信頼を⽰し、メンバーの意思決定を尊重する • 具体的に期待していることを⼝にする（思っているだけだと伝わらない） • 逆に期待していないことも伝える（⾃尊⼼が傷つかない範囲で） • 「○○さんはドキュメント作成は苦⼿だから期待しないけど、コーディングは信頼してるよ」 • メンバーの仕事に極⼒⼝を出さない • 信頼していると宣⾔した後に、細かくチェックしていたら⾔⾏不⼀致になる • 最初は問題が起こりまくるが「産みの苦しみ」として我慢する

2-B) チームビジョンの再定義 • ⽬指すチームの⾔語化・ブランディング • 「継続的進化をするチーム」というビジョンをしつこいくらい語りまくる • 「俺はこうしたいんだ、だから協⼒してくれ」という姿勢で「求められている感」を醸成 • 歓迎される/されない⾏動の指針を⽰す • OK：バグの原因や改修⽅法をメンバーに共有しながら直す（＝時間はかかる） • NG：⼀⼈で素早くバグを直す

2-C) モチベーション3.0と向き合ってくすぐる “＜モチベーション3.0＞には三つの重要な要素がある。 ⼀つは＜⾃律性＞。⾃分の⼈⽣を⾃ら導きたいという欲 求のこと。⼆番⽬は＜マスタリー（熟達）＞。⾃分に とって意味のあることを上達させたいという衝動のこと。 三番⽬は＜⽬的＞。⾃分よりも⼤きいこと、⾃分の利益 を超えたことのために活動したい、という切なる思いの ことだ。”

• 1on1でどのタイプが⾒極めてインプットの仕⽅を変える • ⾃律性タイプ • "Why"をインプットして"What/When"に関してはある程度幅を持たせてメンバーが決め られるようにする • マスタリータイプ • "Why/What/When"をインプットして極上の"How"をアウトプットすることを期待する • ⽬的タイプ • "Why"を丁寧にインプットして"What"を⼀緒に考えてもらう 2-C) モチベーション3.0と向き合ってくすぐる

2-D) ⼼理的安全性の担保 • ミーティングではとにかく明るく振る舞う • メンバーの話を聞くときは顔を⾒て聞く（キーボード打ちながらは絶対NG） • 問題をチームで解決する場を作り「もしこれでも解決しなかったら○○さんに声かけて」「○○さ んはその時こう助けてあげて」と、具体的な解決への道筋まで提⽰してあげる • メールやチャットでは即レス • もし本当に忙しくて質問を受ける余裕がない場合は、その状態を正直に⾔う • メンバーから出てきた意⾒はしっかり拾って、必ず何かしらの答え（採⽤するか⾒送るか）とその 理由を伝える

内部環境を整えた • メンバーの顔⾊が明らかに良くなってきた • メンバーからの提案やメンバー同⼠のミーティングが増えた • それに伴いプロダクトの品質も少しずつ良くなってきた（＝成果が出た）

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

3-A) 階段を刻み、踊り場で遊ばせる • 成⻑への階段を刻んであげる • メンバーを１階から２階に上げる為に、 相⼿に合わせた⾼さ（＝難易度）と、 歩幅（＝導き⽅の丁寧さ）の階段を⽤ 意する • 階段を上ったら踊り場で遊ばせる • Range（＝⾃由に動いていい範囲）と Reason（＝やる⽬的）を伝えて⾃由に やらせる 『無理・無意味から職場を救うマネジメントの基礎理論』より

3-B) チームのカオスエンジニアリング • 「役割と仕事分担」や「会議やミーティング設計」を意図的に壊してみる • 無駄が除去されてパフォーマンスが上がることがある • 突然１週間休んでみたり、EMが持っている仕事を丸投げしたりする • メンバーからも無駄の指摘が出やすくなる • 「無駄なものは変えていい」という意識が⽣まれる • マネージャーのボトルネックが無くなっていく • メンバーが⾃分たちだけでスピーディーに進められることが増えていく • マネージャーしかできないことなんて意外と少ない

3-C) 外部環境と内部環境のスピードを合わせる • エンジニアチームのスピードに、ステークホルダーがついてこれなくなった • WIP（Work in Progress）が増えてきた • メンバーの不満が外に向くようになった • 外部環境を整えて、再びグッドサイクルを回す • 業務の効率化の提案 • 情報共有や調整開始のタイミングの⾒直し

成⻑サイクルを回した • メンバーのパフォーマンスや信頼関係が⽬に⾒えて向上してきた • エンジニアチーム以外の組織も成⻑してきた • リリースできた機能が爆発的に増えた（＝成果が⼤きくなってきた）

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

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

１年後の状態 üバグ・障害数９割減 ü仕様のブラックボックスは完璧に解消 üiOSとAndroidの機能差は「意図するもの」のみに üフルリニューアル⼤成功＋その後新機能リリース３件連続成功 üエンジニアのモチベーションが⾶躍的向上 üエンジニア間のコミュニケーション活性化（忘年会が楽しい！） üエンジニア間のスキル差を埋めようとする活動（勉強会やモブプロなど） üエンジニアの離職率が劇的低下 üエンジニアチームと良好な関係を保ち、かつお互い刺激し合っている ü「緊急の仕様変更」はポジティブなもののみ üただし⼀部の組織はまだ改善しきれていない（今後の継続課題） プロダクト エンジニアチーム ステークホルダ

エンジニアリングマネージャーの変化 １年前 • メンバーの顔⾊を伺いながら孤軍奮闘 • メンバーとの1on1で愚痴と向き合う • 朝会で⼀⽣懸命ファシリテート １年後 • メンバーと⼀緒にチーム作り • メンバーとの1on1で希望と向き合う • 朝会で端っこでコーヒー飲みながらニヤニヤ

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

参考図書

Next ジャーニー…

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

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