# バーンダウンチャート ## 定義 バーンダウンチャート(burndown chart)は、プロジェクトの残作業量をイテレーションの経過とともに可視化するグラフである。リリースバーンダウンチャートの場合、縦軸はプロジェクト全体の残ストーリーポイント(または残ストーリーの理想日数)、横軸はイテレーション数であり、各イテレーション開始時点での残作業量を示す。このグラフが表現しているのはチームの正味進捗(net progress)、すなわち実際に完了させた作業量からリリースに向けて増加した作業量を引いた値であり、単に「作業を完了させた量」だけを示すものではない。残作業が一時的に増えることを「バーンアップ(burn up)」と呼ぶ。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §2) > [!note] 本ページは19章「リリース計画のモニタリング」が扱う**リリース単位**のバーンダウンチャート(折れ線グラフ版・棒グラフ版)とパーキングロットチャートを軸に立てている。イテレーション内(タスク単位・日次)のバーンダウンチャートは20章「イテレーション計画のモニタリング」の担当範囲であり、別節として本ページに後から積み増される。 ## リリースバーンダウンチャート(折れ線グラフ版) 縦軸(残ポイント)と横軸(イテレーション数)の折れ線グラフで、各イテレーション開始時点の残作業量をプロットする。理想的には計画どおりのベロシティで残ポイントが一定のペースで減少していく直線になる(図19.2、240ポイントのプロジェクトが8イテレーションで完了する例)。しかし現実のプロジェクトでは、再見積りによる残りのストーリーの規模の変化や、リリースに含めるスコープの拡大によって、途中のイテレーションで残ポイントが一時的に増える「バーンアップ」が起こりうる(図19.3、同じ240ポイントのプロジェクトの第3イテレーション完了時点の例)。折れ線グラフ版は理解も説明も容易で、縦軸の目標点(例: 240ポイント)と現在の残ポイントを直線で結び右へ延ばすことで、現在の傾向を維持した場合の完了見込み時期をひと目で読み取れる。ただしこの見込みは、現在の状況がそのまま続くことを前提にしている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §2) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch19-fig19.3-realistic-burndown.png]] (図19.3 240ポイントのプロジェクトの、もっと現実的なバーンダウンチャート。第3イテレーション完了時点。Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §2) ## リリースバーンダウン棒グラフ:ベロシティとスコープの分離 折れ線グラフ版は「完了した作業量」と「スコープの変化」を1本の線に合成してしまうため、バーンアップが起きたときにその原因(進捗の遅れなのか、スコープの拡大なのか)を1枚のグラフからは切り分けられない。この弱点に対する派生形が棒グラフ版のリリースバーンダウンチャートである(図19.4)。垂直の棒の**上端**の伸び縮みでチームのベロシティによる進捗、**下端**の伸び縮み(作業が追加されれば下端が負の方向に伸び、取り除かれれば正の方向に縮む)でスコープの増減を、それぞれ独立に表現する。実在するプロジェクトの例(図19.5)では、再見積りによって棒の上端が伸びる場面と、フィーチャが削られて下端が縮む場面が同一のグラフ上で読み取れる。表現できる情報量は折れ線グラフ版より多いが、読み方は明快でなく、作業の増減を上端・下端のどちらに反映すべきかで組織内の合意が取れていないと使いこなせないため、著者は初めて一緒に仕事をするチームにはまず折れ線グラフ版を導入し、組織が十分成熟してから棒グラフ版へ移行するとしている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §2-1) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch19-fig19.4-velocity-and-scope.png]] (図19.4 ベロシティとスコープの変化を別々に表現する。棒の上端がチームの進捗、下端がスコープの増減をあらわす。Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §2-1) ## パーキングロットチャート:テーマ単位の別表現 バーンダウンチャート(折れ線・棒グラフいずれも)がプロジェクト全体の残作業量を1本のグラフで示すのに対し、ジェフ・デ・ルーカが提案したパーキングロットチャートは、リリースするテーマ(またはユーザーストーリーの論理的なまとまり)ごとに四角形を用意し、テーマ名・ストーリー数・ポイント合計・完了率(パーセンテージ)を記入する、まったく別の可視化手法である。多くの情報を小さな空間に圧縮でき、リリース中のすべてのテーマを1ページにまとめられる。ただし、どのテーマの完了率が何%かはわかっても、テーマ内のどのストーリーが具体的に完了しているかまでは読み取れない。四角形を色分けして、完了・順調・要注意・大幅遅延などの状態を一目でわかるようにする工夫もありうる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §3) ## イテレーションバーンダウンチャート:タスク単位・日次の別軸 20章「イテレーション計画のモニタリング」が扱うイテレーションバーンダウンチャートは、縦軸に**残作業の合計時間**(タスクの残り所要時間の合計)、横軸に**イテレーションの何日目か**を取る折れ線グラフである。縦軸がストーリーポイント(または残ストーリーの理想日数)、横軸がイテレーション数であるリリースバーンダウンチャート(上述)とは、縦軸の単位(時間 対 ポイント/理想日)と横軸の刻み幅(日 対 イテレーション)の両方が異なる。データの出所も異なり、リリースバーンダウンチャートが各イテレーション終了時のベロシティ(オール・オア・ナッシングで確定したストーリーポイント)から作られるのに対し、イテレーションバーンダウンチャートは[[タスクボード]]の最終列(各ストーリー行の残りタスク時間の合計)を毎朝集計した値から作られる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] §1, §2) ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch20-fig20.2-iteration-burndown.png]] (図20.2 イテレーションバーンダウンチャート。縦軸は時間(残作業の合計)、横軸は日。Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] §2) 20章は、イテレーションバーンダウンチャートの利用そのものに留保を付けている。イテレーション長が1週間の場合はほぼ不要であり、理由は進捗の傾向がグラフ上に現れる頃にはイテレーションが終わっているからだとされる。著者の経験では、イテレーション長が2週間より長い場合に非常に便利になる。したがって本チャートはあらゆるイテレーション長で一律に有用なツールではなく、イテレーション長に応じて採否を判断すべきものとして位置づけられている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] §2) 20章はさらに、イテレーションバーンダウンチャートと隣接するが別の実践として、タスクの投入工数の**実績**と見積りを比較する運用には否定的な立場を取る。理由は、比較が見積り担当者に「評価への不安」を招き、不安が「逃走・闘争反応」を誘発して分析的でなく直感的な見積りに陥りやすくなるためであり、大抵の場合はリスクと手間が利点を上回るとまとめている。イテレーションバーンダウンチャート自体が集計するのは「残りの見積り時間」であって「投入済みの実績時間」ではない点に注意が必要である。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] §3, まとめ) ## 横断的知見 - リリースバーンダウンチャート(19章)とイテレーションバーンダウンチャート(20章)は「バーンダウン」という同じ名前と折れ線グラフという同じ見た目を共有するが、縦軸の単位が異なる(ポイント/理想日 対 時間)うえに、拠って立つ完了判定の原則も異なる。リリースバーンダウンチャートはベロシティのオール・オア・ナッシング原則(完了したストーリーのポイントだけを加算し、部分的な完了は一切算入しない)の上に成り立つのに対し、イテレーションバーンダウンチャートはタスクボード上の残り見積り時間という連続的な量を毎日集計したものであり、部分的に進んだタスクの見積り減少もそのままグラフに反映される。両者は「残りを可視化する」という目的は共有しつつ、完了を離散的(ストーリー単位)に扱うか連続的(時間単位)に扱うかという設計思想の違いを持つ。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] §1, §2) - 19章はリリースバーンダウンチャートが導入するのに組織の成熟度を要する(棒グラフ版の場合)としつつ、リリース単位でのモニタリング自体には留保を付けていない。一方20章は、イテレーションバーンダウンチャートについて「イテレーション長が1週間ならほぼ不要」というイテレーション長に依存した採否条件を明示している。同じバーンダウンチャートという道具でも、対象の時間軸が長い(リリース、数ヶ月)ほど無条件に有用とされ、対象の時間軸が短い(イテレーション、数週間)ほど「そもそも使う価値があるか」から検討が必要になるという非対称性が、2つの章を並べて初めて見える。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §2-1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] §2) - 19章はバーンダウンチャートが表現する値を「正味進捗(実際に完了させた作業量からリリースに向けて増加した作業量を引いたもの)」と定義するにとどまり、この正味進捗の読み方を経営層にどう伝えるかまでは論じていない。23章のケーススタディはこれを実践する場面を示す: キャラクターフィーチャの追加(35ポイント)によって残ポイントが2イテレーション前とほぼ同じ133ポイントまで戻ったバーンダウンチャートを見て、代表取締役フィルは「2イテレーション経過したのに最初と同じに見える」と懸念を示した。プログラマのアランはこれに対し「リスクの高い部分は完了し、多くを学んだ。後退して見える点を打つことも、進んでいる証拠だ」と説明し、正味進捗上の一時的な後退を「学習の証拠」として語ることでステークホルダーの理解を得ている。19章が理論として述べた「正味進捗」という読み方が、23章では数字の後退を悲観材料にしないための語り口として運用されていることがわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §9) - 19章は棒グラフ版のバーンダウンチャートを、ベロシティとスコープの変化を分離できる点で折れ線グラフ版より表現力が高いと位置づけている。ところが23章のケーススタディで実際に経営層へ提示されたのは、傾向線を書き加えた折れ線グラフ版のリリースバーンダウンチャート(図23.5〜図23.8)であり、棒グラフ版は使われていない。フィルへの説明では、スコープ拡大による残ポイントの増加を口頭の語り(前項参照)で補っており、19章が挙げていた「棒グラフ版導入には組織の十分な成熟が要る」という条件が、23章のような比較的少人数・短期間のチームでは折れ線グラフ版+口頭説明という組み合わせで代替されている可能性を示唆する。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §2-1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §9) - 19章はリリースバーンダウンチャートを「進捗をモニタリングする手段」として導入するが、伝達先(誰に見せるか)までは踏み込まない。21章「計画とコミュニケーション」は同じグラフを明確にチーム外への伝達手段として位置づけ直し、「改めて書くまでもないが、リリースバーンダウンチャートが進捗を伝える最も重要なツールである」と述べる。23章のケーススタディはこの伝達を実演する: フランクとアランは2イテレーション分の実績をもとにしたリリースバーンダウンチャートを代表取締役フィルに提示し(図23.5〜図23.8)、キャラクターフィーチャの追加で残ポイントが増えて後退したように見える場面でも「後退して見える点を打つことも、進んでいる証拠だ」と口頭で補足しながらグラフを使って説明した。19章が定義した「モニタリングの道具」としてのバーンダウンチャートは、21章で「伝達の道具」へと役割が広がり、23章でその両立(モニタリングしながら経営層に説明する)が実例として示されている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 21 計画とコミュニケーション]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §9) ## 未解決の問い - 棒グラフ版バーンダウンチャートの導入可否を左右する「組織の成熟度」を、19章は具体的な基準(測定方法)として示していない。何をもって「揉めずに使いこなせる」と判断すればよいか。 - 傾向線(23章の実例、図23.6・図23.8)をバーンダウンチャートに引き始める妥当なタイミング(最低何イテレーション分の実績データが必要か)は、19章にも23章にも明示的な基準がない。 - パーキングロットチャートとリリースバーンダウンチャート(折れ線・棒グラフいずれも)を同一プロジェクトで併用する場合の使い分け・更新頻度の実例は原本に示されていない。 - 20章はイテレーション長が「1週間ならほぼ不要」「2週間より長いと非常に便利」と述べるが、ちょうど2週間の場合にイテレーションバーンダウンチャートを使うべきかどうかの判断は明示されていない。 - イテレーションバーンダウンチャートの残り時間が、タスクの再見積り(20章§1、見積りをいつでも見直してよいという原則)によって一時的に増える「バーンアップ」が起こりうるかどうか、20章は明言していない。リリースバーンダウンチャートのバーンアップ(19章§2)に相当する現象がイテレーション単位でも観察されるかは未確認。 ## 関連 - 概念: [[ベロシティ]](バーンダウンチャートの縦軸・横軸を構成する基礎量) / [[計画のコミュニケーション]](バーンダウンチャートを外部伝達に使う視点) / [[リリース計画づくり]](モニタリング対象となる計画そのもの) / [[イテレーション計画づくり]](イテレーションバーンダウンチャートがモニタリングする対象) / [[タスクボード]](イテレーションバーンダウンチャートの残り時間の集計元) - source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 21 計画とコミュニケーション]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] - 書籍: [[wiki/entities/アジャイルな見積りと計画づくり|アジャイルな見積りと計画づくり]] ## 出典 - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 19章・20章(主典拠)、21章・23章(横断的知見の突き合わせに使用)。