見積りの難しさ 〜「アジャイルな見積りと計画づくり」を読んで〜
お盆休みに会社から借りていたアジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～を読み返してみました。
本書は2009年に翻訳されて発売されて多くの書評記事で取り上げられています。
今回は私自身が抱えていた見積もりに対する課題と本書から得た学びを備忘録としてまとめたいと思います。
（※弊社の書籍購入制度については以下ブログもよんでみてください！）
エンジニア組織の書籍購入数が5.5倍になった話
はじめに：見積りの重要性と難しさ
見積もりという作業は、どんなプロジェクトでも避けて通れない課題です。職位や経験に関係なく、プロジェクトに携わるすべての人が直面する挑戦です。
しかし、まだ行なっていない作業について、具体的な規模や期間を想像して正確に見積もることは、簡単なことではありません。
自身の経験としても、たとえば、初期の概算見積りから大幅にずれが生じたり、計画がマイルストーン中心となってしまい直近のチームメンバーのモチベーションが低下することがありました。
この経験から、私は見積もりの精度を高めることがプロジェクトの成功に直結する重要な要素であることを痛感しました。最近、以下に挙げたような見積もりに関する記事を目にする機会があり、改めて見積もりの技術や考え方について学び直す必要性を感じました。
また最近以下のような見積もりに関する興味深い記事を拝見する機会があったので、改めて見積もり関して興味を持ち、再度こちらの本を読み直してみようと思いました。
（対象記事は工数見積もりを行わない開発をどのように行っているかの記事内容となっています）
参考
「アジャイルな見積りと計画づくり」の構成
本書は7部構成となっています。それぞれの部で、アジャイルにおける見積りや計画の立て方が詳しく説明されています。
簡単に全体の構成概要を紹介します。
- 第1部 問題とゴール
- 第2部 規模を見積もる
- 第3部 価値のための計画づくり
- 第4部 スケジュールを立てる
- 第5部 トラッキングと情報共有
- 第6部 なぜアジャイルな計画づくりがうまくいくのか
- 第7部 ケーススタディ
第1部 問題とゴール
この部では、見積りと計画づくりがなぜ難しいのか、そしてそれを克服するためにアジャイルなアプローチがどのように役立つかを説明しています。アジャイルの目的は、変化に対応しながらも価値を最大化することであり、そのための問題意識と目標設定が重要であることを強調しています。
見積もりと計画づくり
見積もりにおいては、不確実性コーンという有名な図があります。（本書の第1章でも触れられています）
上記の図を一目見てわかる通り、プロダクトスケジュールの初期コンセプト時点では見積もりの幅が非常に大きいことがわかります。
この図は「初期段階での見積り幅に誤差が生じるのは仕方がない」ということを示すためによく使われますが、もっと重要なことはプロジェクトが進むにつれて見積りが精緻化されることです。
プロジェクトが進むにつれてより正確に見積もれるようになる。こうして見積もりが徐々に調整されていく様子を示すのが不確実性コーンである。（p35）
本書では「よい計画づくり」を以下のような特徴を持ったプロセスと定義しています。
- リスクを軽減する
- 不確実性を減らす
- 意思決定を支援する
- 信頼を確立する
- 情報を伝達する
とくに、「計画」と「計画づくり（planning）」を明確に区別している点が印象的でした。
計画とはドキュメントや図表であり、ある地点でのスナップショットを記録したものだ（p33）
アジャイルな計画づくりでは、計画そのものよりも、その過程を重視しています。計画は変更されるものであり、変更が起きることは学びがあった証拠です。
立てた計画はじきに見直され破棄されてしまう。しかし、計画づくりの過程で得た知識や洞察はずっと後まで残る。（p34）
本書が主張しているプロダクトを成長させるために計画「づくり」を継続していくという考え方は、個人的にも良い考え方だなと思いました。
第2部 規模を見積もる
この部では、プロジェクトの規模をどのように見積もるかについて詳しく解説されています。
本書では、規模の見積もりと期間の見積もりを明確に区別する重要性が何度も強調されています。
期間から見積もるのではなく、規模を見積りその結果から期間を推定する 方法について知ることができました。
規模の見積もりを行う方法としては、ストーリーポイントと理想日を用いた方法が紹介されています。
アジャイルやスクラム開発を行っている方についてはストーリーポイントでの見積もりは馴染み深いものなのかと思います。
（著者の方もストーリ−ポイントでの見積もりを推奨）
第3部 価値のための計画づくり
この部では、プロジェクトでどの機能やタスクに優先順位をつけるべきかを考えるための手法が紹介されています。
アジャイルでは、価値を最大化するために、優先順位を適切につけることが重要です。どのように価値を評価し、計画に反映させるかについての具体的なアプローチが示されています。
こちらの章についてはざっと流し読みをした程度なのですが、優先度付けの具体的な手法が紹介されています。
複数の優先度付けの手法が載っており参考になったのですが、もう少しプロダクト特性に合った手法決めのような内容についてまとまっている内容が知ることができたらなと感じました。
第4部 スケジュールを立てる
この部では、リリース計画やイテレーションごとのスケジュールを立てる方法が紹介されています。リリースとイテレーションは異なるスパンで計画されるべきであり、それぞれに適したスケジュール策定の手法が説明されています。計画を立てる際のポイントや注意点が整理されています。
個人的に現在課題感を感じており、集中して読んだのはこの部でした。
印象に残った内容については次のセクションに記載しています。
第5部 トラッキングと情報共有
この部では、策定したアジャイルな計画をどのように追跡し、ステークホルダーに適切に共有するかがまとめられています。計画が進行する中で、情報の透明性を保ちつつ、進捗を効果的にトラッキングするためのツールや方法が具体的に紹介されています。
こちらについても個人的に課題感を感じている箇所であったため、興味深く読まさせていただきました。進捗状況の情報共有は個人的にも課題と感じていた箇所でした。
具体的な手法としては、バーンダウンチャートやベロシティレポートなどのアジャイルで良く利用されるレポートが紹介されています。
個人的には次の章にも記載している「イテレーション終了報告書」の作成が印象的でした。
第6部 なぜアジャイルな計画づくりがうまくいくのか
この部は一章のみで構成されており、第2章で説明された「通常の計画づくりがうまくいかない理由」と対比しながら、アジャイルな計画づくりが成功する理由を解説しています。
この章をチェックリストとして活用することで、自分たちの計画がアジャイルなプロセスに沿っているかどうかを確認できる内容となっています。
第7部 ケーススタディ
この部では、小説仕立てで具体的なプロジェクト開発が描かれ、これまでの章で紹介された理論や手法がどのように実践されるかが示されています。
実際のケースに即した解説が加わることで、理論がどのように現場で活かされるのかが理解しやすくなっています。
個人的に記憶に残った箇所
ここからは本書を読んで、とくに個人的に記憶に残った箇所を記載していこうと思います。
スパイク (14章 イテレーション計画づくり)
調査用タスクの名前を「スパイク」と呼ぶことを、本書ではじめて知りました。
個人的にも技術調査をどのような建て付けで行うかは悩むこともあったので、以下のブログ記事が参考になりました。
（5. スパイクをプロダクトバックログに入れるか、それともバッファのなかで行うか）
参考
スクラムにおける技術的スパイクの進め方 | Ryuzee.com
コミットメント駆動のイテレーションプランニング (14章 イテレーション計画づくり)
イテレーションの計画には、主に2つのアプローチが紹介されています。
過去の実績からタスク量を決定する「ベロシティ駆動プランニング」と、チーム全体で合意できる範囲でタスクを設定する「コミットメント駆動プランニング」です。
一般的には「ベロシティ駆動」が広く採用されていますが、著者は「コミットメント駆動」を推奨しています。
これは、ベロシティが概算であり、実際のイテレーション中に消化しきれないチケットが生じる可能性があるためです。
リリース計画にはベロシティが適していますが、イテレーション計画には、チームがコミットできる範囲で計画を立てる方が現実的である旨が述べられていました。
プロジェクトの特性やチームの成熟度に依る部分もあるとはいえ、このような複数のプランニング方法があるということは大きな学びでした。
プロジェクトバッファ (17章 不確実性に備えるバッファの計画)
プロジェクトのバッファについて、いつもどの程度のバッファを積めばいいのかが悩みの種でした。
これまでは、過去に経験していたプロジェクトを参考にしたり、リスク要素を洗い出してどれくらいの大きさになりそうかなど、どちらかというと経験ベースの決め方をしており何となくモヤっとしてしまっていることが多かったです。
そのような中で本書では二乗和平方根法を使ったバッファ計画がオススメの具体的な手法として紹介されていました。
参考のQitaの記事がまとまっており、分かりやすかったです。計算内容とともに納得感を持って理解することができました。
参考
[スケジュールに乗せるバッファはどれぐらいが適切か？ - 二乗和平方根法（SRSS法）
ガントチャート (21章 計画とコミュニケーション)
ガントチャートは、ウォーターフォール型のプロジェクト管理でよく使われるツールであり、固定的なスケジュール管理が求められるため、アジャイルには不向きだとされています。
しかし、イテレーションの進捗状況を可視化するためには、ガントチャートも有効に活用できる場面があるという紹介がされていました。
とくに、ユーザーストーリーの進捗を管理する際には、ガントチャートが役立つと本書では推奨されています。
以下のポイントに注意することで、アジャイルプロジェクトでも効果的にガントチャートを活用できます。
- ガントチャートは、イテレーション期間ごとにユーザーストーリー単位で管理すること。
- 担当者をガントチャートに割り振らないこと。
アジャイル開発とガントチャートの相性は個人的にも良くないと思っていたので、上記のようなアプローチを通じてうまくツールとして活用していければと思いました。
Jiraのタイムライン機能も本書に記載していた内容
イテレーション終了報告書 (21章 計画とコミュニケーション)
イテレーション終了報告書は、チームの進捗状況をまとめ、ステークホルダーに最新情報を伝えるための重要なツールです。
この報告書には、日程、要員、指標、実施内容、評価などが記載され、プロジェクトの透明性を高める役割を果たします。
著者は、この報告書の作成は必須ではないが、作成することでステークホルダーとの信頼関係を強化できると述べています。
さらに、週あたり15分程度の時間で作成可能であるため、負担なく導入できる点も魅力的だと思います。
この手軽さからイテレーションの振り返りとともに報告書の作成を取り入れて、チームとステークホルダーの間でより効果的なコミュニケーションを図れるような活用ができたらと考えています。
まとめと今後への活かし方について
本記事では、『アジャイルな見積りと計画づくり』を通じて、プロジェクト管理における見積りの重要性やその難しさ、そしてアジャイルなアプローチの利点を再確認しました。
とくに印象的だったのは、計画そのものではなく、計画づくりの過程を重視する姿勢です。このアプローチは、変化に柔軟に対応し、チーム全体の価値を最大化するための強力なツールとなると感じました。
本書を読む前に、帯に記載のある「見積もりと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない」という言葉を見て印象に残っていました。
そして本書を読み終えた後、訳者あとがきで「見積もりと計画づくりをアジャイルに」しさえすればプロジェクトがアジャイルになるわけではないと、逆は成り立たないよという旨の内容が述べられています。
その上でプロジェクトを進めるために大事なことは、技術とビジネスの調和と記載がありました。
重要なのは、技術とビジネスの調和です。開発者には見積もりを出す権利がある一方で、進捗を誠実で透明性のある形で報告する義務があります。顧客やプロダクトオーナーには要求を出す権利がありますが、リリースやイテレーションに収まらない場合には、優先順位を決定する義務もあります。
見積りと計画づくりはまさに「チームが技術とビジネスの関心事項」を調和させるための場です。そしてアジャイルな見積もりと計画づくりは、これをプロジェクト期間全体を通じて繰り返すことで「調和を日常的に取れるように」する営みです。
プロジェクト管理は短期的な成果だけでなく、チームの成長を見据えた長期的な視野が必要です。
今回の学びを基に、次のチャレンジでもさらに精度の高い見積りと柔軟な計画づくりに挑戦し、チーム全体の成功を目指していきたいと思います！
Discussion
はじめまして。別にアジャイル開発じゃないはずの案件が、途中からアジャイルっぽくなっていくケースで最近悩まされていて、ふとこの記事にたどり着きました。
アジャイル開発に詳しくないからか、出だしの「自身の経験としても、たとえば、初期の概算見積りから大幅にずれが生じたり、計画がマイルストーン中心となってしまい直近のチームメンバーのモチベーションが低下することがありました。」のところで「？」となってしまいました。。
「計画がマイルストーン中心となってしまい」というのは良くないこと、なんでしょうか・・？
ともあれ、見積もりは本当に難しいですよね。
コメントありがとうございます！！
すいません、言葉足らずの記載となっていました。
記載の前提として、当時の開発手法としてアジャイル開発を行なっており、本書にも書いてある通りイテレーションごとのインクリメント（ユーザ価値）を提供するようにゴールを定めて開発を進めていました。
ただそのイテレーション目標が達成できなかった際に、振り返りであくまでマイルストーン（ビジネスサイドとのリリース合意時期）には影響がないから、、、という流れとなり、イテレーションの目標が形骸化したことには有耶無耶になったことに対してモヤモヤが発生した、という意図で記載していました。
（マイルストーンが目標であるならイテレーションを切って開発している意味とは？？となりました）
おっしゃる通り見積もりは難しく、だからこそ段階的に計画作りと見積もりを進めたいと思っているのですが、それも難しいなーと思っている所です。。笑