アジャイル・スクラム勉強会の第5回資料です。

1. アジャイルな見積
規模による相対見積
アジャイル・スクラム勉強会

2. 見積タイミングの違い
 WFは最初に1回で見積もる
 プロジェクト開始前に、開発スピードやリスクを予想して
見積もる
 プロジェクトの途中で思ったよりも早く開発が進んでいる場合
は？
 プロジェクトの途中で思ったよりも開発が進まない場合は？
 アジャイルは分散させて複数回見積もる
 1スプリント毎（1週間毎など）に見積もる
 それまでの経験や学習によって開発メンバーの開発スピードが
上がっていることを見積もりに反映できる
 逆に、思ったよりもスピードが上がらない・不測の事態が発生
なども、見積もりに反映できる

3. 見積で使用するツール
 PBL(Product Back Log) − 優先順に並んだ機能の一覧
 プロダクトやシステムで実現したい機能が優先順で並んでいる
一覧
 機能の内容はお客様の言葉で書かれている
例：＜ユーザのロール＞は＜機能の内容＞したい。なぜならば＜ビジ
ネス上の価値＞をしたいからだ。
 各機能に対して、開発チームが“規模”を見積もる
 SBL(Sprint Back Log) − スプリントのタスク一覧
 1スプリント（1週間など特定の期間）で実施するタスクの一覧
 日々のステータスを管理するため、カンバンボードを使用する
ことが多い
 各タスクに対して、開発チームが“理想時間”を設定する
 理想時間とは、スムーズに割り込み作業などがなければどれくらい
の時間でタスクが終わりそうかということを示した日数

4. PBLとSBLの運用例
PBL SBL
タスクA-1
機能A
機能B
機能C
お客様の代表
(プロダクトオーナー)
開発チーム
More…
タスクA-2
タスクB-1
タスクB-2
 PBLの項目はプロダクトやサー
ビスの機能はどうあるべき
か・優先度はどうするかとい
う話なので、PBLは基本的に
お客様の代表（プロダクト
オーナー）が管理する
 SBLの項目は機能を実現するた
めの具体的なタスク（画面を
実装する・DBを構築する・
データを挿入すると言ったレ
ベル）を示すので、SBLは開発
チームが管理する
 SBLのタスクは、PBLの中から
優先順の高い機能をピック
アップしてタスク分解して用
意する
 SBLのタスクに対するレビュー
は開発チーム内で行う
 PBLの機能に対するレビューは
お客様の代表（プロダクト
オーナー）に対して行い、成
果物として受け入れてもらう
必要がある
優
先
度

5. PBLはなぜ“規模”で見積もるのか
 古から使われてきた見積手法
 ステップ数
 プログラムの行数から規模を見積もる。単純だが不正確。
 ファンクションポイント法
 機能の複雑性をもとに見積もる。正確だが複雑で時間がかかる。
 過去の実績日数から見積もる
 熟練者が過去の経験をもとに見積もる。過去の実績と内容が一致していれば見
積もり精度も高いが、経験と違うところがあれば見積がズレる。
 そもそも経験者がいないと正確に見積もれない。
 規模を見積日数といった具体的な指標で見積もると問題が多い
 今現在の見積日数と、1ヶ月後の見積日数は一致しない可能性がある
 一ヶ月後は習熟が進んだことで見積日数が減るかもしれない
 人ごとに作業に対する見積日数が異なる場合がある
 熟練者と初級者で同じ作業なのに見積日数は異なる
 お客様に見積日数＝現実日数であると誤解される恐れがある
 見積が予測ではなく約束になってしまう
そのため、人ごとに尺度が異なる・誤解されやすい“日数”ではなく、
ポイントなどの抽象的な“規模”で見積もる

6. 規模を“相対見積”で見積もる理由
 例えば、この写真のビルの高さを
見積もってほしいと言われた場合、
どうするか？
 過去に見たことがあるビルの高さ
から、当てずっぽうで言ってみ
る？
 16階建てだから、1階あたりの高さ
がわかればわかるかも？
 隣のビルの高さがわかったら、
ざっくり2倍くらいかも？
 機能の見積もこれと同じで、基準
となる規模見積に対して比べるこ
とで相対的に見積もる
 基準値を5ポイントとする例
 同じくらいの規模：5ポイント
 ちょっと大きい：8ポイント
 ちょっと小さい：3ポイント
 2倍くらい：10ポイント
？
機能A
機能B
機能C
5pt
8pt 3pt

7. 規模から期間への変換はどうする？
 以下のような手順を行うことで、ポイントなどの規模から期間へ変
換できる
① 1スプリント（1週間など特定の期間）で何ポイントのPBL項目を消
化できるか測定する
 例えば、1スプリントで10ポイントを消化できたとする
② PBLのすべての項目の合計ポイント数を、1スプリントで消化できた
ポイント数で割る
 例えば、PBLの全ての項目の合計ポイント数が100ポイントだとしたら、1
スプリントで10ポイントのPBL項目を消化できるので、10スプリント
（10週間）でPBLの全ての機能が実現できる見込みとなる
 このようにPBLの総規模（総ポイント数）から「限られた期間でど
こまで機能を実現できそうか」を予測できる
 この情報を使って、プロジェクトの着地点（期間内でどの機能まで
実現できそうか）をお客様の代表（プロダクトオーナー）と会話す
ることができる
 開発チームの本当の開発スピードを使って測定した結果なので、説
得力がある
 お客様や自社の上層部からの「もっと早くできるはずでは？」というプ
レッシャーに現実的に回答できる

8. SBLのタスクには理想時間を設定する
 PBLの機能をSBLでタスクレ
ベルに分解する
 このタイミングで、担当す
る人ごとに理想時間を設定
する
 ただし、理想時間は機能の
規模見積には使用しない点
に注意
 SBLで設定したタスクの理
想時間は1スプリント内の
進捗管理でのみ使用する
 未着手・着手・レビュー
中・完了で振り分けて、状
況を見える化する
 1スプリントの最後に、お
客様に対して機能をレ
ビューできそうか把握する
機能A タスクA-1
タスクA-1
初級者 熟練者
5pt
3日
5日
対象の機能の見積ポイントや、タスクの作業規模
は同じだが、習熟度によって所要日数が異なる。
しかし、チーム全体で「1スプリントあたり10ポイ
ント消化できる」実績がわかっていれば、PBLで行
う機能の規模見積（ポイント見積）ではチーム全
体として見積もるので個々の習熟度の違いは無視
できる。
PBLの見積は、個人のパフォーマンスではなく、
チームのパフォーマンスで見積もるのがポイント

9. 言葉の定義を整理
今回の勉強会で登場した新しい言葉について定義を整理します。
PBLやプロダクトオーナーなど、これまであまり馴染みのない言葉も多いので、慣
れるまで適宜日本語の言葉に置き換えてもよい。（言葉の正確性よりも目的を達成
できることが大事）
 PBL(Product Back Log) − 優先順に並んだ機能の一覧
 プロダクトやシステムの機能を優先順で並べた一覧
 規模で見積もる
 SBL(Sprint Back Log) − xサイクル目のタスク一覧
 スプリント内で実施するタスクの一覧
 PBL項目から作業分解してタスクを洗い出す
 各タスクに理想時間を設定する
 プロダクトオーナー − お客様の代表
 お客様の代表者
 機能の定義や優先順の決定に責任を持つ
 開発チーム
 開発者の集まり
 機能の相対見積もりやタスクの見積もりに責任を持つ
 スプリント − 開発サイクル
 1週間など、区切られた期間

10. 雑談Time
日数ではなく規模で見積もること
について、どのような印象を持ち
ましたか？
直近のスプリントの実績ポイント
を用いることで、機能が完成する
タイミングを未来予測できること
について理解できましたか？