フレームワーク活用ガイドひとことで言うと#
カンバンの効果を「感覚」ではなく**「数値」で把握するために、リードタイム・サイクルタイム・スループット・WIPの4つの主要メトリクス**を計測し、フローの改善に活用する手法。
押さえておきたい用語#
- リードタイム（Lead Time）
- 作業が依頼されてから完了するまでの全体時間である。顧客から見た「待ち時間」を表す。
- サイクルタイム（Cycle Time）
- 作業に着手してから完了するまでの時間のこと。チームの実作業時間を表す。
- スループット（Throughput）
- 一定期間内に完了したアイテム数のこと。チームの生産能力を測る基本指標。
- CFD（Cumulative Flow Diagram）
- 各ステータスのアイテム数の推移を面グラフで表示する図を指す。帯の幅の拡大がボトルネックを示す。
- リトルの法則（Little’s Law）
- リードタイム = WIP ÷ スループットという関係式のこと。WIPを減らせばリードタイムが短くなることを数学的に証明する。
カンバンメトリクスの全体像#
こんな悩みに効く#
- カンバンボードを運用しているが、改善しているかどうか判断できない
- 「いつ完了しますか」という質問にデータで答えられない
- ボトルネックがどこにあるか定量的に把握できない
基本の使い方#
カンバンで計測すべき4つの基本メトリクスを把握する。
- リードタイム: 作業が依頼されてから完了するまでの全体時間
- サイクルタイム: 作業に着手してから完了するまでの時間
- スループット: 一定期間内に完了したアイテム数
- WIP（仕掛かり数）: ある時点で進行中のアイテム数
ポイント: リトルの法則 — リードタイム = WIP ÷ スループット。この関係を理解することが改善の基礎。
各アイテムの状態遷移日時を記録する仕組みを作る。
- カンバンツール（Jira, Trelloなど）の状態変更ログを活用する
- 各アイテムの「依頼日」「着手日」「完了日」を最低限記録する
- 手動記録の場合は、ボード更新時に日付を付箋に書き込む
ポイント: まず2〜4週間のデータを蓄積してから分析を始める。短期間のデータでは傾向が見えない。
蓄積したデータをグラフ化して傾向を読み取る。
- サイクルタイムの散布図: 外れ値（異常に長いアイテム）の原因を調査する
- 累積フロー図（CFD）: 各ステータスのアイテム数の推移を面グラフで表示し、滞留を検知する
- スループットの推移: 週次のデリバリー数が安定しているか確認する
ポイント: 累積フロー図の「帯の幅の拡大」はボトルネックのサイン。
データに基づいてフローを改善し、予測の精度を上げる。
- ボトルネックのステータスのWIP制限を調整する
- サイクルタイムのパーセンタイル値を使って予測する（例: 「85%のアイテムは7日以内に完了」）
- モンテカルロシミュレーションで複数アイテムの完了予測を行う
ポイント: 「平均」ではなく「パーセンタイル」で予測する。平均は外れ値に引っ張られ、実態を反映しない。
具体例#
計測開始（4週間のデータ蓄積）:
- 平均サイクルタイム: 6.2日
- 85パーセンタイルサイクルタイム: 12日
- 週次スループット: 平均5アイテム
- 平均WIP: 9アイテム
分析結果: 累積フロー図で「コードレビュー」ステータスの帯が拡大傾向。サイクルタイム散布図で10日超えのアイテムはすべてレビュー待ちで3日以上滞留。
改善策:
- コードレビューのWIP制限を3→2に引き下げ
- 「レビュー待ち」が2日を超えたらアラート通知
- レビュー担当を1名→2名に増員
| 指標 | 改善前 | 4週間後 |
|---|---|---|
| 平均サイクルタイム | 6.2日 | 4.1日 |
| 85%タイルサイクルタイム | 12日 | 6日 |
| 週次スループット | 5 | 7アイテム |
CFDとサイクルタイム散布図の分析でレビュー待ちがボトルネックと特定。WIP制限調整と増員で85パーセンタイルのサイクルタイムを12日から6日に半減させた。
状況: 従業員100名のEC企業。マーケティングチームがキャンペーンの企画から公開まで平均18日かかっており、「競合の方が動きが速い」と経営から指摘されていた。
計測結果（8週間）:
- リードタイム: 平均18日（85パーセンタイル: 25日）
- サイクルタイム: 平均8日
- 待ち時間（リードタイム - サイクルタイム）: 平均10日
分析: リードタイム18日のうち10日が「待ち時間」。内訳は承認待ち5日、デザイン順番待ち3日、法務チェック待ち2日。実作業は8日しかかかっていない。
改善:
- 承認プロセスを簡略化（金額10万円未満は部長承認不要に）
- デザイナーのWIP制限を3→2に
- 法務チェックを並行実施（デザイン開始と同時に法務にドラフト共有）
| 指標 | 改善前 | 改善後 |
|---|---|---|
| リードタイム | 平均18日 | 平均9日 |
| 待ち時間 | 10日 | 3日 |
| 月間キャンペーン数 | 3本 | 6本 |
この取り組みが示すように、メトリクスの分析で「実作業より待ち時間の方が長い」と判明。待ち時間を70%削減することでリードタイムを半減し、月間キャンペーン数を2倍にした。
状況: 従業員200名のSIer。保守チーム4名で月30〜40件の改修依頼を処理。顧客から「いつ完了するか」と聞かれるたびに「2週間くらい」と答えるが、実際の完了は1〜6週間とばらつきが大きく、信頼を失っていた。
サイクルタイムの分析（12週間のデータ）:
- 平均: 8日
- 50パーセンタイル: 6日
- 85パーセンタイル: 14日
- 95パーセンタイル: 21日
予測方法の変更:
- 「2週間くらい」→「85%の確率で14日以内に完了します」に変更
- 大型改修（見積もり5日超）は個別に予測を提示
- 月次で顧客にスループットレポートを共有
| 指標 | 変更前 | 変更後 |
|---|---|---|
| 予測精度（期限内完了率） | 55% | 87% |
| 顧客満足度 | 3.0/5.0 | 4.3/5.0 |
| エスカレーション件数 | 月5件 | 月1件 |
パーセンタイルベースの予測に切り替えたことで、期限内完了率が55%から87%に改善。「だいたい2週間」という曖昧な回答から「85%の確率で14日以内」というデータに基づく回答に変えるだけで、顧客の信頼が回復した。
やりがちな失敗パターン#
- メトリクスを個人評価に使う — 「Aさんのサイクルタイムが長い」と個人を責めると、チームの心理的安全性が壊れる。メトリクスはプロセス改善のためのものであり、個人評価には使わない
- 平均値だけで判断する — 平均サイクルタイム5日でも、実際は2日〜15日にばらつくことがある。パーセンタイル値と分布を見て判断する
- 計測しても振り返りに使わない — データを集めるだけでは改善は起きない。定期的なレトロスペクティブでメトリクスを議論し、改善アクションにつなげる
- メトリクスの数を増やしすぎる — 指標が多すぎると何に注目すべきかわからなくなる。まずは4つの基本指標に集中し、慣れてから追加する
まとめ#
カンバンメトリクスは、フロー型の開発プロセスを定量的に管理・改善するための必須ツール。リードタイム、サイクルタイム、スループット、WIPの4指標を継続的に計測し、累積フロー図やサイクルタイム散布図で可視化することで、ボトルネックの発見とデリバリー予測の精度向上を実現する。「計測なくして改善なし」の精神で、データ駆動の改善サイクルを回そう。