アジャイルな計画づくりとは？「アジャイルな見積もりと計画づくり」を読んだ

イントロダクションのなかで本書がなぜこのタイトルなのか理由の説明の記載があった。

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

アジャイルプロジェクトなのにマスタースケジュールにはいつリリース予定なのかを記載することに違和感を感じていた。本を読み進めていくとアジャイルプロジェクトでの計画づくりがしっくりくる。

スクラムマスターはぜひ読むことをお勧めする。何度も読み返して自分の血肉にしていきたい名著だ。

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

目次
イントロダクション
第1部　問題とゴール
　　1章 計画の目的
　　2章 なぜ計画づくりに失敗するのか
　　3章 アジャイル手法
第2部　規模を見積もる
　　4章 ストーリーポイントによる規模の見積り
　　5章 理想日による見積り
　　6章 見積りの技法
　　7章 再見積り
　　8章 ストーリーポイントと理想日
第3部　価値のための計画づくり
　　9章 テーマの優先順位づけ
　　10章 金銭価値による優先順位づけ
　　11章 「 望ましさ」による優先順位づけ
　　12章 ユーザーストーリーの分割
第4部　スケジュールを立てる
　　13章 リリース計画づくりの基本
　　14章 イテレーション計画づくり
　　15章 イテレーションの長さを決める
　　16章 ベロシティの見積り
　　17章 不確実性に備えるバッファの計画
　　18章 複数チーム編成プロジェクトの計画づくり
第5部　トラッキングと情報共有
　　19章 リリース計画のモニタリング
　　20章 イテレーション計画のモニタリング
　　21章 計画とコミュニケーション
第6部　なぜアジャイルな計画づくりがうまくいくのか
　　22章 なぜアジャイルな計画づくりがうまくいくのか
第7部　ケーススタディ

ストーリーをタスクに分解してはならない

プロジェクトを進めていると分解しづらいユーザーストーリーに出くわすことがある。またSE思考の癖でユーザーストーリーがタスクのような記載になってしまうことがある。でもストーリーをタスクに分解してはいけない。以下は本の中で言及されているユーザーストーリーの悪い例だ。

・ユーザーインターフェイスを実現する
・中間層を実現する

ユーザーストーリーがタスクになるとPOからみて受入可能条件を記載しづらい。またアジャイルで作っているつもりがミニウォーターフォールになってしまうことがある。（例でいくとユーザーインターフェイスが実現するまで後続作業ができなくなってしまう）こういったときの対応方法はシステムを閃光弾で照らすというものだ。

「閃光弾」とは、あるフィーチャーに必要な論理層すべてをまたいで実装することを指す。各層の実装は部分的なもので構わない。たとえば、ユーザーインターフェイスの一部と、中間層の一部、データベースの一部といった具合だ。常に、特定の論理層を１つだけ完成させるよりも、部分的にであってもすべての論理層をまたいで実践することを考えよう。

タスクを見積もる

アジャイルプロジェクトではグループで見積もりすべきだとある。グループで見積もりをすべき理由は4つ。

1. イテレーションプランニングの段階ではタスクを個人にアサインしない。よって、そもそも担当者が見積もることは不可能である。
2. 他のメンバーがそのタスクの見積もりに何の貢献もできないことにはならない。
3. 作業を終えるのに必要な時間について複数の意見を集めることで、ユーザーストーリーやタスクに関するチーム内での意識の違いを確認できる。
4. タスクを担当者が見積もってしまうと、個人のプライドやエゴのせいで、見積もりが誤っていたことを後で認めづらくなる。協調作業の結果としての見積もりがあれば、誤りを認めることへの抵抗感も軽減される。

グループで見積もりすることは関係者間の認識相違を減らせるなどメリットがある。但しグループで見積もりをする分の時間が掛かるので注意が必要だ。ウォーターフォールの感覚で見積もりをするとそれだけで時間が掛かってしまう。アジャイルで見積もること、アジャイルな計画づくりを意識して取り組むことが必要だ。

不確実性に備えるバッファの計画

アジャイルプロジェクトでのスケジュールバッファをどのように取るべきかを悩んでいた。アジャイルプロジェクトとはいっても納期はある。（但しスコープ、品質、コスト、スケジュールが動かせない場合はアジャイルはやめたほうがいい）

本で紹介されていたバッファのとり方は２つ。フィーチャーバッファおよびスケジュールバッファだ。スケジュールバッファはPMであれば馴染み深いと思う。フィーチャーバッファは本を読んでなるほどと思った。フィーチャーバッファはプロダクトバックログでやるべきことの中にバッファを取り入れておく。フィーチャーの一部をバッファ＝オプションとしておくことで当初想定したベロシティが出なかったとしてもバッファで対応できるようになる。

なぜアジャイルな計画づくりがうまくいくのか

アジャイルな計画づくりがうまくいく理由として、本の中では以下の９つが紹介されている。どれもなるほどと思った。

１．頻繁に計画を見直ししている
２．規模の見積もりと期間の見積りを分離している
３．複数レベルの計画を立てている
４．計画の基準がタスクではなくフィーチャーである
５．小さなストーリーがよどみない流れをつくっている
６．イテレーションから仕掛作業を持ち越さない
７．チーム全体を対象にトラッキングしている
８．不確実性を受け入れて、計画に取り組んでいる
９．アジャイルな見積もりと計画づくりのための１２のガイドライン

これまでウォーターフォールのWBSに慣れた感覚からすると、上記のうち、4.計画の基準がタスクではなくフィーチャーであるというのがスケジュールの考え方をあらためる必要があると痛感した。今までWBSを作ってはタスク漏れがないか気にかけていたがそもそもタスクを扱うというアプローチでは防ぎきれなかったのだ。

まとめ

原著が出版されたのは2005年、日本で訳書が出版されたのが2009年とIT業界ではかなり古い書籍になる。それでも今読んでアジャイルの理解が深まった。プログラミング言語やツールに依存せず、そもそも見積もりとはなにか、スケジュールとはなにかを考えさせられる本だった。これからスクラムマスターを続けていくうえで何度も読み返すことになる本になりそうだ。