アジャイルな見積りと計画作り:レバレッジメモ

PySpaで id:Yoshioriに「見積りって難しい」という話をしたら「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」を教えてもらった。さっそく読んでみたのでレバレッジメモ。

「不確実性に対処するためにバッチサイズを小さくしてアジャイルに開発しよう」とか言いつつ「見積りはプロジェクトの最初に立てて変更しません」という運用をしているのはおかしい。見積りや計画づくりもアジャイルに、状況に応じて変わって行かなければ、という本。

要するに「プロジェクトの最初に正確な計画・見積りが作れるはずがない。最初に正確な計画・見積りづくりをしようとして過剰にコストを掛けるのではなく、イテレーションごとにより精度の高い見積りへと更新していく形を取ろう」ということ。

従来型の見積りの仕方が失敗するパターンがいくつか上げられていて興味深い。

例えば「タスクXに何日掛かるか見積もれ」って言われて、「3日掛かります」と答えたとすると、実際の作業が4日かかる場合には本当に4日消費されるのに、実際の作業が2日で終わったら残り1日がコードの質を高めるとかテストコードを充実させるなどの「本来予定されていない作業」に使われて3日消費されるので伸びることはあっても縮むことはないとか。仕事は与えられた時間を全部使うところまで膨張する。

見積りを「コミットメント(約束)」として捉えてしまうと、不確実なタスクに対して「(2日で終わるか2週間掛かるかわからないからなぁ…)『2週間』かかります」「いやそんなに掛かるわけ無いだろ、もっと短くしろ」「そんなこと言われましても…じゃあ1週間(不安だなぁ)」「(なんだよ、縮められるんじゃないか、今後もガンガン削っていこう)」という不毛な争いが発生する。ステークホルダーがお互いに争い合うゲームになってしまう。協力してゴールを目指すゲームになるような仕組みづくりが重要なのに。

見積りはその通りにいかないことが大前提で、だから、重要なフィーチャーから作っていって、時間が足りなくなったら重要でないものを切り捨てられるように計画を立てなきゃ。「計画通りに全部の実装ができる」と思い込んで優先度付け・順番付けの手を抜くのは後で苦しむ。

この本が紹介している「ストーリーポイント」を用いた見積りは、要は一言で言えば「時間を見積もるな。規模を見積り、速度を計測し、時間を導出しろ」ということになる。規模の大きなものほど正確には見積もれない。だからモノサシも大きいところほど間隔が広くなっている。例えば1, 2, 3, 5, 8, 13, 20, 40, 100。規模をざっくり見積もるための便宜上の単位が「ストーリーポイント」だ。

プロジェクトの計画をたてる粒度では、タスクではなくフィーチャーをリストアップする。フィーチャーは顧客視点で、「ユーザは〜ができる」みたいな記述になっている。こうすることで「これをやることでどんな顧客価値が生まれるか、捨てると何が失われるか」がわかりやすい。で、その「フィーチャー」の規模をストーリーポイントで見積もる。これは後で実際にイテレーションが始まる際にイテレーションの計画をたてる段階で「タスク」と「時間」の見積りに詳細化する。最初の段階でタスクと時間への詳細化をしても開発が進むうちに変わっちゃうから無駄なコストになってしまう。

次にリストアップしたフィーチャー(とそれをまとめたテーマ)に優先順位を付けなければならない。判断材料にはいくつもの切り口がある。金銭価値(得られるor失わずに済むor節約できる)。開発やサポートに掛かるコスト。得られる知見。削減できるリスク。前二つにばかり考えがちなので注意。高価値高リスクなフィーチャーから始め、高価値低リスク、低価値低リスク、の順で開発することが勧められている。

顧客満足度もまた優先順位付けの切り口の一つである。この本ではアンケートに基づく狩野モデルと、ウィーガーの方法が紹介されている。僕の目的にはウィーガ−の方法の方が向いていそう。実行した時のメリットとしなかった時のデメリットを1〜9の相対評価で出し、それを見積りで割ってROIを求める。

大きすぎてイテレーションに入らないストーリー(とエピック)は、イテレーション計画の前段階で分割する必要がある。この時、タスクに分割しないように気をつけなければいけない。「サーバに1イテレーション、クライアントに1イテレーション」みたいな両方が完成しないと何も学べないような分割の仕方をしたのではイテレーションを分けて「早く実行→学習のサイクルを回そう」としているのに台無し。そうではなく、サーバとクライアントの両方を使い試しに使うことが出来る最低限の実装とかを作る。トレーサー(曳光弾)。優先度の低いサブストーリーを切り出す。データ境界、データ操作(CRUD)の境界、機能要件・非機能要件の境界、ロギングやエラー処理などの横断的関心事。

リリース計画。リリースの必要条件は?ストーリーがどれくらいの規模かをストーリーポイントで見積もる。イテレーションの長さ、イテレーションごとのベロシティ(速度)、ストーリーの優先順位を決める。ストーリーを選択してリリース日を決める。このプロジェクトの計画において日付が重要か、フィーチャが重要か?日付が重要ならはみ出すフィーチャーは捨てなければならないし、フィーチャーが重要なら締め切りは延ばさなければならない。

ベロシティの見積りは、16章に詳細が書かれているが、1回実際にやってみて計測するのが一番。

次に各イテレーションごとにそのイテレーションの計画を立てる。ベロシティドリブンとコミットメントドリブンの2つが紹介されているが筆者のオススメはコミットメントドリブン。P173の図がわかりやすい。まずは最初に決めた優先度のままでいいのか変更が必要かを考える。次に、このイテレーションでのゴールを一言で表現する。「レポート機能が改善される」ぐらいの詳細度でOK。それから、ストーリーの選択、ストーリーのタスクへの分解、タスクの見積り、を行う。この段階で初めて「時間での見積り」に変わる。チームメンバに「このタスクをこのイテレーションで達成できるとコミット(約束)できるか」と聞きながら、コミットできる範囲で足していく。「これ以上無理」となったら計画終了。

ミーティングもタスクに含めることが重要。1時間のミーティングを6人でやるなら最低6時間のタスクとして工数に計上する。準備時間が必要ならそれも工数に含めること。

「何時間掛かるのかやってみないとわからないよなぁ」的なタスク、あるある。「スパイク」と「プレースホルダ」という切り分け方をする。スパイクは、精度の良い見積りのために必要な知識を得るタスク。プレースホルダーは「いまは正確に見積もれないタスク」をあとで見積り直すつもりでとりあえず適当に見積もっておくもの。

バッファの準備方法。バッファを「サボり」や「水増し」と思われないための合理的な理由付け、理論武装が重要。フィーチャバッファとスケジュールバッファがある。前者はあらかじめMUST HAVEなタスクが計画の70%を超えないようにしておき、時間が足りなくなったらそれを削る方法。後者は「この時間までに完成する確率が50%」って見積りと「90%」って見積りを出して、そこから見積りの不確実さ(標準偏差)を導出して云々する数学の苦手な人を威圧するのには最適な方法w

コミュニケーション。プロジェクトをマネジメントする上では、利害関係者に進捗を伝える必要性がでてくる。見積りに幅があることを伝えるために、平均ベロシティで終了のタイミングを計算するだけではなく、ワースト3ベロシティなどでも計算する。ガントチャートWBSを要求されたらしれっとフィーチャー単位で出す。

まとめ

  • 計画を頻繁に見直す
  • 規模の見積りと期間の見積もりを混同しない
  • リリース、イテレーション、今日、という詳細度の異なる計画を立てる
  • 粒度の大きい計画ではタスクではなくフィーチャーを使う
  • 不確実性があることを計画に入れる
  • フィーチャーは優先順位を付ける
  • 実際の値を見積りの根拠にする、実測値で計画を正確に変えていく
  • バッファを必ず取る