1.
ストーリーポイント
2015/05/25

2.
アジェンダ
• アジャイルな見積もりと計画づくり
• なんで見積もるの？なんで計画すんの？
• 大事なこと
• つまりどういうこと？
• 見積もり方
• 利点
• こういう時どーすんの？

3.
アジャイルな見積と計画づくり

4.
アジャイルな見積と計画づくり
• 発売日 : 2009/01/29
• 著者
• Mike Cohn
• Mountain Goat Software
社の設立者
• 訳者
• 安井 力
• 角谷信太郎

5.
なんで見積もるの？
なんで計画すんの？

6.
計画することがすべてだ。
立てた計画はどうでもいい。
― 陸軍元帥 ヘルムート・グラフ・フォン・モルトケ

7.
なんで見積もるの？なんで計画すんの？
• 上長にやれといわれたから
• 上長に報告しなきゃいけないから
• みんながやってるから
• なんとなくスクラムっぽいから
無意味！

8.
なんで見積もるの？なんで計画すんの？
「計画づくりとは探求なのだ」

9.
なんで見積もるの？なんで計画すんの？
計画づくりとは
「なにをつくるべきか？」
という問いに答えること

10.
なんで見積もるの？なんで計画すんの？
• 自分たちが「今」すべきことは何なのかの認識をあわせ
るため
• 自分たちのゴールを明確にするため
• プロジェクトのゴール、スプリントのゴール… etc
• ゴールに対する現在地を確認するため
• 自分たちの歩く速さを常に可視化するため

11.
なんで見積もるの？なんで計画すんの？
全ては自分たちのためにやること！

12.
大事なこと

13.
大事なこと
規模を見積もり
期間は導出する

14.
つまりどういうこと？

15.
つまりどういうこと？
• 規模
• ストーリーポイント！！
• あれやんなきゃいけないね
• これ考えないといけないね
• 結構リスキーだね
• これ結構めんどいやつだね
• 期間
• こんくらい時間かかりそうだね
• だとしたらいつ終わりそうだね

16.
見積もり方

17.
見積もり方
• 相対的に見積もる
• 基準を決める
• ３つ （ 1, 5, 13 くらい）※アジャイルサムライ流
• 基準より重いか軽いかを考える
• フィボナッチ数列っぽい値でSPを付ける
• プランニングポーカー

18.
見積もり方
• フィボナッチ数列っぽい値
• プランニングポーカー
• 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ？
• ざっくり見積もる為の数字
• そもそも見積もりなんて曖昧なものなので完璧を求め
ない

19.
見積もる時の注意
• 時間を区切る
• １見積もり３分とか
• １,２とかの差にあまりこだわらない
• ざっくりで良いんです！
• 議論する時は必ず基準を明確にする
• 「このストーリーが３Pで、これよ
り俺は重いと思うから５なんだ」
• 「これとこれやらなきゃいけないか
らこっちより重い！」
• チームで見積もる
• ストーリーやタスクに対する認
識をみんなであわせる！
• レビュー時にも楽になるし、手
戻り減るよね
• 誰がやるかを見積もり時に考慮し
ない
• 誰がやってもポイントは同じに
なります

20.
利点

21.
利点
タスク SP
設計 10
API作る 5
VIEW作る 3

22.
リソース ベロシティ
Aさん（新人） 3
Bさん （中堅） 5
Gさん （ベテラン） 10
ベロシティ：１スプリントで消化できるSP

23.
リソース ベロシティ
Aさん（新人） 3
Bさん （中堅） 5
Gさん （ベテラン） 10
スプリント１
Gさん 設計 10SP
スプリント２
Bさん 設計 10SP
Gさんが設計する場合
Bさんが設計する場合
Bさん API 5SP
BさんがAPI実装する場合
人が変わっても
規模は変わらないので
見積もり直す必要はない！！

24.
利点
タスク 人日
設計
Aさん 1日
Bさん ２日
API作る
Aさん 1/2日
Bさん 1日
VIEW作る 省略

25.
利点
• めんどくさい！
• 担当者変えたくない！
• もうずっと同じ人に任せる！
属人化いっちょあがり
見積もり直さなきゃ…
WBS直さなきゃ…
またアレやり直さな
きゃ…

26.
例としては個人のベロシティと書きましたが
実際はベロシティはチーム全体で計算します
個人の責任と問わず
チームでアウトプットすることにフォーカスする

27.
チーム全体のベロシティ
全体のSP
↓
期間を導出する
距離(SP) ÷ 速さ(ベロシティ) = 時間

28.
こういうときどーすんの？

29.
こういう時どーすんの？
1.人によって前提知識が違うので（調査とか含めると）作業量（規模）
も変わってくる
→ 調査を別タスクにする
→ 前提知識があって調査が不要な人はベロシティが高い人である
と考える
2.前回同じような機能を作った時に共通化したので、機能的には同じ
ようなものでも今回は超簡単にできてしまう
→ チームのベロシティが上がったと考えて、SPは同じSPにします

30.
こういう時どーすんの？
3.ボリュームが読めない（バグ系とか、要件定義とか）
→まずは、これまでに似たようなタスクが無いか探す
→ 時間で区切って（例えば１日）やってみて、そこから見積もる
（こーいうやつをスパイクと呼びます）
→ 最悪終わってからSPを決める
4.どこまで見積もるの？突発的に発生する作業とかも？
→ あくまで個人的なアレですが、突発タスクは見積もらないでも良い
と思ってます。

31.
まとめ
• 見積もりと計画づくりがアジャイルでないのに、プロジェクトが
アジャイルであるということはありえない
• 計画自体（Plan）ではなく、計画すること（Planning）が大事
• 規模を見積もり、期間は導出する！！
• ストーリーポイントは工数（時間）ではない
• 完璧を求めない （ざっくりでよい！見積もりは確率）
• あくまでチームで考える

32.
Any Questions?