1. ベロシティ Deep Dive 2024/1/10 Regional Scrum Gathering Tokyo 2024 初版 株式会社アトラクタ 吉羽 龍太郎 (@ryuzee)
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー ▸ X(Twitter): @ryuzee / https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. アトラクタのアジャイルコーチングで 持続的に成果を出し続けるアジャイルチームを作る 「あなたのゴールは、他人から押し付けられるアジャイルの行動規範に依存するのではなく、 自分たちで考えることのできる、生産的なアジャイルチームを育てることです」 書籍『アジャイルコーチング』（Rachel Davies、Liz Sedley 著、永瀬美穂、角征典 訳、オーム社、2017） なぜアジャイル開発では「コーチ」なのか 変化に気づき、対応するを養う 顧客志向の目的と行動様式を獲得する コーチの経験と知見の力を借りた素早い立ち上がり
5. スクラムチームにおける 「ベロシティ」「生産性」 という言葉の登場回数と 生み出す価値は反比例 する @RYUZEE
6. ゲームに勝つのは、フィ ールドに集中する選手 であって、スコアボード に釘付けになっている選 手ではない ウォーレン・バフェット
7. ベロシティ DEEP DIVE ベロシティとは？ ▸ 1スプリントで「完成」したプロダクトバックログアイテムのサイズの合計値 ▸ （例）3ポイント、5ポイント、5ポイントのプロダクトバックログアイテムが完成＝13ポイント ▸ 完成しなかったものは計算に入れない ▸ 部分的な計上などもしない ▸ とても簡単に計測できる！ ▸ でも簡単だからといって測るべきとは限らない 7
8. ベロシティ DEEP DIVE ベロシティの良くない使い方 ▸ 1. ベロシティを「生産性」の指標として扱う ▸ 2. 数字の上下に一喜一憂する ▸ 3. 目標ベロシティを設定し、それに届かないことを問題とみなす ▸ 4. ベロシティを誰かに報告する ▸ 5. スクラムチームや個人を評価するために使う ▸ 6. 複数チーム間で比較する 8
9. ベロシティ DEEP DIVE 1. ベロシティを「生産性」の指標として扱う ▸ やめろ ▸ ヤメロ ▸ YAMERO 9
10. ベロシティ DEEP DIVE 「生産性」とは何か？ ▸ 生産性 = 産出 ÷ 投入 ▸ 生産性は大きく2つに分けられる ▸ 物的生産性……生産したものの数や量を元にしたもの ▸ 付加価値生産性……生産したものが生み出した付加価値（金銭など）を元にしたもの ▸ ひとことで「生産性」というと誤解を招く 10
11. ベロシティ DEEP DIVE 11 スクラムは何を目指しているのか？（スクラムガイド内での単語の登場回数） 2020 2017 2016 2013 2011/10 2011/7 2010 ベロシティ 0 0 0 0 0 0 1 生産性 2 4 4 4 3 4 3 価値 21 19 18 21 10 11 13 ※「価値基準」は計算に含めていない
12. ベロシティ DEEP DIVE スクラムは何を目指しているのか？ ▸ スクラムが目指しているのはプロダクトが生み出す価値（アウトカムやインパクト） ▸ つまりスクラムでは付加価値生産性を重視しなければいけない ▸ 物的生産性がいくら高くても、アウトカムやインパクトがなければ無意味 ▸ ベロシティは物的生産性 ▸ 開発生産性と言ってもよい ▸ 「スクラムは効率がいいですか？」とよく聞かれるが、「効率はよくない」 ▸ イベントに20%の時間を使い、何度も作ったものに手を加えるやり方が効率がよいわけがない ▸ スクラムは効率より効果を目指している 12
13. ベロシティ DEEP DIVE 2. 数字の上下に一喜一憂する（ベロシティは正確なのか？） ▸ スクラムにおける見積りは「だいたいいいかんじ」の見積り ▸ たとえば、ストーリーポイントを使う場合、フィボナッチ数列が一般的（1/2/3/5/8/13/……） ▸ 対象の規模が大きくなるほど見積りの誤差が出る前提になっている ▸ でも全体で見るとそれなりに収まる ▸ つまりベロシティも「だいたいいいかんじ」の数字であり、厳密性を求めるものではない ▸ 「だったら、もっと見積りに時間を使えばいいんじゃ？」 ▸ その時間をプロダクトの価値を生み出すことに使え 13
14. ベロシティ DEEP DIVE 3. 目標ベロシティを設定し、それに届かないことを問題とみなす ▸ スクラムは経験主義 ▸ 「経験主義では、知識は経験から生まれ、意思決定は観察に基づく」 ▸ 目標に届かなかった事実を踏まえて、次にどうするかのほうが重要 ▸ スクラムチームの能力を超えた目標を立てても達成できるはずがない ▸ 「スプリントプランニングで計画した分が完成しなかったので問題だ」も同じ ▸ 単に計画や目標が間違っているだけ 14
15. ベロシティ DEEP DIVE 15 4. ベロシティを誰かに報告する？ ▸ 開発者がプロダクトオーナーに報告する？ ▸ 「スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ」 ▸ プロダクトオーナーがどれだけ完成しているか把握していないなら説明責任を果たしていない ▸ プロダクトオーナーがステークホルダーに報告する？ ▸ 「スクラムチームは、自分たちで作業を管理できるように組織によって構成され、その権限が与えら れている」 ▸ 「プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結 果に責任を持つ」 ▸ ベロシティを報告しても、プロダクトの価値は見える化も検証もされない
16. ベロシティ DEEP DIVE 16 5. スクラムチームや個人を評価するために使う ▸ 作った物の量で評価できるのは量産品だけ ▸ スクラムチームは価値を追求しなければいけない ▸ スクラムの価値基準の1つは「集中」 ▸ プロダクトゴールは1つ、スプリントゴールも1つ ▸ つまり、いちばん大事なことに集中する ▸ プロダクトの価値以外にベロシティをスクラムチームや個人が重要視しているなら集中できていない ▸ 個人ごとにベロシティを算出しようとすると、スクラムチーム内の協力関係を阻害し、仕掛りが大量に生ま れるリスクを抱える ▸
17. 管理のために用いられ る測定はすべて信頼で きない グッドハートの法則
18. あなたが私をどう評価 するか教えてくれたら、 どう私が行動するか教 えましょう エリヤフ・ゴールドラット
19. ベロシティ DEEP DIVE 6. 複数チーム間で比較する ▸ 単純比較はできない ▸ 異なるプロダクト同士ではストーリーポイントの1ポイントが示すサイズ自体が違う ▸ 見積りの基準を揃えたら？ ▸ スクラムチームが得られるメリットが何もない ▸ スクラムチームは自己管理であり、いつ誰が何をどうやって行なうかは自分たちで決める ▸ 見積りのやり方を強制するのは自己管理に反している ▸ 唯一の例外は、同一プロダクト、同一プロダクトバックログを扱うチームが複数いる場合 ▸ この場合は比較できるが、意味があるかどうかは別の問題 19
20. ベロシティ DEEP DIVE 20 「言ってることはわかるけど、でも組織がいろいろ言うんですよ」 定量的に報告してください。 じゃないと状況がわかりません
21. ベロシティ DEEP DIVE 組織がSMARTを求める ▸ 目標設定やタスク分解のときによく言われる ▸ Speci c 具体的 ▸ Measurable 計測可能 ▸ Achievable 達成可能 ▸ Related 関連性がある ▸ Time-bounded 期限がある ▸ なぜか「Measurable 計測可能」がやたらと強調される fi ▸ 本当はRelated (関連性がある) が重要 21
22. 何も測らないよりは、何か測っ た方がいい？そんなことはな い！ 重要でないものの正確な 尺度よりも、価値あるもののあ いまいな尺度の方がいい ジム・ハイスミス https://jimhighsmith.com/productivity-measures-are-a-myth-held-over-from-the-1980s/
23. 測定できないものは管 理できない、と考えるの は誤りである。 これは代 償の大きい誤解だ エドワーズ・デミング
25. ベロシティ DEEP DIVE スクラムマスターの出番では？ ▸ スクラムマスターの組織に対する働きかけ ▸ 組織へのスクラムの導入を指導・トレーニング・コーチする ▸ 組織においてスクラムの実施方法を計画・助言する ▸ 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう ▸ ステークホルダーとスクラムチームの間の障壁を取り除く 25
26. ベロシティ DEEP DIVE 26 スプリントレビューに来てもらおう ▸ そんなに気になるのであれば、スプリントレビューに来てもらう ▸ 「プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなけ ればならない。 これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューで の検査可能なインクリメントによって見える化される」 ▸ 「スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自 分たちの環境で何が変化したかについてレビューする」 ▸ 「プロダクトゴールは、プロダクトの将来の状態を表している。 それがスクラムチームの計画のター ゲットになる」 ▸ ベロシティだけではスクラムチームのこともプロダクトのこともわからない
27. ベロシティ DEEP DIVE 27 それでも定量的な指標が必要と言われたら？ Output E ort Outcome Impact ff [^1]: 出典 Measuring developer productivity? A response to McKinsey, Kent Beck他
28. ベロシティ DEEP DIVE 28 それでも定量的な指標が必要と言われたら？ Output できあがった計画、書いた コード、できあがった機 能…… E ort Outcome 計画づくり、ミーティング、 コードを書く、PRを送る、 テストする、N時間働く…… 顧客やユーザーの 行動変容 Impact ff 生み出された価値（売上、コ ンバージョン向上、チャーン 減少……）
29. サイクルの早い段階で測 定すればするほど、測定 は簡単になる。そしてま た、意図しない結果をもた らす可能性も高くなる ケント・ベック
30. ベロシティ DEEP DIVE 30 それでも定量的な指標が必要と言われたら？ ▸ プロダクトの価値と関連する指標（付加価値生産性につながる指標）を選ぶ ▸ NSM、KGI、KPIなど ▸ 「期限までにN個の機能を作った」のような開発生産性（物的生産性）指標が最重要なわけではない fl ▸ ただしプロダクト関連の指標は遅行指標になりがちなので、もう少し工夫が必要かもしれない Net ix Attention 月間N時間以上視聴しているユーザーの数 Spotify Attention 有償顧客の月間楽曲再生時間の合計 Amazon Transaction 1プライムユーザーあたりの購入金額の合計 Walmart Transaction 顧客の1回あたりの購入点数 Salesforce Productivity アカウントあたりの平均レコード作成数 Adobe Productivity エンゲージメントが高いサブスク購入者数
31. ベロシティ DEEP DIVE 複数の観点から指標を見る（SPACEフレームワーク） ▸ 『LeanとDevOpsの科学』の著者の1人ニコール・フォースグレンらによる論文[^1]で公表 ▸ 複数のカテゴリを計測（定性データも含む）することで全体像を適切に把握できるようにする ▸ SPACE ▸ S: Satisfaction and well-being: 満足度 ▸ P: Performance: パフォーマンス ▸ A: Activity: アクティビティ ▸ C: Communication and collaboration: コミュニケーションとコラボレーション ▸ E: E ciency and ow: 効率とフロー fl ffi [^1]: 出典 The SPACE of Developer Productivity, Nicole Forsgren他, https://queue.acm.org/detail.cfm?id=3454124 31
32. ベロシティ DEEP DIVE 32 SPACEの指標の例 S 従業員満足度、自分のチームに他の人を推薦するか、必要なツールやリソースがある か、燃え尽きやストレスを抱えていないか…… P 信頼性、バグがないこと、サービスの健全性、顧客満足度、顧客増加やリテンション、機能 の利用状況、コスト削減…… A プルリクエストやコミット数、コードレビュー回数、ビルド/テスト/リリース回数、インフラ 利用率、インシデント回数、オンコール対応数、インシデント対応回数…… C ドキュメントや専門知識の見つけやすさ、統合の速さ、レビューの質、人同士の繋がりを 示すネットワーク指標、新メンバーのオンボーディングにかかる時間や体験の質 E 受け渡し回数、フローを維持する能力、割り込みの回数/タイミング/インパクト、作業時 間、付加価値時間、待ち時間…… ※複数のカテゴリから指標を選ぶこと、システムではなく感覚や感情に由来する指標を含めることを推奨している
33. ベロシティ DEEP DIVE ベロシティの良い使い方 ▸ 1. スクラムチームがスプリントでどれくらいの量を計画するかの材料に使う ▸ 2. スクラムチームが将来の見通しをたてるために使う ▸ 3. スクラムチームが自分たちを検査するために使う 33
34. ベロシティ DEEP DIVE 34 1. スクラムチームがスプリントでどれくらいの量を計画するかの材料に使う プロダクトバックログ ▸ ベロシティは事実ベースの計画に使える 3 ▸ 平均的なベロシティが10なら上から2つくらいが完成しそう（赤線） 8 ▸ 平均的なベロシティが20ならいちばん下を除いて完成しそう（緑線） ▸ プロダクトバックログリファインメントのときも同じ考え方が使える 2 1 2 ▸ どのくらいのプロダクトバックログアイテムを準備すればいいかわかる 3 ▸ ただしプロダクトバックログアイテムの見積りの誤差、キャパシティの変動があ るので、あくまでも目安として考える 5 ▸ たくさん完成させることよりスプリントゴールの達成を優先せよ
35. ベロシティ DEEP DIVE 35 あるチームのベロシティ推移 #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 投入 33 36 47 58 31 30 48 46 33 43 52 ベロシティ 33 24 47 50 31 30 33 46 33 43 52 タスク見積り 43h 36h 33h 44h 29h 22h 46h 33h 29h 38h 41h キャパシティ 84h 63h 61h 72h 78h 36h 77h 80h 53h 86h 86h 出来事 全員1日 休み 1人 2日不在 1人 1日不在 1人 1日不在 全員1日 休み 1人 1日不在 プランニ 1人 祝日あり ング短時 1日不在 間終了
36. ベロシティ DEEP DIVE 2. スクラムチームが将来の見通しをたてるために使う ▸ ベロシティは昨日の天気（スクラムパターン） ▸ 直近数スプリントの実績をもとにして、今後の見通しをたてるのに使える ▸ 例えば、過去3スプリントのベロシティが22→26→24と推移していた場合 ▸ 残りスプリントがあと5回なら、開発できそうなのは120ポイント分 ▸ 最低限のリリースまでに96ポイント分の開発が必要なら、リリースまで4スプリント ▸ 始めて数スプリントの状況での数値はあてにならない ▸ 時間を経るごとに見通しの精度は上がっていく ▸ とはいえ、これは約束ではなく見通しであることに注意 36
37. ベロシティ DEEP DIVE 3. スクラムチームが自分たちを検査するために使う ▸ スクラムの3本柱は透明性・検査・適応 ▸ ベロシティのデータを見ながら、自分たちのパフォーマンスを改善する ▸ （例）ベロシティの上下が激しい ▸ 未完成のものを次のスプリントで完成させることが常態化していないか？ ▸ 特定の種類のプロダクトバックログアイテムの見積りの精度が低くないか？ ▸ 開発者のなかにスキルのボトルネックがないか？ ▸ 割り込みや掛け持ちで作業に使える時間が不安定になっていないか？ 37
38. ベロシティ DEEP DIVE 38 まとめ ▸ ベロシティとは1スプリントで「完成」したプロダクトバックログアイテムのサイズの合計値 ▸ ベロシティを「生産性」の指標として扱わない。アジャイルやスクラムが目指すのは価値の実現であり、こ の文脈での生産性は「付加価値生産性」である ▸ たくさんの機能を開発できても価値が増えるとは限らない ▸ ベロシティを誰かに報告したり、評価に使ったり、目標値を設定したりするのは無意味 ▸ 計測しやすい指標だからといって、それが意味があるとは限らない ▸ アジャイルにおける進捗の尺度は動作するソフトウェア。スプリントレビューに招待しよう ▸ 指標が必要なら、まずは付加価値生産性に近いプロダクトの指標を使う ▸ ベロシティはスクラムチーム自身の予測と改善のために使う
39. ベロシティなんかに DEEP DIVEせず、もっと 重要なところに集中しろ @RYUZEE
