マネージャーが、スクラムチームとともに良い未来をつくるためにできること / RSGT2022

by いっしー

Slide 1

Slide 1 text

マネージャーが、スクラムチームとともに良い未来をつくるためにできること

Slide 2

Slide 2 text

石毛琴恵（いっしー）エンジニアリングマネージャー@アカツキ oturu333 furoshiki.fm 2

Slide 3

Slide 3 text

石毛琴恵（いっしー）エンジニアリングマネージャー@アカツキ oturu333 furoshiki.fm 3

Slide 4

Slide 4 text

4 新規チームエンジニアリングが必要な変更（機能改修、機能追加）運用チームエンジニアリングが不要な変更（イベント追加、ガチャ更新等）プロジェクト PL 190人

Slide 5

Slide 5 text

5 新規チーム運用チームセクションセクションセクションセクションセクションセクションプロジェクト PL

Slide 6

Slide 6 text

6 新規チーム運用チームセクションセクションセクションセクションセクションセクション ● プロジェクト全体の課題解決 ● エンジニア / SMのコーチング、目標設定、評価 ● エンジニア採用、社内異動プロジェクト PL

Slide 7

Slide 7 text

7 新規チーム運用チーム PL セクションセクションセクションセクションセクションセクションプロジェクト全体の課題解決プロジェクト

Slide 8

Slide 8 text

8 新規チーム運用チーム PL LeSSの導入 2020/01〜2021/03 SMにパスセクションセクションセクションセクションセクションセクションプロジェクト全体の課題解決プロジェクト

Slide 9

Slide 9 text

9 新規チーム運用チーム PL LeSSの導入 2020/01〜2021/03 SMに委譲セクションセクションセクションセクションセクションセクションプロジェクト全体の課題解決プロジェクト ScrumFestOsaka2021 CEDEC2021

Slide 10

Slide 10 text

10 新規チーム運用チーム PL プロセス改善 2021/04〜現在セクションセクションセクションセクションセクションセクションプロジェクト全体の課題解決プロジェクト

Slide 11

Slide 11 text

11 新規チーム運用チーム PL セクションセクションセクションセクションセクションセクションプロジェクト全体の課題解決プロジェクト

Slide 12

Slide 12 text

12 新規チーム運用チーム PL セクションセクションセクションセクションセクションセクション ● エンジニア / SMのコーチング、目標設定、評価 ● エンジニア採用、社内異動プロジェクト

Slide 13

Slide 13 text

13 今日お話すること 2021/01のLeSSな開発プロセスの導入から1年が経ち、導入直後はSMとして、導入から3ヶ月たった頃から、マネージャーとしてスクラムチームと関わるようになりました。その中で自分がどのように関わることによって、スクラムチームを阻害せず、より良い方向へ進んでいけるのかを迷い、試してみたことをお話します。

Slide 14

Slide 14 text

14 アジェンダ ◂ マネージャーはスクラムチームが自律する邪魔になる？ ◂ SMとの認識がずれ始めた？ ◂ まとめ

Slide 15

Slide 15 text

1. マネージャーはスクラムチームが自律する邪魔になる？

Slide 16

Slide 16 text

16 SMをやめたときに思っていたこと ◂ スクラムチームから距離を取ったほうが、メンバーが自律的に動けるようになるだろう ◂ SMもいるので、自分がやることはもうないだろう

Slide 17

Slide 17 text

17 離れて観察してみて気づいたこと自発的に改善のための行動をする人が少ない ◂ 気になっても言わない、やったら良いと思っているのに提案しない ◂ 1on1で話を聞くと、メンバーは「こうしたら良い / やりたいと思うけど、チームに望まれているか分からない」という趣旨の発言が散見した

Slide 18

Slide 18 text

「自分たちで考えて改善していくことを望んでいる」と言葉では伝えているが、伝わっていない 18

Slide 19

Slide 19 text

19 自分に何が出来るか ● プロジェクト目標（プロダクトゴール）がある ● セクションごとに目標を立てる文化があるが、スクラムチームで認識が揃っていないために達成できない（自分たちだけでは実現できない）ものも多い ○ 例えば「速度改善をしていきたい」と目標を掲げても、優先度次第になる個人目標セクション目標個人目標個人目標スクラム（新規）チームプロジェクトプロジェクト目標（プロダクトゴール）

Slide 20

Slide 20 text

20 自分に何が出来るか個人目標セクション目標個人目標個人目標スクラム（新規）チーム目標を作る文化は定着しているし、意識されている。ただ、達成できないことも多いため、やや形骸化している。良いかんじに目標設計を整理してやってほしいことを明確に伝え、認識が揃ったセクション目標を立てられれば良いのではないか。？？？？プロジェクトプロジェクト目標（プロダクトゴール）

Slide 21

Slide 21 text

21 やったこと PLやPO、SMと相談して、スクラムチームの行動目標を作り、セクション目標を新規チーム内で共有する場を作った。 ● 常に改善し続けよう ● 保守的にならず、小さく失敗して学んでいこう ● HRTを大事にしよう ● 相手（仲間、ユーザー）の立場に立って考えよう個人目標セクション目標個人目標個人目標スクラム（新規）チームスクラムチーム行動目標プロジェクトプロジェクト目標（プロダクトゴール）

Slide 22

Slide 22 text

すると、良い行動が生まれ始めた 22 セクション目標が実現性があり、自発性を感じるものに変わった。そこから行動が見られるようになった。 ◂ ペアワーク・モブワークが増えた ◂ エンジニア主導で、HackDayを提案 & 実施 ◂ 2日 / 半年、重すぎないが後回しになる改善タスクへの着手をしてみよう ◂ 大きな改善に取り組むためのチームができた

Slide 23

Slide 23 text

感じたこと ◂ 行動目標という共通言語があることで、立場に関わらず動きやすくなったんだろう ◂ 「自己管理をしてね」と思っていたが、セオリーと違っていても、結果的に自己管理ができるチームになれれば良いんだな 23

Slide 24

Slide 24 text

2. SMとの認識がずれ始めた？

Slide 25

Slide 25 text

25 ◂ SMとは隔週で1on1し、SMのデイリーMTG も大体参加していた ◂ 中長期的にSMがやりたいことが見えなくなったような違和感。SM同士でもずれている気がする ◂ どこまで関与して良いのか分からない…SMに任せておいたほうが良いのだろうか… SMを離れてから半年ほどが経ち…

Slide 26

Slide 26 text

SMも悩んでいた ◂ 大規模スクラムだと、SMが複数人いて（弊社だと3名）、みんなで認識を合わせるのが大変、時間がかかる ◂ SMの交代もあり、都度の認識合わせの時間が増えた ◂ みんながこれをやりたいのか分からない 26

Slide 27

Slide 27 text

やったこと ◂ SMと1on1をして ◂ 悩みの壁打ちをする ◂ 問いかけをしてみるあまり効果はなかった 27

Slide 28

Slide 28 text

SMの1人の個人目標設定をきっかけに… ◂ 個人の目標を立てようとしたときに、SM内で優先度や現在地の認識のズレが顕著に ◂ そこで「みんなはいつまでにどんな状態になっていたら良いと思ってる？」と聞いてみた ◂ SM同士で、SMにとっての理想を話し合うことになった 28

Slide 29

Slide 29 text

SMの目標（共通認識）ができた SMにとっての理想の状態と、自分からの情報（PLの考えや、運用チームの情報）を伝え合い SM-EM間でありたい姿や温度感の認識を揃えることができた。「SMの目標」として、アウトプットができた。 29

Slide 30

Slide 30 text

良い変化があった ◂ チームメンバーだけでは対応が難しい課題に SMが動いてくれることになった ◂ これまで自分がハブとなっていた人たちとも SMが直接会話をし、一緒に改善していこうとするアクションが見られた 30

Slide 31

Slide 31 text

感じたこと 31 ◂ SMを委譲してスクラムチーム以外と仕事をするようになり、持つ情報が増えた。そこで得た情報をスクラムチームに共有することにより、スクラムチームにとっても良いことがあった ◂ スクラムマスターに悩みを打ち明けることで一緒に解決してくれる仲間が増えた

Slide 32

Slide 32 text

3. まとめ

Slide 33

Slide 33 text

“ 33 スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。スクラムガイド

Slide 34

Slide 34 text

“ 34 ミドルマネージャーの役割は全体を見渡し、素晴らしいプロダクトを作るために強い組織を作ることです。チームとスクラムマスターが取り組んでいる障害の排除と改善を手助けすべきです。 less.works

Slide 35

Slide 35 text

より良い未来を作るとは「あたりまえ」を変え続けること 35 PO たくさん作るにはたくさん人が必要効率を上げていくことも大事エンジニアレビューで認識を合わせるリーダーが忙しいのは普通ペアワーク・モブワークリーダーでなくてもできる仕事はみんなできるようになろう検証テスト項目を作れる人は一部のみテスト項目を全員作れるようになろう LeSS導入以降、「あたりまえ」は変化し続けている

Slide 36

Slide 36 text

スクラムチームとともにより良い未来を作るためにマネージャーとして、自分ができること 36 変化をしたい人たちの背中を押す主体的に行動しやすい環境作りや、情報提供、個人への声かけ。改善のプロセスをサポートする現状把握、理想のない状態は改善ができない。少し離れているからこそ、そういった状態にアドバイスができる。

Slide 37

Slide 37 text

（余談）あくまで間接的であることが大事 37 新規チーム（なくなったミッション） ● エンジニアの目標設定、評価 ● エンジニア採用、社内異動エンジニアの目標設定、評価（ついでに採用）は、段階的に委譲しました。「評価者」という状態は影響力が強いので、良かったかなと思います。