# プロジェクトバッファ ## 定義 プロジェクトバッファ(project buffer)は、見積り誤差を吸収するためにプロジェクトのスケジュールに組み込む余裕である。不確実性が高いプロジェクトや、見積りを外したときの代償が高くつくプロジェクトでは、バッファを組み込むことが適切なリスク管理戦略になる。バッファには、フィーチャの不確実性に備える**フィーチャバッファ(feature buffer)**と、期日の不確実性に備える**スケジュールバッファ(schedule buffer)**の2種類があり、これらを組み合わせて使うことも多い。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] p.202, §3) ## タスク完了時間の分布と50%見積り/90%見積り バッファが必要になる根拠は、タスクの完了時間が単一の値ではなく幅を持った分布であることにある。あるタスクの完了時間の分布を描くと、完了が早まることは稀だが遅れる理由はいくらでもあるため、分布の頂点(最も完了可能性が高い時間)であっても、その時点までに完了する可能性は50%に満たない。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-1, 図17.1) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch17-fig17.1-task-duration-distribution.png]] (図17.1 タスク完了までの時間の分布。Source: ch.17 §2-1) 見積りと計画づくりでは、ある日にちょうど完了する可能性(図17.1)よりも、その日までに完了する可能性の累積分布(図17.2)のほうが重要になる。この累積分布の考え方は、100人の同じスキル・経験を持つプログラマが同じ機能を開発した場合の完成日の日次集計(表17.1)によっても具体化されている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-1, 図17.2, 表17.1) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch17-fig17.2-cumulative-distribution.png]] (図17.2 完了時間の可能性の累積分布。Source: ch.17 §2-1) この分布の考え方を実務に落とすため、各タスクについて**50%見積り**(その時間より早く終わる確率・もっと長くかかる確率がそれぞれ50%となる見積り)と**90%見積り**(90%の確率で達成できるとコミットメントできる見積り)の2点見積りを出す。両者の差を「個別マージン」と呼ぶ。飛行機に乗るための移動を例にすると、鍵を探す・運転する・駐車する・チェックインする・保安検査を受けるという各タスクの50%見積り合計は1時間10分、90%見積り合計は2時間50分になる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-1, 図17.3) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch17-fig17.3-fifty-vs-ninety-estimate.png]] (図17.3 飛行機に乗るための50%見積りと90%見積り。Source: ch.17 §2-1) ## フィーチャバッファとスケジュールバッファ **フィーチャバッファ**は、顧客が選んだ必須フィーチャの見積り合計に、最低限セットの25〜40%相当のオプションフィーチャを追加する方式である。オプション分は必須フィーチャをすべて実現し終えてから、時間に余裕ができた場合にのみ開発する。この手順はDSDM(Dynamic Systems Development Method)のMoSCoWルール(必須・重要・有用・不要の4分類)と同じ効果を持ち、DSDMでは必須要求への工数割り当てを全体の70%以内に抑えることで30%相当のフィーチャバッファを設ける。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §1) **スケジュールバッファ**は、個々のタスクの個別マージンを取り除き、プロジェクト全体の締め切りに対してまとめてバッファを設定する方式である。個々のタスクの遅れではなく、手順が連なった全体としての遅れから守ることを目的とする。個別マージンを取り除きプロジェクトバッファをまとめて末尾に置くと、単に90%見積りを合計するより短いスケジュールで同程度の安全性が得られる。飛行機の例では、各タスクを50%見積りにしプロジェクトバッファ53分を加えると合計1時間58分となり、90%見積りの合計(2時間50分)より1時間近く短くなる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2, §2-1, 図17.4) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch17-fig17.4-project-buffer.png]] (図17.4 プロジェクト全体にバッファを適用する。Source: ch.17 §2-1) 個別マージンをプロジェクト全体のバッファへ移動することには、パーキンソンの法則(仕事は使える時間をすべて食いつぶす)や学生症候群(締め切り直前まで仕事に着手しない現象。出典: [[Eliyahu M. Goldratt]] *Critical Chain*, 1997)を避けやすくなるという利点もある。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-1) ## スケジュールバッファの算出(二乗和平方根法) プロジェクトバッファの大きさは、各ユーザーストーリーの50%見積りと90%見積りの差から求める。この差は2つの標準偏差にほぼ等しく、標準偏差は(wi − ai)÷2(wiは最悪ケース=90%見積り、aiは平均ケース=50%見積り)で表せる。プロジェクト全体を90%の確率で達成できるバッファにするには、各ストーリーの2点見積りの差を2乗し、その合計値の平方根を取ればよい。この算出法は**二乗和平方根法(SRSS法)**と呼ばれ、[[Donald G. Reinertsen]]・[[Robert C. Newbold]]・[[Lawrence P. Leach]]が提唱したものである。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-2) > [!example] 表17.2の算出例(原本の数値をそのまま引用) > 6つのユーザーストーリーの50%見積りの合計は17、90%見積りの合計は35であり、各ストーリーの(90%見積り−50%見積り)の2乗の合計は90になる。90の平方根は9.4であり、これを丸めたスケジュールバッファは9になる。プロジェクト全体の期間は50%見積りの合計にスケジュールバッファを加えた17+9=26となる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-2, 表17.2) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch17-tbl17.2-schedule-buffer-calculation.png]] (表17.2 6つのストーリーのプロジェクト全体のスケジュールバッファの算出。Source: ch.17 §2-2) スケジュールバッファの大きさに最も影響を与えるのは50%見積りと90%見積りの差が最大のストーリーであり、差がゼロのストーリーはバッファに何も影響を与えない。50%見積りと90%見積りの2点見積りを出せない場合は、すべてのストーリーを50%見積りで行い、その合計値の半分をバッファにする簡易な方法もあるが、個々のストーリーの不確実性の大きさを反映できない欠陥を持つ。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-2, §2-3) 二乗和平方根法がもっとも信頼できるのは、見積り対象が最低でも10以上のユーザーストーリー(またはフィーチャ)である場合であり、対象が10未満ならプロジェクトバッファを用意すべきではない。また、バッファの大きさはプロジェクト期間全体の少なくとも20%が必要であり、それより少ないとプロジェクトを守りきれない可能性がある。このガイドラインは[[Lawrence P. Leach]]の提唱による。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-4) ## バッファの取り扱いと伝え方 プロジェクトを様々な種類の不確実性から守るには、フィーチャバッファ(フィーチャの不確実性)とスケジュールバッファ(期日の不確実性)を組み合わせるのが望ましい。複数のバッファを使うと、それぞれのバッファは小さくなる傾向がある。図17.5の3プロジェクトは、スコープ固定・スケジュール交渉可能(a)、スケジュール固定・スコープ柔軟(b)、両方のバッファを備え納期と最低限のフィーチャの両方にコミットする(c)という違いを持つ。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §3, 図17.5) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch17-fig17.5-three-buffer-projects.png]] (図17.5 異なるバッファを使った3つのプロジェクト。Source: ch.17 §3) フィーチャバッファ・スケジュールバッファ以外に、実際にアサインする人数より多い予算枠を確保する**予算バッファ**もある。予算バッファは中規模から大規模プロジェクトでよく見られるが、小規模プロジェクトでは、(1)バッファ分をそのまま最初から使ったほうが生産性向上に直結する、(2)少人数への割合的なバッファは端数になり効果が薄い、という2つの理由からあまり見られない。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §3) スケジュールバッファは水増し(見積りに根拠なしに追加する時間)ではなく、個別マージンを取り除いた見積り合計に加えるプロジェクトの安全のための余裕である。バッファを加える際は、50%見積りと90%見積りによる2点見積り法か、50%見積りによる1点見積り法のいずれかを使うべきであり、悲観的な90%見積りにさらにバッファを加えるとスケジュールが長くなりすぎる。バッファの存在や算出方法を隠さず、全員がスケジュールに自信を持てるようにするためのものだと説明することが誤解を避ける鍵である。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §4, §5) ## 合流バッファ(feeding buffer) 合流バッファ(feeding buffer)は、複数チームが1つのプロジェクトに関わる場合に、あるチームの成果を受け取る別チームが確実に予定通り着手できるよう、成果を提供する側チームの作業に加える時間的余裕である。17章のフィーチャバッファ・スケジュールバッファがプロジェクト全体(または単一チーム)の見積り不確実性を対象にするのに対し、合流バッファはチーム間の受け渡しという特定の依存関係だけを保護する点で異なる。「移動する先読み範囲」による計画で複雑・頻繁なチーム間の相互依存に対応できない場合にはじめて検討する技法であり、追加前にまず依存関係そのものを減らせないか(担当チームの交換、成果物の一部だけを受け取っての着手可否)を検討する。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 18 複数チーム編成プロジェクトの計画づくり]] §4, §4-1) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch18-fig18.2-feeding-buffer.png]] (図18.2 合流バッファを追加する。チーム1のAPI開発の直後、全国記録に着手する前に合流バッファを挿入し、チーム2が第3イテレーション初日から確実に個人成績のストーリーに着手できるようにする。Source: ch.18 §4) 合流バッファの大きさを決めるにも17章のガイドラインが参考になるが、チーム間の依存関係が発生するのは通常一部のストーリー・フィーチャに限られるため、17章の二乗和平方根法(見積り対象が最低10ストーリー以上であることを前提とする)を採用するにはストーリー数が足りないことが多い。この場合は、依存関係の原因となるストーリーの大きさの一定割合をバッファの大きさとすればよく、1つの目安としてストーリーの大きさの50%をバッファにする考え方があるが、最終的な大きさはチームが判断する。合流バッファを1イテレーションより長くすることもできるが、有効に機能することは稀である。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 18 複数チーム編成プロジェクトの計画づくり]] §4-2) ## 横断的知見 - 17章のフィーチャバッファ・スケジュールバッファはいずれも「時間的な余裕」または「実現しなくてよいフィーチャの余裕」を事前に計画へ織り込む理論だが、23章のケーススタディはこれとは異なる第三の運用を実例として示す。プロジェクト後半、残ポイントの見積り更新に際して、優先順位の低いストーリー(17〜22ポイント分)を「削っても構わない候補」としてあらかじめ合意しておく運用が採られた。これは17章のフィーチャバッファ(最初から最低限セット+オプション分として計画に組み込む)とは異なり、既に計画済みのバックログの末尾から任意のタイミングで削れるスコープの余裕を確保する運用であり、17章の用語で言えば時間的バッファではなくスコープを削ることで納期を守る実質的なバッファとして機能した。17章はこの運用パターンを明示的には扱っていない。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §8, p.309-310) - 17章は「バッファの存在や算出方法を隠さず開示する」ことを運用上の注意として挙げるのみで具体例を示さないが、23章のケーススタディはこの原則が実践された様子を裏づける。フランクとアランは経営層への報告で、キャラクター追加によって残ポイントが増え「後退して見える」場面でも、その理由(リスクの高い部分は完了し多くを学んだ)を説明し、あらかじめ合意した削除候補ストーリーを外せば短縮できるという代替案もあわせて提示した。バッファやスコープの余裕を隠さず開示し、その根拠を伝えるという17章の運用指針が、23章では経営層との具体的な対話として現れている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §5, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §9, p.312-313) - 17章のフィーチャバッファ・スケジュールバッファは、いずれもプロジェクト(または単一チーム)内部の見積り誤差を吸収する目的で設計されているのに対し、18章の合流バッファは対象が異なる。守る単位が「1つのチームの見積り」から「チーム間の受け渡しタイミング」へ移り、バッファが吸収する不確実性の発生源も「タスクの完了時間のばらつき」から「他チームの作業が期日通り完了するかどうか」へ変わっている。18章はこの新しい種類のバッファを17章の延長として明示的に位置づけており(「合流バッファは17章で紹介したスケジュールバッファと似ている」)、バッファという概念が単一チームの不確実性対策から複数チーム間の調整手段へ一般化されていることがわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 18 複数チーム編成プロジェクトの計画づくり]] §4) - 17章は二乗和平方根法が使えない場合の簡易な代替として「すべてのストーリーを50%見積りでおこない、その合計値の半分をバッファにする」方法を挙げる(個々のストーリーの不確実性の大きさを反映できない欠陥付き、§2-3)。18章の合流バッファも、対象ストーリー数が少なく二乗和平方根法の前提(最低10ストーリー)を満たせない場合の代替として「ストーリーの大きさの50%」という目安を挙げている。算出の母数(17章はプロジェクト全体の50%見積り合計、18章は依存対象ストーリー個別の大きさ)は異なるが、両章とも統計的な手法が使えない小規模な見積り対象に対して「半分」という同じ比率に落ち着いている点は、原本が明示的に理論づけているわけではない偶然の一致として記録しておく価値がある。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-3, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 18 複数チーム編成プロジェクトの計画づくり]] §4-2) ## 未解決の問い - 23章の「削除候補ストーリー」によるスコープバッファは、17章のフィーチャバッファ(最初から最低限セット+オプション分として計画する形式)とどう理論的に整理できるか。両者は「削れるスコープを確保する」という点で似ているが、フィーチャバッファが計画時点で確定した固定量であるのに対し、23章の削除候補はプロジェクト途中で任意に選定・更新されている。この違いが持つ意味は17章・23章のいずれにも明示されていない。 - 二乗和平方根法(SRSS法)によるスケジュールバッファの算出は、ベロシティの不確実性(16章の不確実性コーン・表16.1)とどう関係するか、あるいは独立に扱うべきかは17章に明示がない。 - バッファの大きさをプロジェクト進行中(イテレーションを重ねるごと)にどう再算出・更新すべきかは17章では扱われていない。19章「リリース計画のモニタリング」の担当範囲になりうる。 - 合流バッファ・フィーチャバッファ・スケジュールバッファを同一プロジェクト内で併用する場合、バッファ同士が重複してプロジェクト全体を過剰に保守的にしてしまわないかは18章・17章のいずれにも明示がない。 - 合流バッファの「ストーリーの大きさの50%」という目安は、どのような条件下で妥当と判断できるかの定量的根拠が18章では示されていない。 ## 関連 - 概念: [[リリース計画づくり]](バッファはリリース計画の不確実性への備え) / [[ベロシティ]](バッファ加算後のポイント数をベロシティで割ってイテレーション数を求める) / [[複数チームのプロジェクト計画]](合流バッファを含む複数チーム編成プロジェクトの追加テクニック) - 実体: [[wiki/entities/アジャイルな見積りと計画づくり|アジャイルな見積りと計画づくり]] / [[Eliyahu M. Goldratt]] / [[Donald G. Reinertsen]] / [[Robert C. Newbold]] / [[Lawrence P. Leach]] - source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 18 複数チーム編成プロジェクトの計画づくり]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] ## 出典 - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 17章(主典拠)、18章・23章(横断的知見の突き合わせに使用)。