累積フロー分析(CFD)

英語名 Cumulative Flow Analysis
読み方 シーエフディー / ルイセキ フロー ブンセキ
難易度
所要時間 データ収集は日次5分 / 分析は週次30分
提唱者 リーン生産方式 / カンバンメソッド(David J. Anderson)
目次

ひとことで言うと
#

カンバンボードの各列(待機中・開発中・レビュー中・完了)のアイテム数を毎日積み上げてグラフ化し、WIP(仕掛かり作業数)・リードタイム・スループットの3指標を一枚の図から読み取る分析手法。

押さえておきたい用語
#

押さえておきたい用語
WIP(Work In Progress)
現在進行中の作業アイテム数。CFDでは各ステータスの帯の縦幅として表示される。WIPが増えるとリードタイムも伸びる。
リードタイム
アイテムが「待機中」に入ってから「完了」になるまでの所要日数。CFDでは帯の横幅として読み取れる。
スループット
一定期間に「完了」に到達したアイテム数。CFDでは「完了」の帯の傾きで表現される。
ボトルネック
フロー全体の中で処理速度が最も遅いステージ。CFDでは特定の帯だけが膨らんでいる箇所として可視化される。

累積フロー分析の全体像
#

累積フロー図(CFD):帯の幅と傾きからWIP・リードタイム・スループットを読む
日付 →累積アイテム数待機中開発中レビュー中完了← リードタイム →WIPスループット= 完了の傾き
累積フロー分析の運用フロー
1
日次データ収集
各ステータスのアイテム数を毎日記録する
2
グラフ描画
積み上げ面グラフとしてCFDを更新する
3
パターン分析
帯の膨らみや傾きの変化からボトルネックを読む
改善アクション
ボトルネックのステージにリソースを集中投入する

こんな悩みに効く
#

  • カンバンボードを使っているがフローの問題に気づけない
  • 「なんとなく遅い」が数値で説明できない
  • どのステージがボトルネックか可視化したい
  • WIPの増加が全体の遅延にどう影響するか理解したい

基本の使い方
#

カンバンのステータス定義を確認する
チームのカンバンボードが「Backlog → To Do → In Progress → In Review → Done」のようにステータスを持っていることを確認する。ステータスが4〜6段階あるとCFDの読みやすさが上がる。
毎日同じ時刻に各ステータスのアイテム数を記録する
スプレッドシートやJira/Trelloのプラグインを使い、毎日15時(またはデイリーの後)に各ステータスのアイテム数を記録する。自動取得できるツールがあればそちらを使う。
積み上げ面グラフとして描画する
X軸を日付、Y軸を累積アイテム数とし、下から「完了」「レビュー中」「開発中」「待機中」の順に積み上げる。帯の縦幅が各ステータスのWIP、横幅がリードタイムを示す。
異常パターンを読み取る
特定の帯だけが膨らんでいればそのステージがボトルネック。帯の幅が時間とともに広がっていればWIPが増加しリードタイムが伸びているサイン。「完了」の傾きが緩やかになったらスループットが落ちている。
ボトルネックに対策を打つ
レビュー帯が膨らんでいるならレビュアーを増やす、開発帯が膨らんでいるならWIP制限を強化する。対策後にCFDの変化を追跡し、帯が均一に近づいたら改善が効いている証拠。

具体例
#

例1:SaaS開発チームがレビュー待ちのボトルネックを解消する

エンジニア8名のSaaS開発チーム。スプリントレビューで「完了した機能が少ない」と毎回指摘されていた。

CFDを2週間取ったところ、「In Review」の帯が日に日に膨らんでいることが判明。レビュー待ちのPRが常時8〜12件溜まっていた。

指標CFD導入前対策後(4週間)
レビュー待ちの平均滞留3.2日0.8日
スプリント完了ストーリー数12本19本
リードタイム(中央値)8.5日4.2日

対策として「午前中の最初の1時間はレビュー優先」というルールを導入。CFDのレビュー帯が薄くなり始めたのを全員で確認し、ルールが定着した。

例2:製造業のカイゼンチームが受注→出荷の滞留を特定する

従業員120名の精密部品メーカー。受注から出荷までのリードタイムが長く、顧客から納期短縮の要望が増えていた。

生産工程を「受注→設計→加工→検査→出荷」の5ステージでCFDを作成。1か月分のデータを分析したところ、「検査」の帯が他ステージの 2.5倍 の幅に膨らんでいた。

原因は検査装置が1台しかなく、加工が終わった部品が検査待ちで滞留していたこと。検査装置を1台追加(投資額 350万円)した結果、受注→出荷のリードタイムが 18日→12日 に短縮。年間の追加受注で投資回収は4か月で完了した。

例3:カスタマーサポートチームが問い合わせ対応のフローを改善する

ECサイトのカスタマーサポート(10名)。問い合わせ対応を「受付→一次対応→エスカレーション→解決」のカンバンで管理していたが、解決までの平均日数が伸び続けていた。

CFDを3週間作成したところ、「エスカレーション」帯が急速に膨らんでいた。技術チームへのエスカレーション案件が積み上がり、回答が戻ってくるまで平均 4.5日 かかっていたのが原因。

技術チームとの週次ミーティングに加え、「24時間以内に一次回答を返す」SLAを設定。CFDでエスカレーション帯の推移を毎日チームに共有した結果、平均解決日数は 6.8日→3.1日 に半減し、顧客満足度調査のスコアが 3.2→4.1(5点満点)に改善している。

やりがちな失敗パターン
#

  1. データ収集を手動で始めて続かない ─ Jira・Trello・Notionなど自動でステータス数を取れるツールを使う。手動は3日で面倒になる
  2. ステータスが「To Do」と「Done」しかない ─ 中間ステータスがないとCFDで読み取れる情報が極端に少なくなる。最低4段階は設ける
  3. グラフを作るだけで分析しない ─ CFDは「帯の異常を見つけてアクションを起こす」までがセット。飾りのグラフにしない
  4. 帯の膨らみを見つけても対策しない ─ ボトルネックがわかったら即座にリソース配分を変える。次のスプリントまで放置しない

まとめ
#

累積フロー分析(CFD)は、カンバンの各ステータスのアイテム数を日次で積み上げグラフ化し、WIP・リードタイム・スループットを一枚の図で読み取る手法。帯の膨らみがボトルネックを、横幅の拡大がリードタイムの悪化を示す。データ収集を自動化し、週次で帯のパターンを分析してアクションにつなげることが運用のポイント。