アジャイルな見積りと計画づくり：第2部：規模を見積もる「４章 ストーリーポイントによる規模の見積もり」まとめ
個人的感想
「期間を導出する」と「自分で期間を見積もる」 この差は大きいと感じた。暗黙的に過去の経験をもとにして期間を見積もっているかもしれないが、数字に落とし、計測していくと、その数字が定規となり、顧客に見せられ、何もないよりも、説得力がでると感じた。顧客とのコミュニケーションの信頼が増すことで、よりいっそう仕事がしやすくなり、価値の高いものを生む仕組みが作れると感じた。
目次
- 規模を見積もる
- ストーリーポイントは相対的
- ベロシティ
- ベロシティが見積もりミスを補正する
規模を見積もる
- アジャイルチームは、規模の見積もりと期間の見積もりとを分けて考える
- 規模の見積と期間の見積の違い。この違いを理解するために、これから私の庭の端にある一山の土を、庭の反対側の端まで運ぶことになったとしよう
- 期間のみを見積もる場合
- 私は土の山を眺めて、手持ちの道具を思い浮かべる（シャベルと手押し車だ）。そして、この作業に５時間かかると見積もる。ここで５時間という見積もりを出すのに、私は規模の見積もりをせずに、いきなり時間（期間）を見積もった
- 規模の見積もりから始めて期間を見積もる場合
- 山の寸法から考えて、私は土の量を300立法フィートと見積もった。これが、私のプロジェクトの規模の見積もりだ。しかしこの場合、規模だけ見積もっても役に立たない。規模の見積もり（300立法フィート）を期間の見積もりに変換しなくてはならないからだ。私の手押し車のラベルには、積載容量が6立法フィートと書いてある。300立法フィートを6立法フィートで割れば、この手押し車で50往復ですべての土を運べることが分かる。次に、1回の往復にかかる時間を見積もる。土を積むのに3分。庭の端から端まで手押し車を運んで土を降ろすのに2分。空の手押し車を押してもどるのに1分。合計すると、1往復にかかる時間は6分という見積もりになった。全部で50往復する予定だから、期間の見積もりは300分、すなわち5時間だ。
- 期間のみを見積もる場合
- アジャイルプロジェクトの場合、期間の見積もりは以下の図のようなプロセスになる。プロジェクトの期間を見積もるには、まず規模を見積もる
- 第２部では規模の単位を２つ紹介する。ストーリーポイント（第４章）と理想日（第５章）だ。次に、６章で見積りのテクニックを紹介し、７章では再見積もりすべきタイミングを紹介する。最後の８章では、ストーリーポイントによる見積もりと理想時間による見積のどちらを選ぶべきかを検討する
- ソフトウェア開発の規模の見積もりは、あるストーリーやフィーチャが、他のストーリーやフィーチャと比べて大きいか小さいか、それだけわかれば良いのだ
ストーリーポイントは相対的
- ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。ストーリーポイントを使った見積ではそのような、ひとまとまりの仕事に対してポイントを付ける
- ポイントの数値そのものはあまり重要ではない。重要なのは、他の作業との相対値だ。2ポイント付けられたストーリーは、1ポイントのストーリーの2倍の大きさであり、3ポイントのストーリーの3分の2の大きさとなる
- ストーリーポイントの数値は、ストーリー全体の規模を表す
- ストーリーの規模を定義するための数式は存在しない。ストーリーポイントによる見積もりが示す値は、フィーチャを実装するのに必要な作業、開発内容の複雑さ、開発に内在するリスクなどが渾然一体となったものである
- ストーリーポイントによる見積もりの始め方には2通りある
- 1つは、これから取り組むストーリーのなかで最も小さいと思えるものを基準として、それを1ポイントとする方法だ
- もう１つの方法は、中くらいの大きさと思えるストーリーを決めて、それに見積もりで使う数値範囲の中央に近い値を付けるというものだ
- 私自身は、ほとんどのストーリーを1から10の範囲に収めるようにしている（この理由は6章「見積の技法」で説明する）。したがって、中くらいのストーリーには5ポイントを付けることになる。このようにしてかなり独断的にでも、最初のストーリーポイントを付けたら、残りのストーリーは見積り済みのストーリーと比較しながらポイントを見積もっていく
- アジャイルプロジェクトにおいては、イテレーションを開始する時点ではあいまいな要求しか決まっていないことが多い。詳細な仕様はイテレーションの途中で発見される。しかし、ストーリーの要求があいまいであっても、ポイントを付けなくてはならない
- 例えば、犬の肩の高さをあらわすポイントであると定義しよう。テリアが3、ダックスフンドが1、プードルが3、ラブラドールレトリバーが5。テリアとプードルにポイントをつけたならば、そのやり方はもうわかるはずだ。より詳細な情報がないと、テリアやプードルのポイントを決めるのは難しかったはずだ。
ベロシティ
- ストーリーポイントに単位を持たせずにプロジェクトを進めていくためには、新しいコンセプトを導入しなければならない。それがベロシティだ。ベロシティとは、チームの進む速度を表す数値のことである
- ベロシティ値は、チームが1回のイテレーションで完成させたユーザーストーリーのストーリーポイントの合計値だ（今の時点ではこの定義で十分である）。チームが1イテレーションで5ポイントのストーリーを3つ完成させたなら、ベロシティは15ポイントになる
- たとえば、チームが前回のイテレーションで10のストーリーポイント分の作業を完成させたのであれば、次のイテレーションでも10ストーリーポイント分の作業をこなせると予測できるはずだ
- 必要なフィーチャのストーリーポイントの見積もりを合計すれば、プロジェクト全体の規模を見積もれる
- チームのベロシティが分かれば、規模をベロシティで割ると、必要なイテレーションの回数の見積が出る
- イテレーション数とはすなわち期間なので、これをカレンダーに当てはめれば、それがスケジュールとなる
- 5章では、ストーリーポイントではなく理想時間を使った見積もり手法を紹介する。理想時間で見積もるチームのベロシティは、完了したストーリーの理想時間の合計値である
- アジャイルな見積りと計画づくりの信条は、「規模を見積もり、期間は導出する」ことだ。例えば、すべてのユーザーストーリーを見積もって、合計が100ストーリーポイントになったとしよう。これがシステム規模の見積だ。チームの過去の経験から、ベロシティは2週間のイテレーションで10ポイントであり、今後も同じベロシティを維持すると仮定する。規模の見積もりとはこれまでのベロシティから、10イテレーションすなわち20週間という期間が導出される
- これはリリースプランニングを非常に単純化した説明だが、今のところは十分である。詳細は第４章「スケジュールを立てる」で解説する
- 付け加えておくと、この例が非常にシンプルになっているのは、チームが過去のベロシティを使えたからである。だが、いつでもチームの過去のベロシティを使えるとは限らない。場合によっては、過去の数値が使えない状況でも、ベロシティを見積もらなくてはならない。ベロシティの見積もりは難しいが、いくつか方法がある。ベロシティを見積もる方法は、16章「ベロシティの見積もり」で説明する
ベロシティが見積もりミスを補正する
- プロジェクトが進捗するということはユーザーストーリーをこなしていくことなので、数イテレーションも実施すればチームのベロシティが分かってみる。
- ポイントによる見積の素晴らしい点は、ベロシティを適用することで計画時の見積もりミスが自動的に補正されることだ
- たとえば、あるチームがプロジェクト全体の規模を200ポイントだと見積もったとする。当初、このチームは1イテレーションに25ポイントの作業をこなせると考えた。つまり、プロジェクトには8イテレーションかかるという計画だ。しかしながら、プロジェクトが始まってみると、ベロシティは20ポイントしか出ないことがわかった。この場合、再見積もりをしなくてもプロジェクトの期間が8イテレーションではなく10イテレーションになることがわかる
- このやり方が優れている点は、ストーリーポイントによって作業量の見積りと期間の見積りとを完全に分けて考えていることである。もちろん、作業量とスケジュールは関連している。しかし、両者を分けて考えることで、別々に見積もれるようになるのだ。といっても、実際には、あなたが期間を見積もることはない。期間は計算によって導出されるのだ
- 期間を自分で見積もることと導出することとの違いは、細かい問題に思えるかも知れないが、重要である
