# アジャイルな計画づくり ## 定義 ### 計画づくりとは何か 見積りと計画づくりは、プロジェクトの規模や影響度にかかわらずどんなソフトウェア開発プロジェクトにも欠かせず、計画は投資判断の根拠となる。計画は、プロジェクトに必要な人材の把握や、プロジェクトがユーザーの求めるフィーチャを提供できるかの確認にも役立つ。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] p.026) 計画づくりは単に期日やスケジュールを決定する作業にとどまらない。計画づくりとは、ソフトウェア開発全体にわたる問い、すなわち「なにをつくるべきか？」に対する適切な答えを探る試みであり、価値の探求そのものである。この答えには、いきなり最適解を出すのではなく、答えをゴールへ少しずつ近づけていくこと(インクリメンタルに)、そしてそれを繰り返すこと(イテレーティブに)の両方が求められる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] p.028) ### よい計画の条件 よい計画とは、ステークホルダーがそれを基に意思決定できるという意味で信頼できる計画である。何をもって信頼できる計画とするかは状況によって異なり、プロジェクトの初期段階と後期とでは求められる精度も変わる。計画が多少不正確であっても(たとえば6ヶ月の予定が7ヶ月になった程度)、プロジェクトの進行中に計画を定期的に更新していれば、その計画は有用であり続ける。逆に、6ヶ月の予定が実際には12ヶ月かかったなら、それはまずい計画だったということになる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] §2) よい計画づくりは、以下の5つの特徴を持つプロセスである。いずれも「ソフトウェア開発の問い」に対する答えを見つける手助けとなる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] p.029) 1. リスクを軽減する: 見積りや計画づくりの過程で潜在的な問題点が明らかになり、早い段階での対処や見積りへの反映が可能になる。 2. 不確実性を減らす: 計画づくりはプロダクトの新しい機能だけでなく、プロダクト・技術・チーム自身についての新しい知識も生み出す。この知識を継続的に取り込みながらプロダクトのあるべき姿を洗練させる。 3. 意思決定を支援する: 見積りと計画があってはじめて、プロジェクトを実施する価値があるか、複数の候補からどれを選ぶか、といったトレードオフの判断ができる。 4. 信頼を確立する: 約束どおりのフィーチャを安定して頻繁に提供し続けることで、開発者と顧客のあいだに信頼が培われる。信頼できる見積りは持続可能なペースでの開発を可能にし、それがコード品質を高め、見積りの信頼性をさらに高めるという好循環を生む。 5. 情報を伝達する: 計画は期待と可能性を伝達するものであり、フィーチャ・期日・コストを厳格に確約するものではない。単なる日付だけに落とし込むと、その日付を導き出した前提や期待が失われる。 ### アジャイルな計画づくりの特徴 本書が扱うのは、静的な成果物である「計画(plan)」ではなく、活動としての「計画づくり(planning)」である。計画とはある時点のスナップショットを記録したドキュメントや図表にすぎないが、計画づくりは活動であり、アジャイルな計画づくりが重視するのは計画そのものよりも、計画をつくる過程である。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] §3) アジャイルな計画づくりは、次の4点で定義される。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] §3) - 計画よりも計画づくりを重視する - 変化を促進する - 計画そのものは容易に変更できる - プロジェクト全体にわたって繰り返される アジャイルな計画づくりでは、プランニングに費やす労力・投資と、プロジェクトの最中に得られる知識とを天秤にかける。変更そのものに価値があるわけではなく、変更が起きるということは何かを学習したり過ちに気づいたりしたことを意味するからこそ、変更に積極的になる。計画の変更は必ずしも予定期日を動かすことを意味せず、フィーチャの実装取りやめや実現範囲の縮小、人員追加など、期日を守りながら計画を変更する方法は複数ある。プロジェクトの初期段階で全体の計画を詳細まで定義するのは不可能だという立場から、アジャイルな計画づくりはプロジェクトの全期間に均等に分散させておこなうものとされ、リリースプランニングを土台に複数のイテレーションプランニングが繰り返される。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] §3) ## 横断的知見 - 1章は「信頼できる計画」を、ステークホルダーが意思決定できる根拠として定義し、計画の不正確さそのものよりも定期的な更新によって計画が有用であり続けることを重視する。また「計画よりも計画づくりを重視し、計画そのものは容易に変更できるようにする」ことをアジャイルな計画づくりの定義に含めている。一方2章が挙げる活動ベースの計画の失敗機序(パーキンソンの法則による作業の遅延、遅れが後工程へ伝播すること、マルチタスク化の代償)はいずれも、計画を「一度立てたら動かさない確約」として扱うことに起因している。両章を並べると、1章が原則として掲げる「計画の可変性」が、2章の失敗機序に対する処方箋の位置にあることが見える。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] §2, §3, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 2 なぜ計画づくりに失敗するのか]] §1, §2) - 1章は、プロジェクトの進行にともなって見積り誤差の範囲が狭まっていく不確実性コーンを紹介し、初期段階の見積りには不確実性を反映すべきだと述べる。2章は、従来型の計画づくりがこの不確実性(プロダクトに関する不確実性と手法に関する不確実性の両方)を無視し、大抵のスケジュールを絶対に動かせない特定の日付として表現しがちであることを、5つの失敗理由の1つに数える。両章を合わせると、不確実性コーンは「なぜ見積りに幅を持たせるべきか」の理論的根拠であり、2章の指摘はその理論を無視した場合に実際に何が起きるかを示す実例になっている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] p.026-027, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 2 なぜ計画づくりに失敗するのか]] §4) - 1章は、計画とは「期待と可能性を伝達するものであり、フィーチャ・期日・コストを厳格に確約するものではない」と位置づける。2章は、この理念が現場で崩れる典型例として、見積りとコミットメントの混同(フィリップ・アーマーの議論)を挙げる。両章を合わせると、1章が理念として掲げる「情報伝達としての計画」が、2章では具体的にどのように裏切られるか(見積りの暗黙のコミットメント化)が対応づけられる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] §1-5, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 2 なぜ計画づくりに失敗するのか]] §5) - 3章はアジャイルチームに共通する5つの特徴(1つのチームとして働く・短いイテレーションで作業する・イテレーションごとに成果をあげる・ビジネス上の優先度を重視する・検査と適応)を挙げるが、個別の手法名(Scrum・XPなど)は登場しない。この5つの特徴のうち「イテレーションごとに成果をあげる」(タイムボックス化されたイテレーションの終了時点でリリース可能な状態を保つ)と「検査と適応」(直前のイテレーションで得た知識をもとに計画を調整する)は、1章が「不確実性を減らす」計画づくりの効能として挙げた「継続的に知識を取り込みながらプロダクトのあるべき姿を洗練させる」ことを、具体的な運用サイクルとして可能にしている。同時に、2章が指摘する失敗機序「不確実性の無視(スケジュールを絶対に動かせない日付として扱う)」に対しては、タイムボックスと検査・適応のサイクルが、計画を固定された確約ではなく一定周期で更新されるものとして扱う仕組みを提供する。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 2 なぜ計画づくりに失敗するのか]] §4, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 3 アジャイル手法]] §1-2, §1-3, §1-5) - 3章の「ビジネス上の優先度を重視する」という特徴は、独立したタスクの積み上げではなくユーザーにとって価値あるフィーチャ(ユーザーストーリー)を単位に開発を進め、フィーチャ間の技術的依存関係を極力なくすことで実現される。これは2章が挙げる失敗機序「活動ベースの計画づくり」(タスクの完了順序が固定され、遅延が後工程へ伝播する)への対処になっている。フィーチャの依存関係を減らすことで、あるフィーチャの遅れが他のフィーチャの着手を妨げにくくなり、1章が「意思決定を支援する」効能として挙げた、複数候補からの選択やトレードオフの判断がイテレーションを跨いでも成立しやすくなる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] p.029, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 2 なぜ計画づくりに失敗するのか]] §1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 3 アジャイル手法]] §1-4) - イントロダクションは、書名を「アジャイルプロジェクトの見積りと計画づくり」ではなく「アジャイルな見積りと計画づくり」とした理由として、見積りと計画づくりというプロセス自体をアジャイルに進めなければならず、見積りと計画づくりがアジャイルでないのにプロジェクトがアジャイルであることはありえないと述べる。これは1章が「計画よりも計画づくりを重視する」「計画そのものは容易に変更できる」と定義する、アジャイルな計画づくりの4点の言い換えであり、書名の選択そのものが1章の定義を要約する形になっている。両者を合わせると、本概念の核心(静的な成果物としての計画ではなく活動としての計画づくりを重視する立場)は、著者にとって章の中身だけでなく書名という書籍全体の枠組みの選択理由でもあったことがわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Introduction イントロダクション]] p.23, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] §3) - 総括にあたる22章は、アジャイルな計画の基準がタスクではなくフィーチャであることを、従来型の計画表現(ガントチャート・PERT図・WBS)がタスクに焦点を合わせる点と名指しで対比しながら明言する(§4)。これは2章が5つの失敗理由の1つとして挙げた「活動ベースの計画づくり」(タスクの完了順序が固定され、遅延が後工程へ伝播する)への直接の処方箋にあたり、本書が最終的に「計画の基準をタスクからフィーチャへ転換すること」をアジャイルな計画づくりが成功する中心的理由の1つとして総括していることを示す。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 22 なぜアジャイルな計画づくりがうまくいくのか]] §4, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 2 なぜ計画づくりに失敗するのか]] §1) - 22章は、従来型の計画手法の多くがフィーチャをプロジェクト開始時に固定できると誤って信じることを失敗の根本原因として名指しし、目標の不確実性(プロダクトの不確実性)と開発手法の不確実性の両方を認めることを成功理由の1つとして挙げる(§8)。これは、1章が理論的根拠として示した不確実性コーンと、2章が「不確実性の無視」として診断した失敗機序の両方を踏まえた、本書全体を通じた最終的な結論にあたる。両章を並べて浮かんだ「なぜ見積りに幅を持たせるべきか」という問いに対し、22章がその答えを閉じている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 22 なぜアジャイルな計画づくりがうまくいくのか]] §8, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] p.026-027, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 2 なぜ計画づくりに失敗するのか]] §4) - 22章が挙げる「チーム全体を対象にしたトラッキング」(§7)は、3章が挙げたアジャイルチームの特徴の1つ「1つのチームとして働く」を、進捗管理という具体的な運用面で裏づける。22章は、個人単位のトラッキングが「タスクを早く終わらせると見積りが甘いと責められ、期日まで完了報告を控える」という過少申告の問題を引き起こすと述べており、3章が定義として掲げた「1つのチームとして働く」がなぜ計画づくりの成功に寄与するのかを、22章が具体的な弊害の回避として説明する形になっている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 22 なぜアジャイルな計画づくりがうまくいくのか]] §7, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 3 アジャイル手法]]) - 22章はガイドライン11「ゆとりを残す」(チームメンバー全員の時間を100%使い切る計画を立てないこと)を提示している(§9)。これは、1章・2章を並べたときに立てた未解決の問い「2章が指摘するマルチタスク化の代償を避けるために、アジャイルな計画づくりはチームの稼働率をどう管理するのか」に対する、本書全体を通じた回答にあたる。稼働率に意図的な余裕を残すことが、2章が示した「マルチタスク化が生産性を低下させ完了日を遅らせる」という失敗機序への、計画づくり側の具体的な対処として位置づけられる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 22 なぜアジャイルな計画づくりがうまくいくのか]] §9, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 2 なぜ計画づくりに失敗するのか]]) > [!note] 3章は章題こそ「アジャイル手法」だが、本文は Scrum・エクストリームプログラミングなどの個別手法名を一切挙げず、「アジャイルチーム」の一般的な振る舞い(役割・タイムボックス・ユーザーストーリー・プランニング・オニオン・満足条件)を記述するにとどまる。本書は特定の手法の解説書ではなく、手法に依らない見積りと計画づくりの技法を扱う立場を取っている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 3 アジャイル手法]]) ## 未解決の問い - 22章のガイドライン12は複数チーム連携に「移動する先読み範囲」(18章)を使うことを示すのみで、「計画よりも計画づくりを重視する」という原則そのものが複数チーム編成の大規模プロジェクトでも無条件に成り立つのか、それとも追加の仕組みが必要かという問いには明示的に答えていない(18章の範囲)。 - 22章が総括する8つの理由・12のガイドラインは、次の23章のケーススタディ(ボムシェルタースタジオ)で実際にどう体現されるか。総括の章で列挙された理由が、単一の架空プロジェクトの記述の中でどこまで具体的に確認できるかは未検証。 ## 関連 - 概念: [[不確実性コーン]] / [[活動ベースの計画づくり]] / [[リリース計画づくり]] — 本概念が原則として述べる「リリースプランニングを土台に複数のイテレーションプランニングが繰り返される」(§3)の、リリースプランニング側の具体的な手順(満足条件・日付主導とフィーチャ主導・更新の粒度)はこちらの concept で扱う(13章以降)。/ [[プランニング・オニオン]] — 3章が示す、複数レベルの計画づくりの階層構造。/ [[満足条件]] — 3章が示す、リリースプランニングとイテレーションプランニングを駆動する要因。 - 実体: [[Mike Cohn]] - 書籍: [[wiki/entities/アジャイルな見積りと計画づくり|アジャイルな見積りと計画づくり]] - source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Introduction イントロダクション]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 2 なぜ計画づくりに失敗するのか]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 3 アジャイル手法]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 22 なぜアジャイルな計画づくりがうまくいくのか]] ## 出典 - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, イントロダクション. - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 1章. - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 2章. - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 3章. - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 22章.