Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

Yuichi Tsunematsu

June 27, 2020
Tweet

More Decks by Yuichi Tsunematsu

Other Decks in Business

Transcript

  1. 自己紹介
 • 常松祐一 (つねまつ ゆういち) 
 ◦ Engineering Manager 


    ◦ Software Engineering Coach 
 ◦ Agile Development
 • SNSアカウント
 ◦ tunepolo : 
 ◦ tune : 
 
 • 顧客にとって価値のあるプロダクトを、チーム一丸 となって協力し、短期間にリリースする開発体制の あり方を模索しています。 

  2. 3 自分にとってBESTなお店が見つかる 
 日本最大級の"実名型"グルメサービス
 レビューよりもレコメンド。 
 Rettyは他人におすすめしたい 
 美味しいお店を投稿するサービス! 


    食の好みは人それぞれ。 
 自分と嗜好が合う人をフォローして、 
 BESTなお店を見つけられるSNS型! 
 実名制の口コミだからこそ 
 「信頼できる」「ポジティブ」な 
 情報が集まっています! 
 批評ではなくオススメの口コミ 
 自分と好みが近い人から探せる 
 顔が見えて信頼できる実名制 
 confidential
  3. 自身のマネジメント/アジャイル開発経験
 メーカー 海外子会社 メーカー 新規事業 【マネージャー/非アジャイル】 電子辞書の開発を2年半 開発プロセスはウォーターフォール 組織上の職位はマネージャー 人事評価を行う

    【非マネージャー/アジャイル】 新規事業開発を3年 開発プロセスはスクラム、途中から大規模スクラム (LeSS) スクラムでの役割は当初 PO→後にSMへ 組織上の職位は主任研究員 (=課長代理) 人事評価は行わない 【マネージャー/アジャイル】 Webサービスの開発を1年 開発プロセスはスクラム、途中から大規模スクラム (LeSS) スクラムでの役割は社内コーチ、ステークホルダーの 1人 組織上の職位はマネージャー 人事評価を行う
  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. スクラムにおける立ち位置 - アンチパターン
 1. POとマネージャーを兼ねる → 開発チームから意見しにくい
 2. SMとマネージャーを兼ねる
 →

    開発チームから意見しにくい & プレイングマネージャー化
 3. SMをマイクロマネジメントする → チームの自律性が損なわれる
 PO&Mgr SM Engineer PO SM&Mgr Engineer PO SM Engineer Mgr パターン1 パターン2 パターン3
  6. マネージャーとチームのコミュニケーション具体例
 Photo by Markus Spiske on Unsplash 開発チームの自律性を引き出すように留意する
 ◦ 業務へのアサイン


    ◦ 業務指示の出し方
 ◦ 実装方針の決定
 ◦ 定期的な進捗の把握
 ◦ チーム外への進捗報告
 ◦ 新しい取り組みの導入

  7. 業務へのアサイン
 confidential • プロダクトに開発チームをアサイ ンする。
 • チームメンバーは頻繁に入れ替 えない。
 プロダクト =

    期限なし
 • プロジェクトにメンバーをアサイン する。
 • プロジェクトが終わったらメンバー を異動させる。
 プロジェクト = 期限あり

  8. マネージャーがとる日々の具体的な行動
 • Slackのやりとりを覗く
 ◦ 全体チャンネル・チームチャンネル・個人チャンネル など
 • GitHub Pull Requestでのやりとりを覗く


    ◦ 噛み合った議論をしているか
 • スクラムイベントでの立ち振る舞いを覗く
 ◦ 儀式的にやってないか
 • おさんぽ (Management By Walking Around : https://kshimizu.hatenadiary.jp/entry/2016/07/14/060511 )
 ◦ 近くに行ってチームの様子を観察
 • 1on1 (後述)

  9. Rettyにおける人事評価制度
 • 3ヶ月ごと
 ◦ 目標管理(Management by Objectives)
 ▪ 1:目標を設定する /

    目標が適正か確認
 ▪ 2:目標を達成するために活動をする
 ▪ 3:目標を達成できたか評価をする
 ◦ 同僚からのピアレビュー
 ◦ マネージャーからの評価
 • 半年ごと
 ◦ 直近1年の成果を鑑みて、業務グレードの見直し

  10. 「目標設定」は分解して設定する
 • 組織目標(部門目標)
 ◦ 複数チームで共通
 ◦ 3ヶ月毎に見直す、大きくは変わらない
 • 個人目標
 ◦

    全員ほぼ共通、公開する
 ◦ 3ヶ月毎に見直す、あまり変わらない
 • 個人課題
 ◦ 個人ごとに固有、非公開
 ◦ 業務グレードが変わらない限り変わらない

  11. 組織目標(部門目標)の例
 • 開発着手からリリースまでの日数 → 平均5日
 • インシデント発生数 → N件以下
 •

    XXX機能のリリース
 ◦ ※3ヶ月ぐらいかかる、大きめで変わらないやりきり目標
 • サイトパフォーマンス改善 N%
 
 目標達成のインセンティブで、スクラム開発に悪影響が出ないよう、留意 する必要がある。
 • 複数チームで共通
 • 3ヶ月毎に見直す、大きくは変わらない
  12. 個人課題の例
 • 現状の期待役割
 ◦ 開発組織の効率改善
 ◦ LeSSの範囲を広げ習熟度を上げていく
 ◦ 開発組織に余裕を作るための下地を作る
 •

    次の業務グレードに上がるために必要なこと
 ◦ 組織を大きく変革していくための中核を担う
 ◦ サービスにおける大きな課題を解決するプロジェクトを主導して成功させる
 ◦ 開発組織メンバーのマインドの向上
 • 個人ごとに固有、非公開
 • 業務グレードが変わらない限り変わらない これは      の本物です。
  13. 定量目標じゃなくて良いの?
 • 設定できるならその方が良い。
 ◦ おかしな指標を建てる方が有害、ベロシティN%アップとか
 • 定量目標を達成できても高い評価が付けられないリスク
 ◦ 目標が低すぎた。周りがより高い成果出した。
 ◦

    給与・賞与の原資は有限。
 • 多くの人は絶対評価されることを求めているのではなく、「期待とずれ のない評価」を受けることを求めている。
 Photo by Ümit Bulut on Unsplash
  14. フィードバックはこまめに、評価のズレを埋めていく
 • 週1回の1on1で都度伝える
 ◦ よかった動き。
 ◦ よくなかった動き、できていないこと。”はっきり”伝える。
 • 成果・アウトプットをどう受け取っているか
 ◦

    自分はどう考えているか ⇦ 本人の期待
 ◦ チームメンバーはこう感じていた(伝聞)
 ◦ マネージャーこう感じた
 ◦ 部門内外のメンバはこう感じていた(伝聞) ⇦ 評価基準はここ

  15. まとめ
 Photo by Hannah Busing on Unsplash • メンバーの力を引き出し続けるにはマネジメントは必要。
 •

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