アジャイルな見積りと計画づくり - 価値あるソフトウェアを育てる概念と技法

著者名：マイク・コーン/安井力

マイナビ出版（2009/01発売）

• ISBN：9784839924027
• NDC分類：007.63

内容説明

ソフトウェア開発の難題である見積りと計画づくりを「アジャイル」にすることで、開発の現実に即した、誤差の少ない計画づくりができるようになる。その技法を、分かりやすく説いた１冊。
　
「イントロダクション」より
　本書のタイトルを「アジャイルプロジェクトの見積りと計画づくり」とすることもできた。だが実際には「アジャイルな見積りと計画づくり」というタイトルになっている。２つの違いは些細に見えるかもしれないが、そうではない。採用した現在のタイトルは、見積りや計画づくりといったプロセスを、アジャイルに進めなければならないと謳っているのだ。見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。
　本書は主に計画づくりを扱っている。計画づくりとは「なにをいつまでに作ればいいのか？」という質問に答える作業だと私は考えている。しかし、この質問に答えるためには、まず見積りに関する質問（これの大きさは？）と、スケジュールに関する質問（「いつできるのか？」「このときまでになにができるのか？」）に答えねばならない。

■ＣＯＮＴＥＮＴＳ
【第１部】問題とゴール／【第２部】規模を見積る規模の見積り／【第３部】価値に基づく計画づくり／【第４部】スケジュールを立てる／【第５部】トラッキングと伝達／【第６部】なぜアジャイルな計画づくりがうまくいくのか／【第７部】ケーススタディ

目次

第１部　問題とゴール
第２部　規模を見積もる
第３部　価値のための計画づくり
第４部　スケジュールを立てる
第５部　トラッキングと情報共有
第６部　なぜアジャイルな計画づくりがうまくいくのか
第７部　ケーススタディ

感想・レビュー

※以下の感想・レビューは、株式会社ブックウォーカーの提供する「読書メーター」によるものです。

[kumokumot]

少しでもアジャイルな現場では誰もが知っておきたい内容かもしれない。マネジメントの基本はやはり分割にあるのだと改めて認識した。それはエピック単位でもストーリー単位でもタスク単位でも。粒度を自在に使い分けたうえでインクリメンタルに規模ベースで見積もりをしていくことが成功につながると理解。アジャイルな計画と見積もりでスムーズにいくだけでなくプロダクトの品質や魅力の向上にも寄与するのは素晴らしい。何度も読み返して身につけたい。

2019/12/25

[イバドラ]

ソフトウェア開発手法の一つであるアジャイル開発。ここ10年でスタートアップ界隈を中心に一気に普及している開発手法だが、納期の見積もりが難しいとの批判も多い。本書は、アジャイル開発でのソフトウェア規模の見積もり、開発期間の見積もり方法を指南する内容になっている。常にチームの開発スピード（ベロシティ）を測定し、開発計画を動的に変更して行く。そうすると、開発初期の段階では不確実性が大きいのだが、計測を重ねるにつれチームの実力がわかってきて、だんだんと見積もりが正確になるのだという。このように一冊を通して、アジャ

2017/02/04

[Shohei I]

ソフトウェア開発の見積りと計画づくりを、アジャイルにする技法が書かれた一冊。 計画は作って終わりではなく、その後も新しい知見が入るたびに更新し続けるというのが一番の学びでした。プロジェクトが始まると、当初見えていなかったことがいろいろと見えてきます。それをもとに計画を修正する。そうやって計画の精度を進めながら高めていく。アジャイルだろうとウォーターフォールだろうと、同じじゃないかと思います。最初から完璧な計画を立てることなんてできないから、やりながら修正していこうという心持ちでいることが重要なのでしょう。

2025/07/30

[ふくみみ]

書名通りアジャイルの見積もりについてしっかり書かれた本です。アジャイルのお約束の一つに他人のせいにせず皆で取り組むというものがあります。この本を読んでその理由が、現実的じゃない無茶な計画を受け入れる方法が「他人のせいにすること」だからかなと思いました。アジャイルは急がば回れというか、曖昧に誤魔化されていたものを見える化する分、本当にここまでやるの？と知識だけだと疑ってしまうで、ケーススタディの実際にやってみせる様は貴重です。イテレーションを廻して経験値を積むことがどう財産になるか良くわかりました。

2011/11/20

[tk_ono]

まず、すばらしい本だった。この考え方はすばらしい。顧客から開発者まで、ソフトウェア開発に係わるすべての人がこの考えの元に行動ができたら、みんなもっと幸せになれるんだろうな。まずはプロジェクトの要求や期間は固定的なものではなくて、必要に応じて変えていくものだという認識が必要。だが、そのためには変更する理由が明確でないといけないので、見積もりと開発速度が明らかになっている必要がある。見積もりは期間ではなく規模で表し、開発速度はある期間でチームが開発できる量で表す。期間はその2つから導出できる。見積もりはプラン

2011/10/01