ブログトップ 記事一覧 ログイン 無料ブログ開設

idesaku blog

2009-04-25

[][][]アジャイルな見積りと計画づくり

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
安井 力 角谷 信太郎

毎日コミュニケーションズ 2009-01-29
売り上げランキング : 5012

Amazonで詳しく見る
by G-Tools

見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。

おそらく、『アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング』と並んで、現代のアジャイル開発における最重要の一冊。あまりにすばらしい内容なので、毎日持ち歩き、たくさんブックダーツを打ちまくった結果、こんなにくたびれてさせてしまった。

f:id:idesaku:20090425194654j:image

アジャイルプロセスを導入しようとして挫折した人は多いと思う。何を隠そう、自分もそうだ。いったいどこで躓いてしまうのだろう?

ペアプログラミング」や「スタンドアップミーティング」といった、アジャイルプロセスのプラクティスのほとんどは、実は導入はさほど難しくない。それなのに、アジャイルプロセスの導入は失敗する。プラクティスを部分的に取り入れて"似非アジャイルプロセス"を実施することはできても、そこからさらに推し進めて全てのプラクティスを導入し、"本当のアジャイルプロセス"を根付かせるまでに至ることができない。

"本当のアジャイルプロセス"を実現するにあたって障害となる、重要でありながらも導入と実践が難しいプラクティスの筆頭は、おそらく本書が扱っている『見積りと計画づくり』を行うためのものであろう。

従来のあらかじめあれこれキッチリ決めておくやり方に慣れた身には、アジャイルプロセスの見積りと計画の曖昧さを許す点*1はなかなか飲み込みがたい。顧客や上司はもちろん、自分たちをも不安にさせる。そんな状況で関係者全てを説得してアジャイルプロセスを導入するのは困難だし*2、だからといって不安を解消しないまま「アジャイルはそういうものだ」とよくある誤解に基づいて無理矢理実施し、あやふやな計画のままプロジェクトを推し進めても、後で痛い目をみるだけだ。見積りは大きく外れ、計画は破綻し、顧客と上司からの信頼も失うだろう。

これに対処すべく存在する、アジャイルプロセスにおける見積りと計画づくりを行うプラクティスは、XPでいう「計画ゲーム」である。しかし、「計画ゲーム」は関連書籍を読んでも説明が少ないか大雑把で、いまひとつどうやったらよいものかつかみきれない。これでは我々の不安はちっとも解消されないし、導入にも消極的になる。

しかし、アジャイルプロセスのプラクティスは相補的な性格があるので、導入が難しいからといって「アジャイルな見積りと計画づくり」を避けて他のプラクティスだけを取り込んでも、アジャイルの真の価値を得ることは難しい。それどころか、逆に手ひどいダメージを受けることもままある。それが、アジャイルプロセスへの失望を招き、導入を挫折させる。

そんなアジャイルプロセス導入における問題児であり、それゆえにもっとも面白いところであるはずの「見積りと計画づくり」にフォーカスして、300ページ超の大ボリュームで、本当に現場で使えるノウハウを詰め込んだのが、本書だ。本書は、我々に具体的なプラクティスを示す。本書は、我々から不安を払拭する。これさえ読んでちゃんと実践すれば、きっと今度こそアジャイルプロセスを導入できる。まさにアジャイル界における救世主といえる。訳者後書きにも、こうある。

出版から3年が経過した現在、本書の原著は北米圏のアジャイルソフトウェア開発コミュニティで「必読の一冊」という評価が確立していることです。

ちくしょう!俺たちは北米圏の開発者たちから3年も遅れているのか!3年前に原書を読むことができたなら!でも、3年越しでも出してくれてありがとう!

本書では、アジャイルな見積りおよび計画づくりを行うための数多くのプラクティスが紹介されている。その中には、真に顧客価値を高める方法、見積りと計画づくりを行うための具体的な手法、不確実性への対処方法、リスクと対峙する方法、期日が決められているプロジェクトですらアジャイルプロセスで進める方法、などなど、我々が疑問に思うであろう事柄のほとんど全てに対する回答、少なくともヒントが含まれる。それらはボリュームがボリュームなだけにかなりの数になるため、ここで紹介することができないのが残念だ。

また、本書が紹介するプラクティスが有効である根拠も数多くの事例と共にちゃんと示されるので、これは顧客や上司にアジャイルプロセスを説明する際に役に立つだろう。

そしてありがたいことに、それら全てが豊富な例と共に説明されるのだ。疑問に思う箇所があっても、ほとんどの場合その直後にわかりやすい例が示される。だめ押しとばかりに、最後の最後にケーススタディがくるのも嬉しい。これは実際のところテストだ。物語形式のこのチュートリアルを読むことで、自分が本当に本書で示された知識を獲得できているか、理解できているかがすぐにわかる。

どこまでも濃密、どこまでも丁寧、どこまでも親切。そしてなにより実戦的。実際、「規模と期間で見積りを分けるべき」という指摘に従って、早速本書で紹介されている、フィボナッチ数列を利用したストーリーポイントによる規模見積りを導入してみた。未知のやり方なので受け入れられるか心配だったのだが、それはまったくの杞憂におわり、開発メンバーはあっさりとこの手法を受け入れて、ストーリーを次々と見積もってくれた。これであとはイテレーションを回してベロシティ*3を測定できれば、期間は簡単に求められるわけだ!すばらしい!一見その通りにやれるのか?と疑問に思えても、ちゃんと実践すれば受け入れられるし、うまくいく。

アジャイルプロセスの導入に悩んでいる全ての人が本書を読むべきだ。会社が金を出すのをしぶったら、自腹を切ってでも買って読むべき。

*1:本当はプロセスによらず曖昧になるものだが、アジャイルプロセスは特にその点に注目している

*2:ここも実践を難しくしているところ。見積りと計画だけは開発チームが内部で勝手にやる、というわけにはいかない

*3イテレーションあたりに実装できるストーリーポイント

tissitissi 2009/04/26 08:31 アジャイルは内製向きのプロセスだと思うんですよね。
うちらのようなソフト屋より、発注側、システム室の人が読むのがいいと思う。
残念ながら日本伝来の準委任とか常駐の作業形態とマッチするのではないかと。
業務を知らない人間が仕様書を書くという、他には無い特殊な業界構造が間違ってるんでしょうな。

idesakuidesaku 2009/04/26 11:13 もちろんこういう本は発注側こそ読んでほしいし、そのついでに今の下請け孫請けな歪んだ業界構造も変えて欲しいものですけど、関心を持つのは受注側なんですよね。だから、読んでもらえるのを期待していても埒があかないので、結局受注側が読んで、発注側に強力にプッシュするための武器にすることになるでしょうね。

それに、単に読み物として面白いですよ、これ。

内製向き、というのはごもっとも。自社パッケージ開発とか、予算と納期をある程度コントロールできる環境のほうがより強力に機能しますね。でも、受託でもバッファを適切に取ればアジャイルに開発することはできそうです。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/idesaku/20090425/1240676905