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

by Yuichi Tsunematsu

Slide 1

Slide 1 text

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

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型！   実名制の口コミだからこそ   「信頼できる」「ポジティブ」な   情報が集まっています！   批評ではなくオススメの口コミ   自分と好みが近い人から探せる   顔が見えて信頼できる実名制   confidential

Slide 4

Slide 4 text

今日のお話  No One Left Behind  マネージャーも置いていかない  Regional Scrum Gathering Tokyo 2020 2日 Keynoteより  Photo by Hannah Busing on Unsplash

Slide 5

Slide 5 text

この発表を聞く皆さんへの期待  【マネージャーの方へ】  　事例公開し、いい取り組みを一般化していきましょう。    【マネジメントを受ける側の方へ】  　(内容が良いと思ったら)「こんなふうに振る舞って欲しい」とマネージャーに資料を渡してください。  Photo by Zoltan Tasi on Unsplash

Slide 6

Slide 6 text

自身のマネジメント/アジャイル開発経験  メーカー海外子会社メーカー新規事業【マネージャー/非アジャイル】電子辞書の開発を2年半開発プロセスはウォーターフォール組織上の職位はマネージャー人事評価を行う【非マネージャー/アジャイル】新規事業開発を3年開発プロセスはスクラム、途中から大規模スクラム (LeSS) スクラムでの役割は当初 PO→後にSMへ組織上の職位は主任研究員 (=課長代理) 人事評価は行わない【マネージャー/アジャイル】 Webサービスの開発を1年開発プロセスはスクラム、途中から大規模スクラム (LeSS) スクラムでの役割は社内コーチ、ステークホルダーの 1人組織上の職位はマネージャー人事評価を行う

Slide 7

Slide 7 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 8

Slide 8 text

この後の話の流れ  1. スクラム開発におけるマネジメント  　→ 開発チームに対しての話  2. 目標設定・フィードバック・評価  　→ 個人に対しての話  Photo by Hans-Peter Gauster on Unsplash

Slide 9

Slide 9 text

スクラム開発におけるマネジメント  confidential

Slide 10

Slide 10 text

マネジメントは何のため?  「組織の為に組織の人たちを生き生きとさせ、  高度な成果を上げること」  Peter F. Drucker  → 社会状況が変わり、目指すゴールが変わり、携わる人が変わり、変化に対応していくにはマネジメントは常に必要。  → プロダクト開発の仕組みの改善を促進させる。  Photo by Jamie Street on Unsplash

Slide 11

Slide 11 text

マネージャーの役割  1. 組織する  2. 動機付けを行う  3. 目標を設定する  4. 評価する  5. 人材を育成する 

Slide 12

Slide 12 text

スクラムにおける立ち位置 - アンチパターン  1. POとマネージャーを兼ねる → 開発チームから意見しにくい  2. SMとマネージャーを兼ねる  → 開発チームから意見しにくい & プレイングマネージャー化  3. SMをマイクロマネジメントする → チームの自律性が損なわれる  PO&Mgr SM Engineer PO SM&Mgr Engineer PO SM Engineer Mgr パターン1 パターン2 パターン3

Slide 13

Slide 13 text

スクラムにおける立ち位置 - おすすめ  ● 開発チームの自律性を引き出す働きかけをする。  ● ステークホルダーの1人として、開発チームとコミュニケーションをとる。  ● 開発チームと外部組織とのハブになる。  PO SM Engineer Mgr PO SM Engineer Other Dept. Sales, Marketing, Backoffice etc

Slide 14

Slide 14 text

マネージャーとチームのコミュニケーション具体例  Photo by Markus Spiske on Unsplash 開発チームの自律性を引き出すように留意する  ○ 業務へのアサイン  ○ 業務指示の出し方  ○ 実装方針の決定  ○ 定期的な進捗の把握  ○ チーム外への進捗報告  ○ 新しい取り組みの導入 

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

チーム外への進捗報告  バーンアップチャートは好評でした  実績とスコープ見積もりがクロスするところが完了予定日

Slide 21

Slide 21 text

新しい取り組みの導入  confidential ● 「最近何か実験している?」とチームに投げかける。  ● 一時的にパフォーマンスが落ちても、より改善する可能性があればチームを信じて任せる。  ● トップダウンでとにかくやらせる。  ● 失敗したらメンバーのせい 

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

マネージャーの振る舞いは壁を作りやすい  部門目線でばかり判断する  　→チームの目線が下がる。自分たちがよければ問題ないという考えが強まる。    チームと外部組織の間で仲介し続ける  　→チームは外部に直接コミュニケーションをとってはいけないと考えるようになる。  Photo by Waldemar Brandt on Unsplash

Slide 24

Slide 24 text

チームは「マネージャーにしかできないこと」を期待している  ● 開発チームを外部から守る  ● 開発チームで解決できない問題の対処  ○ ヒト・モノ・カネの手当て  ○ 開発プロセス・社内ルールの見直し  ● 中長期的な方針を示し、皆をまとめる  ● 最後の責任を取る  Photo by Jp Valery on Unsplash

Slide 25

Slide 25 text

対処する問題はよく選ぶ、反射的に対応しない  ● 個人・チームで何とかできるものは戻す  ● 重要な問題は何度も繰り返し上がってくる  ● 表層的な対処ではなく真因に対処する  　→ 事象の因果関係に着目する  　　　「システム思考」がオススメ  Photo by Annie Spratt on Unsplash

Slide 26

Slide 26 text

「スクラム開発におけるマネジメント」のまとめ  ● メンバーの力を引き出し続けるにはマネジメントは必要。  ● チームの自律性を引き出すサポートをする。  ● マネージャーにしかできないことに注力する。  ● 問題の真因に対処する。  Photo by Aaron Burden on Unsplash

Slide 27

Slide 27 text

目標設定・フィードバック・評価  confidential

Slide 28

Slide 28 text

Rettyにおける人事評価制度  ● 3ヶ月ごと  ○ 目標管理(Management by Objectives)  ■ 1：目標を設定する / 目標が適正か確認  ■ 2：目標を達成するために活動をする  ■ 3：目標を達成できたか評価をする  ○ 同僚からのピアレビュー  ○ マネージャーからの評価  ● 半年ごと  ○ 直近1年の成果を鑑みて、業務グレードの見直し 

Slide 29

Slide 29 text

スクラム開発でおきがちな悩み  ● 開発項目が途中で変わる。誰が何の開発を担当するのか事前にわからない。  ● 「スコープを適宜見直す」ため、やりきり目標がそぐわない。  ● 「属人化した役割をなくし、チームで成果を出してもらう」はずなのに、個人目標・役割を明確にすることを求められる。    ● (ピアレビューにおいて)誰が何をやっていたのかわからない。  Photo by Ümit Bulut on Unsplash

Slide 30

Slide 30 text

「目標設定」は分解して設定する  ● 組織目標(部門目標)  ○ 複数チームで共通  ○ 3ヶ月毎に見直す、大きくは変わらない  ● 個人目標  ○ 全員ほぼ共通、公開する  ○ 3ヶ月毎に見直す、あまり変わらない  ● 個人課題  ○ 個人ごとに固有、非公開  ○ 業務グレードが変わらない限り変わらない 

Slide 31

Slide 31 text

組織目標(部門目標)の例  ● 開発着手からリリースまでの日数 → 平均5日  ● インシデント発生数 → N件以下  ● XXX機能のリリース  ○ ※3ヶ月ぐらいかかる、大きめで変わらないやりきり目標  ● サイトパフォーマンス改善 N%    目標達成のインセンティブで、スクラム開発に悪影響が出ないよう、留意する必要がある。  ● 複数チームで共通  ● 3ヶ月毎に見直す、大きくは変わらない

Slide 32

Slide 32 text

個人目標の例  ● 全員ほぼ共通、公開  ● 3ヶ月毎に見直す、あまり変わらない ● +αでチームと離れた個人的な目標を入れるとよい  ○ 技術負債返却、ドキュメント整備、社内コミュニティ活動など  ○ ピアレビューでコメントしやすくなる 

Slide 33

Slide 33 text

個人課題の例  ● 現状の期待役割  ○ 開発組織の効率改善  ○ LeSSの範囲を広げ習熟度を上げていく  ○ 開発組織に余裕を作るための下地を作る  ● 次の業務グレードに上がるために必要なこと  ○ 組織を大きく変革していくための中核を担う  ○ サービスにおける大きな課題を解決するプロジェクトを主導して成功させる  ○ 開発組織メンバーのマインドの向上  ● 個人ごとに固有、非公開  ● 業務グレードが変わらない限り変わらないこれは　　　　　　の本物です。

Slide 34

Slide 34 text

定量目標じゃなくて良いの?  ● 設定できるならその方が良い。  ○ おかしな指標を建てる方が有害、ベロシティN%アップとか  ● 定量目標を達成できても高い評価が付けられないリスク  ○ 目標が低すぎた。周りがより高い成果出した。  ○ 給与・賞与の原資は有限。  ● 多くの人は絶対評価されることを求めているのではなく、「期待とずれのない評価」を受けることを求めている。  Photo by Ümit Bulut on Unsplash

Slide 35

Slide 35 text

フィードバックはこまめに、評価のズレを埋めていく  ● 週1回の1on1で都度伝える  ○ よかった動き。  ○ よくなかった動き、できていないこと。”はっきり”伝える。  ● 成果・アウトプットをどう受け取っているか  ○ 自分はどう考えているか ⇦ 本人の期待  ○ チームメンバーはこう感じていた(伝聞)  ○ マネージャーこう感じた  ○ 部門内外のメンバはこう感じていた(伝聞) ⇦ 評価基準はここ 

Slide 36

Slide 36 text

人によって期待値にズレができるのを防ぎたい  →CircleCI Engineering Comptency Matrix  CircleCI Engineering Competency Matrix https://bit.ly/30YbET7

Slide 37

Slide 37 text

エンジニアに特化した評価制度を整える  【Retty Tech Blog】エンジニア評価制度の取り組みを振り返ってみた https://engineer.retty.me/entry/2020/04/15/090000 自分で項目を選び、成長を文書化し提出。マネージャーがそれについて踏み込んだフィードバックを与える取り組み。半年ごとに実施　

Slide 38

Slide 38 text

人事評価制度はスクラムに合わない、できそこないだよ…  ● とはいえ全社の仕組みを変えることは難しい。  ○ 人事評価制度の改定には大変な労力がかかる。  ● 会社の全てがスクラムになることはない  ○ 総務、人事、採用、営業・・・    　→ 運用でカバーした方がよい。 

Slide 39

Slide 39 text

「目標設定・フィードバック・評価」のまとめ  ● チームで成果をあげてもらうことを意識してもらいつつ、個人への期待を明確にする。  ● フィードバックはこまめに行い、本人評価とのズレを埋める。  ● 「スクラムだから」といって人事評価の基本は変わらない。銀の弾丸はない。  Photo by Aaron Burden on Unsplash

Slide 40

Slide 40 text

まとめ  confidential

Slide 41

Slide 41 text

まとめ  Photo by Hannah Busing on Unsplash ● メンバーの力を引き出し続けるにはマネジメントは必要。  ● チームの自律性を引き出すサポートをし、プロダクト開発の仕組みの改善を促進させる。  ● 「スクラムだから」といって人事評価の基本は変わらない。  ● フィードバックはこまめに行い、本人評価とのズレを埋める。    【マネージャーの方へ】  ○ 事例公開し、いい取り組みを一般化していきましょう。 