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

今回は「ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは（前編）」についてご紹介します。

関連ワード （意味、目先、目標等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

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

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

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

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

ベロシティ Deep Dive

吉羽龍太郎氏。

これから「ベロシティ Deep Dive」ということで「ベロシティ」についてお話をしていきたいと思います。

ベロシティを使っているっていう方、会場にどれぐらいいますか？ （手が挙がる） 結構多いですね、半分以上かな。なるほどなるほど。

最初に自己紹介ですね。吉羽（よしば）と申します。

株式会社アトラクタという会社をやっておりましてアジャイルコーチングの会社としていろんな会社さんの支援をしています。X/Twitterは@ryuzeeですね。

アジャイルとかスクラムに関するブログも書いていまして、ちょっとネタ切れになってきてますので、皆さんからこういうのを書いてほしいというリクエストがあればバンバン書きますのでぜひお気軽にリクエストを寄せていただければと思います。

本もいろいろ書いたり訳したりしています。

ベロシティにDeep Diveしている暇があったら

では本編に入っていきたいと思います。

いきなりひどい言い草なので怒らないでほしいのですが、僕が勝手に、こうなのかな、と考えているのは、スクラムチームの中で「ベロシティ」とか「生産性」という単語が出てくる回数が多ければ多いほど、ちょっと実はやばい状況なんじゃないのかなと。生み出す価値と反比例してるのかな、ということ。そういう気がしてならないわけです。

要は本当に大事なことにフォーカスしないで、目先の数字にばかりフォーカスしているのは、あまりよくない状況なんじゃないのかなと思ってます。

今日はベロシティにDeep Diveするわけで、そこでいきなりそんなことを言うなという感じですが、ベロシティにDeep Diveしている暇があったらプロダクトの価値にDeep Diveしようね、というのが実は本当にお伝えしたいことだったりするわけです。

ウォーレン・バフェットという人の言葉で「ゲームに勝つのは、フィールドに集中する選手であって、スコアボードに釘付けになってる選手ではない」というのがあります。なかなかいい言葉ですよね。

ベロシティとかプルリクの回数とか、メトリクスばかり見ていてもゲームには勝てないわけです。あくまでも断面図として数字が出てくるのであって、そこばかり見ていてもしょうがない、という気がします。

とはいえ、今日はベロシティの適切な使い方とそのアンチパターンみたいなところをお話していきます。

ベロシティとは何か？

まず、ベロシティとはなんぞや、という話ですが、「1スプリントで完成したプロダクトバックログアイテムのサイズの合計値」です。

スクラムはそれ自体では見積もりのやり方は一切決めていません。単に「プロダクトバックログアイテムのサイズを明らかにせよ」としか言っていないので、ストーリーポイントを使うのはひとつのやり方にすぎないのですが、ストーリーポイントを使う例としてはポイントで見積もりをして、例えば3ポイント、5ポイント、5ポイントのプロダクトバックログアイテムが全部完成したら合計して13ポイントになります。

これがベロシティです。当然のことながら完成しなかったものは計算に入れません。

途中まで開発が終わってるものは半分のポイントを計上してもいいですか？ と、たまに質問されますが、半分終わっているかどうかは想像ですよね。

あと半分で全部終わるかどうかは分からないので、部分的な計上は一切せず、完成したものだけを計算しましょう、というのが基本です。

ベロシティは、プロダクトバックログアイテムのサイズを足していけば簡単に計測できるので、誰もが計測したくなるわけです。

けれども、簡単だから測る、それでいいのか？ ということです。

ベロシティのアンチパターン1：生産性の指標として扱う

そこで、いくつかベロシティのアンチパターンを紹介していきます。

1つ目のアンチパターンは、ベロシティを「生産性」の指標として扱う、です。

やめろと。大事なことなので3回言いました。

なぜやめろと言うのか。この「生産性」という単語のうさん臭さですよね。

生産性という言葉はよく使われますし、皆が同じものをイメージしてるように思うかもしれないのですが、実際のところ全然そんなことはないんです。

生産性とは何かというと、定義では「産出したもの」割る「投入したもの」という割り算で計算しますが、大きく分けると生産性とは2つに分けられます。

ひとつは「物的生産性」、もうひとつは「付加価値生産性」です。

物的生産性とは、実際に作ったもの、生産したものの数とか量を基にします。工場のラインで製品を何個作りましたとか、そういうやつですね。

一方で付加価値生産性とは、生産したものが生み出した付加価値を基にしたものです。

つまり、生産性の計算式に何をいれるか、作った物量を入れるか、生み出した付加価値を入れるか、どっちもあり得るということです。

けれど、どの会社でもこれを使い分けていないと思います。

何気なく使っている単語ほど、みんなの定義を揃えるのは重要なんですが、アジャイルでもそこはとても重要になってきます。

スクラムは価値を重視している

そこで、スクラムが何を目指してるのかを考えてみると、僕はスクラムガイドのマニアなのでスクラムガイドを形態素解析して単語をカウントするプログラムを書いたりするのですが、それで過去のスクラムガイドから「ベロシティ」と「生産性」という単語の登場回数を全部解析した結果がこれです。

これを見ていただくと分かりますが、「ベロシティ」は2010年版に一度登場したきりで、その後は登場していません。

一方で「生産性」はどの版でも複数回出てきていますし、さらに「価値」はどの版でも10回以上出てきています。

特に2020年版のスクラムガイドは分量が3分の2ぐらいに減ったのですが、「価値」の登場回数は過去最多です。

つまりスクラムは何を重視しているか。生産性とかベロシティとかではなく、価値を重視している。スクラムガイドからそれは明らかだということになります。

ベロシティの上下に一喜一憂しない

2つ目のアンチパターンは、数字の上下に一喜一憂する、ということです。スクラムをやり始めた人たちにありがちですね。

ベロシティが上がった、やった。また上がった、やった。という感じのやつですが、そもそもスクラムにおける見積もりとは、「だいたいいい感じ」というぐらいの見積もりなんですよ。

例えば、ストーリーポイントで見積もるとすれば、フィボナッチ数列を使いますよね。1、2、3、5、8、13とか。そうすると後ろの数字になるにつれて、前のアイテムの見積もりとの差がどんどん大きくなっていきます。

これだと見積もり対象の規模が大きくなればなるほど見積もりの誤差が出ることはもう前提になっています。ただ、全体をならしてみると、ある見積もりは小さめで、別の見積もりは大きめで、ということが繰り返されてだいたいそれなりに収まりますね、という感じです。

つまりベロシティは厳密性を求めるものでもなんでもない、ということです。

だったら見積もりにもっと時間をかけて精度を上げればよいのでは？ と反論する人がいます。

でも、その時間はプロダクトの価値を生み出すために使うべきです。

見積もりを精緻にすることに時間を使ってしまい開発の時間が足りなくなってしまいました、というのでは無意味ですから、時間を使って見積もりを正確にしましょうというのも意味はありません。

つまり、ベロシティの数字に一喜一憂しても意味がない、ということになります。

ベロシティの目標を立てても悪くはないが……

3つ目のアンチパターンは、目標のベロシティを設定し、それに届かないことを問題とみなす、です。

これは受託開発とかだとよく起こるんですね。例えば、お客さんからの要件を全部達成するには、1スプリントあたり40ポイントのベロシティが必要だから、それを目標にしましょう、とか。

これは原理原則に立ち返りましょう。原理原則とは、スクラムは経験主義だということです。

経験主義では、知識は経験から生まれ、意思決定は観察に基づきます。これはスクラムガイドにもちゃんと書いてあることです。

つまり、経験した事実を踏まえてどうするのか、というのをやっていくしかないわけです。だから目標に届かなかったという事実を踏まえて、次にどうするのか、ということが重要です。

スクラムチームの能力を超えるような目標を立てたところで達成できるはずがないんです。それだけです。チームが悪いのかというと、別にチームは悪くないんですよ。計画が悪かった、それだけです。

目標を立てても悪くはないと思うんです。これぐらいできるはず、できたらいいな、という目標を立てるのは。

ただ、達成できなかったときに「お前らが悪いんだ」ではなくて、その現実を受け止めて、じゃあ次にどうするのかを考えないと意味がない。

ただ、例えば「1スプリントで40ポイントを終わらせれば間に合います」とお客さんに約束してしまった、なんていう場合は救いようがありません。

僕もSIerにいたことがあって、まあまああるんですよ。そういうことが。

1スプリントで40ポイントならなんとかなるかもしれないと思っても、大体最初の数スプリントでその夢は崩れるわけです。やばいと、全然その通りにならないと。で、どうするんだ？ と上に詰められるわけです。

とはいえ、経験した事実を踏まえて、次にどうするかを考えていくのがアジャイルのやり方なので、できるかどうかわからない約束を最初にしてしまった時点で、それはスクラムを分かってませんね、という話になってしまうわけですね。

≫続きます。中編では、ベロシティを個人やチームの評価に使うべきではない、ベロシティをチーム間で比較しない、などのアンチパターンを解説しています。

関連記事

• プロダクトバックログDeep Dive。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか（前編）