今回は、「アジャイルな見積もりと計画づくり」という本を読みました。
なぜこの本を読んだのか
私は現在、スクラムを導入して開発をしています。
会社で説明を受けて普段からチームのみなさんと一緒に見積もりをしたりKPTをしたりしているのですが、見よう見まねでやっている部分があります。例えば、「見積もりを相対的につけるということはわかったけど、どうして相対的につけるんだろう？」というような疑問をたくさん持っています。アジャイル開発の本質を知るべくこの本を読もうと思いました。
この本で学べること
- 見積もりや計画づくりをどうやって行うのか学べる
- そうしたプラクティスが大切なのはなぜか学べる
この本の対象者
- あらゆる規模のアジャイルプロジェクトに従事するプロジェクトマネージャー、プロジェクトリーダー、開発者、経営者
第1章 計画の目的
アジャイルな計画"づくり"で大切なのは、出来上がった計画より、計画を立てる"活動そのもの"。
見積もりと計画づくりは期日やスケジュールを決めるものではなく、価値の探求であるべきで、「何を作るべきか？」問いに答える作業だと書いてありました。1章めからアジャイルに対する私が今まで持っていた印象が根本からひっくり返されました。
第2章 なぜ計画づくりに失敗するのか
2章では、計画作りに失敗する理由についてです。
- 計画づくりでは、作業ごとにタスクを立てると失敗する。フィーチャを単位にするべき。
- 作業を同時並行すると余計に遅れるので失敗する。
- 見積もりをコミットメントと勘違いするとプロジェクトが失敗する。見積もりは（X日までに終わる）確率で、コミットメントは日付。
- 納期を優先してしまい、ユーザーにとって本当に必要な機能が削られるという失敗。
機能ごとに計画を立て、優先順位をつけ、その機能に集中することがプロジェクトが失敗しないコツなのかもしれないです。
第3章 アジャイル手法
アジャイルなチームとはどんなチームであるかについて。
- アジャイルチームはあらかじめ決められた計画に従うよりも、おきた変化に適応することに価値を置く。
- チームが最終的に達成したいことはプロジェクトの顧客とユーザーに最大限の価値を提供すること。
- プロダクトオーナー ... プロダクトのビジョンを提供し、チームが開発するフィーチャの優先順位づけに責任をもつ役割。
- 満足条件 ... 実現すべきフィーチャとフィーチャが期待通りに実装されたことを確認する概要レベルのテストとして表現される。
アジャイルのチームには、一人一人に役割やゴールがあることがわかりました。
第4章 ストーリーポイントによる規模の見積り
ストーリーポイントが相対的に規模を見積もるものだと説明されていました。
レストランでソーダを頼むときは、スモールサイズとラージサイズを聞いて自分にあった量を頼めば良くて、ソーダの具体的なg数まで言わなくてもいいです。こんな感じで、ストーリーポイントも、あのタスクよりは大きいor小さいで規模を見積もっていきます。
第5章 理想日による見積もり
アメフトの試合は、4時間と決められていても時間通りに終わることは少ないです。（日本だと、野球中継の方がわかりやすいかも）
同じようにプロジェクトも、実際に終わる時間（インタビューやCMの時間も入れたアメフト試合の中継時間）よりも理想時間（純粋にアメフトの試合時間）で考えるべきだそうです。
さらに、ユーザーストーリーひとつにつき、実装とテストとPOの確認時間も含めた理想時間を考えることが望ましいとされています。
第6章 見積もりの技法
6章では、見積もりの技法：プランニングポーカーについて出てきます。
見積もりに労力をかけすぎるのは良くないので、10を超えない非線型の数値「 1 , 2, 4, 8」などでプランニングポーカーをするのがオススメだそうです。
第7章 再見積もり
見積もりをやり直したいときにどうするべきか？がわかりました。
進捗が想定通りではないからという理由で見積もりをやり直してはいけません。
また、ベロシティを補正装置として使うことで見積もりの不正確さがなくなります。
第8章 ストーリーポイントと理想日
ストーリーポイントで見積もる方法と理想日で見積もる方法について書かれていました。
ストーリーポイント
ストーリーポイントで見積もる場合、その見積もりはチームの技術力によらない。
理想日での見積もりよりも早く見積もりができる。
理想日
理想日で見積もる場合、プロジェクト関係者に説明しやすいメリットがある。
理想日で見積もっているうちに見積もり力も上がって、タスクを相対的に大きいか小さいか考えられるようになるので、自然とストーリーポイントで見積もるようになっていく。
第9章 テーマの優先順位付け
何事も優先順位をつけるのは大切です。
優先順位をつけるときに必要なのは、
- 金銭価値
- 必要となるコスト
- 得られる知識の量とその意義
- 提言できるリスク
の4つです。
第10章 金銭価値による優先順位づけ
10章では、財務的な分析から優先順位をつけていきます。
収益のモデル化は以下の4つで十分で、さらに効果を予想するのは大抵2年先までで十分です。
- 新しい顧客
- 既存の顧客が追加で購入
- 既存の顧客が継続して使用してくれる利益
- 業務の効率化による利益
第11章 「望ましさ」による優先順位づけ
金銭で優先順位をつける方法の次は、望ましさによる優先順位づけについてです。
苅野の分析による優先順位づけ
- 当たり前のフィーチャ...必須
- 線形のフィーチャ...あればあるほどいい
- 魅力的なフィーチャ...あれば魅力的。
相対的重み付けによる優先順位づけ
- フィーチャについての利点
- フィーチャがないことの悪影響
- 開発するためのコスト
どちらの手法でもよく、自分の組織にあった方を選びましょうとのこと。
第12章 ユーザーストーリーの分割
ユーザーストーリーの分割の方法について。
- 扱うデータに沿って分割するパターン
- ストーリーを実現するためのユーザー操作に沿って分割するパターン
- エラーハンドリングやセキュリティ、ロギングなどの横断的な機能でも分けられる
- 一方で、細かいストーリーをまとめた方がいい場合もある。
第13章 リリース計画づくりの基本
13章から第4部に入ります。ここからはスケジュールの立て方について学びます。
例えば、6ヶ月後に新しいプロダクトをリリースしたい場合、１イテレーションが2週間であれば13回イテレーションを回せます。
ベロシティが20ptであれば、260ptを超えないようにストーリーを選び、それぞれに優先順位をつける。
これの一覧がリリース計画です。リリース計画は、各イテレーションが始まるときに必要に応じて更新するようにします。
第14章 イテレーション計画づくり
リリース計画が立てられたら、ユーザーストーリーを実装することに集中するためにイテレーションプランニングを計画します。
イテレーション計画は、リリース計画とは異なりユーザーストーリーをタスクに分解し、理想時間で見積もります。
やり方はベロシティ駆動とコミットメント駆動の二つがあります。
余談ですが、コラムにあったイテレーションの始まりを「月曜始まり金曜終わり」にするのではなく「金曜始まり木曜終わり」にするというのは目から鱗でした。木曜終わりにすると、終わらなかった分を金曜の午前にやることができるし、午後はレビューとイテレーションの計画を立てるのに当てて１日を終えることができるからだそうです。確かに私自身も、月曜始まり金曜終わりでやっていた頃は、金曜に終わってない分を土日に作業したりしていました。現在の会社は、曜日ではなくてチームごとの会議と全体の会議を合わせてイテレーションの長さを決めたりしています。
第15章 イテレーションの長さを決める
全てのチームが使えるイテレーションの長さはありません。
リリースまでの期間や、不確定要素の高さなど、様々な条件を考慮しながら自分たちで決めます。
だいたい2〜4週間が多いそうです。
第16章 ベロシティの見積もり
ベロシティの見積もりには、以下3つの方法がある。
- 過去の実績値を平均する。（ただし、チームやプロジェクトの性質、技術などに大きな変化がないか確認する。）
- 実際にイテレーションを実施する
- ベロシティを予想する
第17章 不確実性に備えるバッファの計画
バッファの持たせ方について。
フィーチャーバッファ...機能に優先順位をつけて、「全て実装するわけではない」と合意をとるやり方。（買い物の時間が30分しかないので、ほしいものリストにある37個のうち20個しか買わない...みたいな感じ。）
スケジュールバッファ...スケジュール全体にバッファを持たせるやり方。（旅行に行くときに、準備、車、飛行機の搭乗で70分かかるとしたら、100分前にでる。うまくいったら30分暇つぶししないといけないけど...みたいな感じ。）
バッファは水増しではない。バッファはもちろん小さい方が望ましい。
「3日かかる」と心では思っているのに「5日かかる」と口で言ったらそれは水増しなのでよくない。
第18章 複数チーム編成プロジェクトの計画づくり
この章では、一つのプロジェクトに複数のチームが関わっているときに役立つ4つのテクニックについて解説されていました。
- チームで見積もり基準を同じにする
- 複数チームが同じプロジェクトで作業するとき、ユーザーストーリーを早い段階で見積れるようにしておく
- 今後予定されているイテレーションのいくつかまでの先を見越して計画を立てる
- チーム間で合流バッファを設ける
第19章 リリース計画のモニタリング
ベロシティとは、一回のイテレーションで完了させた仕事量を測定したものです。
作業に取り掛かっていても、完了していない分はポイントに入れません。
ベロシティの推移をみる為に、リリースバーンダウンチャートやバーキングロットチャートなどのグラフがあります。
第20章 イテレーション計画のモニタリング
イテレーションの進捗を把握するのに役立つのが、タスクボードといイテレーションバーンダウンチャートです。
タスクボードは、チームによってラベルを変えてもいいですが、私のいるチームではよくBacklog / Open / WIP / In Review / Closeとかでカテゴリ分けされています。
イテレーションバーンダウンチャートは、縦軸に残作業の合計時間を、横軸にイテレーションの何日目かを取る折れ線グラフです。
また、個人単位でベロシティは計測してはならないと書いてありました。そうすると、チームの誰かが困っていても個人のベロシティを優先するような仕組みになってしまうため、チームのベロシティの寄与にはならないからだそうです。なるほど...。
第21章 計画とコミュニケーション
見積もりと計画に関するコミュニケーションは頻繁で正直なものであるべき。
計画や進捗状況を伝える方法として、グラフを使ったもの、過去イテレーションをグラフにしたものなどがあります。
第22章 なぜアジャイルな計画づくりがうまくいくのか
アジャイルな計画づくりの目的とは、どんなフィーチャを、どれだけのリソースを投入して、いつまでに作り上げるのか、この問いの最適解をイテレーションを繰り返しながら近づいていくこと。
計画を頻繁に見直したり、タスクではなくフィーチャを基準として見積もりを立てる。
不確実性を受け入れて、プロダクト開発全体の問いに答えていく行為。
第23章 ケーススタディ：ボムシャルタースタジオ
23章では、6ヶ月遅れているというあるゲームソフト開発のプロジェクトにアジャイルを導入した例を見ていきます。
今までの章で学んだ大切な点を、会話形式で一気に読むことができます。
まとめ
見積もりと計画づくりは期日やスケジュールを設定するためだけのものではなく、計画づくりとは価値の探求だ、という言葉を読んでとても納得・感心しました。この一言にアジャイルの本質の全てが詰まっていると感じました。
昔話になるのですが、チームの誰一人としてアジャイルについてよくわからないままプロジェクトを進めていたことがありました。
用語やフレームワークだけアジャイルっぽいことをしていたのですが、作ってから「こういうことじゃないです」と作り直しになったり、進捗に正直でない人がいて、全然約束してた時間に間に合わなかったり、めちゃくちゃでした。
何が言いたいかというと、この経験から、アジャイルのフレームワークだけ導入しても絶対にアジャイル開発はうまくいかないということです。「なぜ、これをやるのか？」 チームメンバー全員がわかっていないと、各見積もりや計画づくりの段階で話し合うべきことがわからなくて後から出てきた新たなタスクに対処できなかったり、計画を立て直すのが難しいくなったりするのかな、と思いました。
私も将来後輩ができて、プロジェクトを回すようになったときは、「プロジェクトの進め方」ではなく「なぜこれをするのか」に焦点を当てて伝えていきたいなと思いました。
次はスクラムブートキャンプを読みたいです！
ここまでお読みいただきありがとうございました。
