『アジャイルな見積もりと計画づくり』を読んで

#### はじめに
以下のサイトをブックマークに入れて早数年。
[2019夏、先輩が若手に贈る「お世話になった技術書60選」- 入門からガチまで –](https://dev.classmethod.jp/articles/bestbook-2019-summer/)

このサイト内で紹介されている1冊が気になったので購入してみました。
![読むべき技術書.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730667/6fe8e0a2-3a4b-d4ca-25d7-c6b9675d13f8.png)

こういう機会がないとインプットとアウトプットをしないので、
この機会に[『アジャイルな見積もりと計画づくり』](https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%81%AA%E8%A6%8B%E7%A9%8D%E3%82%8A%E3%81%A8%E8%A8%88%E7%94%BB%E3%81%A5%E3%81%8F%E3%82%8A-%E4%BE%A1%E5%80%A4%E3%81%82%E3%82%8B%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%92%E8%82%B2%E3%81%A6%E3%82%8B%E6%A6%82%E5%BF%B5%E3%81%A8%E6%8A%80%E6%B3%95-Mike-Cohn/dp/4839924023/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=3H1TZEOZZOQOR&dib=eyJ2IjoiMSJ9.D765ku7h9C9KyzLWp1JeuQ.fNQJAK1oavr6BdFYswLt3m2N7_0f0HefwF8coIbEee4&dib_tag=se&keywords=%E3%80%8E%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%81%AA%E8%A6%8B%E7%A9%8D%E3%82%82%E3%82%8A%E3%81%A8%E8%A8%88%E7%94%BB%E3%81%A5%E3%81%8F%E3%82%8A%E3%80%8F&qid=1733302831&sprefix=%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%81%AA%E8%A6%8B%E7%A9%8D%E3%82%82%E3%82%8A%E3%81%A8%E8%A8%88%E7%94%BB%E3%81%A5%E3%81%8F%E3%82%8A+%2Caps%2C168&sr=8-1)を読んで思ったことを書いていきます。

![アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730667/642ac80c-f682-678a-8468-819ecf8819c7.jpeg)

そもそもなぜこの本を選んだかというと、
1. CSM資格の更新のために、アジャイル関係の活動をして記録する必要がある
1. 見積もりに苦手意識があり、苦手意識を払しょくしたい
といった思惑があります。

実際に読んでみて、目から鱗だったり、意外な発見があった点について紹介します。

本書は、7部構成の23章に分かれており、コンテンツは以下のようになっています。
![目次.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2730667/0f15ec71-3b11-0884-c62c-c85c5a88e74d.jpeg)

#### 8章 ストーリーポイントと理想日
- ストーリーポイントによる見積もりは長持ちする
言われてみれば確かに。と思ったのが、ストーリーポイントの持続性です。
時間見積もり(期間見積もり)だと、メンバーの経験が積まれることで変化してしまいます。
それと比較してストーリーポイントでの見積もりは、相対的な見積もりなので、変化しづらいです。

#### 13章 リリース計画づくりの基本
- リリース計画について
私がアジャイル開発に対して持っていた疑問として、「終わりが見えない開発を、プロダクトオーナーは許容してくれるのか」というものがありました。あるいは、「最終日が厳格に定められた案件では、アジャイル開発は利用できないのでは？」とも。
イテレーションを複数回回し、機能を足していく開発手法では、
ウォーターフォール開発のように最終日が決まっていないよう思えたのです。
本章では、最終日が決まっていた場合のリリース計画づくりについて紹介されていました。
例えば、6か月後にプロダクトをリリースしたい場合、1イテレーション2週間で13回イテレーションを回せます。
消化できるストーリーポイント数は260ポイントなので、プロダクトオーナーとチームは260ポイントの範囲内で、価値あるストーリーを選び、優先順位を決めます。

#### 15章 イテレーションの長さを決める要因
- 不確実性が高いとイテレーションは短い方が良い
私は当初、不確実性が高いときは解決に長い時間をかかるので、イテレーションも長くなるという考えでした。
本書では、イテレーションを短くすることで、ステークホルダからのフィードバックの機会が増えるため、不確実性が高いものほどイテレーションは短くすべきと紹介されています。

- 筆者の理想的と考えているイテレーション期間は2週間
2週間のイテレーションは短いような気がしますが、筆者は2週間イテレーションがオススメであると述べています。
4週間イテレーションではどうしても序盤、中盤、終盤という区切りが生まれてしまい、スプリント的な動きをできなくなってしまいます。逆に1週間イテレーションでは何かトラブルが起きた段階で体制が崩れてしまう危険性があります。

- 2週間イテレーション × 6回 + 1週間イテレーション1回
とはいえ、2週間イテレーションをずっと続けるのも疲労がたまっていくものです。
その場合の対応策として、2週間イテレーションを6回回した後に、1週間イテレーションを1回回すという手法が紹介されていました。
ただし、合間の1週間イテレーションではのんびりするということではなく、メンバ個人の必要だと思ったタスクに注力する期間として使用します。
1週間の作業を自分で選べる機会は、メンバに活力を与えます。

#### 17章 不確実性に備えるバッファの計画
- スケジュールバッファは水増しではない
スケジュールバッファとは、スケジュール全体に対して何割かの余裕を持たせることです。
個人マージンを除いたスケジュールにスケジュールバッファを設けることは、プロジェクトの安全を保つために必要なことです。
わかりやすかった例として、車の車間距離が挙げられていました。
『車間距離を車一台分にして走り続けることはできるが、そんなことはしない、余裕を持った車間距離がスケジュールバッファである』

#### 20章 イテレーション計画のモニタリング
- 個人のベロシティは測るべきでない
個人のベロシティを測ってしまうと、メンバは保身に走ります。
チームのためではなく、個人のために行動するようになり、チームにとって悪影響です。
個人の計測項目は、チームへの貢献度等に留めるべきです。

#### 22章 なぜアジャイルな計画づくりがうまくいくのか
本章では8個の理由を挙げています。
その中でもビビッと来たものを挙げます。

- 頻繁に計画を見直している
イテレーションごとに計画が見直されることで、完璧な計画を立てることよりも、現時点で有用な計画を立てることにリソースを集中できるようになります。

- 複数レベルの計画を立てている
アジャイルな計画づくりは、リリース計画、イテレーション計画、デイリー計画という3レベルの計画で構成されています。
複数視点の計画は、「（イテレーションという）木を見て（リリースという）森を見ず」という事態を回避してくれます。

- 不確実性を受け入れて、計画に取り込んでいる
アジャイルな計画は、イテレーションを進めるごとに、不確実性が徐々に解消されていくため、
一度計画したら計画変更が認められない従来の開発と比較して不確実性を受け入れやすいです。

#### まとめ
私はなんちゃってアジャイル開発の経験しかなく、アジャイル開発に対する疑問があったので、この機会に疑問を解消できたのは貴重でした。
例が非常に多く、本書の主張を受け取りやすい構造になっているので、気になった方は是非読んでみてください。