アジャイルサムライ読書会、第5回はアジャイル開発における見積もりの立て方についてです。 私達の読書会は、サービス開発に関わる人（プランナー/プログラマー/デザイナーなど誰でも）がよりよいサービス開発のあり方について、お題になった本を通じて、共通認識をもったり知識を交換したり、建設的に議論したりする場です。 2012年4月からは「アジャイルサムライ」を読んでいます。

1. サービス開発者の読書会 #5
2012.05.22 ConnectStar

2. アジャイルサムライ
５回目
アジャイルサムライ——達人開発者への道
How Agile Masters Deliver Great Software
Jonathan Rasmusson
西村直人, 角谷信太郎
近藤修平, 角掛拓未
P1.0, 2011 年 7 月 25 日
Build date: 2011 年 7 月 14 日
(m-sl b-n bc-n)
Prepared exclusively for 木村 壮介 <sosuke@kimura-online.com>, 20120417-01AE2C42

3. 今日やること
1. 前回の振り返り（３分）
2. アジャイルサムライ 第７・８章（１５分）
1. 見積もりー当てずっぽうの奥義
2. アジャイルな計画づくりー現実と向きあう
3. ワークショップ（３０分）
1. Pivotal Trackerにストーリーを入れてみる（１０分）
2. 見積もりを立ててみる（１０分）
3. まとめてみる（１０分）
4. 今回のKPTと次回について（５分）

4. 前回のKPT
KEEP PROBLEM TRY
• 事前に資料を作った。 • 時間が５分すぎた • 読んで考えてくる
• 毎週やってる！ • 前半盛り上がらない • 幹事はもっと早く告知
しよう
• アジャイルサムライに飽 • やっぱり内容を忘れて
きてない！ る • 予め話したい議題を各
自グループにUPしてお
• ワークショップがよ
かった
• 最初に思い出すことで
終わってる
く。
• 文字が小さい

5. 第７章：見積もりー当てずっぽうの奥義
概算見積もりって
1. 最初に立てるものは、不確実性が高い。
2. このプロジェクトはやり遂げられるか、という問いに答える
1. ”やり遂げられる”とは、どういうことか？
3. 相対サイズで、３段階のポイントで見積もる。 理想日を設定して
みる。
4. 三角測量：各ポイントの代表ストーリを抽出して分類
5. プランニングポーカー：複数人で意見を出しあう

6. 第７章：見積もりー当てずっぽうの奥義
【気づき】概算見積もりって
1. やり遂げられるかどうか
1. 現実的かどうか
2. 理想日という流派もある、っていう話し。やってみて理想日流派をやってみてもい
いかも。
3. 日っていっちゃうと、勘違いやズレが起きる。なら、元からポイントという意味の
ない単位にしてしまうほうがよい、という話しか。
4. 今後、CS社ではポイントで見積もります。
5. 三角測量とプランニングポーカーは並列で行えるよね
6. プランニングポーカーは非エンジニアを入れてよいよね。
1. 定例とかでやってもいいかも。代表的なものや迷ったものをみんなでやってみ
る会を持たせる。ポイントに関する相談会・読み合わせをやろう。

7. 第８章：アジャイルな計画づくり
計画づくりについて
1. 変化と向きあう戦略で、 期待をマネージメントする。
2. ソフトウェ アに変換する速度を「ベロシティ」と呼ぶ。
3. 最初の計画を厳格なコミットメントとして扱うと死ぬ。
4. スコープを柔軟にする
1. ユーザストーリーの「交渉の余地がある」
2. 期日を延ばすか、スコープを柔軟にするか の二者択一を迫られた
ら、アジャイルサムライは後者を選ぶことが多い
3. チームでこなせない状態にあっても、スコープを柔軟にすることを拒
まれたら。。。
1. 奇 跡によるマネジメント
2. 事実をありのままに打ち明ける

8. アジャイル開発の原則
要求の変更はたとえ開発の後期であっても歓迎しま
す。変化を味方につけることによって、競争力を引き
上げます。

9. 第８章：アジャイルな計画づくり
最初の計画づくり（ステップ）
1. マスターストーリーリス トを作る
1. マスターストーリーリス トのサブセットのことを「リリース」という
2. プロジェクト規模を見極める
3. 優先順位をつける
4. チームのベロシティを見積もる
1. チームのベロシティ = 完了させたストーリーポイントの合計 / イテレーショ
ン数
2. 個人の生産性を計測するのではない
5. 期日を仮決めする
1. 期日固定 or フィーチャセット固定
6. バーンダウンチャートで可視化＆計測（Pivotal Tracker）

10. 第８章：アジャイルな計画づくり
リリースとは
リリースを定義する
リリースは、お客さんにとって意味のある単位でストーリーをまとめたもの
だ。1 つのリリースはそのまとまりで実装して本番環境にデプロイする価値があ
るように編成しよう。リリース単位のことを MMF(Minimal Marketable Feature 2
Set)* と呼ぶこともある。
MMF の最初の M、すなわち「最少であること(Minimal)」に込められている
のは、なるべく早いうちから成果を届け始めたいという思いだ(システムの価値 の 80% がシステムの機能の 20% からもたらさ
れているというのもよくある話 だ)。だから、最初のリリースに含めるフィーチャは、最も価値の高いものだけに 厳選してお
くのがいいだろう。
アジャイル開発の原則
シンプルさ(ムダなく作れる量を最大限にすること) が本質です。
MMF の 2 番目の M は「市場価値があること(Marketable)」だ。これはつま り、そのリリースは、お客さんにとっての価値がな
きゃだめだってことだ(そう じゃないと使ってもらえない)。そのため、最初のリリースに含めるストーリーを 選ぶときには
「最少であること」と「市場価値があること」が 2 本の大きな柱と なる。

11. 第８章：アジャイルな計画づくり
実際の現場で
1. シナリオ：新しい要求をお客さんが見つけたら
1. 期日を延ばしてもらってもいいし(開発費用は追加になるけ ど)、それ
ほど重要じゃないストーリーをスコープから外してもらってもいい。
2. シナリオ：思っていたほどは速く進んでないとき
1. 事実について話し合うこと
2. スパルタ戦士
3. シナリオ： 大切なチームメンバーがいなくなったら
1. ベロシティは下がる前提でプロジェクトへの期待をマネジメント

12. 第８章：アジャイルな計画づくり
アジャイルでやるの？
シナリオ：なにもかも固定されたプロジェクトで計画に変更の余地がないとき
アジャイルを使うべき？
センセイ プロジェクトが期日も予算もスコープも、そし て品質さえも固定しようとしても、彼らはすぐに気
づくことになろう――荒ぶる 四天王を抑えつけることはできない、と。いつだって何かを諦めねばならんの
だ。 変化はいつもそこにある。我われにできることといえば、変化を見えるようにす るか、さもなくばそれ
を隠し通すしかないのだ。

13. 第８章：アジャイルな計画づくり
【気づき】
1. MMF ≒ MVP
2. いつでも本番リリースの気持ちで提供する

14. ワークショップ
1. Pivotal Trackerにストーリーを入れてみる
2. 見積もりを立ててみる
3. 気づいた点を話す

15. ワークショップ
【気づき】
1. Pivotal Trackerに入れてみて
2. 見積もってみて
1. Pivotal Trackerいい。
2. バーンダウンチャート、ややこしいけど、ちゃんと見ると
ちょーいい。
3. エピックがなぞ

16. KPT