久々にこの本を読み直してみました。

　改めて読むと圧倒的な理論が押し寄せてきて納得感と忘れてしまっていた自分が情けなくなってくるくらいでした。

　そもそもこの本をあらためて引っ張り出してきたのには2つの理由があります。

　1つはこの夏に初めて角谷信太郎さんのお話を生で聴けたこと。

　この本の翻訳者として、また数々の講演、私も大変お世話になった市谷さんの師であること。前々から一度お話ししてみたい。お話を聞いてみたいと思っていたところ、今年のXP祭りの基調講演という形で初めて生でお話を聞けました。

　その時の感動と興奮。そして、前日や翌日の角谷さんのツイートなどをみていて角谷さんの思いや人間性を大きく感じれた今、もう一度触れたいと思い、手に取りました。

　ちなみにXP祭りの角谷さんのお話はこちら

　正直、スライドだけではよくわからないと思いますw

 ***

 　話は変わってもう一つの理由です。

　それはこの8月からチームの体制を大きく変えたことにより、自分の立場が変わったこと。

　それまでは「アジャイル」「スクラム」という分野を探求し、深めようという仲間が車内にはいませんでした。

　スクラムで開発はしているものの、「ベロシティ」という言葉さえ通じない。だけど、チームとしてはなんとかスクラムっぽいことを少しずつ実践していて、なんとか一人で引っ張っていた感じ。

　今思うと我ながらすごいなと思いますw

それが、川口さんを招いた合宿を経て大きく変わりました。

　新たに自分が"プロダクトオーナー"、"スクラムマスター"のロールを担うことになったメンバーの真剣な相談や悩みを目の当たりにして「全てを一人でやるプレイヤー」から「社内アジャイルコーチ」にロールが変わりました。

　自分の経験や平日の夜や休日にお話しさせていただいている歴戦の猛者のアドバイスをもとに解決できることは多くあります。本当に感謝しています。

　ただ、アドバイスだけでは実感できないこともやはり多々あるようで、特に見積もりには苦労している印象でした。

　そのため、改めて一緒に問題を解決するために改めて学びなおしをしてみました。

ちなみにそんなうちのチームのお話はこちら

***

 さて、改めて読んでみて特に感じたのは22章の偉大さです。

　この本は全23章から構成されており、1~21章はゆっくりと解きほぐすように各手法や考え方をこれでもかというくらいぶつけてきます。

　23章はこれらをもとにストーリー的にケーススタディを教えてくれます。

では、22章はというと1~21章を簡潔にまとめてくれてます。

　なぜこれが重要か。

私はこの22章の存在こそが単純なまとめではなく、実践者に向けて書かれた実用書である所以だと考えています。

　ここでイントロダクションの一節を引用すると

　22章で検討しているのは、アジャイルな見積もりと計画づくりがうまくいく理由である。この章は従来の手法がうまくいかない理由を検討した2章とついになっている

　実践者は常に不安にさいなまれます。

・この方法はベストプラクティス通りだろうか？

・ベストプラクティス通りにやっても上手くいかない・・・向いてないのだろうか

・自分たちのやり方にアレンジしたほうがいいのだろうか

　俗にいう守破離の話に関わってきますが、型にはまりすぎると上手くいかない。基本を押さえずにアレンジすると余計に上手くいかない。

　アジャイルなチームにはよくみられる様子な気がします。

それが特に出てくるのが見積もりと計画づくりだと思います。

　私自身もアジャイルやスクラムの説明をする時、アジャイルマニフェストやスクラムガイド、各種セレモニーの話は容易に理解してもらえます。

　しかし、相対見積もりやリリース計画の話は難航します。

　特におこるのは仕事量(ストーリーポイント)と工数や時間の考え方を混同してしまうこと。

　なぜなら、仕事量の考え方の良さはやってみないとわからないことが多いためです。

　そんな時にアジャイルな見積もりと計画づくりが上手くいく理由を力強く語ってくれているこの章にとても勇気付けられます。

*** 

　この本はとても分厚いです。

ただ、1章たりとも無駄がなく、是非とも隅から隅まで読んでいただきたです。

***

最後にそんな私チームの現在とここまでの歩みをお話をする機会があります。

興味を持っていただけた方は是非聴きにきていただき、お話しさせていただければ嬉しいです。

11/5(火) DevLOVEのイベントで恵比寿のクラウドワークスさんでお話します。

11/30(土) Developers SummitのUnder30版である「Developers Boosts」でお話します。