MBOはスクラム（スプリント）運用の中で使えるのか？

参考
スクラム開発におけるマネジメント、目標設定・フィードバック・評価セッションレポート

課題感

会社の目標管理は一般的なMBO目標（クォーター、半年、1年で目標・ノルマを立てて達成、未達成を追う）
一方でスクラム開発はスプリント（1、2週間）ごとに開発機能を決め、PDCAを回していく形式。

発生する具体的な課題

• そもそも根底の価値観、優先度が違う

  • MBOはスケジュール通りに進めることが至上

  • スクラム開発はステークホルダーに合わせスケジュールより品質、コストなど他項目優先することがある

• 開発項目＆スコープが変わる

  • ステークホルダーからの差し込みや開発する中で出てきた優先度高い課題が出てくるため中長期でみると計画のずれが発生する

• 属人性をなくすためのスクラムチームと個人目標は合わない

  • 目標を立てる際に、事前に何の作業やるか不明

  • 組織としての成果は分かっても、個人単位ではだれが何をやったのかわからりづらい

開発項目＆スコープが変わる

現状プロダクトオーナーがざっくりとしたスケジュールを感覚で決め、ガントチャートを作成している。（過去の開発事例などから）
開発進めていくとそもそもの前提条件やスコープが変更したりしてスケジュール変わることがざらに存在する。

• バーンアップチャート

現状中長期のスケジュール管理（リファインメント）を行うことで、マイルストーンごとに大きくポイントを振りバッファ込みの予定ポイント数を作る。
スプリント毎のプランニングでチケットの分解＆正確なポイントを振り直すことでスクラムセレモニーの中で自然にスケジュールの変更など検知できる。
バーンアップチャートについてはGitHub Projectsに機能があるようなので要確認。

Github project/insightの調査内容

属人性をなくすためのアジャイルチームと個人目標は合わない

Rettyの資料を読んだうえでやはり合わないと感じた。
組織目標と個人目標は別で設定すべき。（人事評価はそれら両方踏まえたうえで設計必要そう。）

組織目標＝プロダクト目標

OKRを利用するのがよさそう（OKRとは）
プロダクトが届けたい価値を最高Objectと置いて、マイルストーンやチケットを下位Objectとして分解していく。（チケットのDone率で達成、みったっ性を追っていくイメージ）
以前部署単位の目標設定として使ったことがあるが、以下理由から不適だった。

• 会社全体の目標からドリルダウンするのに時間がかかる

• 会社全体の目標と個人の目標が離れすぎていて個人目標達成による会社への貢献価値が実感できなかった

プロダクトの提供価値を最高Objectとすればマイルストーンやチケットの価値がわかりやすく、スクラム運用の中で自然に作成、更新されていくため管理工数もかからなそう。

チケットのdone, not doneとは別に当初の課題が解決したかのモニタリング指標を追う必要はある。
開発は完了したが、開発したプロダクトが必ずしも当初の課題を解決できるとは限らない。
当初の課題が解決したかを追っていくモニタリング指標を設定し、改善しない場合はさらに振り返り→改修＆新規開発をおこなう。

上記モニタリング指標はPdMが追うべきという考え方もある。しかし開発チームもステークホルダーが最終的に何を解決したいのかという目線は持つべきかつPdMとは別視点からの意見が出たりするのでスクラムチームとして確認した方がいいと考える。

個人目標
チームへの貢献を目標とする。

• チームに不足しているナレッジの勉強

• CI/CDやその他開発フローの改善

上記のようなレトロスペクティブで話され、改善された内容となる。
不足するナレッジなど期初にチーム内で決めた目標と、レトロスペクティブの中で対処したチケット両方を踏まえて個人の評価とする。

結論

Rettyの資料に書いてある通り