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

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

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

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

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

ベロシティを誰かに報告する？

次のアンチパターンは、ベロシティを誰かに報告する、です。

いくつかパターンはあって、開発者がプロダクトオーナーに報告をするパターン、プロダクトオーナーがステークホルダーに報告するパターンなどですね。

開発者がプロダクトオーナーに報告をするパターンは何度か見たことがあります。これはスクラムがうまく回っていない香りがしますよね。なんでプロダクトオーナーがベロシティを開発者に報告してもらわないといけないのでしょう？

スクラムガイドでは「スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ」とあります。スクラムチームとして共同で責任を持つわけですから、当然プロダクトオーナーも状況を知らなくてはいけません。

プロダクトオーナーがプロダクトバックログアイテムを書いてスプリントプランニングで開発者に渡して、あとは開発をよろしくね、みたいなことをやってるとこうなります。けれども、それはスクラムチームとしての共同責任を果たしてないということになります。

もう1つのパターンが、ベロシティをプロダクトオーナーがステークホルダーに報告をするパターン。これもあるあるです。

スクラムガイドには「スクラムチームは、自分たちで作業を管理できるように組織によって構成され、その権限が与えられている」と書かれています。

そして「プロダクトオーナーはスクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ」と書いてあるんです。

結局スクラムチームが全部説明責任を担って自分たちでやっているのに、なんで開発生産性を報告しなければいけないのかと。

スクラムチームはプロダクトの価値を生み出すことに対して説明をしなくてはいけないので、そこにフォーカスした方がいいよねと。

今回のスプリントでのベロシティは13でした、と報告しても、プロダクトの価値もリスクも何も見える化されないので、ベロシティの数字をスクラムチームの外に出しても意味がないと思っています。

ベロシティを個人やチームの評価に使うべきではない

次のアンチパターンは、スクラムチームや個人を評価するために使う、です。

作ったものの量で評価できるのは量産品だけですね。スクラムチームはこれまで何回も説明しているように、価値を追求しなくてはいけない、ということです。

スクラムの価値基準の一つに「集中」というのがあります。集中はとても大事で、確約と集中の2つは、スクラムの5つの価値（確約、勇気、集中、公開、尊敬）の中でも特に大事だと個人的に思っています。

集中するべきなので、プロダクトゴールは1つだし、スプリントゴールも1つなわけです。同時に複数をゴールとして追求したら集中できず、結果も出ないでしょう。

この背景にあるのが、一番大事なことに集中しようよ、ということです。

スクラムチームや個人を評価するためにベロシティを使うと、チームの人たちは当然、ベロシティを気にするようになります。

そうなるとプロダクトの価値とベロシティの両方に気を使うことになり、集中できなくなります。

さらに、個人ごとにベロシティを算出することをやりたがる会社もありますけれど、そうすると個人単位でプロダクトバックログアイテムをアサインすることになります。

すると、スプリントの最後にどのアイテムも未完成で終わるリスクが極めて高くなります。スプリントレビューのときに、何のインクリメントも見せられないしスプリントゴールも達成できない可能性が高くなりますよね。

もしくはみんなが頑張って何とか達成できたとしても、それぞれが自分に割り当てられたアイテムを頑張って終わらせようという力が働くので、他人を助けてる暇なんかないわけですよ。

そうすると起こりそうなのは、例えばプルリクエストのレビューを依頼されても、自分はアイテムに集中していてそんな暇はないからレビューはしません、という状態が多発することです。

こうなるとスクラムチーム内の協力関係を阻害して、仕掛りが大量に生まれる可能性が高くなってきます。

これは最悪のシナリオですので、実際にはここまでひどくはならないと思いますが。

ということでベロシティをスクラムチームや個人を評価するために使うとロクなことにはならない、ということです。

管理のために用いられる測定は信頼できない

これに関係する「グッドハートの法則」という有名な法則があります。これは「管理のために用いられる測定はすべて信頼できない」というものです。

これを解説する書籍はいろいろありますので興味のある方はそちらを読んでいただきたいと思いますが、要するにみんなKPIをハックするようになる、ということです。

ゴールドラットも「あなたが私をどう評価するか教えてくれたら、どう私が行動するか教えましょう」と言っています。

人間は評価基準が分かればそれに合うように行動して最適化してしまうことになるんです。皆さんにも心当たりはありますかね？

ベロシティをチーム間で比較しない

アンチパターンの最後は、「複数チーム間で比較する」ですね。

そもそもチームのパフォーマンスの評価に使うものではない、という話をしていますので当然のことですが、異なるプロダクトではストーリーポイントの見積もりの基準が違うからそもそも比べられません。

しかしここで偉い人とかマネージャなどからのカウンタートークが来るわけです。見積もりの基準を揃えたらいいじゃないか、とね。

でも冷静に考えていただくと、基準を揃えることのメリットはスクラムチームにはないんです。

スクラムチームは自己管理なので、いつ誰が何をどうやってやるかは自分たちで決めます。ですから、見積もりの基準を揃えることを強制される筋合いもない、ということになります。

ですから、チームの外のマネージャが「見積もりの基準を揃えろ」と言いたくなる気持ちは分かりますが、見積もりのやり方を強制するということは自己管理にならないということです。

ただし、唯一の例外は1つのプロダクトに対して複数チームが関わっていて、同じプロダクトバックログアイテムを共有している場合、これは比較はできます。

比較できますが、その意味があるかどうかは全く別問題です。意味があるかどうかはコンテキストによるので、よく考えていただければいいのかなと思います。

定量的に報告を求められたら？

ここまでのアンチパターンの話は、実際には皆さん分かっているんだと思います。

でも「定量的に報告してください」と、うるさく言う上司やマネージャがいることはよくあります。組織が「SMART」を求めるのはありがちなことですね。

特に目標設定やタスク分解をするときによく言われますが、数値で測れるゴールを設定することが重要なんだと、SMARTの「M」のMesurable、計測可能であることがやたらと強調されるんです。

しかし重要なのは、SMARTの「R」、Relatedですよね。目指してるゴールに関連性のあるものを目標として設定しないと意味がないんです。ですが、組織やマネージャが測ることばかり強調してくる、というのがありがちなパターンです。

重要ではないものを正確に測っても意味がなくて、価値があるものの曖昧な尺度の方がよっぽどマシです。曖昧でもいいから意味のあるものを使えよ、ということを、ジム・ハイスミスという人が言っています。

エドワーズ・デミングも「測定できないものは管理できない、と考えるのは誤りである。これは代償の大きい誤解だ」と、それこそ1940年代や50年代から言ってるわけです。

この、測定できないものは管理できない、という部分だけが独り歩きしていって、逆の意味で伝わっていますが、本当はこう言っているのです。

アジャイルソフトウェア開発宣言の原則も、皆さん何回も読んでると思うのですが、そこにも「動くソフトウェアこそが進捗の最も重要な尺度です」と書いてあります。

つまり、動くソフトウェアを定量的に測るのは難しいかもしれないけれど、見れば動いているかどうかは分かる。これで評価できるでしょ、と言っているわけです。何かの数値で測るよりも実物を見せた方がいいでしょうと。

価値観と原則はいくらでもスケールするので、これをやっぱり組織の中で広めていくことが重要かなと思います。

そこでスクラムマスターの出番

ということで、スクラムマスターの出番です。

ベロシティが誤用されて、特にスクラムチームの外側から何か言われてる場合は、スクラムマスターが仕事をしろ、というシチュエーションです。

組織へのスクラムの導入についてコーチング、トレーニングするとか、組織においてスクラムの実施方法を計画、助言するとか。それから、複雑な作業に対する経験的アプローチを社員やステークホルダーに理解してもらう。これもスクラムガイドに書いてあります。

つまり、我々がプロダクトを作る過程は複雑な作業なので、数字だけ見てもしょうがなくて、現地現物で定期的に実物の確認をしてフィードバックループを回す。経験主義をずっと回していく、というアプローチ自体をステークホルダーに理解してもらい、それによってリスクを制御する。これをやっていく必要があります。

だからベロシティの数字、ベロシティじゃなくてもいいのですが、数字だけを見てリスクを制御しようと思っても制御できないわけです。

ということで、スクラムマスターが組織に対する働きかけや教育をやっていく必要があるのかなと思います。

それからスクラムガイドには「ステークホルダーとスクラムチーム間の障壁を取り除く」とも書かれています。何か数字を出せと言って組織と揉めているのだとすれば、それを取り除く仕事はスクラムマスターの出番ですよね。

「分かりました」と言って適当に数字を作るのは、スクラムマスターの行動としてあまり良くなくて、なせそれが必要なのか、その数字をどう使うつもりなのか、その数字を出すことによる自分のチームに対するリスクは何なのか、こういうことを考えていかないといけないわけです。

言われたことを伝書鳩みたいにやるとか、チームに負荷をかけないために自分で数字を計算して出しますとか、それでは一歩踏み込みが足りないのかなと思ったりします。

ではどうしたらいいかというと、そういう人はスプリントレビューに呼ぼうよ、という話です。

チームの外側の人がああだこうだ言ってきて、何か報告しろ、数字を出せ、という気持ちは分かるのですが、現地現物がすごく重要なので、そんなに気になるのならスプリントレビューに来てもらいましょうよ、という話です。

繰り返しますが、ベロシティだけでスクラムチームの状況が分かるわけでもなければプロダクトの状況が分かるわけでもなくて、スプリントレビューに来て実物を見れば安心しますよねと。

だからそこでスクラムチームはインクリメントを見せなくてはいけないんです。インクリメントをスプリントレビューで毎回見せられれば、信頼が形成されて、そうなればマイクロマネジメントをされなくなりますし、報告しろとか言われなくなります。

ベロシティを出せと言われる状況は多分信頼されていないのです。なぜかというとインクリメントを出せていないから。そう考えて、インクリメントを出せるように改善しつつ、スプリントレビューで実物を見せて報告することが本質的な対応かなと思います。

≫続きます。後編では、それでもまだ定量的な報告を求められたらどうするか。そして、ベロシティの良い使い方について解説します。

関連記事

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