概要
スクラム開発に最初期から関わるスペシャリストであるマイク・コーンの書籍です。
「見積もりと計画づくりをアジャイルにすることなしに、アジャイルなプロジェクトはありえない」という序文がすべてを物語っていると思います。「計画の変更に対応するのがアジャイルだから、計画づくり（見積もり）なんてしなくてもいいでしょ」という誤解（実際に自分自身もそう思っていた節があった）を徹底的に打ち砕く一冊です。
なんで計画づくりが必要なの？目的がダイジ！
本書では、言葉の定義やものごとの目的を分かりやすく説明しています。
例えば、フィーチャは「ユーザにとってのソフトウェアの価値を表現したもの」と説明しており、要求仕様、機能要件、などだけでなく、性能目標やセキュリティなどの非機能要件も含まれる、と述べています。
また、何事をやるにしても目的がダイジだよ、ということをきちんと伝えています。
例えば、「計画づくり」の目的は、「何をつくるべきか？」への最適な答えに、繰り返し（イテレーション）を重ねることでたどりつくこと、だと述べています。
見積もりをすることや、計画を作ることは、ややもすると「やって当然」とか「本にそう書いてあるから」という理由でやってしまいます。でも、それではチームの納得感が薄いばかりか、やったことに対する意味がなくなってしまうんですね。
「なぜやるか」を追求するのは、プロジェクトを進める上で非常に大切なことだし、スクラムマスターはチームにそのことを的確にわかりやすく伝えられる力が必要である、と改めて考えさせられました。
工数ではなく、規模の見積もりをする
例えば、「この作業の見積もりは？」と聞かれて「3日ですね」とエンジニアが答えたとします。
その時、3日後にこの作業が終わることは、自分の経験上まずありません。なぜなら、このエンジニアにとっては「何も割込み作業が無くてこの作業だけに集中できて、かつ実装上で大きな技術的問題が起こらなければ」という前提付きで、3日と言っていることがほとんどだからです。
そして、マネージャが3日後に進捗を確認すると、「おいおい、3日といったのに終わっていないじゃないか。どういうことだ。見積もりが甘かったんじゃないか。」と言います。そうすると、エンジニアは「そんなこと言われるくらいなら、見積もりもっと多めにとっとこ。」と思うようになり、次回からマージンを取って同じ作業を「5日」と言ったりします。そして、どんどんと見積もりは意味をなさなくなり、エンジニアとマネージャの関係も険悪になっていくんですね。
これはアジャイルとかウォーターフォールとか関係なく、ソフトウェア開発全般においてお決まりのパターンで、自分自身このような体験を何度もしてきました（エンジニアとしても、マネージャとしても）。本書でも似たような例について言及した上で、どのような見積もりにすべきかを述べています。
本書では、相対的な「サイズ」を示す「ストーリーポイント」で見積もることや割り込みやスキルなどを考慮しない「理想日」で見積もることを推奨しています。つまり、規模の見積もりをしなさい、と言っているんですね。ストーリーポイントと理想日にはどちらにも利点があるため、どちらを採用してもよいようです。
また、不確実性に備えるためのバッファの計画についても言及しています。すなわち、それぞれのタスクのバッファをまとめて「プロジェクトバッファ」として計画しておく、という手法です。これによってパーキンソンの法則や学生症候群を避けられる、としています。自分はこれを、クリティカルチェーンとかCCPMとかいう名前で学んだことがあるのですが、同じ手法だと思われます。
狩野モデルと優先順位
本書では、「狩野モデル」を引用して、フィーチャの優先順位を決定するにあたってフィーチャが以下の3つのどれに当たるのかを検討するのが良いとしている。
- 当たり前、または必須のフィーチャ
- 線形、一元的なフィーチャ
- 魅力的な、わくわくするフィーチャ
これを決定するにあたって、それぞれフィーチャが備わって「いる」ときに与える影響と、フィーチャが備わって「いない」ときに与える影響とを、それぞれユーザにアンケート質問すると良いとしています。
計画づくりにおいて、何をどの順番でつくるのか、は非常に大事なポイントです。スクラムでは優先順位をつける決定権がPOにありますが、POがすべての市場を把握できているとも限りません。そういった場合には、このような手法を用いて定量的に優先順位を決定すると良いのだろうと感じました。
限られた時間の中で最大限のROIを導出するためには、「なにをつくるか」を決めることが非常に大きな意味を持ちます。本書を読んで、改めてその重要性に気付きました。
コメント