スクラム開発におけるマネジメント、目標設定・フィードバック・評価 / Management in Scrum

Scrum Fest Osaka 2020の登壇資料です。

スクラム開発におけるマネジメント、目標設定・フィードバック・評価 / Management in Scrum
https://confengine.com/scrum-fest-osaka-2020/proposal/14019

Transcript

1. スクラム開発におけるマネジメント、
 目標設定・フィードバック・評価
 Retty株式会社
 常松祐一
 2020/06/27

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

3. 3 自分にとってBESTなお店が見つかる 
 日本最大級の"実名型"グルメサービス
 レビューよりもレコメンド。 
 Rettyは他人におすすめしたい 
 美味しいお店を投稿するサービス！ 
 食の好みは人それぞれ。 
 自分と嗜好が合う人をフォローして、 
 BESTなお店を見つけられるSNS型！ 
 実名制の口コミだからこそ 
 「信頼できる」「ポジティブ」な 
 情報が集まっています！ 
 批評ではなくオススメの口コミ 
 自分と好みが近い人から探せる 
 顔が見えて信頼できる実名制 
 confidential
4. 今日のお話
 No One Left Behind
 マネージャーも置いていかない
 Regional Scrum Gathering Tokyo 2020 2日 Keynoteより
 Photo by Hannah Busing on Unsplash
5. この発表を聞く皆さんへの期待
 【マネージャーの方へ】
 　事例公開し、いい取り組みを一般化していきましょう。
 
 【マネジメントを受ける側の方へ】
 　(内容が良いと思ったら)「こんなふうに振る舞って欲しい」とマ ネージャーに資料を渡してください。
 Photo by Zoltan Tasi on Unsplash
6. 自身のマネジメント/アジャイル開発経験
 メーカー 海外子会社 メーカー 新規事業 【マネージャー/非アジャイル】 電子辞書の開発を2年半 開発プロセスはウォーターフォール 組織上の職位はマネージャー 人事評価を行う 【非マネージャー/アジャイル】 新規事業開発を3年 開発プロセスはスクラム、途中から大規模スクラム (LeSS) スクラムでの役割は当初 PO→後にSMへ 組織上の職位は主任研究員 (=課長代理) 人事評価は行わない 【マネージャー/アジャイル】 Webサービスの開発を1年 開発プロセスはスクラム、途中から大規模スクラム (LeSS) スクラムでの役割は社内コーチ、ステークホルダーの 1人 組織上の職位はマネージャー 人事評価を行う
7. Rettyの開発プロセスにおける私の立ち位置
 PO BackLog PdM Team PdM Planner Designer PdM Planner Designer Feature Team x 5 ユーザース トーリー 追加 ユーザース トーリー 追加 ユーザース トーリー 並び替え 開発着手 Engineer Team リファインメント SM Engineer SM Engineer Manager &プロセス全体の 問題解決 Engineer SM
8. この後の話の流れ
 1. スクラム開発におけるマネジメント
 　→ 開発チームに対しての話
 2. 目標設定・フィードバック・評価
 　→ 個人に対しての話
 Photo by Hans-Peter Gauster on Unsplash
9. スクラム開発におけるマネジメント
 confidential
10. マネジメントは何のため?
 「組織の為に組織の人たちを生き生きとさせ、
 高度な成果を上げること」
 Peter F. Drucker
 → 社会状況が変わり、目指すゴールが変わり、携わる 人が変わり、変化に対応していくにはマネジメントは常に 必要。
 → プロダクト開発の仕組みの改善を促進させる。
 Photo by Jamie Street on Unsplash
11. マネージャーの役割
 1. 組織する
 2. 動機付けを行う
 3. 目標を設定する
 4. 評価する
 5. 人材を育成する

12. スクラムにおける立ち位置 - アンチパターン
 1. POとマネージャーを兼ねる → 開発チームから意見しにくい
 2. SMとマネージャーを兼ねる
 → 開発チームから意見しにくい & プレイングマネージャー化
 3. SMをマイクロマネジメントする → チームの自律性が損なわれる
 PO&Mgr SM Engineer PO SM&Mgr Engineer PO SM Engineer Mgr パターン1 パターン2 パターン3
13. スクラムにおける立ち位置 - おすすめ
 • 開発チームの自律性を引き出す働きかけをする。
 • ステークホルダーの1人として、開発チームとコミュニケーションをとる。
 • 開発チームと外部組織とのハブになる。
 PO SM Engineer Mgr PO SM Engineer Other Dept. Sales, Marketing, Backoffice etc
14. マネージャーとチームのコミュニケーション具体例
 Photo by Markus Spiske on Unsplash 開発チームの自律性を引き出すように留意する
 ◦ 業務へのアサイン
 ◦ 業務指示の出し方
 ◦ 実装方針の決定
 ◦ 定期的な進捗の把握
 ◦ チーム外への進捗報告
 ◦ 新しい取り組みの導入

15. 業務へのアサイン
 confidential • プロダクトに開発チームをアサイ ンする。
 • チームメンバーは頻繁に入れ替 えない。
 プロダクト = 期限なし
 • プロジェクトにメンバーをアサイン する。
 • プロジェクトが終わったらメンバー を異動させる。
 プロジェクト = 期限あり

16. 業務指示の出し方
 confidential • プロダクトオーナーへ要望を伝 え、優先順位で考慮してもらう。
 • 開発チームは優先順位が高いも のから着手する。
 • 開発は協力して行う
 • 作業順序はマネージャーが決め る。
 • 個別に指示を出す。
 • 開発は個人で行う。

17. 実装方針の決定
 confidential • チームに決定を委ねる
 
 ※ステークホルダーとして決定に不満 を表明することはある。
 • マネージャーが決める / テックリードと相談して決め て伝える。

18. 定期的な進捗の把握
 confidential • スプリントレビューで代替す る。
 • どこかを見ればわかるよう、 見える化してもらう。(カンバ ンとか)
 • 定例会議を開く。
 • 個別に日報を書いてもらう。

19. チーム外への進捗報告
 confidential • バーンアップチャート
 • ベロシティ
 • ガントチャート
 • 何となくの進捗数値

20. チーム外への進捗報告
 バーンアップチャートは好評でした
 実績とスコープ見積もりがク ロスするところが完了予定 日
21. 新しい取り組みの導入
 confidential • 「最近何か実験している?」とチー ムに投げかける。
 • 一時的にパフォーマンスが落ちて も、より改善する可能性があれば チームを信じて任せる。
 • トップダウンでとにかくやらせる。
 • 失敗したらメンバーのせい

22. マネージャーがとる日々の具体的な行動
 • Slackのやりとりを覗く
 ◦ 全体チャンネル・チームチャンネル・個人チャンネル など
 • GitHub Pull Requestでのやりとりを覗く
 ◦ 噛み合った議論をしているか
 • スクラムイベントでの立ち振る舞いを覗く
 ◦ 儀式的にやってないか
 • おさんぽ (Management By Walking Around : https://kshimizu.hatenadiary.jp/entry/2016/07/14/060511 )
 ◦ 近くに行ってチームの様子を観察
 • 1on1 (後述)

23. マネージャーの振る舞いは壁を作りやすい
 部門目線でばかり判断する
 　→チームの目線が下がる。自分たちがよければ問題ないと いう考えが強まる。
 
 チームと外部組織の間で仲介し続ける
 　→チームは外部に直接コミュニケーションをとってはいけな いと考えるようになる。
 Photo by Waldemar Brandt on Unsplash
24. チームは「マネージャーにしかできないこと」を期待している
 • 開発チームを外部から守る
 • 開発チームで解決できない問題の対処
 ◦ ヒト・モノ・カネの手当て
 ◦ 開発プロセス・社内ルールの見直し
 • 中長期的な方針を示し、皆をまとめる
 • 最後の責任を取る
 Photo by Jp Valery on Unsplash
25. 対処する問題はよく選ぶ、反射的に対応しない
 • 個人・チームで何とかできるものは戻す
 • 重要な問題は何度も繰り返し上がってくる
 • 表層的な対処ではなく真因に対処する
 　→ 事象の因果関係に着目する
 　　　「システム思考」がオススメ
 Photo by Annie Spratt on Unsplash
26. 「スクラム開発におけるマネジメント」のまとめ
 • メンバーの力を引き出し続けるにはマネジメントは 必要。
 • チームの自律性を引き出すサポートをする。
 • マネージャーにしかできないことに注力する。
 • 問題の真因に対処する。
 Photo by Aaron Burden on Unsplash
27. 目標設定・フィードバック・評価
 confidential
28. Rettyにおける人事評価制度
 • 3ヶ月ごと
 ◦ 目標管理(Management by Objectives)
 ▪ 1：目標を設定する / 目標が適正か確認
 ▪ 2：目標を達成するために活動をする
 ▪ 3：目標を達成できたか評価をする
 ◦ 同僚からのピアレビュー
 ◦ マネージャーからの評価
 • 半年ごと
 ◦ 直近1年の成果を鑑みて、業務グレードの見直し

29. スクラム開発でおきがちな悩み
 • 開発項目が途中で変わる。誰が何の開発を担当するのか事前にわ からない。
 • 「スコープを適宜見直す」ため、やりきり目標がそぐわない。
 • 「属人化した役割をなくし、チームで成果を出してもらう」はずなのに、 個人目標・役割を明確にすることを求められる。
 
 • (ピアレビューにおいて)誰が何をやっていたのかわからない。
 Photo by Ümit Bulut on Unsplash
30. 「目標設定」は分解して設定する
 • 組織目標(部門目標)
 ◦ 複数チームで共通
 ◦ 3ヶ月毎に見直す、大きくは変わらない
 • 個人目標
 ◦ 全員ほぼ共通、公開する
 ◦ 3ヶ月毎に見直す、あまり変わらない
 • 個人課題
 ◦ 個人ごとに固有、非公開
 ◦ 業務グレードが変わらない限り変わらない

31. 組織目標(部門目標)の例
 • 開発着手からリリースまでの日数 → 平均5日
 • インシデント発生数 → N件以下
 • XXX機能のリリース
 ◦ ※3ヶ月ぐらいかかる、大きめで変わらないやりきり目標
 • サイトパフォーマンス改善 N%
 
 目標達成のインセンティブで、スクラム開発に悪影響が出ないよう、留意 する必要がある。
 • 複数チームで共通
 • 3ヶ月毎に見直す、大きくは変わらない
32. 個人目標の例
 • 全員ほぼ共通、公開
 • 3ヶ月毎に見直す、あまり変わらない • +αでチームと離れた個人的な目標を入れるとよい
 ◦ 技術負債返却、ドキュメント整備、社内コミュニティ活動など
 ◦ ピアレビューでコメントしやすくなる

33. 個人課題の例
 • 現状の期待役割
 ◦ 開発組織の効率改善
 ◦ LeSSの範囲を広げ習熟度を上げていく
 ◦ 開発組織に余裕を作るための下地を作る
 • 次の業務グレードに上がるために必要なこと
 ◦ 組織を大きく変革していくための中核を担う
 ◦ サービスにおける大きな課題を解決するプロジェクトを主導して成功させる
 ◦ 開発組織メンバーのマインドの向上
 • 個人ごとに固有、非公開
 • 業務グレードが変わらない限り変わらない これは　　　　　　の本物です。
34. 定量目標じゃなくて良いの?
 • 設定できるならその方が良い。
 ◦ おかしな指標を建てる方が有害、ベロシティN%アップとか
 • 定量目標を達成できても高い評価が付けられないリスク
 ◦ 目標が低すぎた。周りがより高い成果出した。
 ◦ 給与・賞与の原資は有限。
 • 多くの人は絶対評価されることを求めているのではなく、「期待とずれ のない評価」を受けることを求めている。
 Photo by Ümit Bulut on Unsplash
35. フィードバックはこまめに、評価のズレを埋めていく
 • 週1回の1on1で都度伝える
 ◦ よかった動き。
 ◦ よくなかった動き、できていないこと。”はっきり”伝える。
 • 成果・アウトプットをどう受け取っているか
 ◦ 自分はどう考えているか ⇦ 本人の期待
 ◦ チームメンバーはこう感じていた(伝聞)
 ◦ マネージャーこう感じた
 ◦ 部門内外のメンバはこう感じていた(伝聞) ⇦ 評価基準はここ

36. 人によって期待値にズレができるのを防ぎたい
 →CircleCI Engineering Comptency Matrix
 CircleCI Engineering Competency Matrix https://bit.ly/30YbET7
37. エンジニアに特化した評価制度を整える
 【Retty Tech Blog】 エンジニア評価制度の取り組みを振り返ってみた https://engineer.retty.me/entry/2020/04/15/090000 自分で項目を選び、成長を文書化し提出。マネージャーがそ れについて踏み込んだフィードバックを与える取り組み。半年 ごとに実施　
38. 人事評価制度はスクラムに合わない、できそこないだよ…
 • とはいえ全社の仕組みを変えることは難しい。
 ◦ 人事評価制度の改定には大変な労力がかかる。
 • 会社の全てがスクラムになることはない
 ◦ 総務、人事、採用、営業・・・
 
 　→ 運用でカバーした方がよい。

39. 「目標設定・フィードバック・評価」のまとめ
 • チームで成果をあげてもらうことを意識してもらいつ つ、個人への期待を明確にする。
 • フィードバックはこまめに行い、本人評価とのズレを埋 める。
 • 「スクラムだから」といって人事評価の基本は変わらな い。銀の弾丸はない。
 Photo by Aaron Burden on Unsplash
40. まとめ
 confidential
41. まとめ
 Photo by Hannah Busing on Unsplash • メンバーの力を引き出し続けるにはマネジメントは必要。
 • チームの自律性を引き出すサポートをし、プロダクト開発の仕組み の改善を促進させる。
 • 「スクラムだから」といって人事評価の基本は変わらない。
 • フィードバックはこまめに行い、本人評価とのズレを埋める。
 
 【マネージャーの方へ】
 ◦ 事例公開し、いい取り組みを一般化していきましょう。