Scrumの見積りと計画づくりは何故優れているのか？

「ソフトウェア見積り」を読みながら、「アジャイルな見積りと計画づくり」「アジャイルサムライ」に書かれている見積り技法が何となく理解できてきた気がするのでメモ。
ラフなメモ書き。
間違っていたら後で直す。

【1】Scrumの見積りは、規模見積り(ストーリーポイント)と工数見積もり(理想時間・理想日)の2種類がある。
初期のスプリント計画では、ストーリーカードに対して、規模見積りをまず行う。
その時、ストーリーポイントの単位で、フィボナッチ数列の数値で相対比較する。
そして、更に実作業であるタスクカードへ分割する場合、各タスクは理想時間、つまり割込みがなく集中して作業できる最短工数を見積る。

スプリントを実施してリリース後、実際の実工数や作業期間が確定する。
つまり、初期のスプリント計画で見積もった規模見積りに対して、納品したストーリーポイント数、実際に作業した実績工数、納品までにかかった期間が確定するので、ストーリーポイントから工数や期間に換算して、補正係数を得ることができる。

以下、「ソフトウェア見積り」の153ページを参照する。
例えば、1スプリントで3週間、4人のチームで12人週かかって27ストーリーポイントの機能をリリースしたと仮定しよう。
すると、下記の補正係数が計測できる。

平均実績工数＝27ストーリーポイント/12人週＝2.25ストーリーポイント/週＝0.45ストーリーポイント/MD
平均スケジュール＝27ストーリーポイント/3週間＝9ストーリーポイント/週＝1.8ストーリーポイント/日

上記の数値がまさにVelocityそのものだ。
このVelocityを使って、180ストーリーポイントのシステム規模の開発をすると仮定しよう。
すると、下記のような推測が成り立つ。

平均実績工数＝180ストーリーポイント/2.25ストーリーポイント/週＝80人週
平均スケジュール＝180ストーリーポイント/27ストーリーポイント/3週間＝20週

つまり、1スプリント＝4週間でイテレーティブな開発をする場合、5スプリントは必要で、1スプリントで36ストーリーポイントを実装できるだろうと見積もれる。
そして、36ストーリーポイントを16人週、つまり4人のチームで4週間かければ開発できるだろうと見積もれる。

【2】従来のWF型開発でも、規模見積りはファンクションポイント法で既に理論化されている。
そして、FP法で見積もられた規模見積りをCOCOMO2で工数見積に換算する手法も既に知られている。
しかしながら、WF型開発では、実際の開発規模がどれくらいの工数に落ち着くのかを知るには、実際に開発工程に入って、最後の本番リリースまで見届けないと分からない。
つまりWF型開発では、規模見積りから工数見積に換算するタイミングは、1年後の本番リリースの時まで待たねばならない大きな弱点がある。

Scrumが従来のWF型開発よりも優れている点は、規模見積りから工数見積もりへ換算するタイミングがスプリント終了時ゆえに頻繁に存在すること。
実際、1スプリントは4週間だから、1ヶ月おきに規模見積りから工数見積もりへ換算した係数(つまりVelocity)を何度も追跡できるから、精度は理論上良くなっていく。

【3】僕も以前FP法で実システムを計測してみたことがあった。

FP法で業務モデルを計測する: プログラマの思索

FP法は業務システムの規模見積りで有効で、モデルのCRUD表が完成すれば即座に計算できる。
だから、OOAやDOAなどのモデリング技法とFP法は相性が良いと思っている。

しかしながら、実際のシステムのFPを計測しても、そこからどれくらいの工数がかかるのか、は結局WBSレベルの作業へ詳細化しなければ工数見積もりできなかった。
COCOMO2などを使って規模見積りから工数見積もりへ換算できたとしても、その工数に妥当性があるかどうか、顧客や上司に説得できるだけの自信はなかった。
それはあくまでも参考値であり、現在の開発チームの実績から得られた見積り工数ではないから、誰も信用しない。
だから、FP法はあまり役立たないな～と思っていた。

だが、Scrumは規模見積りも考慮に入れていて、それを工数見積へ換算する仕組みを持っているのがとても素晴らしい。
しかも短いスプリントをなんども繰り返せば、Velocityの数値はぶれが収まっていくはずだから、顧客や上司へも見積りの正当性を説明しやすい。
何故なら、過去のスプリントの実績値がVelocityに含まれているから、現状の開発チームの開発ペースはVelocityで求められた数値です、と実データで説明できるからだ。
見積りの正当性も、実際のスプリントで計測した工数でなければ、誰も納得はしない。

「アジャイルな見積りと計画づくり」ではこの辺りの話が書かれておらず、僕の頭にピンとこなかったけれど、「ソフトウェア見積り」を読んでようやく理解できた。

【4】上記で得られたVelocityの使い道は、「アジャイルサムライ」ではVelocity駆動のリリース計画づくりとして詳しく説明されている。
アイデアは下記に書いた。

Velocity駆動のイテレーション計画の作り方とは: プログラマの思索

ScrumやXPが教える所では、Velocityを元に作業量を調整するのがマネジメントの基本。
スコープ・コスト・納期のマネジメントの三角形において、コスト(要員)や納期(スプリント)は固定だから、スコープを調整するしかない。
つまり、過去の実績値から得られたVelocity(チームの開発ペース)から類推して、4週間で終われるような作業量をあらかじめ準備するのがスコープ管理なのだ。

駄目なプロマネは、チームの人数を増やしてVelocityを見かけ上大きくして、開発チームがこなせる作業量以上の作業負荷を課して、納期に間に合わせようとする。
このやり方は人月の神話で知られているように、工数(コスト)を予想以上に浪費して開発チームを疲弊させる。

あるいは、開発チームがこなせる作業量以上の残作業をこなすために、納期を延ばす手段をとる時もある。
この場合も、Velocityは変えないのだから、納期を延ばすのは自然だが、人間はリズムで生きる生物だから、スプリントの期間が不安定だとあまり成功しないように思う。
実際、僕の数少ない経験でも、納期を延ばしたとしても、残業が延々と続くだけなので高い作業負荷が続いて、開発チームのペースも予想よりも落ちやすい。
結局、当初予定した納期よりも更に遅れる場合が多い。

この辺りの話は「アジャイルサムライ」の8章で詳しく述べられている。
この章は僕が経験とフィットして、一番好きな章だ。

見積りは計画プロセスで最も大切な技法の一つ。
まだまだ研究する余地がある。