スクラム開発におけるマネジメント、評価指標・サポート・オンボーディング / Management in Scrum (2)

分散アジャイルチームについて考える会の登壇資料です。

スクラム開発におけるマネジメント、評価指標・サポート・オンボーディング
https://distributed-agile-team.connpass.com/event/195425/
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14619

Transcript

1. スクラム開発におけるマネジメント、
 評価指標・サポート・オンボーディング
 常松祐一
 2020/12/17 

2. 自己紹介
 • 常松祐一 (つねまつ ゆういち) 
 ◦ Engineering Manager 
 ◦ Software Engineering Coach 
 ◦ Agile Development
 • SNSアカウント
 ◦ tunepolo : 
 ◦ tune : 
 
 • 顧客にとって価値のあるプロダクトを、チーム一丸 となって協力し、短期間にリリースする開発体制の あり方を模索しています。 

3. 3 自分にとってBESTなお店が見つかる 
 日本最大級の"実名型"グルメサービス
 レビューよりもレコメンド。 
 Rettyは他人におすすめしたい 
 美味しいお店を投稿するサービス！ 
 食の好みは人それぞれ。 
 自分と嗜好が合う人をフォローして、 
 BESTなお店を見つけられるSNS型！ 
 実名制の口コミだからこそ 
 「信頼できる」「ポジティブ」な 
 情報が集まっています！ 
 批評ではなくオススメの口コミ 
 自分と好みが近い人から探せる 
 顔が見えて信頼できる実名制 

4. Rettyの開発プロセスにおける私の立ち位置
 PO BackLog PdM Team PdM Planner Designer PdM Planner Designer Feature Team x 5 ユーザース トーリー 追加 ユーザース トーリー 追加 ユーザース トーリー 並び替え 開発着手 Engineer Team リファインメント SM Engineer SM Engineer Manager &プロセス全体の 問題解決 Engineer SM
5. 前回登壇(Scrum Fest Osaka 2020)のおさらい
 1. スクラム開発におけるマネジメント
 　→ 開発チームに対しての話
 2. 目標設定・フィードバック・評価
 　→ 個人に対しての話
 Photo by Hans-Peter Gauster on Unsplash
6. Photo by Hannah Busing on Unsplash 前回登壇(Scrum Fest Osaka 2020)のまとめ
 @nakayama_san のTweetより引用
7. 今日の発表の前提・立ち位置
 • 議論を好む勉強会だと思い、モヤモヤポイントもそのまま持っ てきています。
 • 「スクラム開発におけるマネジメント」ですが、所々「スクラム開 発をやっている現場でのマネジメント」になっているかもしれま せん。

8. 評価指標

9. スクラムチームの評価
 • ステークホルダーに素直に聞く
 ◦ ここで不満がでるなら他に何を取り繕ってもダメ
 • チームメンバーに素直に聞く
 • 実験を評価する
 ◦ 一時的にチームパフォーマンスが落ちても新しいやり方を 模索して欲しい

10. スクラムチーム個人の評価 - よかったもの
 • やることが変わっても変更の必要性がない
 ◦ チーム開発に貢献するスタンス、着手からリリースまでの日数、 障害数など
 • 複数観点で設定する。施策・不具合対応・チーム外貢献など
 ◦ 調整の余地がある
 • 可能であれば持ち場を持たせる
 ◦ ドキュメントの整理、QAプロセスの改善、リファクタリングのリー ドなど

11. スクラムチーム個人の評価 - 悪かったもの
 • やりきり目標 vs 定量目標
 ◦ 人によって向き・不向きがある。
 ◦ ほどよい難易度に定量目標を置くことは難しい
 →月1くらいで調整しないと実態からずれる。
 • 個人・チームでコントロールできないものが含まれている
 ◦ 会社都合・外部都合でリリースがブロックされるとか

12. サポート

13. 1on1の開催
 • 週1回 最大30分
 ◦ よかったことも悪かったことも、早めにフィードバック
 ◦ 伝えたいことがある時だけ設定すると相手が身構える。
 • マネージャーと行う。
 ◦ PO/SMと行うことは止めないが、権威化・上下関係が生まれ るのではないか?
 • 気をつけていること
 ◦ スクラム開発の進捗報告は適当に聞き流す
 ◦ チームの問題はチームで解決してもらう

14. 問題のエスカレーション
 • 複数チームでスクラムを行っているため、振り返り結果の共有 会を毎週実施する
 • チーム内で解決できない課題をエスカレーションしてもらう。課 題はマネージャー間で相談して対処する。
 ◦ すぐに対処する問題
 ◦ すぐに対処しない問題

15. オンボーディング

16. チームを立ち上げるとき
 • チームメンバーの構成
 ◦ 案1)スキルマップを考慮してバランスよく考える
 ◦ 案2)メンバーに決めてもらう
 • スクラムマスターの選び方
 ◦ 案1)やる気がある人、立候補
 ◦ 案2)場・役割を与えられて動く人
 ◦ 案3)リーダーや管理職候補ばかりにしない

17. スクラムマスターを育てる
 • まずはスクラムの基本をキチンと守らせる
 ◦ 2〜3ヶ月経つと開発の各所に違和感を感じるようになるの でそこからスタート
 • 専任か兼任か
 ◦ Rettyでは今のところ全員「兼任」
 ▪ 自身の希望抜きに専任させるのどうなんでしょう?キャ リアに繋がるのか？
 ▪ スクラムマスターを外部から雇い入れる？
 ◦ 専任ならチーム外まで目を光らせて欲しいけど

18. メンバーをチームに入れるとき
 • 早々にチームに入れる。準備期間は特に設けない。
 • チーム開発を意識させる
 ◦ 「〇〇さんのために簡単なタスクが欲しい」は怪しいサイン

19. マネージャーの育成

20. マネージャーの育成
 • プレイヤーとして手を動かすのを止めてもらう
 ◦ プレイングマネージャーとして評価されることと、マネー ジャーとして評価されることは別
 • テコ入れするポイントを見極める
 ◦ 縛りプレイを心がける
 • マネージャーにとっての成功
 ◦ メンバーの成長、生き生きと働いてくれていること

21. まとめ

22. まとめ
 • 今回の発表は「ベストプラクティス」というより、常松が悩んで いるポイントの吐き出し
 • アジャイルな開発を支えられるマネジメントのレベルアップをし ていきたいので疑問・質問・議論は歓迎です。