ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは（後編）

2024年2月26日

開発プロジェクトにおいて、開発スピードを測る尺度としてよく使われるのが「ベロシティ」です。このベロシティによって示される数字を適切に扱い、開発に活かしていくにはどうすればよいのでしょうか。

そのことを詳しく株式会社アトラクタ吉羽龍太郎氏のセッション「ベロシティ Deep Dive」が、1月に都内で開催されたアジャイル開発の代表的な方法論であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2024」で行われました。

吉羽氏のセッションの内容をダイジェストで紹介しましょう。

本記事は前編、中編、後編の3つに分かれています。いまお読みの記事は後編です。

それでもまだ定量的な報告を求められたら？

それでもまだ、定量的な指標が必要なんだと言われたら、これはなかなか手ごわい状況です。

そういうときにどうするか、という話をします。

これはケント・ベックのブログに載っていたものを書き起こしたものですが、インパクトやアウトカムというのはこういうつながりになっています。

エフォート→アウトプット→アウトカム→インパクト

エフォートとは、計画づくりを頑張りました、ミーティングを何回やりました、コードを何行書きました、プルリクエストを何本送りました、何時間働きました、などの労力をどれだけかけたか、というものです。

アウトプットは、出来上がった計画書とか書いたコードとか、出来上がった機能とか、目に見える形になったもの。

アウトカムが行動変容で、インパクトは売り上げとかコンバージョンレートの向上とかチャーンレートの減少とか。これらはコンテキストによるので自分たちのプロダクトに応じて当てはめていただければいいんですけれど、こんな感じで分解をできるわけです。

この中のどこを測ると良いのかを考えると、最終的に目指しているのはインパクトなので、できればインパクトがいいですよね。もしそれが無理ならアウトカムがいいし、それも無理ならアウトプット、それも無理ならエフォートですよね。

ただ、計画作りを頑張りました、ミーティングを何回やりました、ということを測っても意味があるのかは分からないですよね。なので、インパクトやそれに近いものを狙って測る必要があるのかなと思います。

ちなみにベロシティはアウトプットの一種ですかね。

これに関してケント・ベックは「サイクルの早い段階で測定すればするほど、測定は簡単になる。そしてまた、意図しない結果をもたらす可能性も高くなる」と言っています。

つまりエフォートを測るとみんなそこに最適化しちゃうので、その先のアウトカムやインパクトに必ずしもつながらないよね、と言ってるわけですね。

ですのでアウトカムやインパクトのように、なるべく後ろにあるものを測っていくといいよね、ということになります。

なのでスクラムチームみんなで見るべき指標はプロダクトに関連する指標を選んだ方がいいと個人的には思います。それはNSM（North Star Metric）でもいいし、KGI（Key Goal Indicator）でもKPI（Key Performance Indicator）でもいいです。

ただ、プロダクトの指標は遅行指標が多いんですね。しばらく後にならないと結果が分からないというのも多いので、先行指標を探したい、ということはスクラムチームで話せばいいんです。

プロダクトオーナーしかそのプロダクトのメトリクスに関心がないという状態は非常に不健全です。チーム全員がプロダクトのメトリクスに関心を持っているのがあるべき状態かなと思います。

SPACEフレームワークの紹介

ここで1つフレームワークを紹介しておきます。

「SPACEフレームワーク」というものがあります。これは「LeanとDevOpsの科学」という本の著者の1人であるニコール・フォースグレンという人が論文で発表していて誰でも読めるようになってます。

この中でも明確に、単一のメトリクスを見てもしょうがなくて、複数のメトリクスを見る必要があるよと言っていて、それを複数のカテゴリの中から選んだ方がいいよと言ってるわけです。

そのカテゴリがS（Satisfaction and wellp-being：満足度）、P（Performance：パフォーマンス）、A（Activiti：アクティビティ）、C（Communication and collaboration：コミュニケーションとコラボレーション）、E（Efficeiency and flow：効率とフロー）ということで、それぞれの頭文字をとってSPACEフレームワークということになっています。

ただ、これら全部のカテゴリのマトリクスを必ず全部測れというわけではなくて、複数のカテゴリからチームにとって必要な分だけを選んでね、と言ってるわけです。

ベロシティの良い使い方

ベロシティの良い使い方は、実は非常にシンプルです。1つは、スクラムチームがスプリントでどれぐらいの量を計画するかの材料に使う。

もう1つは、スクラムチームが将来の見通しを立てるために使う。最後は、スクラムチームが自分たちを検査するために使う。

全部にあえて主語として「スクラムチーム」を入れました。つまり、自分たちのためにベロシティを使いましょう、ということです。

それぞれを見ていきましょう。

1つ目の、スクラムチームがスプリントでどれぐらいの量を計画するかの材料に使う。

ベロシティは事実ベースの計画作りに使えますよね。このスライドでは、左側にプロダクトバックログアイテムが並んでいて、平均的なベロシティが10であれば上から2つぐらいが完成しそうだと分かるし、20であれば下の緑の線まで完成しそうだと、大体分かりますよね。

リファインメントのときも同じです。ベロシティが分かってれば、準備がどれぐらい必要かは見えてくるので、そういう計画の材料に使うというのがシンプルな使い方です。

ただし、ベロシティには誤差がありますのであくまで目安として考えてください。数字はどうせ正確ではありません。

スプリントプランニングのときにベロシティ分めいっぱいプロダクトバックログを積みたい、というチームもありますが、スプリントの唯一の目的はスプリントゴールの達成です。

スプリントゴールに関係ないプロダクトバックログを無理に積んでも仕方がないので、ゴールを達成するための計画作りに使ってください。

ちなみに、僕が支援したチームのベロシティの推移を出すとこんな感じです。

デコボコしてますよね、だってプロダクトバックログアイテムの見積もりがしょっちゅうずれますからね。

下にある「出来事」に、「全員1日休み」とか「1人2日不在」などと書かれていますが、こういう記録もとっておくと、スプリントレトロスペクティブでちょっと議論する材料になったりします。

この例は本物です。どこのお客さんかは言えませんが、許可はもらっています。

ベロシティは昨日の天気

次に、スクラムチームが将来の見通しを立てるために使う、ということについて。

「ベロシティは昨日の天気」というスクラムのパターンがあります。直近数スプリントの平均値を使って今後の見通しを立てましょう、というのがよくある使い方です。

例えば、過去3スプリントのベロシティが22→26→24と、まあ普通はこんなに綺麗に安定しないですが、これぐらいで推移してたら、1スプリント24ぐらいはできるのかなと想像がつくので、残りのスプリントがあと5回だったら120ポイント分できるねと。

最低限のリリースまでに96ポイント必要だとしたら、4スプリントは必要だねということが、とりあえず分かります。

ただ、この数字が当てになるかというと、つねに当てになるわけではなくて、時間を経るごとに、チームが安定するごとに数字の信用性は上がっていくので、いつも見通しを更新することが重要です。

そのスクラムチームの説明責任と、いつも自分たちの状況を見える化するという意味で、今後の見通しを見えるように伝えていく。それを繰り返し繰り返しやってください。

ベロシティを自分たちの検査のために使う

最後は、スクラムチームが自分たちの検査のために使う。

透明性、検査と適用ということで、ベロシティのデータを見ながら自分たちのパフォーマンスの改善に使えるはずです。

例えばベロシティの上下動がものすごく激しいとき。0→50→0→50とか、こんな極端な動きははないと思いますけれど、もしこうだとしたら、未完成なものを次スプリントに先送りすることが常態化してるのかもしれない、とか、特定のプロダクトバックログアイテムの見積もりは当てにならないのかもしれない、とか、何かのスキルが足りてなくてボトルネックになっていて、その作業があるときだけうまくいかないのかもしれないとか、掛け持ちがあって時間が不安定なのでベロシティがおかしくなってるのかもしれないとか、議論をして仮説を立てて、検証ができるはずです。