お題の背景
ストーリーポイントによる見積に基づき算出されたベロシティを
チームの生産性を評価するために用いる。
複数のチームの生産性を横通しで評価するための物差しとして、
ベロシティを用いる。
皆さんの現場では、上記のような経験はありませんか？
この記事を読むことで、
ストーリーポイントとベロシティが何のために用いられるべきなのか、
ベロシティでのチームの評価がなぜ危険なのか、
読者の方々が改めて考えるきっかけとなることを期待しています。
本記事を作成するにあたっては、
「アジャイルな見積と計画づくり」という書籍を参考にしました。
ストーリーポイントとは
本書籍の中では、以下のような説明がされています。
ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。ストーリーポイントを使った見積りではそのような、ひとまとまりの仕事に対してポイントを付ける。ポイントの数値そのものはあまり重要ではない。重要なのは、他の作業との相対値だ。2ポイントを付けられたストーリーは、1ポイントのストーリーの2倍の大きさであり、3ポイントのストーリーの3分の2の大きさとなる。
ポイントの数値そのものはあまり重要ではなく、
他の作業との相対値が重要となるのです。
案件特性、技術力、経験、メンバーの特性等のコンテキストが揃ったチームの中で、
それぞれの作業の相対値を見積もることで、
作業を大小レベルで見積もることが出来ます。
ベロシティとは
本書籍の中では、以下のような説明がされています。
ストーリーポイントに単位を持たせずにプロジェクトを進めていくためには、新しいコンセプトを導入しなければならない。それがベロシティだ。ベロシティとは、チームの進む速度をあらわす数値のことである。ベロシティの値は、チームが1sprintのイテレーションで完了させたユーザーストーリーのストーリーポイントの合計値だ
※1チームがイテレーションで5ポイントのストーリーを3つ完了させたなら、ベロシテイは15ポイントになる。
5ポイントのストーリーを2つだったら、ベロシティは10ポイントだ。
あくまで、そのチームのイテレーションの中で完了させた
ユーザーストーリーのストーリーポイントの合計値がベロシティなわけです。
案件特性、技術力、経験、メンバーの特性等のコンテキストが揃ったチームの中で、
sprintを回し、イテレーションを完了させていく中で、
そのチームの進む速度の傾向が掴めてくるようになります。
傾向が掴めれば、将来の予測もできるようになります。
マネージャは各チームの予実を管理し、生産性を比較したくなる
マネージャは1つのスクラムチームを見ているわけではありません。
おそらく、複数のチームを俯瞰して管理しなければならないかと思います。
プロジェクトを管理する立場にある人、
特にウォーターフォール開発のPM経験が豊富な人にとっては、
各チームの作業における予実を正確に把握し、どの程度の生産性が出ているのか、
横並びで比較したくなるのではないでしょうか。
各チームの生産性を横並びで評価するために、
画面作成のストーリポイントは○ポイント、画面修正は△ポイント！ のように
チーム間を共通の物差しで管理したくなります。
そこで、ベロシティやストーリポイントを用いて
チームの生産性を比較し、評価しようと考えてしまいます。
これには、「定めた計画通りに作業を進めること」を大事にし、
不確実なものを避けたいという考えてしまう
日本人の文化特性が現れているのかもしれません。
アジャイル的な考え方でいうと、計画を守ること自体が目的になるのではなく、
不確実性を受け入れて「いかに素早くユーザに価値を届けるか」を
見失わないことのほうがより重要です。
では、なぜチームを評価するための指標として扱うことが危険なのか、
見ていきましょう。
ベロシティによる評価が危険な理由
理由として、以下の３点が考えられます。
トラッキング（予実管理）がメンバーにプレッシャーを与える
本書籍中の記述を紹介
あとどれだけ残っているか知ることのほうが、どれだけやったかを知るよりもずっと役に立つ。さらにいえば、投入した工数の実績と見積りとを比較すると「評価への不安」を招きやすい。見積りをした人が、自分で出した見積りに不安を抱くと、「逃走・闘争反応」としてよく知られる緊張した心身状態に陥ってしまう。
プロジェクトマネージャやトラッキングの担当者は、見積り担当にプレッシャーを与えないように気をつけなければならない。見積り結果を試すようなプレッシャーを与えてしまうと、かえって見積り精度が悪くなることがあるからだ。
あくまで見積りは変わりやすいものとして、
不確実性を受け入れることがアジャイル開発においては重要です。
ベロシティはいくらでも誤魔化せる
チームの生産性評価のために、ベロシティが扱われていると分かってしまった場合、
チームはどのように行動するでしょうか。
おそらく、ストーリーポイントを過剰に見積り、
高いベロシティが出ていることをアピールするでしょう。
そのように誤魔化されて算出されたベロシティに、何の意味があるのでしょうか。
恐らく無意味なものになり、ベロシティはインフレし続けるかと思います。
本書籍の中では、こんな記述があります。
チームによっては、個人単位でのベロシテイを測定しているところもある。チームメンバーごとに完了させたストーリーポイントや理想日の合計を記録するのだ。警告する。個人のベロシティをトラッキングしてはならない。個人のベロシテイをトラッキングするのは、プロジェクト全体の成功を妨げることになる。イテレーションごとに個人のベロシテイを測定してトラッキングした結果を公表することになったら、チームのメンバーはそれにどう反応するだろうか?自分のストーリーを終わらせることと、チームメンバーを手伝うことのどちらかを選ばねばならなくなったときに、個人のベロシテイを測定しているチームでは、どう振る舞うのが自分にとって利益があるだろうか?
重要なのはチームとしてのベロシティだ。メンバー個人個人のベロシティに意味はない。意味のない一時的な興味であったとしても、個人のベロシティを測定することに価値はない。
上記では、個人のベロシティを計測することで、
個人の利益を優先することに走ってしまうであろうと語られています。
これは、個人に限った話だけではなく、
それぞれのチーム毎のベロシティを計測する際にも同じことが言えるかと思います。
ストーリーポイントとベロシティはチーム内で算出する値であり、
いくらでも誤魔化せます。
誤魔化してまで算出された値に、何の意味があるのか考えてみると、
自ずと答えは出るのではないかと思います。
チーム横通しで評価出来るほど、画一的な値にはならない
本書籍の中で、ベロシティの見積もり方法について、以下のように記述されています。
ベロシティの見積りに過去の実続値を使う前に、以下のような質問に答えてみること。
・技術は同じか?
・業務分野は同じか?
・チームは同じか?
・プロダクトオーナーは同じか?
・ツールは同じか?
・作業環境は同じか?
・見積もった人は同じか?上記の質問の回答に1つでも「いいえ」があるなら、過去の実績値を採用することは考え直したほうがよい。過去のベロシテイを採用することにしたとしても、幅を大きく取って、見積りが不確実だということを表現すべきだ。
ここから読み取れることの１つとして、
チームのバックグランド（技術、業務分野、チーム、ツール等）が
同じ場合に限って、ベロシティの見積りが有効であると言えます。
つまり、チーム横通しでベロシティを評価するのは難しいということです。
これは、ベロシティの元ネタであるストーリーポイントの見積りにも
同じことが言えると思います。
上記の主張については、素直に考えてみても納得がいくのではないでしょうか。
全く異なるプロダクトを開発していて、全く別の人達が別々のツールを使用している中で、
「画面作成」や「画面修正」等が同じストーリーポイントになるとは考えにくいです。
各種値の扱いに関するあるべき姿
では何のために「ストーリポイント」と「ベロシティ」の値を用いるべきなのか、
と考えます。
結論から言うと、チームの中で扱う、チームの調子を表す１つの参考値として、
これらの値は扱われるべきなのです。
「ストーリーポイント」は絶対的な値として定められるのではなく、
ユーザストーリーやフィーチャーの相対的な大小を整理するために、扱われるべきです。
「ベロシティ」はチームの生産性を評価する値として定められるのではなく、
最近調子が良いから30ポイントくらい消化できそう、
このスプリントでは20ポイントしか消化できていないけど
何があったのか振り返ってみよう等、
チーム自身の調子を表し、チーム内のメンバーのために活用される値として、
扱われるべきです。
チームが、「ストーリーポイント」と「ベロシティ」を使用する目的が無いのならば、
集計する意味は薄いのです。
あくまで、より良いプロダクト開発を進める上で、
意義のある値であるとチームが感じたのならば、集計して使用すればいいのです。
だいぶ投げやりな意見となってしまいますが、結局、何のために？の部分については、
チーム内で納得した答えが出ていれば、それでいいのです。
チームの生産性が評価されるためではなく、チーム自身が何かしらの目的を持って、
これらの値が活用されるべきなのです。
現場とマネージャの間に潜むジレンマ
ここまで言ってしまうと、マネージャとしては参考値がないので、
チームの評価は適当にしてもいいの？
となってしまうかもしれません。
そんな中で管理者は何を見るべき、評価するべきなのか、考えてみる必要があります。
ここに明確な答えこそありませんが、1つ考えられるとしたら、
どれだけそのプロダクトのコミット出来たか、プロダクトのリリースにより
ユーザにどれだけの価値を与えることができたのかという部分を評価するのが、
アジャイルの考えにも即していて、適切であると考えられます。
まとめ
「ベロシティ」を評価に用いるのはアンチパターン
「ストーリーポイント」と「ベロシティ」はあくまでチーム内で活用されるべき値
チームの調子を測るため等、チームの中で「ストーリーポイント」と
「ベロシティ」を使用する目的があるのであれば、使用しても構わない
皆様の現場では、「ストーリーポイント」と「ベロシティ」を
どのように扱っているでしょうか。
共感出来る部分、間違っている部分等、様々あると思います。
様々な立場における、色々な考え方を知りたいため、
コメント欄に率直な意見をご記入いただければ幸いです。
