書籍『アジャイルな見積もりと計画づくり』のまとめ

所感

アジャイルの実践的な手法が詰まった本でした。
私自身XPを採用している現場で働いているのですが、日々イテレーションを回していくうえで「なぜ規模の見積もり？」と疑問に思ったりすることが多くありました。『アジャイルサムライ』を読んで基本はわかったつもりで現場で働いていたのですが、やはり実際にやってみると「こういうときはどうすればいいんだっけ？」とわからなくなってしまうものです。

『アジャイルな見積もりと計画づくり』では見積もりの方法、計画づくりの方法、トラッキングの方法が書かれています。「なぜそうするのか」という理由も書いてあるので腹落ちしながら読みすすめることができました。
また、アジャイルじゃない現場で働いていた人が読むときは「アジャイルチームは職能横断的にフィーチャに取り組む」ということを意識しながら読んだほうが良いです。私も最近アジャイルチームに入ったばかりでまだ慣れていないのですが、この本に書かれている方法論の根底にあるのは「チームメンバが役割を超えてフィーチャに取り組むことで価値を最大化させる」という考えだと思います。フィーチャの見積もりを時間ではなく規模で出すのも、取り組むのは個人ではないからです。

第一部 問題とゴール

計画の目的

• 計画づくりの目的は、「なにをつくるべきか」という問いに答えること。この質問への回答には以下のものが盛り込まれる
  • フィーチャ
  • リソース
  • スケジュール
• 良い計画とはどういうものか？
  • リスクを軽減する
  • 不確実性を減らす
  • 意思決定を支援する
  • 信頼を確立する
  • 情報を伝達する

なぜ計画づくりに失敗するのか

• フィーチャではなく作業を計画している
• マルチタスク化が遅れを助長する
  • 2つの作業を平行にすすめると効率が上がる
  • 3つ以上の作業を並行するとスイッチングコストが負荷となってしまう
• 優先順位の順にフィーチャを開発していない
• 不確実性を無視している
• 見積もりがコミットメントになっている

アジャイル手法

• アジャイルチームが現場でどう振る舞うのか？
  • 1つのチームとして働く
    • プロダクトオーナー
    • 顧客
    • 開発者
    • プロジェクトマネージャ
  • 短いイテレーションで作業する
  • イテレーションごとに成果を上げる
    • イテレーションは2~4週のタイムボックスであり、終了までに要求をリリース可能なソフトウェアに変換する。
  • ビジネス上の優先度を重視する
  • 検査と適応
• アジャイルチームは3つのレベルで計画づくりをする。
  • リリースプランニング
    • リリース全体への計画(3~6ヶ月)
    • リリースでどうやってすべての満足条件を満たすかチーム全員で決定する
  • イテレーションプランニング
    • 1イテレーション分の計画(2~4週間)
  • 「今日」のプランニング
    • メンバーがその日に何をするか決めた1日単位の計画

第二部 規模の見積もり

ストーリーポイントによる規模の見積もり

• アジャイルプロジェクトのユーザーストーリーやフィーチャはSサイズ, Mサイズ, Lサイズのように見積もれる
• ストーリーポイント
  • ユーザーストーリー・フィーチャの作業の大きさを表す単位
  • ポイントの数値そのものはそこまで重要ではなく、他の作業との相対値である。
• ベロシティ
  • チームの進む速度を表す数値
  • チームが1下位のイテレーションで完了させたユーザーストーリーのストーリーポイントの合計値
  • 必要なすべてのフィーチャのストーリーポイントの見積もりの合計をベロシティで割ると、必要なイテレーションの回数の見積もりが出る。

見積もりの技法

• 見積もりはある程度以上の労力を費やしても正確さには寄与しない。
• 見積もりは全員で出す。
  • アジャイルプロジェクトでは誰がどの作業をするのか事前にわからないため。
  • 専門外のメンバーの意見が役に立つ場合があるため。
• 見積もりに使うポイントは相対で10倍以内にする。以下は一例。
  • (0), 1, 2, 3, 5, 8
  • (0), 1, 2, 4, 8
• 見積もりの技法
  • 専門家の意見
    • 専門家にどれくらい時間がかかるかを聞く。
  • 対比
    • 「このストーリーはあのストーリーより少し大きい」といった考え。
  • 分割
    • 1つのストーリーやフィーチャを見積もりやすいように小さく分けること。
• プランニングポーカー
  • 3つの手法を組み合わせた見積もり手法
  • フィーチャについて話し合った後、手元のカードから自分の見積もりを表すポイントのカードを同時に見せ合う。
  • 全員が合意できる見積もりポイントに達するまで話し合いとカードの選択を繰り返す。
    • 議論を長引かせないために、原則1フィーチャにつき2分までにする。
  • プランニングポーカーがうまくいく理由
    • 複数の専門家の見解をまとめた見積もりになる
    • 活発な対話が引き出される
    • 個人の見積もりを平均したほうがより良い傾向を残す傾向があるため
    • 楽しいから

再見積もり

• 再見積もりすべき時とは、ストーリーの相対サイズについての考え方が変わったとき。
• 進捗が想定どおりでないという理由だけで再見積もりはしない。
  • ストーリーポイントは相対見積もりなので、1つのストーリーのポイントを変えるとほか全てのストーリーポイントも相対的に変更する必要がある。
  • ベロシティを補正装置として使う。
    • 例えば、25ポイントのベロシティを想定して200ポイントのプロジェクトを8イテレーションで完了させるという見積もりをする。実際のベロシティは20ポイントだったが、再見積もりをしなくてもプロジェクトの期間が10イテレーションになることがわかる。

ストーリーポイントと理想日

• サイズを図る指標として、「ストーリーポイント」と「理想日」の2つがある。
• ストーリーポイントの長所
  • 職能横断的な作業の進め方を促進する
    • ストーリーポイントはチーム全体の作業をまとめているので、個々のメンバーが職能横断的に取り組める。
  • 見積もりが長持ちする
    • 理想日はチームの経験値によって変化しやすい。ストーリーポイントの「規模の見積もり」は経験によって変化しない。
  • 純粋に大きさだけを表す
    • 純粋な大きさだと対比で見積もれる。理想日は開発者のスキルによって変わるので相対で見積もれない。
    • 大きさで見積もれば、現実時間と比較しない。理想日で見積もると「10日間のイテレーションで8理想日分のストーリーしか完了できなかった理由」を考えてしまう
  • ストーリーポイントで見積もるほうが早い
    • 理想日よりストーリーポイントで見積もるほうが抽象度を高くして議論ができ、個々の作業を考えずに済む。
  • 僕の理想日と公則装備は違う
    • 足の速さは人それぞれだが、コースの距離は全員同じ。実際に作業を担当する人によって変わらない。
• 理想日の長所
  • プロジェクト関係者に説明しやすい
    • 「他の作業をせず、これだけに取り組んだ時に完了までにかかる時間」と説明するだけで済む。ストーリーポイントは不確実性コーン、少しずつ計画を正確にしていくこと、ベロシティの計測といった考え方を伝える必要がある。(そういった考え方を伝えられるチャンスがあるというメリットとも捉えられる
    • 導入しやすい

第三部 価値のための計画づくり

テーマの優先順位づけ

• ストーリーやテーマを比較しながら優先順位づけするのがプロダクトオーナーの責任。
  • 価値を見積もるのが難しい小さなストーリーやフィーチャをまとめて「テーマ」とする
• 4つの要素をもって優先順位付けを行う。
  • 金銭価値
    • そのテーマに含まれるフィーチャによって組織はどれだけ収益をあげられる、費用を節約できるか？
  • コスト
    • フィーチャにどれだけのコスト(時間も含まれる)がかかるか？
  • 新しい知識
    • プロダクトの一部を開発して、顧客から得たフィードバックによって得られる知識。
      • プロダクト知識（なにを開発するか）
      • プロジェクト知識(どうやって開発するか)
    • 知識を獲得することで、プロジェクト全体の不確実性を減らすことができる。
  • リスク
    • スケジュールのリスク(10月までに終わらないかもしれない)
    • コストのリスク(ハードウェアを妥当な値段で購入できないかもしれない)
    • 機能のリスク(この機能を動作させられないかもしれない)
• 4つの要素を検討する際には、まずは価値とコストの面から暫定的に優先順位付けを行う。それから他の要素を加味して、それぞれのテーマの優先順位を調整する。

「望ましさ」による優先順位付け

• プロダクトのフィーチャは3つのカテゴリーに分類できる。(狩野モデル）
  • 当たり前, 必須
  • 線形、一元的(あればあるほどよい)
  • 魅力的
• テーマがどのカテゴリに含まれるかは、ユーザーアンケートを通して知る。
  • そのフィーチャがプロダクトにあったとしたらどう思うか？
  • そのフィーチャがプロダクトになかったとしたらどう思うか？
    • これらの質問を、5つの選択肢から選んで回答してもらう。
      • 気に入る
      • 当然である
      • なんとも感じない
      • しかたない
      • 気に入らない
  • 

ユーザーストーリーの分割

• より正確な見積もりが必要な場合に分割する。
  • あるフィーチャがリリースに含まれるかどうかギリギリの場合など
• データ境界に沿って分割する
  • 「ユーザーとして、バランスシートの情報を入力できる」をユーザーが入力するデータの種類に対応させて分割する。
    • 「ユーザーとして、バランスシートのデータをサマリで入力できる」
      • 資産と負債の2つだけを入力できるようにする
    • 「ユーザーとして、バランスシートにカテゴリごとの入力ができる」
      • 現金預金、投資有価証券、不動産など1レベル詳細化した項目を扱うようにする
    • 「ユーザーとして、入力を間違えないような入力値のバリデーションがほしい」
      • チームで話し合ってバリデーションの内容を決める。(負の値も入力できるなど）
    • 「ユーザーとして、貸付金の詳細を入力できる」
      • ユーザは100件まで貸付金を入力できるようにした
• 操作の境界で分割する
  • CRUD操作を境界にする
  • 「コーチとして、チームの選手を管理できる」
    • コーチとして、新しい選手をチームに追加できる
    • コーチとして、チームの選手の情報を編集できる
    • コーチとして、チームから抜けた選手を削除できる
• 横断的な関心事を分離する
  • セキュリティ、ロギング、エラーハンドリングなどを別ストーリーに分離する
  • 横断的な機能を含まないストーリーと、含むストーリーの2つに分ける
• 優先度に沿ってストーリーを分割する
  • ログイン機能の場合、基本部分を優先し、ロギングや再試行回数制限といった補足的な要素は優先度を落とす。
• ストーリーをタスクに分解しない
  • NG: 「UIを実装する」「中間層を実装する」
  • OK: UI・中間層・DBの一部を部分的でもいいので実装する（曳光弾）。
• 関連する変更への誘惑を断つ
  • 「ついでにこの変更もやれるじゃないか」をしない。
    • 半日かけて1年前のバグを修正するか、他の作業をするかは状況によって異なるはず。
• ストーリーをまとめる
  • イテレーションの長さによってストーリーの粒度を変える。
    • ２週間のイテレーションなら、2~5日で完了できる大きさにストーリーを分割する。
    • 1週間のイテレーションならもう少し小さくする。

第四部 スケジュールを立てる

リリース計画づくりの基本

• リリース計画は、リリースまでにどれだけ作業できて、どんなユーザーストーリーを実現できるかを判断すること
  • 単純なケースなら、ベロシティ×予定しているイテレーション数に収まるようにストーリーを選択する。
• リリース計画は、以下の手順で進める。
  • 1. 満足条件を決める
    • プロジェクトの成功と失敗を決める評価条件
    • 例えば、「4つのテーマを3ヶ月で、増員することなく開発したい」
  • 1. ユーザーストーリーを見積もる
  • 1. イテレーションの長さを決める
  • 1. ベロシティを見積もる
  • 1. ユーザーストーリーに優先順位をつける
  • 1. ストーリーを選択肢、リリース日を決める
    • リリース計画をどれだけ詳細にするかを決める
      • イテレーションにフィーチャを振り分けるか、直前でやるフィーチャを決めるか
• 各イテレーションの開始時点でリリース計画を見直して、更新する。

イテレーション計画づくり

• イテレーション計画は、1回のイテレーションでの具体的な作業を計画する
• イテレーションプランニングの手法
  • ベロシティ駆動
    • 1. 優先順位を調整する
      • ビジネスの状況によって優先順位は変わるため、定期的に見直す
    • 1. 目標ベロシティを決める
    • 1. イテレーションのゴールを決める
    • 1. ユーザーストーリーを選ぶ
    • 1. ユーザーストーリーをタスクに分解する
    • 1. タスクを見積もる
  • コミットメント駆動
    • 1. 優先順位を調整する
    • 1. イテレーションのゴールを決める
    • 1. ユーザーストーリーを選ぶ
    • 1. ユーザーストーリーをタスクに分解する
    • 1. タスクを見積もる
    • 1. チームにコミットできるか尋ねる
      • 「今話しあったこのフィーチャをリリースできると確約しますか？」
      • 7a. (確約できない場合) ユーザーストーリーを減らす
      • 7b. (確約できる場合) イテレーションプランニングの完了
• ストーリーポイントと実装にかかる時間に強い相関はないと思ったほうが良い。
  • 1ポイントよりも早く終わる2ポイントもある。
  • リリースまでに十分な数のストーリーをこなせば、こうした誤差はならされていくので問題はない。

イテレーションの長さを決める

• チームによって適切なイテレーションの長さは変わる。
• 以下の項目を考慮してイテレーションの長さを決める。
  • リリースまでの期間
    • 短期間ならイテレーションも短くするほうがいい。
  • 不確実性の高さ
    • 不確実性が高いプロジェクトならイテレーションも短くするほうがいい。
      • ベロシティの計測頻度を増やしたり、ユーザからのフィードバックを得る機会を増やして不確実性を減らせるため。
  • フィードバックの得やすさ
  • 優先順位が安定している期間
    • イテレーション中に優先順位は変えないほうがいい。
  • 外部からのフィードバックの必要性
    • チーム外にイテレーションの成果を見せて初めて作業が無駄になることがわかるケースが有る。
    • 外部からフィードバックを得る頻度が低くなればなるほど判断を謝る可能性が高まる。
  • イテレーションのオーバーヘッド
    • リグレッションテストなど、イテレーションを繰り返すためのコストが高い場合は長めにする。
  • 切迫感を感じ始めるまでの時間
    • 日々の作業で感じるプレッシャーが均一に感じられるような長さのイテレーションにする
    • 4週間にすると、最初の1週間はのんびりと仕事をしてしまう

ベロシティを見積もる

• ベロシティの見積もり技法
  • 過去の実績値を使う
    • 現在のチームが過去と変わってない場合は有用。以下の質問に全て「はい」で答えられるか確認すること。
      • 技術は同じか？
      • 業務分野は同じか？
      • チームは同じか？
      • プロダクトオーナーは同じか？
      • ツールは同じか？
      • 作業環境は同じか？
      • 見積もった人は同じか？
  • 実際に1イテレーションやってみる
    • 可能なら3イテレーションやって平均値を使えば精度が上がる。
  • 予想する
    • 代表的なストーリーをいくつか選んでタスクに分解し、イテレーションの作業可能時間内に収まるかを調べる
• 見積もり結果に幅を持たせること。
  • 例えば見積もり結果に60%と160%をかける

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

• フィーチャバッファ
  • まず必須のフィーチャを選び、そこから25~40%のフィーチャを選ぶ。
  • これらすべてを実現することを前提にプロジェクトの計画を立てる。
• スケジュールバッファ
  • 各ユーザーストーリーの50%自信のある見積もりと90%自信のある見積もりの差の平方を求め、その値の合計の平方根から算出される。
• 機能面での不確実性から守るためにはフィーチャバッファを使い、スケジュール面での不確実性から守るにはスケジュールバッファを使う。
  • 両方組み合わせて使うこともできる。

複数チーム編成プロジェクトの計画づくり

• 複数のチームが関わってくる場合に役立つテクニック4つ
  • チーム間で共有できる見積もり基準の確率
    • すべてのチームで同じ見積もり単位を採用する（理想日orストーリーポイント）
  • 早い段階でのユーザーストーリーの詳細化
    • プロダクトオーナーの満足条件を明確にしておく
  • 先を見越した計画づくり
    • 「移動する先読み範囲」
      • 今後予定されているイテレーションのいくつか(2~3ite)までの先を見越して計画を立てる
      • 近いうちに各チーム間でどういった連携が必要になるかを調整できる
  • 合流バッファを取り入れた計画
    • あるチームの作業の遅れがほかチームの作業開始に影響が及ばないようにプロジェクトに時間的な余裕を設ける

第五部 トラッキングと情報共有

リリース計画のモニタリング

• リリースのトラッキング(ベロシティ)
  • ベロシティの算出はオール・オア・ナッシングにする。
    • 途中まで計上するといったことはしない。
    • むしろ大事なのは途中までになってしまった理由を追求することである。
• リリースバーンダウンチャート
  • 
  • 縦軸が残ストーリーポイント(または残ストーリーの理想日数)
  • 横軸がイテレーション数
  • 
  • バーンダウンチャートは棒グラフにもできる。棒グラフ版のほうが表現力が高い(増減ストーリーもわかる)
• パーキングロットチャート
  • 
    • 1枚の紙で、実装予定のテーマ単位ごとに進捗状況を表現できる
    • 多くの情報を小さな空間に圧縮して見せられる

イテレーション計画のモニタリング

• タスクボード
  • 
    • チームの作業を整理し、可視化するためのもの。
    • タスクボードの列にそれぞれラベルをつけておき、作業の進行に応じてタスクカードを順番に右の列へと動かしていく。
• イテレーションバーンダウンチャート
  • 縦軸に残タスクの合計時間、横軸にイテレーションの何日目かを取る
  • イテレーションの長さが2週間以上あるなら便利。
• イテレーション計画のモニタリングにおいて注意すべき点
  • タスクの所要時間の見積もりと実績との比較はしない。見積もり担当にプレッシャーをかけることになるし、見積もりは変わりやすいものである。
  • 個人のベロシティを測らない。
    • 自分のストーリーを優先して、他人を助けないようになる。
    • そもそもユーザーストーリーは1人だけでは実現できないように書くべき。

計画とコミュニケーション

• 開発者と顧客の間で信頼関係を築くため、見積もりと計画のコミュニケーションは正直で頻繁な、双方向のものであるべき。
• コミュニケーションのための手法
  • 計画の情報共有
    • 目標期日に幅をもたせるか、見積もりの確度を一緒に伝える。
      • 「予定したフィーチャは90%の確率で7/31までに完了できそうです」
    • フィーチャレベルの粒度のガントチャートも有用。タスクレベルのガントチャートにはしない。
  • 進捗の情報共有
    • バーンダウンチャートを使う
    • 過去のベロシティをまとめたグラフを使う
      • 直近のイテレーションのベロシティ
      • 全イテレーションの平均ベロシティ
      • ワースト3イテレーションの平均ベロシティ
  • イテレーション終了報告書

# プロジェクト概要

## 日程
- イテレーション開始日 9/1
- イテレーション終了日 9/14
- 作業日数 9日

## 要員
|  名前  |  予定作業日数  |  実績作業日数  |
| ---- | ---- | ---- |
|  カリーナ |  9  |  9  |
|  ワジム  |  9  |  7  |
|  合計  |  18  |  16  |

## 指標
- ナイトリービルド結果
    - 図
- イテレーションバーンダウン
    - 図
- ベロシティ
    - 図

## 実施内容と評価
|  ストーリー  |  結果  |  予定ポイント  |  ベロシティ加算ポイント  |
| ---- | ---- | ---- | ---- |
|  コーチとして、練習を設定できる |  完了  |  8  |  8  |
|  選手として、自分のプロフィールを変更できる |  着手  |  1  |  0  |
|  合計 |  -  |  9  |  8  |

## イテレーションレビュー
- ゲーリーから、選手成績を競泳種目ごとにグラフ表示するストーリーを追加してはどうかと提案があった

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

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

• 頻繁に計画を見直している
  • イテレーションごとにリリース計画が見直され、イテレーション計画が立てられる
• 規模の見積もりと期間の見積もりを分離している
  • 作業の大きさとかかる時間には相関関係があるが、大きさ以外の要素(スキル、チーム規模など)も影響を与えている
  • まず規模(仕事の大きさという抽象的な概念)を見積もる。この規模とベロシティから機関の見積もりを算出する。
• 複数レベルの計画を立てている
  • リリース・イテレーション・今日
  • 職能横断チームがイテレーションだけに気を取られず、リリースというゴールを意識できるようになる
• 計画の基準がタスクではなくフィーチャである
  • タスク基準ではなくフィーチャ基準にすることで、プロダクトに対する理解を促進する。
• 小さなストーリーが淀みない流れを作っている
  • 作業の見積もりが相対的に10倍以内に収まっているので、新規フィーチャにかかる時間が安定している。
• イテレーションから仕掛作業を持ち越さない
  • 仕掛り作業を次イテレーションに自動的に持ち越さない。新しく計画を立て直す。
  • 実際には継続することも多いが、必ず継続するというわけではない。
• チーム全体を対象にトラッキングしている
  • 個々人をトラッキングすると数多くの問題が起こる。
    • タスクを早く終わらせると「見積もりが甘い」と責められたり
• 不確実性を受け入れて、計画に取り組んでいる
  • ユーザーのフィードバックを次回以降のイテレーションに反映できる。
    • 従来の計画手法(ウォーターフォール的)はフィーチャをプロジェクト開始時に固定してしまい、ユーザの望まないフィーチャを盛り込んだプロダクトを開発してしまう。
• アジャイルな見積もりと計画づくりのための12のガイドライン
  • 1. チーム全体を巻き込む
    • プロジェクトの価値を限界まで高めるためには、チーム全体の参加とコミットメントが欠かせない。
  • 1. 複数レベルの計画を立てる
  • 1. 大きさの見積もりと機関の見積もりを区別するために別々の見積もり単位を使う
    • ストーリーポイントor理想日とベロシティ
  • ４． 不確実性はフィーチャか日付のいずれかで表現する
    • フィーチャバッファとプロジェクトバッファ
  • 1. 頻繁に計画を見直す
  • 1. 進捗をトラッキングして情報を共有する
    • バーンダウンチャート
  • 1. 学習することの大切さを受け入れる
    • 顧客から得たフィードバックを反映して、新しいフィーチャを追加するなど
  • 1. フィーチャは適切な大きさで計画する
    • 相対で10倍以内
    • 期間が長ければストーリーをまとめてエピックにしたり、見積もりをテーマ単位で出す
  • 1. フィーチャを優先順位付けする
  • 1. 現実に即した見積もりと計画を立てる
    • ベロシティを測定した実績値を根拠にする
    • フィーチャの完了度は0%か100%
  • 1. ゆとりを残す
  • 1. 複数チームの連携には「移動する先読み範囲」を使う
    • チーム感で依存関係が生じるフィーチャについては、あらかじめ実装するイテレーションを決めておく