# リリース計画づくり ## 定義 ### リリース計画づくりとは リリースプランニング(release planning)は、1回のイテレーションよりも長い期間を対象とする、抽象度の高いリリース計画を立てる作業である。1回のリリースは典型的に期間3ヶ月〜6ヶ月、イテレーション3〜12回をこなす期間になり、具体的なリリース期間とイテレーション数はイテレーションの長さの選び方で変わる。リリース計画づくりは、(1)プロダクトオーナーとチームが何をどれだけの期間で開発するかを決断するために必要であり、(2)何をいつ開発できるかを組織に伝達する手段になり、(3)チームがイテレーションを繰り返す先の最終目標を示す道しるべになる、という3つの理由で重要とされる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] 冒頭 p.148) リリース計画そのものは、プロダクトオーナーとチームが選んだ、プロジェクトで開発するユーザーストーリーの簡単な一覧である。予定イテレーション数にチームのベロシティを掛けて総作業量の上限を求め、その上限を超えないように価値の高いユーザーストーリーから優先順位を付けて選ぶ。この段階では、ユーザーストーリーやタスクへの開発担当者の割り当てや作業順序は決めない。誰がどの順番で作業するかは実際に作業する人ができるだけ遅く決めるのが望ましく、ユーザーストーリーのタスクへの分解はイテレーション開始時点でおこなう。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §1) ### 標準手順(図13.1) リリースプランニングの典型的な手順は、以下の6ステップで構成される。「イテレーションの長さを決める」はどの順序で実施してもよいとされ、全体はリリースの満足条件を満たすまでイテレーションを繰り返すループとして進む。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §1, 図13.1) 1. 満足条件を決める 2. ユーザーストーリーを見積もる 3. イテレーションの長さを決める(どの順序でもよい) 4. ベロシティを見積もる 5. ユーザーストーリーに優先順位を付ける 6. ストーリーを選択し、リリース日を決める ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch13-fig13.1-release-planning-steps.png]] (図13.1 リリースプランニングの手順。Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §1, 図13.1) 満足条件(conditions of satisfaction)は、プロジェクトの成功・失敗を決める評価条件であり、ほとんどのプロジェクトではスケジュール・スコープ・リソースの三種の神器で表現されたゴールの組み合わせになる。プロダクトオーナーはリリース計画ミーティングのたびに、これら3要素それぞれの理想的な目標を提示する。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §1-1) ### 日付主導とフィーチャ主導 満足条件の3要素(スケジュール・スコープ・リソース)に目標が設定されていても、大抵の場合は特に重要な要素が1つに絞られ、プロジェクトは日付かフィーチャのいずれかに主導される。 - **日付主導のプロジェクト(date-driven project)**: 特定の日付には絶対にリリースしなければならないが、どのフィーチャを含めるかは調整できる。 - **フィーチャ主導のプロジェクト(feature-driven project)**: リリースは早いに越したことはないが、それよりも特定のフィーチャ一式が完成していることのほうが重要である。 フィーチャ主導のプロジェクトでは、必要なフィーチャすべての見積りを合計し期待されるベロシティで割ることで、必要なイテレーション数を求める。日付主導のプロジェクトでは、カレンダーからこなせるイテレーション数が先に決まり、そこに期待されるベロシティを掛けてリリースに含められるストーリーポイント(または理想日)の合計を求め、優先順位に従ってポイントを割り振っていく。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §1-1, §1-6) ### 更新の粒度とタイミング リリース計画は一度立てて棚にしまいこむものではなく、定期的な見直しと更新が必須である。開発チームのベロシティがほぼ一定で、イテレーションプランニングでも驚きがないなら、4週間から6週間は公式に更新しなくてもよい。とはいえ、多くのプロジェクトはイテレーション終了時点でリリース計画を見直すルールを定めており、それで成果をあげている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §2) リリース計画をどこまで詳細にするか(全イテレーションへのフィーチャ割り振りまで事前に決めるか、全体の開発内容だけを決めておくか)もチームの合意事項である。事前に詳細化すれば複数チーム間の作業分担に役立つが時間がかかり、また各イテレーション開始時点のほうがリリースプランニング時点より情報が多い。最初の3回程度のイテレーションだけ事前にフィーチャを割り振り、残りはひとまとめにしておく折衷案が実務上の落としどころとされる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §1-6) ## 横断的知見 - [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]]は、アジャイルな計画づくりが「プロジェクトの全期間に均等に分散させておこなうものであり、リリースプランニングを土台に複数のイテレーションプランニングが繰り返される」と抽象的に位置づけるにとどまり、リリースプランニング自体の具体的な手順は示していない。[[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]]はこの「土台」を図13.1の6ステップとして具体化し、1章が述べた「計画づくりは繰り返される」という原則を、「リリースの満足条件を満たすまでイテレーションを繰り返す」という具体的なループとして裏づけている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]], [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]]) - 表14.2([[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]])は、リリース計画とイテレーション計画を「水平線」「構成要素」「見積り単位」の3点で体系的に対比する: リリース計画は3〜6ヶ月先までを見通しユーザーストーリーをストーリーポイントまたは理想日で見積もるのに対し、イテレーション計画は1〜4週間先までを見通しタスクを理想時間で見積もる。この対比は、[[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]]が単独では明示していない「なぜリリース計画のユーザーストーリーは抽象的な単位(ポイント/理想日)のままでよいのか」を補完する: イテレーション計画の段階でストーリーをタスクに分解し尽くすまでは、チームがそのストーリーを深く理解しているとは言えず、細かい見積り単位(時間)を使っても信頼できないためである。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]], [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]]) - リリース計画は「ユーザーストーリーやタスクへの開発担当者の割り当てや作業順序は決めない」(13章§1)。イテレーション計画も「タスクに担当者を割り当てない。担当者がタスクにサインアップするのはイテレーションが始まってから」(14章§1)。両章を通じて、著者は計画の各段階で「誰が・いつ」という実行の詳細確定をできるだけ遅らせるという原則を一貫して採用していることがわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]], [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]]) - 13章は「1回のリリースは典型的に期間3ヶ月〜6ヶ月、イテレーション3〜12回をこなす期間になる」と述べるのみで、なぜこの範囲が典型的なのかは説明しない。15章「イテレーションの長さを決める」§1-1は、この背後にある理由を補完する: リリースまでの期間が短すぎると、イテレーション終了時に得られるフィードバック・進捗測定・軌道修正のチャンスが不足するため、著者はプロジェクト期間中に少なくとも4、5回のチャンスを確保する目安を示す。13章の「予定イテレーション数」は、リリース期間をこの目安が満たせるだけのイテレーション数に分割した結果であり、13章単独では暗黙の前提だった「なぜこの期間・回数が典型的か」を15章が具体的な根拠(フィードバック機会の確保)として与えている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] 冒頭 p.148, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1-1) - 13章はリリース計画を「予定イテレーション数にベロシティを掛けて総作業量の上限を求める」計算として示すが、そのベロシティ自体がどれだけ不確実かは13章単独では論じていない。16章「ベロシティの見積り」の図16.1(不確実性コーン)は、プロジェクトの進行段階(初期のプロダクト定義〜検収されたソフトウェア)に応じてスケジュール見積りが当初予測の60%〜160%から徐々に狭まっていくことを示しており、これは「予定イテレーション数×ベロシティ」というリリース計画の総作業量そのものが、プロジェクト初期ほど大きな幅を持つ暫定値でしかないことの根拠になっている。13章が示す「4〜6週間は公式に更新しなくてもよい」という運用も、この幅がイテレーションを重ねるごとに(表16.1の係数のとおり)狭まっていくことを前提にしていると読める。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §1, §2, 図16.1, 表16.1) - 13章は「ストーリーを選択し、リリース日を決める」(手順6)までを標準手順として示すが、決めた計画をどう追跡し続けるかは13章単独では扱わない。19章「リリース計画のモニタリング」はこの続きを、ベロシティ・スコープの変化・再見積りという3要因を[[バーンダウンチャート]](正味進捗を示す折れ線・棒グラフ)で追跡する方法として具体化する。リリースバーンダウンチャートは定義上「イテレーション開始時点での残作業量を示すグラフ」であり、13章が「4〜6週間は公式に更新しなくてもよい」(§2)としていた粒度よりも細かい、イテレーションごとの観測点を前提にしている。19章は13章が明示しなかった「更新の合間に何を継続監視しておくべきか」という具体的な観測対象(完了作業量・スコープ変化・再見積り)を補っている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §1, §2) - 13章はリリース計画を「予定イテレーション数にベロシティを掛けて総作業量の上限を求める」一度きりの計算として説明するが、23章のケーススタディはこの計算がリリース期間中に複数回更新される様子を示す。初期見積り(6〜10イテレーション、12〜20週間)は、第1イテレーション終了時のベロシティ確定(§6)、キャラクターフィーチャの追加(§8)、傾向線を反映した経営層向けの再提示(§9)と、少なくとも3回組み直されている。これは13章が「ずれをどう扱うか」を抽象的にしか述べていなかった部分の実例であり、リリース計画のずれは1回の修正で解消するものではなく、モニタリングのたびに計画そのものを更新し続ける反復プロセスであることを示している。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §4-2, §6, §8, §9) - 13章は満足条件の3要素(スケジュール・スコープ・リソース)を計画時点で提示するものと位置づけるが、実績の追跡局面ではスコープの側だけを可変な調整弁として扱う運用が23章に見られる。ケーススタディでは、削っても構わない優先順位の低いストーリー(17〜22ポイント分)をあらかじめ合意しておき、スケジュール(日付)を守るためにスコープを削る形のバッファとして機能させている。これは17章が扱う時間的なバッファとは異なる種類の「予定と実績のずれ」への備え方であり、13章の満足条件の枠組みのなかで、モニタリング局面ではスコープが可変・日付が固定という日付主導プロジェクトの運用が具体的にどう回るかを示す実例である。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §1-1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §8) - 13章の標準手順(図13.1)は「ユーザーストーリーを見積もる」「ベロシティを見積もる」を独立したステップとして示すのみで、両者を掛け合わせた総作業量の上限そのものが持つ不確実性には立ち入らない。17章「不確実性に備えるバッファの計画」は、この総作業量の見積りに対して不確実性の高いプロジェクトでどう安全余裕を持たせるかを具体化する: フィーチャバッファは13章の「優先順位に従ってポイントを割り振っていく」(§1-1)手順そのものに、最低限セットの25〜40%相当のオプションフィーチャを追加するという形で組み込まれ、スケジュールバッファは13章が前提とする「予定イテレーション数×ベロシティ」の総量計算に対し、個々のユーザーストーリーの50%見積り・90%見積りの差から求めた安全余裕(二乗和平方根法)を上乗せする形で組み込まれる。13章単独では「上限を超えないように」としか述べられていなかった選定基準に、17章は不確実性に応じた具体的な余裕の持たせ方を与えている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §1, §1-1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §1, §2-2) - 17章のスケジュールバッファのガイドライン(見積り対象が10ストーリー未満ならバッファを用意すべきでない、バッファはプロジェクト期間全体の20%以上)は、13章が典型例とする「1回のリリースはイテレーション3〜12回」という規模のプロジェクトであれば、多くの場合ストーリー数の条件を満たす。ただし13章はこの前提を明示しておらず、17章のガイドラインがどのリリース規模から適用可能になるかは、両章を突き合わせて初めて見える暗黙の整合である。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] 冒頭 p.148, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-4) - 13章は「複数チーム間の作業分担に役立つ」という理由でリリース計画の事前詳細化(最初の3イテレーション程度)に触れるが、これが複数チームの場合に具体的にどう変わるかは述べない(§1-6)。18章「複数チーム編成プロジェクトの計画づくり」はこの空白を埋め、複数チームが連携する場合はリリース計画を2〜3イテレーションごとに更新する「移動する先読み範囲(rolling lookahead window)」という技法として具体化する。さらに18章は、イテレーションをまたいだチーム間の作業の引き継ぎは、イテレーションの最中よりも完了時点でおこなうほうが安全だとし、13章単独では触れられていなかった「詳細化と更新のタイミング」を複数チームの文脈で補っている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] §1-6, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 18 複数チーム編成プロジェクトの計画づくり]] §3) ## 未解決の問い - 満足条件がスケジュール・スコープ・リソースの間で衝突し、日付主導ともフィーチャ主導とも言い切れない場合、リリース計画づくりの手順はどう調整すればよいか。 - リリース計画時点のストーリーポイント見積りは、イテレーション計画でタスクに分解された後の理想時間見積りとどれだけ整合するか。14章はポイントと時間の対応関係が固定的でないこと(図14.5・図14.6の分布)を示すのみで、この乖離がリリース計画側の見積り精度にどう跳ね返るかまでは論じていない。 - 13章の「4〜6週間は公式に更新しなくてもよい」という運用と、19章のバーンダウンチャートが前提とするイテレーションごとの観測点は、どちらを基準にリリース計画の公式な更新タイミングを決めるべきか。両者の使い分け基準は本ページの範囲では未解決。 - 17章のバッファ(フィーチャバッファ・スケジュールバッファ)をリリース計画の総作業量に組み込んだ後、そのバッファがどれだけ消費されたか(残っているか)を19章のモニタリング手法(バーンダウンチャート等)でどう可視化・追跡すべきかは、17章・19章のいずれも明示していない。バッファの計画と、その後の消費状況モニタリングの接続は本ページの範囲では未解決。詳細は [[プロジェクトバッファ]] の未解決の問いも参照。 ## 関連 - 概念: [[アジャイルな計画づくり]] / [[イテレーション計画づくり]] / [[イテレーションの長さ]] / [[プロジェクトバッファ]](リリース計画の総作業量に不確実性への安全余裕を組み込む手段) / [[複数チームのプロジェクト計画]](複数チームがリリース計画を共有する場合の追加テクニック) - 実体: [[SwimStats]] - 書籍: [[wiki/entities/アジャイルな見積りと計画づくり|アジャイルな見積りと計画づくり]] - source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 13 リリース計画づくりの基本]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 1 計画の目的]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 14 イテレーション計画づくり]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 18 複数チーム編成プロジェクトの計画づくり]] ## 出典 - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 1章・13章・14章・15章・16章・17章・18章.