『アジャイルな見積りと計画づくり』

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

分厚いのに頑張って読んだ。感想など。

この本は何か

「アジャイルなチーム」による、ソフトウェア（or サービス）開発プロジェクトにおいて、

・いつ、どうやって計画を立てるか
　・プロジェクトの分割方法（リリース、イテレーション。テーマ、エピック、ストーリー）
　・規模、期間の考え方
　・優先度のつけ方。
・いつ、どうやって計画された作業を実行するか
・いつ、どうやって計画の見直しを行うか
・チーム内・チーム間の情報共有をどう行うか

というようなことが書いてある。

「アジャイルなチーム」というのは、明確な定義はないが、おそらく４〜８名程度のチーム。
チームには以下の役割を含む。（兼務あり）
・プロダクトオーナー
・顧客
・開発者
・プロジェクトマネージャ

プロジェクトのターゲットは、ソフトウェアに限定しているわけではないようだが、暗黙にそれが前提にはされているようなのでそれで。

この本に書いてないこと

イントロダクションでも名言されているが、計画がメイン。
プログラミングやら設計やらの個別タスクの詳細に関しては当然ながら触れていない。
理論面の話なので、こういうツールを使ってどうこう、という話もない。

２チーム以上が関わるような中規模以上のプロジェクトについては、言及がないわけではないが、かなり弱い。
複数チーム間での連携の方法について若干の記載がある程度。
プロジェクトを分割して複数チームを並行稼働させる際のマネジメント理論などはない。

チームの重要性、チームが一丸となってプロジェクトに当たることの重要性は説かれているが、「チームマネジメント」そのものについての独立した章があるわけではない。
組織編成論とかもない。スクラムについては単語が数カ所に出てくる程度。

ポイント

２２章「なぜアジャイルな計画づくりがうまくいくのか」にまとめているので抜粋。

１．頻繁に計画を見直している
２．規模の見積りと期間の見積りを分離している
３．複数レベルの計画を立てている
　　※　リリース、イテレーション、「今日」の３つ。粒度・精度の異なる３段階。
４．計画の基準がタスクではなくフィーチャである
　　※　フィーチャ＝顧客にとっての価値の単位。要求仕様、機能要件、ユースケースみたいなもん。
５．小さなストーリーがよどみない流れをつくっている
　　※　サイクルタイム（プロセスの開始から終了までにかかる時間）
　　　　＝フィーチャの開発着手からユーザーがそれを手にするまでの時間が短い、ということ。
６．イテレーションから仕掛り作業を持ち越さない
　　※　イテレーション毎に計画を立て直す、ということ。
７．チーム全体を対象にトラッキングしている
　　※　個人を対象にするのはよくない。
８．不確実性を受け入れて、計画に取り込んでいる

同章に「アジャイルな見積りと計画づくりのための１２のガイドライン」というのもあったので挙げておく。

１．チーム全体を巻き込む
２．複数レベルの計画を立てる
３．大きさの見積りと期間の見積りを区別するために別々の見積り単位を使う
４．不確実性はフィーチャか日付のいずれかで表現する
５．頻繁に計画を見直す
６．進捗をトラッキングして情報を共有する
７．学習することの大切さを受け入れる
８．フィーチャは適切な大きさで計画する
９．フィーチャを優先順位づけする
１０．現実に即した見積りと計画を立てる
１１．ゆとりを残す
１２．複数チームの連携には「移動する先読み範囲」を使う

読み始めた時点での自分の状況

アジャイルブーム的な状況なので、なんとなく反感があったが、いいことも言われているようなので、とりあえず評価が高くて理論寄りのものを読んでみようと思った。

PMBOKには触れており一通りは知ってる程度。こちらはプロジェクト活動を俯瞰的に把握するには有用な参考資料と思っている。

読み終わった後の感想

「確かに良本なんだけどなぁ…」というところ…。

とにかく、対象を細かく分けて、成果を目に見える形で確認しながら進むべき、という点で思想が一貫しているのはよい。
・時間　　　→　イテレーション
・スコープ　→　ストーリー
・人（組織）→　チーム

　※　どうチームを編成するか、については書いていなかった。残念。

本書全体を端的にまとめると↑に尽きるんだと思う。

で、気に入らなかった点。

「アジャイルだから成功する」みたいな文句で、観念的な「従来の手法」に比較してここがよい、みたいな売り込み方が気に障る。
何かのついでのような流れで、ガントチャートやらWBSの批判をするのはいかがなものか。背景の思想の差異を正しく説明せずに手法を批判しても意味はないのに。

全般的に、「従来の手法」に対する反作用でできていると思われるような箇所がある。
「タスクではなくフィーチャ」という主張はなされてはいるが、最終的には本書の手法であっても最下位の階層ではタスクの単位で作業を行っている。フィーチャとタスクの役割の違いをフラットに説明すればいいのに、タスクを「従来の手法」の象徴のように批判している箇所があるので、読者にタスクそのものが悪であるかのような、誤った印象を与えかねない。

「チーム一丸となって取り組むべき」という主張には同意する。
のだが、理念的な目標と、実際の個々人の役割・適正の差を鑑みての実務指針とを区別せずに、理念だけを言って詳細説明を省いているような感がある。
「チームによるので明確な指針はない。話しあって決めて欲しい」とでも書いてくれればいいのだが。

まあ、こんなとこ。

適用範囲を間違えなければ良本ということでいいかと。
『アジャイルな見積りと計画づくり』というタイトル通りの内容。

ただ、最初の一冊としては勧めづらい。
やはり、手法以前のプロジェクト・組織についての一般論を押さえていないと使い方を誤る気はする。

オワリ