関連サイト
本書の関連ページが用意されています。
内容紹介
「イントロダクション」より
本書のタイトルを「アジャイルプロジェクトの見積りと計画づくり」とすることもできた。だが実際には「アジャイルな見積りと計画づくり」というタイトルになっている。2つの違いは些細に見えるかもしれないが、そうではない。採用した現在のタイトルは、見積りや計画づくりといったプロセスを、アジャイルに進めなければならないと謳っているのだ。見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。
本書は主に計画づくりを扱っている。計画づくりとは「なにをいつまでに作ればいいのか？」という質問に答える作業だと私は考えている。しかし、この質問に答えるためには、まず見積りに関する質問（これの大きさは？）と、スケジュールに関する質問（「いつできるのか？」「このときまでになにができるのか？」）に答えねばならない。
「訳者あとがき」より
本書は2005年10月に出版されたMike Cohn 著『Agile Estimating and Planning 』（Pearson Education, 2005）の全訳です。著者のマイク・コーンはアジャイル開発手法のひとつであるSCRUM に最初期から携わっているアジャイル開発のスペシャリストです。
本書の原著が出版されてから3 年になります。「動きが早い」とよく言われる（ ほんとうにそうでしょうか？ と思いますが、それはまた別の話）ソフトウェア開発業界にあって「3 年前の書籍の翻訳」は不利に働くこともありますが、本書に限ってはそんなことはありません。むしろ日本の皆さんにいま、本書をお届けできるのはとても良いタイミングだと考えています。その理由は主に3 つあります。
まず、出版から3 年が経過した現在、本書の原著は北米圏のアジャイルソフトウェア開発コミュニティで「必読の一冊」という評価が確立していることです。本書はさまざまなアジャイルソフトウェア開発やソフトウェア開発の見積りや計画に関する書籍や記事で参考文献とされています。ロバート・マーチンによる「まえがき」にあった「本書は名著と呼ばれることになるだろう」という予言は見事成就したといえます。
次に、今回の翻訳の出版にあたっても著者のマイクから「出版されてから年を追うごとに売行きが伸びているよ」とメールで教えてもらったことです。これを裏付ける現象として、マイク自身も「日本の読者に向けて」で語っているように、北米ではここ数年でメインストリーム企業がアジャイル開発を採用する事例が急速に増えています。
理由の最後は、実は本書が訳者の私たちの「秘密兵器」だということです。過去3 年間、私たちはさまざまなソフトウェア開発の現場をアジャイルにしていくうえで、本書を大いに参考にしていました。誰よりも訳者である私たちが、本書の内容は日本の開発現場に適用できると確信しています（そして、適用できる現場の数は確実に増えていると感じています）。
本書のような名著の翻訳を私たちが手がけられたことを光栄に思うと同時に、私たちの「秘密兵器」がこうして日本の皆さんの手に入りやすくなってしまうことを少しだけ残念に思います :-)
書誌情報
- 著者: Mike Cohn, 安井 力（訳）, 角谷信太郎（訳）
- 発行日: 2009-01-28 (紙書籍版発行日: 2009-01-28)
- 最終更新日: 2012-12-25
- バージョン: 1.0.0
- ページ数: 338ページ(PDF版換算)
- 対応フォーマット: PDF
- 出版社: マイナビ出版
対象読者
著者について
Mike Cohn
マイク・コーンはMountain Goat Software社の設立者。同社はプロセスとプロジェクトマネージメントのコンサルティングとトレーニングを業務としている。マイクの得意分野は、企業がアジャイルプロセスとアジャイルのテクニックを利用して、きわめて高生産性の開発組織の実現を支援することである。マイクは本書に加えて『User Stories Applied： for AgileSoftware Development』およびJavaやC++プログラミングに関する数冊の著書がある。20年以上にわたる実務経験のなかで、新興ベンチャーからフォーチュン40社まで、さまざまな規模の企業で技術責任者を務めてきた。Better Software、IEEE Computer、CutterIT Journal、Software Test and Quality Engineering、Agile TimesおよびC/C++Users Journalに記事や論文を寄稿している。カンファレンスでも頻繁に講演をおこなっている。アジャイルアライアンスの創立メンバーであり、現役員。認定SCRUMマスター。IEEEComputer Society会員。ACM会員。
安井 力
オブジェクト指向技術からアジャイル手法に傾倒し、プロセスとファシリテーションを中心にコーチングやメンタリング、ときにはプログラマやメンバーとして、チームがアジャイルになるための支援をしている。モデリング、Python、人間系の問題も興味がある。株式会社永和システムマネジメント コンサルティングセンター所属。日本XPユーザーグループスタッフ。「Agile Conferenceに行こう！の会」メンバー。認定SCRUMマスター。
著書に『Web2.0ビギナーズバイブル』（共著、2007年、毎日コミュニケーションズ）、『Webアプリケーションテスト手法』（共著、2008年、毎日コミュニケーションズ）。通称はやっとむ。http://www.yattom.jp/
角谷信太郎
「楽しさ」がシステム開発の生産性を左右すると信じてRubyによるアジャイル開発を現場で実践するテスト駆動開発者。好きな言語はRuby。好きなメソッドはObject#extend。好きな映画は『未来世紀ブラジル』。日本Rubyの会理事。株式会社永和システムマネジメント サービスプロバイディング事業部チーフプログラマ。
著書に『JavaからRubyへ』（翻訳、2007年、オライリー・ジャパン）、『アジャイルプラクティス』（共同監訳、2007年、オーム社）、『インターフェイス指向設計』（監訳、2008年、オライリー・ジャパン）。http://kakutani.com
目次
イントロダクション
第1部 問題とゴール
1章 計画の目的
- 1． なぜ見積りや計画づくりが必要なのか？
- 1-1． リスクを軽減する
- 1-2． 不確実性を減らす
- 1-3． 意思決定を支援する
- 1-4． 信頼を確立する
- 1-5． 情報を伝達する
- 2．よい計画とはなにか
- 3．アジャイルな「計画づくり」とは？
- まとめ
2章 なぜ計画づくりに失敗するのか
- 1．フィーチャではなく作業を計画している
- 1-1． 作業は早く終わらない
- 1-2． スケジュールの遅れは先へと伝わる
- 1-3． 作業は独立していない
- 2．マルチタスク化が遅れを助長する
- 3．優先順位の順にフィーチャを開発していない
- 4．不確実性を無視している
- 5．見積りがコミットメントになっている
- まとめ
3章 アジャイル手法
- 1．プロジェクトへのアジャイルなアプローチ
- 1-1．1つのチームとして働く
- 1-2 ． 短いイテレーションで作業する
- 1-3． イテレーションごとに成果をあげる
- 1-4． ビジネス上の優先度を重視する
- 1-5． 検査と適応
- 2．アジャイルな計画づくり
- 2-1． 複数のレベルでの計画づくり
- 2-2． 満足条件
- まとめ
第2部 規模を見積もる
4章 ストーリーポイントによる規模の見積り
- 1．ストーリーポイントは相対的
- 2．ベロシティ
- 2-1． ベロシティが見積りミスを補正する
- まとめ
5章 理想日による見積り
- 1．理想時間とソフトウェア開発
- 2．規模の見積りとしての理想日
- 3．見積りは1つだけ
- まとめ
6章 見積りの技法
- 1．チームで見積もる
- 2．見積りのスケール
- 2-1． ユーザーストーリー、エピック、テーマ
- 3．見積り技法
- 3-1． 専門家の意見
- 3-2． 対比
- 3-3． 分割
- 4．プランニングポーカー
- 4-1． 小規模なセッション
- 4-2． 実施のタイミング
- 5．プランニングポーカーがうまくいく理由
- まとめ
7章 再見積り
- 1．SwimStats Webサイト
- 2．再見積りすべきでないとき
- 3．再見積りすべきとき
- 3-1． シナリオ1：再見積りをしない
- 3-2． シナリオ2：完了させたストーリーを再見積りする
- 3-3． シナリオ3：相対サイズが変わったら再見積りする
- 4．部分的に完了したストーリーの再見積り
- 5．再見積りの目的
- まとめ
8章 ストーリーポイントと理想日
- 1．ストーリーポイントの長所
- 1-1． ストーリーポイントは職能横断的な作業の進め方を促進する
- 1-2． ストーリーポイントによる見積りは長持ちする
- 1-3． ストーリーポイントは純粋に大きさだけをあらわす
- 1-4． ストーリーポイントで見積もるほうが早い
- 1-5． 僕の理想日と君の理想日は違う
- 2．理想日の長所
- 2-1． 理想日はプロジェクト関係者に説明しやすい
- 2-2． 理想日は導入しやすい
- 3．私のお勧め
- まとめ
第3部 価値のための計画づくり
9章 テーマの優先順位づけ
- 1．優先順位づけの判断要素
- 1-1． 金銭価値
- 1-2． コスト
- 1-3． 新しい知識
- 1-4． リスク
- 2．4 つの要素を総合する
- 3．優先順位づけの例
- 3-1． 技術基盤の構築
- 3-2． ユーザーインターフェイスの設計
- まとめ
10章 金銭価値による優先順位づけ
- 1．収益源
- 1-1． 新しい収益
- 1-2． 増加する収益
- 1-3． 維持できる収益
- 1-4． 業務の効率化
- 2．例題：WebPayroll
- 2-1． 新しい収益を算出する
- 2-2． 増加する収益を算出する
- 2-3． 維持できる収益を算出する
- 2-4． 業務の効率化の影響を算出する
- 2-5． 開発コストを見積もる
- 2-6． コストと収益をまとめる
- 3．財務指標
- 3-1． 貨幣の時間的価値
- 3-2． 正味現在価値
- 3-3． 内部収益率
- 3-4． 回収期間
- 3-5． 割引回収期間
- 4．収益を比較する
- まとめ
11章 「 望ましさ」による優先順位づけ
- 1．顧客満足度の狩野モデル
- 1-1． 狩野モデルでテーマを評価する
- 1-2． 回答を分類する
- 2．もう1 つの方法：相対的重み付け
- まとめ
12章 ユーザーストーリーの分割
- 1． ユーザーストーリーをいつ分割するのか
- 2． データ境界に沿って分割する
- 3． 操作の境界で分割する
- 4． 横断的な関心事を分離する
- 5． パフォーマンス制約をストーリーにする
- 6． 優先度に沿ってストーリーを分割する
- 7． ストーリーをタスクに分解してはならない
- 8． 関連する変更への誘惑を断つ
- 9． ストーリーをまとめる
- まとめ
第4部 スケジュールを立てる
13章 リリース計画づくりの基本
- 1． リリース計画
- 1-1． 満足条件を決める
- 1-2． ユーザーストーリーを見積もる
- 1-3． イテレーションの長さを決める
- 1-4． ベロシティを見積もる
- 1-5． ユーザーストーリーに優先順位を付ける
- 1-6． ストーリーを選択し、リリース日を決める
- 2． リリース計画を更新する
- 3． 例題
- 3-1． 満足条件を決める
- 3-2． ユーザーストーリーを見積もる
- 3-3． イテレーションの長さを決める
- 3-4． ベロシティを見積もる
- 3-5． ユーザーストーリーに優先順位を付ける
- 3-6． ストーリーを選択し、リリース日を決める
- まとめ
14章 イテレーション計画づくり
- 1． イテレーションプランニングではタスクの担当者を決めない
- 2． イテレーション計画とリリース計画の違い
- 3． ベロシティ駆動イテレーションプランニング
- 3-1． 優先順位を調整する
- 3-2． 目標ベロシティを決める
- 3-3． イテレーションのゴールを決める
- 3-4． ユーザーストーリーを選ぶ
- 3-5． ユーザーストーリーをタスクに分解する
- 3-5-1． プロジェクトに価値を与える作業のみを含める
- 3-5-2． 慣れるまでは詳細に
- 3-5-3． ミーティングはタスクに含める（それも多めに）
- 3-5-4． バグ
- 3-5-5． 依存関係の扱い
- 3-5-6． タスクへの分解が難しい場合
- 3-6． タスクを見積もる
- 3-7． 多少の設計はOK
- 3-8． タスクの適切なサイズ
- 4．コミットメント駆動のイテレーションプランニング
- 4-1 ． チームにコミットできるかたずねる
- 4-1-1． 見積りを合計する
- 4-1-2． 保守とコミットメント
- 5． 私のおすすめ
- 6． タスクの見積りとストーリーポイントの関係
- まとめ
15章 イテレーションの長さを決める
- 1． イテレーションの長さを決める要因
- 1-1． リリースまでの期間
- 1-2． 不確実性の高さ
- 1-3． フィードバックの得やすさ
- 1-4． 優先順位が安定している期間
- 1-5． 外部からのフィードバックの必要性
- 1-6． イテレーションのオーバーヘッド
- 1-7． 切迫感を感じ始めるまでの時間
- 2． イテレーションの長さを決める
- 3． ケーススタディ
- 3-1． ナパプロジェクト
- 3-2． グッドマンプロジェクト
- まとめ
16章 ベロシティの見積り
- 1． 過去の実績値を使う
- 2． 実際に1 イテレーションやってみる
- 3． 予想する
- 3-1． 1日の作業可能時間を見積もる
- 3-2． 1イテレーションあたりの作業可能時間を見積もる
- 3-3． ストーリーを分解して作業量を見極める
- 3-4． 見積りに幅を持たせる
- 4． 他のバリエーション
- 5． どのやり方で見積もるか？
- まとめ
17章 不確実性に備えるバッファの計画
- 1． フィーチャバッファ
- 2． スケジュールバッファ
- 2-1． 見積りの不確実性を反映する
- 2-2． プロジェクトバッファの大きさを決める
- 2-3． より単純なバッファ計算方法
- 2-4． バッファのガイドライン
- 3． 複数のバッファを組み合わせる
- 4． スケジュールバッファは水増しではない
- 5． 使用上の注意
- まとめ
18章 複数チーム編成プロジェクトの計画づくり
- 1． 共有できる見積り基準の確立
- 2． 早い段階でのユーザーストーリーの詳細化
- 3． 先を見越した計画づくり
- 4． 合流バッファを取り入れた計画
- 4-1． なぜバッファを追加するのか
- 4-2． 合流バッファの大きさを決める
- 5． だけどチーム間連携って大変じゃない？
- まとめ
第5部 トラッキングと情報共有
19章 リリース計画のモニタリング
- 1． リリースのトラッキング
- 2． リリースバーンダウンチャート
- 2-1． リリースバーンダウン棒グラフ
- 3． パーキングロットチャート
- まとめ
20章 イテレーション計画のモニタリング
- 1． タスクボード
- 2． イテレーションバーンダウンチャート
- 3． 投入工数のトラッキング
- 4． 個人のベロシティ
- まとめ
21章 計画とコミュニケーション
- 1． 計画の情報共有
- 2． 進捗の情報共有
- 3． イテレーション終了報告書
- まとめ
第6部 なぜアジャイルな計画づくりがうまくいくのか
22章 なぜアジャイルな計画づくりがうまくいくのか
- 1． 頻繁に計画を見直している
- 2． 規模の見積りと期間の見積りを分離している
- 3． 複数レベルの計画を立てている
- 4． 計画の基準がタスクではなくフィーチャである
- 5． 小さなストーリーがよどみない流れをつくっている
- 6． イテレーションから仕掛り作業を持ち越さない
- 7． チーム全体を対象にトラッキングしている
- 8． 不確実性を受け入れて、計画に取り込んでいる
- 9． アジャイルな見積りと計画づくりのための12のガイドライン
- まとめ
第7部 ケーススタディ
23章 ケーススタディ：ボムシェルタースタジオ
- 1． 1日目―月曜の朝
- 2． ユーザーストーリーの見積り
- 3． プロダクトリサーチの準備
- 4． イテレーションとリリースの計画づくり、第1 ラウンド
- 4-1． 第1イテレーションの計画づくり
- 4-2． リリースプランニング
- 5． 2週間後
- 6． 第2イテレーションの計画づくり
- 7． さらに2週間後
- 8． リリース計画の見直し
- 9． 見直した計画の報告
- 10． 18週間後