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

この記事は 「ひとりでアジャイルo0h① Advent Calendar 2021」のday-15です。 adventar.org

day-15は「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」です。

どんな本

アジャイルソフトウェア開発をやるにあたっての、計画や見積もりについて扱かった本です。
「そもそも完全な見通しを立てる、というのは現実的ではない」「不確実性に適応していこう」というようなスタンスで発明された「アジャイル」において、やはり「計画」「見積もり」は難しいポイントの1つです。
その辺りに悩んだり苦しめられた事がある人は必読・・・!といって良い本だと思います。

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

P23 イントロダクション

という一言が、本書のスタンスを言い表しているように感じます。
もしくは、

本書で扱うのはアジャイルな「計画づくり(planning)」だ。アジャイルな「計画(plan)」ではない。計画とはドキュメントや図表であり、ある時点のスナップショットを記録したものだ。そこに記録されているものは、不確かな未来にプロジェクトで起きるだろうと予測したひとつの姿に過ぎない。いっぽう、プランニング、すなわち計画づくりは「活動」である。アジャイルな計画づくりで重視するのは、計画よりも、計画を作る家庭そのものなのだ。

P33 1章 計画の目的

もハッとさせられたフレーズです。

本書は、

「なぜ(アジャイルな)計画づくりが重要なのか、どんな価値をもたらすのか」
「それはどうやって取り組めば良いのか、あるいは、計画づくりをより意味のある活動にするには何が重要なのか」
「作った計画をうまく活用する、プロジェクトの利益に結びつけるにはどうすればいいのか」

といった事を扱った本です。

よくある「なぜ理想日ではなくポイント、相対見積もりを用いるのか」といった話はもちろん、「優先順位付けはどのように行うのか」「1スプリント目においてベロシティはどうするのか」「バッファはどのように扱えば良いのか」などにも踏み込んで話しています。

お気に入りポイントかいつまみ

「なぜ計画するのか」に改めて立ち返って考える

計画や見積もり、面倒くさいんですよねぇ。。。それに正解もわからない!
とも思いますが、本書を読むと(特に第1部)、どんなプロジェクトであろうと・・あるいは「集中」を生み出すためにアジャイル開発にこそ計画って重要な経済活動なんだな、ということに気付かされます。

よい計画づくりとは、以下のような特徴を持ったプロセスのことだ。いずれも「ソフトウェア開発の問い」に対する答えを見つける手助けとなる

  • リスクを軽減する
  • 不確実性を減らす
  • 意思決定を支援する
  • 信頼を確立する
  • 情報を伝達する

P29

このあたりの「なぜ、そう言えるのか」について本書は全体を通して深めているような印象を抱きました。

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

スクラムに取り組み始めたときなど、なかなかイメージが得にくいことの1つが「ストーリーポイント」や「相対見積もり」ではないでしょうか。
時間ではなくタスクの規模を見積もること、という原則が本書で丁寧に解説されています。 (規模の見積もりの尺度として理想日を用いる、という方法も可能ですし、それは本書でも紹介されています)

本書は全体的に「少しスクラム(やアジャイル)の全体像・基礎が把握できてきた」というレベル感以上にある人が対象かと思いますが、この部分(4〜6章)については入門〜基礎レベルにある人にとっても価値のある話になるかも知れません。

優先順位付けとリスク

バックログ(のリスト)を作成した後に、優先度に応じて並び替える・・・というのは当然ながら必要なことですが、「どのように並べるのが良いか」というのはプロジェクトの成功の肝とも言える部分です。

その中でも、「リスクを下げるために」という観点は、なるほどなと思いました。
アジャイルは「不確実性」に立ち向かうものであり、検査と適応によってそれを成します。すなわち「未知のものを、いかに効率的に学習できるか」です。
そういった意味では、「未知性が高い」というリスクについては、早めに軽減することでプロジェクトをより確実なものにできます。

「リスク」と「価値」の軸で4象限を作り、「高リスク・高価値」に当たる部分を優先的に進めていこうというのがリスクに基づく優先順位付けです。

優先順位付けの例として、「コスト(後でやるより今やったほうが低コストになる)」「フィーチャーの開発によって得られる知識」「プロジェクトの成功を妨げるようなリスク」という順を提示しています。
知識というのは、「プロジェクトナレッジ」と「プロダクトナレッジ」があるとのことです。プロジェクトナレッジとは、技術検証等を含む「プロジェクト内部で必要とするもの」で、プロダクトナレッジとは「顧客に提供する価値の発見・創造につながるもの」とされます。検査と適応の態度について、とても重要な点です。

こうした複合的な軸で、全体を見渡して「最も合理的な進み方を考える」というのが計画づくりの価値と言えるのだな、と思いました。

ストーリーの分割

ユーザーストーリーのスライスについても、頭を悩ませる大きな問題の1つです。
そのあたりも本書ではまるまる1章を割いて扱っています。

  1. データ境界による分割
  2. 操作の境界での分割
  3. 横断的な関心事の分割
    1. 例えばロギングやエラーハンドリングなど
  4. パフォーマンス制約をストーリーにする
    1. 機能要件と非機能要件を別々のストーリーにする
  5. 優先度に沿って分割する

といった、具体的な観点を提示しています。

どうしても慣れが必要な部分だと感じるのですが、少なくとも「タスクごとに分割する」「コンポーネントやレイヤーで分割する」といった誘惑に抗うための自信が持てそうだな、と思いました。
「タスク」ではなく「フィーチャー」で捉える脳みそになりたいものです。

バッファ

バッファのもたせ方についても、具体的・数量的な方法が紹介されていました。
「なんとなく一律1.2掛けにしておく」といったおまじない的な方法ではなく、「(主観的な)自信・確率」に基づいて「バッファ = リスクをどの程度設けるか」という話が紹介されます。

まとめ

他にも、「予定に幅を持たせる」「ベロシティ駆動とコミットメント駆動」などは、自分がアジャイルっぽくプロジェクトを回している際に(摘み食い的に読みながら)非常に参考にした内容でした。

ともすれば「アジャイルなんだから、計画は雑にやってしまう」といった感覚になっているチームも数多いかと思います。
「不確実性を取り入れた計画づくり」と「どんぶり勘定」は別物であるということを、本書を通じて感じることが出来ました。

22章の「なぜアジャイルな計画づくりがうまくいくのか」もお気に入りの章であり、この本の全てであるとも言えるかも知れません。

「ドキュメントはいらない」「計画は立てない」という2大アジャイル勘違いの1つに対して、真摯に向き合った1冊でした。