スクラムでの初期の見積り

みなさんこんにちは。@ryuzeeです。

よくスクラムで初期見積りってどうやるの？って聞かれますので、思ったことをツラツラと書いておきます。 ちなみに見積りはあたらないので（もちろん当てる努力はしますし、当たった方がいいのは勿論ですが）、そのつもりで考えたほうが良いでしょう。例えば競馬で一点買いして毎回的中すると思う幸せな人はあまりいませんが、一方で開発の見積りは毎回当たると考えちゃうのはどうかしてるということです。

1. 開発初期に全体を見積もる

そもそも一発であたる見積りをするのは不可能であるのは不確実性コーンのグラフ等を見れば分かります。だからといって見積りをしなくてよいわけではありません。

この時点では、分かっている要求をプロダクトバックログに落として、それぞれのプロダクトバックログアイテムをラフに見積もっておきます。もしプロダクトバックログがないようであれば、そもそも何のためにプロダクトを作るのかが分かっていないということなので、まずそれを用意します（失敗しているケースの多くがプロダクトバックログがなく、なんとなくこういう感じのモノ、というレベルの理解しかない状態で開発を始めてしまっています）。

プロダクトバックログアイテムを物理時間で見積もるのは初期のプロダクトバックログアイテムの粒度を踏まえると正確性にかけるので、ポイント等で見積もることがお勧めです。全てを時間単位で正確に見積もろうとすると、全てのプロダクトバックログアイテムを詳細化しなければならず、膨大な時間がかかってしまう上に、見積りが全て詳細化の上に成り立つことになってしまうため、要求が変化した場合に対応しきれなくなってしまいます。

お勧めはプロダクトバックログアイテムをSMLの3種類で見積もり、それぞれをストーリーポイントの2,5,8に割り当てる方法です。この方法によって、まずはプロダクトバックログアイテム全体のサイズを把握します。もちろん要求は常に変化するので、プロダクトバックログに載っているものが全てではなく追加されるかもしれないし、削除されるプロダクトバックログアイテムがあるかもしれないことには注意が必要です。

2. 初期段階で期間やコストは見積もれる？

1ができている状態で期間は見積もれるだろうか？おおよそのコストは見積もれるでしょうか？

2.1 チームのサイズが決まっている場合

チームのサイズが決まっている場合、1スプリントあたりのチームにかかるコストはほぼ確定できます。例えば1か月スプリントでプロダクトオーナーとスクラムマスターが200万円、開発者が1人あたり100万円で6人いたとすれば、月間1000万円の費用になり、1スプリントあたりのコストは1000万円ということになります（開発機等の費用ももちろん必要ですが、人件費が通常一番大きいので省略）

したがって、開発に使えるスプリント回数が固定であれば、

総費用＝ 1スプリントあたりの費用 ×スプリント実行回数

となります。

一方でスコープ網羅を目指して、スプリント回数が可変である場合は、開発初期では、何回スプリントを実施するかは確定できません。というのはチームが1スプリントあたりにどのくらいの量を作れるかの数値がないからです。したがってこちらのケースの場合は、開発費用の見積りはスプリントを経るごとに正確になります。

2.2 期間を優先し、チームのサイズをあとから決める場合

アジャイルな開発手法の多くは、チームを継続的に維持することによって、チームの文化や規律や技術力を向上させることに価値を置いています。したがって寄せ集めチームを作って進めるのはうまくいきません。一方で既存のチームに対して文化が壊れない程度に人を追加する（もちろんスクラムのチーム人数の範囲で）というアプローチはないわけではありません。

この場合も実は2.1の話とあまり変わりません。チームのサイズをいじったとしてもチームが1スプリントあたりに作れるモノの量は、開発開始時点では正確には分からないので見積り精度が向上するのは、スプリントを実施してからになります。

必要ベロシティ＝プロダクトバックログアイテムの合計ポイント ÷ スプリント数

この必要ベロシティと実際のベロシティとの乖離をみて、チームに人を足すかどうかの判断をするしかありません。ただし、ベロシティは人を追加しただけであがるかどうかは分からない点について理解しておく必要があります（遅れているプロジェクトに人を追加してもうまくいかない、というのと似ています。またチームサイズが大きくなると、コミュニケーションコストが増大するので、ベロシティは線形比例しません）。

2.3. 追加開発など過去の経験がある場合

この場合はチームが同じであり、プロダクトバックログの見積りの基準が過去の開発と同一または類似であれば、ベロシティを参考値として再利用できるので見積りが可能になってくるかもしれません。ただしあくまで参考値として使うので、精度があがってくるのは実際にスプリントを回してからになります。

3. 見積りの更新

ここまで見て分かる通り、見積りが正しいかどうかはスプリントを実施してみなければ分かりません。同じように、スコープ保証の場合でいつリリースできるのか？スケジュール固定の場合にどの程度の量までリリースできるのか？についても回してみないと分かりません。実際にスプリントを回して、データが取れるようになったら、常時見積りや計画を更新していくことになります。そのためのスプリントプランニングやスプリントレビューなのです。その結果を常にステークホルダーに見せ続けることが大事で、それがスクラムにおける透明性の1つとも言えます。

4. それでも初期見積りでコストと期間出さなきゃいけないんだけど？

受託開発だとよくあるケースです。コンペなどになっていて初期見積りでコストと期間を出さなきゃいけない、とか初期見積りの内容によって実施に開発するかどうかを判断する、というケースもあるでしょう。その場合は、上述のことを踏まえつつ、見積りを実際に開発することになるであろうチームでやることです。絶対に組織の管理職や営業にまかせてしまってはいけません。他人の(適当な)見積りを渡されて責任をもって仕事するのは難しいからです。あとは変化を受け入れるやり方するのであれば、金額と期間固定するならスコープは可変にしかなりません。スコープを保証しつつ変化を受け入れ続ける（しかも定額制）というのはムリです。

予算を固定化して得られる価値を最大化するアプローチと、機能を固定化してかかるコストを最小化するアプローチとどっちが良いかを考えるようにしてください。

それでは。