このブログをご覧のみなさん、こんにちは。

前回、見積りの時間を減らしたいなら「アジャイルな見積りと計画づくり」を読もうで見積りについて、ご紹介しました。よく“ストーリーポイント”で規模を見積っていつつ、この“ストーリーポイント”を“時間”に置き換えて見積もっている人がいます。“時間”で見積る行為そのものが悪いとは言いませんが、それには非常に大きなデメリットがあります。デメリットを理解して使っているのであれば問題ありませんが、理解せずに使っているのであれば、デメリットを今回ご紹介しますので、参考にしてください。

“ストーリーポイント”で見積るメリット、“時間”で見積るデメリットの例

Q. 皇居一周を一緒に走ろうと話している 3 人グループがいます。しかし、見積りで意見が分かれてしまいました。
A「皇居一周なら三十分だね」
B「ん？ 1 時間じゃね？」
C「えっ？ 45 分でしょ？」
一同「デタラメなこというんじゃない！！」

さて、いったい誰が正しいのでしょうか？

答えをすぐに書いてしまうのはつまらないと感じるかもしれませんが、答えとして誰が正しいのかというと、実は全員が正しいのです。

A「皇居一周は約 5 km で、自分なら三十分で走れる」
B「確かに皇居一周は約 5 km だが、私だと 1 時間かかる」
C「そうだね、皇居一周は約 5 km だけど、俺には 45分かかるよ」

一同「皇居一周は約 5 km には同意する」

人によって走る速度が違うように、ソフトウェア開発でも人によって開発速度が違います。そのため、“時間”の見積りで合意するには全員がまったく同じ開発速度である必要があります。しかし、規模(上の例では距離)は人によって異なるわけではありません。そのため、まったく同じ開発速度ではない場合でも規模に対してなら合意ができます。そのため、“ストーリーポイント”を規模で見積るのが好ましいのです。基準となる規模で合意できていれば、将来新しく出てきたフィーチャーに対する見積りでも合意ができます。

これ以外に“時間”で見積るデメリット

合意し難いというデメリットを書きましたが、他にも実はデメリットがあります。このデメリットは“ストーリーポイント”で見積っているつもりが、“時間”で見積っている場合に起こってしまいます。

みなさんはしばらく前に見積もったストーリーのポイントが小さくなったと感じたことはないでしょうか？

しばらく前に見積もったストーリーのポイントが小さくなったように感じるのは自分たちが成長しているからです。皇居一周走ろうとしていた 3 人は 10km/h、5km/h、7.5km/h で最初から走れたわけではなく、何度も繰り返し走っていると走る速度はある程度早くなります。同様に、ソフトウェア開発でも繰り返し開発をしていると、開発速度が早くなります。

A「このフィーチャーって前の 5 ポイントと似てるよね」
B「でも今ならそれ半日もかからないでできちゃうよ」
A「最初の見積りに入って今までやらなかったこのフィーチャー 13 ポイントって書いてあるけど、今なら半日でできるよね？」
B「そうだね、じゃぁこのフィーチャー 5 ポイントに変えちゃおうか」

上の発言はどちらも、作業単位を開発速度で割った“時間”と考えています。それは「半日もかからない」「半日でできる」という発言からも明らかにです。しかし、開発速度は上にも書いた通り、繰り返し開発をしているとある程度早くなっていきます。そんな変わってしまう速度という物差しで見積りをしてしまうと、最初に見積った“ストーリーポイント”とイテレーションをある程度繰り返してから見積った“ストーリーポイント”では例え同じ作業だったとしても実際は異なってしまいます。開発速度はベロシティ(＝イテレーション内で消化した“ストーリーポイント”の数)で測れるのですから、それを“ストーリーポイント”を見積る際の物差しには使わない方が良いでしょう。

まとめ

• 人によって開発速度が違うので、“時間”で合意するのは難しい
• 規模は人によって違わないので、規模(“ストーリーポイント”)で見積りに合意するのが好ましい
• 開発速度で“ストーリーポイント”を見積りがちだが、最初とある程度イテレーションが進んだ後の見積りでは異なってしまうので開発速度で見積るのは避けた方が良い