ひとことで言うと#
カンバンボードの各列(待機中・開発中・レビュー中・完了)のアイテム数を毎日積み上げてグラフ化し、WIP(仕掛かり作業数)・リードタイム・スループットの3指標を一枚の図から読み取る分析手法。
押さえておきたい用語#
- WIP(Work In Progress)
- 現在進行中の作業アイテム数。CFDでは各ステータスの帯の縦幅として表示される。WIPが増えるとリードタイムも伸びる。
- リードタイム
- アイテムが「待機中」に入ってから「完了」になるまでの所要日数。CFDでは帯の横幅として読み取れる。
- スループット
- 一定期間に「完了」に到達したアイテム数。CFDでは「完了」の帯の傾きで表現される。
- ボトルネック
- フロー全体の中で処理速度が最も遅いステージ。CFDでは特定の帯だけが膨らんでいる箇所として可視化される。
累積フロー分析の全体像#
こんな悩みに効く#
- カンバンボードを使っているがフローの問題に気づけない
- 「なんとなく遅い」が数値で説明できない
- どのステージがボトルネックか可視化したい
- WIPの増加が全体の遅延にどう影響するか理解したい
基本の使い方#
具体例#
エンジニア8名のSaaS開発チーム。スプリントレビューで「完了した機能が少ない」と毎回指摘されていた。
CFDを2週間取ったところ、「In Review」の帯が日に日に膨らんでいることが判明。レビュー待ちのPRが常時8〜12件溜まっていた。
| 指標 | CFD導入前 | 対策後(4週間) |
|---|---|---|
| レビュー待ちの平均滞留 | 3.2日 | 0.8日 |
| スプリント完了ストーリー数 | 12本 | 19本 |
| リードタイム(中央値) | 8.5日 | 4.2日 |
対策として「午前中の最初の1時間はレビュー優先」というルールを導入。CFDのレビュー帯が薄くなり始めたのを全員で確認し、ルールが定着した。
従業員120名の精密部品メーカー。受注から出荷までのリードタイムが長く、顧客から納期短縮の要望が増えていた。
生産工程を「受注→設計→加工→検査→出荷」の5ステージでCFDを作成。1か月分のデータを分析したところ、「検査」の帯が他ステージの 2.5倍 の幅に膨らんでいた。
原因は検査装置が1台しかなく、加工が終わった部品が検査待ちで滞留していたこと。検査装置を1台追加(投資額 350万円)した結果、受注→出荷のリードタイムが 18日→12日 に短縮。年間の追加受注で投資回収は4か月で完了した。
ECサイトのカスタマーサポート(10名)。問い合わせ対応を「受付→一次対応→エスカレーション→解決」のカンバンで管理していたが、解決までの平均日数が伸び続けていた。
CFDを3週間作成したところ、「エスカレーション」帯が急速に膨らんでいた。技術チームへのエスカレーション案件が積み上がり、回答が戻ってくるまで平均 4.5日 かかっていたのが原因。
技術チームとの週次ミーティングに加え、「24時間以内に一次回答を返す」SLAを設定。CFDでエスカレーション帯の推移を毎日チームに共有した結果、平均解決日数は 6.8日→3.1日 に半減し、顧客満足度調査のスコアが 3.2→4.1(5点満点)に改善している。
やりがちな失敗パターン#
- データ収集を手動で始めて続かない ─ Jira・Trello・Notionなど自動でステータス数を取れるツールを使う。手動は3日で面倒になる
- ステータスが「To Do」と「Done」しかない ─ 中間ステータスがないとCFDで読み取れる情報が極端に少なくなる。最低4段階は設ける
- グラフを作るだけで分析しない ─ CFDは「帯の異常を見つけてアクションを起こす」までがセット。飾りのグラフにしない
- 帯の膨らみを見つけても対策しない ─ ボトルネックがわかったら即座にリソース配分を変える。次のスプリントまで放置しない
まとめ#
累積フロー分析(CFD)は、カンバンの各ステータスのアイテム数を日次で積み上げグラフ化し、WIP・リードタイム・スループットを一枚の図で読み取る手法。帯の膨らみがボトルネックを、横幅の拡大がリードタイムの悪化を示す。データ収集を自動化し、週次で帯のパターンを分析してアクションにつなげることが運用のポイント。