ベロシティではなくサイクルタイムで計測する

はじめに

私はベロシティを計測することを好みません。ベロシティは、キャパシティのある特定時点での計測です。つまり、チームやコードに変化があったときには、ベロシティも変わってしまいます（詳しくは、Velocity is Not Accelerationに書きました）。

それに対して、私はサイクルタイムの計測を好みます。サイクルタイムとは、チームがチームのボード上でなんらかを完了するまでの時間です。

サイクルタイムは、チームがどれくらい協働できるかや、ストーリーをどれくらい小さくできるかの指標になります。どのアジャイルなアプローチでも、私たちは、より協働することやよりストーリーを小さくしたいと望みます。そのため、サイクルタイムの計測は、有意義（積極的）なフィードバックループを生み出します。

小さなストーリーで協働するチームのサイクルタイムは短くなる傾向があります。小さなストーリーであっても協働しづらい分散チームでは、サイクルタイムが長くなる傾向があります。

サイクルタイムの計測方法

1. バリューストリームマップ (VSM) を用いて作業時間と待ち時間をみえるようにします
2. 作業の状態が変わるたびにメモします
   • 作業時間: ラインの上部（訳注: 図中のWork timeの箇所）に記載
   • 待ち時間: ラインの下部（訳注: 図中のWait timeの箇所）に記載
3. すべての作業時間を足し合わせます
4. すべての待ち時間を足し合わせます
5. サイクルタイムはすべての作業時間と待ち時間を足したものです

これでデータが出揃いました。作業時間がすべての合計時間とほぼ同じであれば、チームができる限り速く稼働していることがわかります。待ち時間がすべての合計時間とほぼ同じであれば、チームはできうる協働をしていないことになります。チームには、引継ぎと待ちの状態があるということです。

ところで、チームが協働できていないのは、チームのせいではないことが多いです。それは、マネージャーがチームの仕事ではない仕事をチームメンバーに依頼していたり、マネージャーがリソース効率を信じている場合が多いです。

協働できているチームと協働できていないチームの2つの異なるチームをみていくことにしましょう。

協働できるチームのバリューストリームマップ

このチームは協働しています。よくあるのは3人組です。ステファニーとダンはペアを組んで開発をしています。彼らと並行してティムがテスターとして仕事をしています。ティムがテストを実施した後で、ステファニーとダンは、いくつかの問題を解決します（訳注: 図中の左から1つ目と2つ目の解説です）。

彼らは、PO のピーターがストーリーをレビューできるようになるまで待たなければなりません（訳注: 図中の真ん中の赤字部分の解説です）。そして、すべてを実施できたら、このストーリーを完成（done）とすることができます（訳注: Item done の解説です）。このストーリーのサイクルタイムは、5.25時間となります。そのうちの待ち時間は、0.5時間だけです。

待ち時間が全体の10%未満なので、そこまで気にすることはないでしょう。チームに問題ないかを確認してもいいですが、もっとデータが溜まるまでは強調しないことにしてもいいです。

チームの平均サイクルタイムが5.25¹時間だと決める前に、もっと多くのストーリーを計測します。 まだチームの平均はわかりません。もしかしたら、今回はとても早かったかもしれません。1つのストーリーが完成するまでには2日かかることが多いのかもしれません。1つのストーリーでは十分な情報が得られないということです。重要なのは、さまざまなストーリーの待ち時間です。

私は、平均値を使う前に、1〜2週間でのサイクルタイムを計測し、そのサイクルタイムがどうなのかを観察するようにしています。

個人活動が主なチームのバリューストリームマップ

このチームは前のチームと全く違う働き方をしています。メンバーは個人で仕事をしています。

サムは、ひとりで作業をしてからコードレビューを依頼します。誰かがレビューできるまで時間がかかることになります（訳注: 図中の一番左の解説です）。そこで、ダンが問題をみつけたとします。サムはダンにもっと問題をみつけるよう依頼します。その後に、サムはテスターがテストするのを待つことになります。4時間後にシンディーがようやくテストできるようになりました。彼女はコードの問題をみつけます。サムとシンディーは、ストーリの意図を明確にします。シンディーはテストを変更し、サムは自分のコードを修正します。

このケースでは、サムもシンディーもコードやテストのレビューを依頼していません。これはよくないかもしれません。コードやテストのレビューについてのチームのワーキングアグリーメントにも依ります。

そして、彼らは、PO がストーリーをレビューできるまで待つことにあります。

このチームのサイクルタイムは、18.25時間です。そのうち、待ち時間がどれだけあるかをみてください。待ち時間は、10時間です。作業時間より多いのです。

チームにとってこのストーリーが容易だったのか、困難だったのかはわかりません。しかし、待ち時間は？というととても長いです。

サイクルタイムにある待ち時間は、フロー効率を考えることは重要であることを示しています。また、ペアリング、スウォーミング、モビングのような協働の仕方を考えるためにも、フロー効率は重要です。チームの WIP (訳注: 仕掛かり作業) を1つのアイテム（訳注: ストーリー）に絞れるようにすれば、チームのサイクルタイムの待ち時間を減らすことができるでしょう。

サイクルタイムを用いてストーリーの所要時間を見積もる

アジャイルプロジェクトを成功させるためには、ベロシティやストーリーポイントを用いることを避けることをお勧めします。その代わりに、ストーリーにどれくらいの時間がかかるのかを、チームがサイクルタイムを計測することで、みていくことをお勧めしています。

ストーリーの数をカウントするのもお勧めです。ポイント数は関係ありません。チームが、常に1回のイテレーションで2つのストーリーを完成できるとしたら、サイクルタイムは5日ということになります。何も見積もる必要はありません。すべきことは、次の2つのストーリーについて議論することだけです。

サイクルタイムは現実です。ストーリーの数をカウントし、サイクルタイムを用いて、合理的に見積もることができます。確率論的スケジューリングを行い、最も楽観的、現実的、悲観的な日付を観測することもできます。

私がチームをコーチしているときに、チームがサイクルタイムを短縮する方法を検討していたら、待ち時間を短縮できるかどうか、その方法をいつも議論すべきだと提案します。

ベロシティの代わりにサイクルタイムを計測できるかどうか検討してみてください。サイクルタイムが有効であったかどうかもぜひお知らせください。