【書籍】アジャイルな見積りと計画づくり｜レビュー｜計画への誤解を解いて失敗しないアジャイル開発へ
「アジャイルな見積りと計画づくり」を読み終えての気づきをご紹介します。本書では、アジャイルな見積りと計画づくりに対する、「なぜ？（Why）」と「どうやって？（How）」が明確に描かれています。
- 作品：アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法
- 出版社： 毎日コミュニケーションズ (2009/1/29)
- 著者：Mike Cohn
- ISBN-10：4839924023
日本語版は「マイナビ」から出版されています。
英語版の原著のタイトルは下記となっています。
Agile Estimating and Planning
(Robert C. Martin Series) (English Edition)
「Estimate、Plan」ではなく、なぜ「Estimating、Planning」の現在分詞系となっているのかという謎が、本書にて解き明かされます。
https://amzn.to/3mjb9vAアジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法（マイナビ）｜レビュー
本書はアジャイルにおける大いなる誤解のひとつに対して明確に回答しています。
「出来たときが終わるときです」
私は上記の言い訳を聞くことがありましたが（自分もそう発言したことがあるかも）、ずっと腑に落ちていませんでした。でも、それがアジャイルなのかな、知らんけど。とモヤモヤ。。
そんなにアジャイルは自由なの？
計画も方針もなかったら誰がどこに向かうの？
期日がないプロジェクトなんてあるの？
ただ、例えば、下記のようなケースでは見積りも計画もしないことが許されるでしょう。
・PoC的で、リスクより得られる学びを最重視するプロジェクト
・リスクの許容度が非常に高いプロジェクト
・とにかく前に進まなければいけないほど追い込まれているプロジェクト
このような恵まれたアジャイルプロジェクトは希少です。
やはり実際には、多くのアジャイル開発の現場で、「予算」があり「期日（リリース日）」があります。その２つがないとプロジェクトに対する意思決定がとても難しいのです。
そのため、当然のように下記の問いが飛んできます。
・いくらでできるのですか？（予算、コスト）
この問いは困ります。そして、下記のようなことが脳裏によぎります。
「何をつくるか決まっていないのにどう答えればいいの？」
「アジャイルだからわかりません、と無邪気に回答して、納得してもらえる気がしない。」
この問いに答えられない状態が続くと、期待とのギャップが限界に達し、信頼関係も崩壊し、失敗プロジェクトの烙印を押されかねません。きっと、誰しも新たに挑戦するアジャイル開発を失敗しないようにしたいはず。。
このような悩みは私の他にもたくさんいるはず！と思います。
「だいたいこれぐらいになります。」と自信も確証もないのに答えてしまったら、後で現実とのギャップを指摘され、「見積りの精度が悪いのではないか？」「どうキャッチアップするの？」と責められてしまうかもしれません。
本書を読んで、理解することで、この悩みが消えるとしたら、書籍を購入して読むコスト（お金と時間）をはるかに凌駕する価値を得ることができます。章ごとに『まとめ』があるため、頭の中を整理しやすいはずです。
特に「計画づくり」については目から鱗だらけです。。
評価：★★★★★（最高）
不確実性コーン｜英語：Cone of uncertainty
本書ではアジャイルな見積りで重要な概念である「不確実性コーン」が紹介されています。
ソフトウェア開発を実践したことがある方は経験則的に、コストの見積りについて、初期段階では不確実性が高く、開発が進むにつれて正確になっていくことがお分りかと思います。
そして、上記の図のように、コストが少なくなるブレ幅より、多くなるブレ幅の方が大きくなっています。たいていは思ったより楽だった、よりも、思ったより大変だった、やることが増えた、ことが多くなります。
図の横軸はウォーターフォール開発の工程（段階を）表しています。
プロジェクトの初期段階（要求の完了）では60%〜160%もの誤差が生じます。
そして、最終的に「ソフトウェアの完了」となるまで不確実性はゼロにならないということです。
これを見れば、いかに見積りが曖昧なものでコミットメントできないものであることが分ります。これを関係者で共有し、共通意識を持てるといいですね。
アジャイルなプロジェクトではイテレーション（スプリント）単位に「ソフトウェアの完了」まで実装するため、不確実性（リスク）をゼロにしながら積み上げることができます。
図はバリー・ベームが1981年に発表し、スティーブ・マコネルが「不確実性コーン」と名付けています。英語では「cone of uncertainty」となります。
このコーン（Cone）は著者のコーン（Cohn）でもなく、まして、とうもろこし（Corn）でもありません。笑
絵の形が円錐形（Cone）に見えることから名付けられています。
アジャイルな見積りと計画づくりの読了後に期待する姿
アジャイルな見積りと計画づくりの対象の読者
アジャイル開発に関わる全ての人におすすめです。特に下記の読者には必携の書となるでしょう。
アジャイルな見積りと計画づくりの名言を4つご紹介
計画づくりとは価値の探求なのだ。
アジャイルな見積りと計画づくり
見積りは確率だが、コミットメントは確率ではない。
アジャイルな見積りと計画づくり
見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。
アジャイルな見積りと計画づくり
むしろアジャイルチームの方が、従来型のチームよりも信頼のおける計画を立てられるのだ。
アジャイルな見積りと計画づくり
計画することがすべてだ。立てた計画はどうでもいい。
アジャイルな見積りと計画づくり
アジャイルニンジャが特に役立った気づき
計画をアジャイルに作ることができる
複数レベルごとに計画づくりする
不確実性に備えるバッファの計画を立てる
レビューのまとめ
著者の「マイク・コーエン（Mike Cohn）」は、アジャイル宣言に署名をした17名のうちの1人であるアジャイル開発のスペシャリストです。
そして、同じく署名をした、スクラムの「ケン・シュウェイバー（Ken Schwaber）」や「ロン・ジェフリーズ（Ron Jeffries）」、XPの「ケント・ベック（Kent Beck）」からも賛辞を寄せられています。
ここまでの面々を揃えられると、アジャイルの公式的な見積りと計画づくりですね！
ただ、そのアジャイル宣言の日本語訳がなんとも誤解を生みやすいです。
ウォーターフォール開発は「計画ファースト」だと言う人もいます。たしかに、最初にプロジェクト計画書を作成したり、要件定義書を作成し、それに従うため、アジャイルよりも計画を重視するようにも感じます。
計画に従うことよりも変化への対応を
アジャイルソフトウェア開発宣言
Responding to change over following a plan
そのような誤解のひとつの要因として、アジャイル宣言の上記の一文があります。
これを見ると従来型（主にウォーターフォール開発）は計画を重じていたが、アジャイルでは不確実な状態で計画なんかを立てるよりも、変化に対していきあたりばったり対応した方が良い、みたいな「計画軽視」のようにも見えてしまいます。
ここで英文を眺めてみてください。「a plan（ひとつの計画）」と「Responding（適応の現在分詞系）」とあります。「過去に立てたスナップショット的なひとつの計画よりも変化に適応し続けよう」と理解することができます。
もっというと、「計画（Plan）」ではなく「計画づくり（Planning）」に価値の重きを置く、と言いたいのではないでしょうか。計画をつくり続けるアジャイルの方が断然計画を重要視するということが伝わってきます。
アジャイル宣言に署名したマイク・コーエンが計画づくりを重要だと言っていますので、きっとそうです。
※補足しますが、アジャイルでは無駄に計画に対して時間をかけたりしません。（本書を読めばわかります）
「アジャイルな見積りと計画づくり」は2006年に英語版の原著、2009年に日本語版となっておりますが、2020年現在で全く衰えを感じません。
割と見過ごされがちなサブタイトルについて、「価値あるソフトウェアを育てる概念と技法」となっており、見積りと計画づくりは目的ではなく手段であることがわかります。価値あるソフトウェアを育てるための概念（Why）と技法（How）について書いてるよ、ということです。
長々書きましたが、アジャイル開発のプロジェクトに悩み、失敗させたくない全ての人に読んでいただたら幸いです。