累積フロー図（CFD）とは？アジャイル開発のボトルネックを可視化する手法

累積フロー図とは

累積フロー図（Cumulative Flow Diagram、以下CFD）とは、ワークフローの各状態（バックログ、進行中、完了など）にあるアイテム数の累積値を時系列で積み上げた面グラフです。カンバン方式の創始者デビッド・アンダーソンが提唱したもので、アジャイル開発やリーン生産のフロー管理において最も包括的な状態可視化ツールとされています。

CFDが優れているのは、1つのグラフからWIP（仕掛中の作業数）、リードタイム（着手から完了までの時間）、スループット（単位時間あたりの完了数）という3つの重要メトリクスを同時に読み取れる点です。これはリトルの法則（平均リードタイム = 平均WIP / 平均スループット）の視覚的な表現でもあります。

バーンダウンチャートが「残作業量の減少」を表現するのに対し、CFDは「作業の流れの全体像」を表現します。バーンダウンでは見えないボトルネックの位置、WIPの蓄積パターン、フローの安定性がCFDでは一目で把握できます。プロジェクトマネージャーやスクラムマスターにとって、日常的な意思決定に欠かせないダッシュボードツールです。

構成要素

面グラフの構造

CFDは横軸に時間、縦軸に累積アイテム数を取り、ワークフローの各状態を異なる色の帯として積み上げます。一般的には下から「完了」「進行中（開発中、レビュー中など）」「バックログ」の順に積み上げます。各帯の面積がその状態にあるアイテムの累積量を表します。

3つの基本メトリクスの読み方

WIP（Work in Progress）は、任意の時点における「進行中」帯の縦方向の幅として読み取れます。完了線とバックログ線の間の垂直距離が、その時点でシステム内にあるアイテム数です。

リードタイムは、任意のアイテム数レベルでの「進行中」帯の横方向の幅として読み取れます。バックログに入った時点から完了した時点までの水平距離が、そのアイテムのリードタイムに相当します。

スループットは、「完了」線の傾きとして読み取れます。完了線が急であれば高いスループット、緩やかであれば低いスループットを示します。

リトルの法則との関係

リトルの法則は、安定したシステムにおいて「平均リードタイム = 平均WIP / 平均スループット」が成立することを示します。CFDでは、帯の縦幅がWIP、傾きがスループット、横幅がリードタイムに対応するため、リトルの法則の関係をグラフ上で直観的に確認できます。WIPを減らせばリードタイムが短縮し、スループットが一定であればWIPとリードタイムは比例関係にあります。

実践的な使い方

ステップ1: ワークフローステージの定義

CFDの帯を構成するワークフローステージを定義します。最もシンプルな形は「バックログ」「進行中」「完了」の3段階ですが、実務ではより詳細な段階に分けることが有効です。たとえば「バックログ」「分析中」「開発中」「レビュー中」「テスト中」「完了」の6段階とすれば、どの段階でボトルネックが発生しているかを正確に特定できます。

ステップ2: データ収集と更新の自動化

CFDのデータは毎日（または各スプリントの終わり）に更新します。各ステージにあるアイテム数を記録し、累積値を算出します。JIRA、Azure DevOps、Trelloなどの主要プロジェクト管理ツールにはCFDの自動生成機能が搭載されています。手動で作成する場合はスプレッドシートで十分です。

ステップ3: パターンの分析と解釈

CFDの形状パターンから、ワークフローの健全性を診断します。理想的なCFDでは、各帯の幅がほぼ一定に保たれ、帯が平行に上昇していきます。帯の幅が広がっていく場合はWIPが増加している兆候であり、フローに問題が生じています。特定の帯だけが急速に広がる場合は、そのステージがボトルネックになっています。

ステップ4: 改善アクションの実行と効果検証

パターン分析の結果に基づいて改善アクションを実行し、CFDの変化で効果を検証します。WIP制限の導入・調整、ボトルネックステージへのリソース追加、プロセスの並列化、バッチサイズの縮小など、具体的な施策をCFDの変化と紐づけて評価します。

活用場面

スプリントレトロスペクティブ: CFDを使ってスプリント中のフローの問題を客観的データに基づいて議論し、改善策を導出します
WIP制限の最適化: 帯の幅の変動を観察しながら、各ステージのWIP制限値を段階的に調整します
リードタイム予測: 過去のCFDパターンから将来のリードタイムを確率的に予測し、デリバリーの期待値をステークホルダーに報告します
スケーリングの判断: スループットが需要に対して不足している場合の、チーム増員やプロセス改善の必要性を定量的に判断します
マネジメントレポーティング: 技術的な詳細を省きつつ、プロジェクトの健全性を経営層に視覚的に伝えるダッシュボードとして活用します

注意点

ワークフロー定義の不整合

チームメンバー間でワークフローステージの定義が異なると、CFDのデータ品質が低下します。「開発中」の定義が人によって異なれば、帯の幅は実態を反映しません。ステージの入口基準と出口基準（Definition of Ready / Definition of Done）を明文化しておくことが前提条件です。

大きなアイテムと小さなアイテムの混在

CFDはアイテム数をカウントするため、サイズが大きく異なるアイテムが混在すると解釈が難しくなります。1日で完了するバグ修正と2週間かかる新機能開発を同じ1アイテムとしてカウントすると、フローの実態が歪みます。アイテムのサイズを揃えるか、ストーリーポイントベースのCFDを併用することで対処できます。

CFDだけでの意思決定は危険

CFDはフローの状態を可視化するツールであり、なぜ問題が起きているかの原因分析には別のツールが必要です。ボトルネックの存在は分かっても、その原因がスキル不足なのか仕様の曖昧さなのか技術的負債なのかはCFDからは読み取れません。根本原因分析と組み合わせて使ってください。

まとめ

累積フロー図はアジャイル開発のワークフローをWIP・リードタイム・スループットの3つの視点で同時に可視化する面グラフです。帯の幅と傾きのパターンからボトルネックを特定し、改善アクションの効果を定量的に検証できます。フロー管理の基本ダッシュボードとして、カンバンやスクラムを実践するすべてのチームに推奨できるツールです。