スクラムでのプロジェクト初期の見積り

 2012/08/11
このエントリーをはてなブックマークに追加

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

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

1. プロジェクト初期に全体を見積もる

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

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

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

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

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

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

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

チームのサイズが決まっている場合、1スプリントあたりのチームにかかるコストはほぼ確定できます。 例えば1ヶ月スプリントでPOとSMが200万円、開発チームが1人100万円で6人いたとすれば、月間1000万円の費用になり、1スプリントあたりのコストは1000万円ということになります(開発機等の費用ももちろん必要ですが、人件費が通常一番大きいので省略) したがって、プロジェクトのスプリント回数が固定であれば、

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

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

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

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

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

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

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

2.3. エンハンスプロジェクト等過去の経験があるプロジェクトの場合

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

3. 見積りの更新

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

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

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

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

それでは。

 2012/08/11
このエントリーをはてなブックマークに追加