Slide 1

Slide 1 text

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


Slide 2

Slide 2 text

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


Slide 3

Slide 3 text

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


Slide 4

Slide 4 text

Rettyの開発プロセスにおける私の立ち位置
 PO BackLog PdM Team PdM Planner Designer PdM Planner Designer Feature Team x 5 ユーザース トーリー 追加 ユーザース トーリー 追加 ユーザース トーリー 並び替え 開発着手 Engineer Team リファインメント SM Engineer SM Engineer Manager &プロセス全体の 問題解決 Engineer SM

Slide 5

Slide 5 text

前回登壇(Scrum Fest Osaka 2020)のおさらい
 1. スクラム開発におけるマネジメント
  → 開発チームに対しての話
 2. 目標設定・フィードバック・評価
  → 個人に対しての話
 Photo by Hans-Peter Gauster on Unsplash

Slide 6

Slide 6 text

Photo by Hannah Busing on Unsplash 前回登壇(Scrum Fest Osaka 2020)のまとめ
 @nakayama_san のTweetより引用

Slide 7

Slide 7 text

今日の発表の前提・立ち位置
 ● 議論を好む勉強会だと思い、モヤモヤポイントもそのまま持っ てきています。
 ● 「スクラム開発におけるマネジメント」ですが、所々「スクラム開 発をやっている現場でのマネジメント」になっているかもしれま せん。


Slide 8

Slide 8 text

評価指標


Slide 9

Slide 9 text

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


Slide 10

Slide 10 text

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


Slide 11

Slide 11 text

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


Slide 12

Slide 12 text

サポート


Slide 13

Slide 13 text

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


Slide 14

Slide 14 text

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


Slide 15

Slide 15 text

オンボーディング


Slide 16

Slide 16 text

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


Slide 17

Slide 17 text

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


Slide 18

Slide 18 text

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


Slide 19

Slide 19 text

マネージャーの育成


Slide 20

Slide 20 text

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


Slide 21

Slide 21 text

まとめ


Slide 22

Slide 22 text

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