商品の詳細

• Amazon.co.jp ランキング: #11847 / 本
• 発売日: 2009-01-29
• 版型: 単行本（ソフトカバー）
• 336 ページ

内容紹介
ソフトウェア開発の難題である見積りと計画づくりを「アジャイル」にすることで、開発の現実に即した、誤差の少ない計画づくりができるようになる。
その技法を、分かりやすく説いた1冊です。

「イントロダクション」より
本書のタイトルを「アジャイルプロジェクトの見積りと計画づくり」とすることもできた。だが実際には「アジャイルな見積りと計画づくり」というタイトルになっている。2つの違いは些細に見えるかもしれないが、そうではない。採用した現在のタイトルは、見積りや計画づくりといったプロセスを、アジャイルに進めなければならないと謳っているのだ。見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。
本書は主に計画づくりを扱っている。計画づくりとは「なにをいつまでに作ればいいのか?」という質問に答える作業だと私は考えている。しかし、この質問に答えるためには、まず見積りに関する質問(これの大きさは?)と、スケジュールに関する質問(「いつできるのか?」「このときまでになにができるのか?」)に答えねばならない。

著者について
【訳者略歴】
安井力(Tsutomu Yasui)
オブジェクト指向技術からアジャイル手法に傾倒し、プロセスとファシリテーションを中心にコーチングやメンタリング、ときにはプログラマやメンバーとして、チームがアジャイルになるための支援をしている。モデリング、Python、人間系の問題も興味がある。株式会社永和システムマネジメント コンサルティングセンター所属。日本XPユーザーグループスタッフ。「Agile Conferenceに行こう!の会」メンバー。
認定SCRUMマスター。著書に『Web2.0ビギナーズバイブル』(共著、2007年、毎日コミュニケーションズ)、『Webアプリケーションテスト手法』(共著、2008年、毎日コミュニケーションズ)。
通称はやっとむ。

角谷信太郎(Shintaro Kakutani)
「楽しさ」がシステム開発の生産性を左右すると信じてRuby によるアジャイル開発を現場で実践するテスト駆動開発者。好きな言語はRuby。好きなメソッドはObject#extend。好きな映画は『未来世紀ブラジル』。日本Ruby の会理事。株式会社永和システムマネジメント サービスプロバイディング事業部チーフプログラマ。
著書に『Java から Ruby へ』(翻訳、2007年、オライリー・ジャパン)、『アジャイルプラクティス』(共同監訳、2007年、オーム社)、『インターフェイス指向設計』(監訳、2008年、オライリー・ジャパン)。

著者略歴 (「BOOK著者紹介情報」より)
安井 力
オブジェクト指向技術からアジャイル手法に傾倒し、プロセスとファシリテーションを中心にコーチングやメンタリング、ときにはプログラマやメンバーとして、チームがアジャイルになるための支援をしている。モデリング、Python、人間系の問題も興味がある。株式会社永和システムマネジメントコンサルティングセンター所属。日本XPユーザーグループスタッフ。「Agile Conferenceに行こう!の会」メンバー。認定SCRUMマスター

角谷 信太郎
日本Rubyの会理事。株式会社永和システムマネジメントサービスプロバイディング事業部チーフプログラマ(本データはこの書籍が刊行された当時に掲載されていたものです)

カスタマーレビュー

自信を持って見積もりを出すための手引き書
本書は個人的に何度も要望してきた「見積もり方」の暗黙知を形式知としてまとめた本だ。世間一般に言われるコード桁数による見積もりやFP法などのような「規模の見積もり技法」だけではない、プロジェクトの始まりから終わりまでのライフサイクルを通じて、見積もりとはどのような物かを本書は教えてくれる。

1部では現状の問題と新しい概念の導入を述べ、2-5部では問題解決のためのプラクティスの数々を紹介し、6部ではこれまでに述べたプラクティスが成功する理由を述べるとともに読者への自信を補強し、最後に7部ではケーススタディとしてプラクティスをどのように実践するかを小説仕立てで書いている。開発プロセスを論じている本は多々あるが、本書のような6部と7部がある物は数少ない。

また、章の最後に議論のポイントを提示しているのも「どうすれば自分のプロジェクトに導入できるか」を考える良いきっかけになると思う。この「議論のポイント」は「考えてみよう」ではなく、「話し合ってみよう」となっている。自分で考えるだけではなく、本書を片手に見積もりと計画について、同僚や仲間と話し合ってみるだけでも新しい価値が生まれるはずだ。

「正直になること」がアジャイル成功の秘訣
約5年前のXP祭り2004で、XPの達人がが「XPで一番面白いのは計画ゲーム」という発言をしていて、当時XP聞きかじり組だった自分は感心したものだった。なにしろXPといえばペアプログラミングや TDDばかりが取りざたされていて、計画ゲームやメタファーなんてプラクティスは、なんとなく「手の届かないもの」っぽい感じがあったものだ。

その後もしばらくは、計画ゲームはマジシャンの扱う道具で、その種明かしはベールの向こうという状況が続いていたと思う。で、計画ゲーム抜きで導入された「なんちゃってXP」が、失敗の山を築いていたわけだ。

本書は、そんなベールの向こう側をあますところなく見せてくれる。手品の種明かしがつぎつぎとなされるわけで、これは面白くないわけがない。

何がいいって、「例え話」が豊富なところがいい。まったく未知の概念を説明するのに、例え話は効果的だ。計画を頻繁に見直すことを水平線の向こうへの航海で例えてみたり、見積りの手法を家のペンキ塗りでたとえてみたりという具合。本書最後にあるケーススタディも、広い意味で例え話だと思うが、これがめっぽう面白くて、まさにクライマックス。

読んでいて、本当に隠されていたアジャイルの種明かしは「正直になること」なんじゃないかと思った。未経験者だけで集まってアジャイル開発なんてできないことを「正直に」認める。正確な見積りなんてできないことを「正直に」認める。チームメンバに、顧客に、いまわかっていることを「正直に」伝える。 5年前のアジャイル本が、きれいごとを並べてばかりだったのに比べると、本書は呆れるほど正直だ。

そうしてみると従来の手法は、実に欺瞞に満ちているなぁ。できっこないとわかっているのに、最初から正確なスケジュールを求める。チームメンバの出してきた見積りをしれっと2倍にしてから上司に見せる。嘘で塗り固めた計画が、うまく運ぶわけがない。バレたら困るから、手遅れになるまで見直ししないしね。

結局、お互いに正直になれる土壌作りが、正しいアジャイルの第一歩ですよ(これが一番難しかったりして)。

ソフトウェアの見積りは本来こうでないか？
献本いただきました、旧来の見積り・計画立案の問題点を明確にし、それについてアジャイルな見積り・計画ではこのように問題を解決するという方法を示してくれる。TOC-CCPMと通じる物がある、旧来の問題点はTOC-CCPMスペシャリストの研修で教えていただいたことと同じ、バッファの考えも同じ。TOC-CCPMをソフトウェアに適用するためのガイドとしても使える。