Kanbanで進捗を予測する方法｜データに基づく現実的な予測アプローチ

Kanbanで進捗を予測する方法とは、勘や希望的観測ではなく、過去のフローデータを使って作業の完了時期やリリース見通しを考えるアプローチです。リードタイム、スループット、WIP、サービスレベル期待値、累積フロー図などを活用することで、より現実的な予測ができます。

従来の進捗予測では、担当者の見積もりや理想的な計画に依存しすぎることがあります。しかし、実際のプロジェクトでは、仕様変更、レビュー待ち、承認遅延、割り込み作業、品質問題などによって計画どおりに進まないことが少なくありません。Kanbanでは、そうした不確実性を前提に、過去データと確率を使って予測します。

この記事では、Kanban 進捗予測の基本的な考え方、リードタイムやスループットを使った予測方法、SLE、Littleの法則、累積フロー図、モンテカルロシミュレーション、AI時代の予測課題までを体系的に解説します。

1. なぜKanbanで進捗予測ができるのか

Kanbanで進捗予測ができる理由は、仕事の流れを継続的に記録できるからです。作業がいつ始まり、いつ完了し、どの工程で止まり、一定期間にどれだけ完了したかを蓄積すれば、将来の進み方を現実的に考えやすくなります。

Kanbanの予測は、未来を正確に言い当てるものではありません。過去の実績から「どれくらいの確率で、どの時期に完了しそうか」を考えるための方法です。確約ではなく、データに基づく見通しとして扱うことが重要です。

1.1. フローデータを蓄積できるから

Kanbanでは、作業項目がボード上を移動する過程を記録できます。いつ依頼されたか、いつ作業を開始したか、いつレビューに入ったか、いつDoneになったかを記録することで、フローの実績データが蓄積されます。

このデータを使えば、過去の作業がどれくらいの期間で完了したかを確認できます。進捗予測では、理想的な計画よりも、実際にチームがどのくらいのペースで作業を完了してきたかを見ることが重要です。

1.2. 作業パターンを分析できるから

Kanbanのデータを蓄積すると、作業パターンを分析できます。たとえば、軽微な修正は短期間で終わるが、新機能開発はばらつきが大きい、レビュー工程で滞留しやすい、承認待ちが長いといった傾向が見えてきます。

作業パターンを理解できれば、すべてのタスクを同じように予測するのではなく、作業タイプごとに現実的な見通しを立てられます。これにより、予測の精度と説明力が高まります。

1.3. 予測可能性を高められるから

Kanbanは、フローを安定させることで予測可能性を高めます。WIPを制限し、ボトルネックを減らし、リードタイムのばらつきを小さくできれば、将来の完了時期も予測しやすくなります。

予測可能性とは、必ず予定どおりに終わることではありません。過去実績に基づいて、どのくらいの範囲で完了しそうかを説明できる状態です。Kanbanでは、速さだけでなく安定性が重要になります。

1.4. データに基づいて判断できるから

Kanbanの進捗予測では、担当者の感覚だけに頼らず、過去データを使って判断できます。たとえば、「通常この種類の作業は80%の確率で10日以内に完了している」といった形で説明できます。

データに基づく判断は、ステークホルダーとの会話にも役立ちます。希望的な納期ではなく、実績に基づいた見通しを共有することで、期待値を調整しやすくなります。

2. 従来の進捗予測が抱える課題

従来の進捗予測では、事前見積もりや計画表に強く依存することがあります。しかし、プロジェクトには不確実性があり、見積もりどおりに進むとは限りません。

Kanbanによる予測では、予測を固定的な約束として扱うのではなく、実績データをもとに更新し続けるものとして扱います。この違いを理解することが、現実的な予測につながります。

2.1. 見積もりに依存しすぎる

従来型の進捗予測では、作業開始前の見積もりに強く依存することがあります。担当者が「3日で終わる」と見積もれば、その数字が計画の前提になります。しかし、見積もりは不確実性を含むため、実績とずれることがあります。

Kanbanでは、見積もりだけでなく、過去の完了実績を重視します。同じような作業が過去にどれくらいで完了しているかを見れば、より現実的な予測ができます。

2.2. 不確実性を過小評価する

進捗予測でよくある問題は、不確実性を過小評価することです。仕様変更、レビュー遅延、依存関係、品質問題、割り込み作業などは、計画時に十分考慮されないことがあります。

Kanbanでは、不確実性を前提に予測します。リードタイム分布やスループットのばらつきを見ることで、どれくらい遅れる可能性があるかを現実的に考えられます。

2.3. 楽観的な計画になりやすい

従来の計画は、理想的な条件を前提にした楽観的なものになりやすいです。すべての作業が順調に進み、レビューもすぐ終わり、割り込みがない前提で計画すると、実際の進捗との差が大きくなります。

Kanbanの予測では、過去の実績を使うため、実際に発生した待機や遅延も含めて考えられます。これにより、理想ではなく現実に近い見通しを作りやすくなります。

2.4. 実績データを活用しない

過去の実績データを活用しない予測は、毎回ゼロから見積もる状態になります。チームがどれくらいのペースで完了しているかを見ないまま計画すると、同じような誤差を繰り返す可能性があります。

Kanbanでは、リードタイム、スループット、WIP、サイクルタイムを継続的に蓄積します。実績データを使うことで、予測は学習可能なプロセスになります。

従来型予測とKanban予測の違い

3. Kanbanにおける予測の考え方

Kanbanにおける予測では、未来を一つの確定日として扱うのではなく、確率的な見通しとして扱います。これは、ソフトウェア開発や業務改善には不確実性があるためです。

重要なのは、予測を一度出して終わりにしないことです。新しいデータが入れば予測を更新し、フローが変われば見通しも見直します。Kanbanの予測は、継続的に学習するアプローチです。

3.1. 確約ではなく確率で考える

Kanbanの進捗予測では、「必ずこの日に終わる」と断定するのではなく、「この日までに終わる可能性が高い」と表現します。たとえば、「85%の確率で10日以内に完了する見込み」のように伝えます。

確率で考えることで、不確実性を正直に扱えます。ステークホルダーにも、予定が絶対ではなく、実績に基づいた見通しであることを伝えやすくなります。

3.2. 過去データを活用する

Kanban予測の基本は、過去データの活用です。過去に完了した作業のリードタイムやスループットを見れば、今後の作業がどれくらいで完了しそうかを考えられます。

ただし、過去データを使うときは、作業タイプやチーム体制が現在と大きく違っていないか確認する必要があります。古すぎるデータや条件が違うデータは、予測を歪める可能性があります。

3.3. フローを重視する

Kanban予測では、個別タスクの見積もりだけでなく、フロー全体を重視します。作業がどれくらい速く完了するかは、個人の作業速度だけでなく、レビュー、テスト、承認、リリースの流れにも左右されます。

フローを見れば、予測を悪化させる要因を発見できます。たとえば、レビュー待ちが長ければ、個別タスクの見積もりを改善しても全体の予測精度は上がりません。

3.4. 継続的に更新する

Kanbanの予測は、固定された計画ではありません。作業が完了し、新しいデータが増え、ボトルネックが変化すれば、予測も更新する必要があります。

継続的に更新することで、予測は現実に近づきます。初期の見通しにこだわるのではなく、最新のフロー状態に基づいてステークホルダーへ説明することが重要です。

4. 予測に必要な主要指標

Kanbanで進捗を予測するには、複数のフローメトリクスを使います。特に、リードタイム、サイクルタイム、スループット、WIPは基本となる指標です。

これらの指標は単独で使うよりも、組み合わせて見ることで効果を発揮します。リードタイムが長い原因を探るには、WIPや待機時間も合わせて確認する必要があります。

4.1. リードタイム

リードタイムは、要求が発生してから完了するまでの時間です。顧客や依頼者の視点で、価値が届くまでにどれくらい時間がかかるかを示します。

進捗予測では、リードタイムの過去実績を使って、現在の作業がどれくらいで完了しそうかを考えます。平均だけでなく、分布やパーセンタイルを見ることが重要です。

4.2. サイクルタイム

サイクルタイムは、作業開始から完了までの時間です。チーム内部の作業フローを分析するために使います。レビューやテストを含めた実際の流れを見ることができます。

進捗予測では、サイクルタイムを使って内部工程の安定性を確認します。作業開始後の完了見通しを考える場合に特に役立ちます。

4.3. スループット

スループットは、一定期間に完了した作業項目の数です。週単位や月単位でどれくらいの作業を完了できているかを見ることで、将来の完了数を予測できます。

複数タスクやリリース予測では、スループットが重要です。残りの作業数と過去のスループットを組み合わせることで、いつ頃完了しそうかを考えられます。

4.4. WIP

WIPは、現在進行中の作業量です。WIPが多すぎると、リードタイムが長くなり、予測のばらつきも大きくなります。

進捗予測では、WIPの状態を必ず確認する必要があります。作業が多すぎる状態では、過去データに基づく予測も不安定になりやすくなります。

進捗予測で利用する主要指標

5. リードタイムを使って予測する

リードタイムは、Kanbanで進捗予測を行う際の中心的な指標です。過去に同じような作業がどれくらいの期間で完了したかを確認することで、現在の作業の完了時期を予測できます。

ただし、リードタイムは平均だけを見るのではなく、分布として見ることが重要です。作業によって完了時間にばらつきがあるため、確率を含めて予測する必要があります。

5.1. リードタイムの定義

リードタイムとは、要求や依頼が発生してから、その作業が完了するまでの時間です。たとえば、機能要望が登録されてからリリースされるまでの期間がリードタイムになります。

予測に使う場合は、開始点と終了点を明確にする必要があります。要求登録から測るのか、コミットメント時点から測るのか、リリース完了まで測るのかをチームで統一します。

5.2. 過去データを収集する

リードタイム予測では、過去に完了した作業のデータを収集します。作業項目ごとに、開始日、完了日、作業タイプ、担当チーム、サイズ感などを記録すると分析しやすくなります。

データ量が少ない場合は、予測の信頼性が下がります。最初は大まかな傾向でも構いませんが、継続的にデータを蓄積することで予測精度が高まります。

5.3. 分布を確認する

リードタイムは平均値だけでなく、分布を確認することが重要です。多くの作業が5日以内に終わる一方で、一部が20日以上かかる場合、平均だけではリスクを把握できません。

分布を見ることで、どれくらいの確率で何日以内に完了しそうかを考えられます。SLEを設定する場合も、分布に基づいて現実的な期間と確率を決めます。

5.4. 完了日を予測する

現在の作業の完了日を予測するには、過去のリードタイム分布を参照します。たとえば、過去の類似作業の85%が10日以内に完了しているなら、今回も10日以内に完了する可能性が高いと説明できます。

ただし、現在のWIPやボトルネックの状態も考慮する必要があります。過去データが良くても、今レビュー工程が詰まっていれば、完了日は遅れる可能性があります。

6. スループットを活用する

スループットは、一定期間に完了した作業数を示す指標です。複数タスクの完了時期やリリース時期を予測する際に特に役立ちます。

スループットを使うと、残り作業数に対してチームがどれくらいのペースで完了できるかを考えられます。個別タスクの見積もりに依存しすぎない予測が可能になります。

6.1. スループットの定義

スループットとは、一定期間内にDoneになった作業項目の数です。たとえば、1週間に完了したチケット数、1か月に完了した改善案件数などがスループットになります。

重要なのは、開始数ではなく完了数を見ることです。多くの作業に着手していても、Doneにならなければスループットには含めません。

6.2. 完了能力を把握する

スループットを測定すると、チームの完了能力がわかります。過去数週間で平均して何件完了しているかを見ることで、今後の作業量に対する見通しを立てやすくなります。

ただし、スループットは一定ではありません。作業の種類、割り込み、メンバー構成、WIP、レビュー負荷によって変動します。そのため、平均だけでなくばらつきも見る必要があります。

6.3. 将来の完了数を予測する

スループットを使うと、今後一定期間にどれくらいの作業を完了できそうかを予測できます。たとえば、過去に週5件前後完了しているなら、4週間で20件前後完了する可能性があります。

ただし、単純な掛け算では不確実性を十分に扱えません。スループットのばらつきを考慮し、確率的に予測することが望ましいです。

6.4. キャパシティ計画に活用する

スループットは、キャパシティ計画にも活用できます。チームが現実的にどれくらいの作業を完了できるかを把握すれば、無理な計画を避けやすくなります。

キャパシティ計画では、緊急対応やレビュー負荷も考慮します。過去の完了数だけでなく、現在のチーム状況やWIPも合わせて判断することが重要です。

7. サービスレベル期待値を利用する

サービスレベル期待値、つまりSLEは、Kanbanで予測可能性を高めるための重要な考え方です。SLEは、作業がどれくらいの確率で、どれくらいの期間内に完了するかを示します。

SLEを使うと、ステークホルダーに対して現実的な期待値を伝えやすくなります。固定納期ではなく、過去データに基づく確率的な見通しとして扱うことがポイントです。

7.1. SLEの考え方

SLEとは、Service Level Expectationの略です。たとえば、「85%の作業は10日以内に完了する見込み」のように、期間と確率をセットで表現します。

SLEは、チームの過去データに基づいて設定します。感覚で決めるのではなく、リードタイムやサイクルタイムの分布を見て、現実的な期待値を作ることが重要です。

7.2. 信頼区間を設定する

SLEでは、どの程度の信頼度で予測するかを決めます。たとえば、50%の確率で5日以内、85%の確率で10日以内、95%の確率で15日以内というように、複数の水準で説明できます。

信頼度を高くするほど、予測期間は長くなりやすくなります。ステークホルダーと話すときは、短いがリスクの高い見通しと、長めだが安全な見通しを分けて説明すると効果的です。

7.3. 予測可能性を高める

SLEを活用すると、チームは予測可能性を高められます。過去データに基づく期待値があるため、「いつ終わるかわからない」状態を減らせます。

ただし、SLEは一度設定して終わりではありません。フローが改善されたり、チーム体制が変わったりした場合は、SLEも更新する必要があります。

7.4. 顧客期待を管理する

SLEは、顧客やステークホルダーの期待を管理するために有効です。無理な納期を約束するのではなく、過去実績に基づいて現実的な見通しを共有できます。

顧客期待を管理するには、不確実性も一緒に伝えることが重要です。「平均では7日」ではなく、「85%の確率で10日以内」のように説明すると、リスクを含めた会話がしやすくなります。

SLEを活用する場合としない場合の違い

8. リードタイム分布を理解する

Kanbanで現実的な予測を行うには、リードタイム分布を理解することが重要です。平均値だけを見ても、作業のばらつきや遅延リスクは見えません。

リードタイム分布を見ることで、どれくらいの作業が短期間で終わり、どれくらいの作業が長引くのかを把握できます。確率的な予測には欠かせない考え方です。

8.1. 平均値だけを見ない

リードタイムの平均値は便利ですが、予測には不十分なことがあります。多くの作業が短く終わっていても、一部の作業が極端に長引くと、平均値は実感と合わない数字になります。

進捗予測では、平均だけでなく中央値、85パーセンタイル、95パーセンタイルなどを見ることが重要です。ばらつきを理解することで、現実的な予測ができます。

8.2. ばらつきを分析する

リードタイムのばらつきは、予測可能性に大きく影響します。ばらつきが小さいチームは、完了時期を予測しやすくなります。一方、ばらつきが大きいチームでは、同じ作業でも完了時期が読みにくくなります。

ばらつきの原因には、作業サイズの違い、割り込み、レビュー待ち、承認遅延、外部依存などがあります。ばらつきを減らすことは、予測精度を高める重要な改善です。

8.3. 外れ値を理解する

外れ値とは、通常よりも極端に長くかかった作業です。外れ値を単に除外するのではなく、なぜ長引いたのかを理解することが重要です。

外れ値の原因が一時的な事故なら別扱いできますが、頻繁に起きるならフロー上の問題です。外れ値を分析することで、予測リスクと改善機会を発見できます。

8.4. 現実的な予測を行う

リードタイム分布を使うと、現実的な予測ができます。たとえば、「過去データでは、80%の類似作業が12日以内に完了している」という形で説明できます。

このような予測は、単一の完了日を断言するよりも信頼性があります。不確実性を含めて説明できるため、ステークホルダーとの合意形成にも役立ちます。

9. WIPが予測精度に与える影響

WIPは、Kanbanの進捗予測に大きな影響を与えます。WIPが多すぎると、作業の待機時間が増え、リードタイムが長くなり、予測のばらつきも大きくなります。

予測精度を高めるには、単にデータを見るだけでなく、WIPを適切に管理する必要があります。WIP制限が機能しているチームほど、フローが安定しやすくなります。

9.1. WIPとリードタイムの関係

WIPが増えると、作業がキューに溜まりやすくなります。進行中の作業が多い状態では、各タスクが少しずつ進むだけになり、完了までの時間が長くなります。

リードタイムを短く安定させるには、WIPを適切に制限することが重要です。作業を始めすぎないことで、完了までの流れを改善できます。

9.2. フロー安定性との関係

WIPが多すぎると、フローは不安定になります。ある週は多く完了し、別の週はほとんど完了しないような状態になりやすくなります。

フローが不安定だと、予測も不安定になります。Kanbanで予測精度を高めるには、WIPを管理し、完了ペースを安定させる必要があります。

9.3. 予測可能性への影響

WIPが制御されていないと、作業がいつ完了するか予測しにくくなります。多くの作業が同時進行していると、優先順位が変わりやすく、待機も増えます。

予測可能性を高めるには、現在のWIPが過去データと同じような状態かを確認することが重要です。現在のWIPが異常に多ければ、過去実績に基づく予測は楽観的になる可能性があります。

9.4. WIP制限の重要性

WIP制限は、予測精度を高めるためにも重要です。WIPを制限すると、作業が完了まで流れやすくなり、リードタイムやスループットが安定します。

WIP制限は、チームを縛るものではなく、予測可能なフローを作るための仕組みです。進捗予測を改善したいなら、まずWIPの状態を確認するべきです。

10. Littleの法則を活用する

Littleの法則は、WIP、スループット、リードタイムの関係を理解するために役立つ考え方です。Kanbanでは、フローが安定している場合に、これらの指標の関係からシステムの状態を分析できます。

この法則を理解すると、作業を増やしすぎるとリードタイムが長くなりやすい理由がわかります。予測においては、WIPと完了能力のバランスを見るために有効です。

10.1. Littleの法則の概要

Littleの法則は、安定したシステムにおいて、平均WIP、平均スループット、平均リードタイムの間に関係があるという考え方です。簡単に言えば、システム内にある作業量と完了速度が、完了までの時間に影響します。

Kanbanでこの考え方を使うと、WIPを増やせば必ず早く終わるわけではないことが理解できます。むしろ、完了能力が変わらないままWIPだけ増えれば、リードタイムは長くなります。

10.2. フロー分析への応用

Littleの法則は、フロー分析に応用できます。WIPが増えているのにスループットが上がっていない場合、リードタイムが悪化する可能性があります。

フローを分析するときは、WIP、スループット、リードタイムを別々に見るのではなく、関係性として見ることが重要です。これにより、改善すべき方向が見えやすくなります。

10.3. WIPとスループットの関係

WIPとスループットは、予測において重要な関係を持ちます。WIPが多くても、スループットが変わらなければ、作業が完了するまでの時間は長くなります。

スループットを高めるには、単に作業を増やすのではなく、ボトルネックを改善する必要があります。開発だけを速くしても、レビューが詰まっていれば全体の完了能力は上がりません。

10.4. 予測への活用

Littleの法則を理解すると、予測の前提を確認しやすくなります。現在のWIPが過去より大きく増えている場合、過去のリードタイムをそのまま使った予測は危険です。

予測に活用する際は、システムが安定しているか、WIPが大きく変化していないか、スループットが維持されているかを確認します。Kanbanの進捗予測では、フローの安定性が前提になります。

Littleの法則から読み取れる内容

11. 累積フロー図を使った予測

累積フロー図は、Kanbanのフロー状態を視覚的に把握するためのグラフです。各工程にある作業数を時間の経過とともに表示することで、WIP、ボトルネック、完了ペースを確認できます。

進捗予測では、累積フロー図を使ってフローが安定しているかを確認します。安定していないフローでは、過去データに基づく予測の信頼性が下がるためです。

11.1. フローの安定性を確認する

累積フロー図では、各工程の幅を見ることでフローの安定性を確認できます。工程ごとの幅が大きく変化していなければ、フローは比較的安定していると考えられます。

一方で、特定の工程の幅が急に広がっている場合、その工程に作業が溜まっている可能性があります。進捗予測を行う前に、まずフローが安定しているかを確認することが重要です。

11.2. ボトルネックを発見する

累積フロー図は、ボトルネック発見にも役立ちます。レビュー工程やテスト工程の領域が広がっている場合、その工程で作業が滞留している可能性があります。

ボトルネックがある状態では、予測は楽観的になりやすくなります。累積フロー図で詰まりを確認し、必要に応じてWIP制限や工程改善を行うことが重要です。

11.3. 将来の流れを予測する

累積フロー図では、Doneの増え方を見ることで、将来の完了ペースを考えられます。Doneが安定して増えているなら、その傾向を使って今後の進捗を予測しやすくなります。

ただし、過去の傾向が今後も続くとは限りません。チーム体制、作業タイプ、割り込み、外部依存が変わる場合は、予測も調整する必要があります。

11.4. リスクを早期発見する

累積フロー図は、リスクの早期発見にも使えます。WIPが急増している、Doneが増えていない、特定工程の幅が広がっているといった変化は、進捗遅延のサインです。

こうしたサインを早めに見つければ、リリース直前になって問題に気づくリスクを減らせます。Kanbanでは、予測と改善を同時に行うことが重要です。

累積フロー図による進捗予測例

12. 単一タスクの完了日を予測する

単一タスクの完了日を予測する場合は、過去の類似作業のリードタイムやサイクルタイムを使います。特に、作業タイプが近いデータを参照することで、より現実的な見通しを作れます。

ただし、単一タスクの予測には不確実性があります。個別の作業は例外要因の影響を受けやすいため、確率で表現することが重要です。

12.1. 類似データを参照する

単一タスクを予測するときは、過去の類似データを参照します。たとえば、バグ修正を予測するなら過去のバグ修正、UI改善を予測するなら過去のUI改善のデータを見るべきです。

作業タイプが違うデータを混ぜると、予測がずれやすくなります。データを分類し、できるだけ似た性質の作業を使うことが大切です。

12.2. リードタイム分布を活用する

単一タスクの予測では、リードタイム分布を活用します。平均値だけでなく、どのくらいの確率で何日以内に完了しているかを見ることで、現実的な完了見通しを出せます。

たとえば、過去の類似作業の80%が8日以内、95%が14日以内に完了しているなら、リスク水準に応じて予測日を選べます。重要な案件ほど高い信頼度で考えるべきです。

12.3. 確率で表現する

単一タスクの完了日は、確率で表現することが望ましいです。「8日で終わります」ではなく、「過去データでは80%の確率で8日以内に完了しています」のように伝えます。

確率で表現すれば、不確実性を隠さずに共有できます。ステークホルダーも、早い見通しと安全な見通しを分けて理解しやすくなります。

12.4. 定期的に更新する

単一タスクの予測は、作業が進むにつれて更新する必要があります。作業項目の経過時間、ブロッカー、レビュー状況、WIPの変化によって完了見通しは変わります。

最初に出した予測に固執するのではなく、最新のデータで更新します。Kanbanの予測は、一度決めた計画ではなく、継続的に見直す見通しです。

13. 複数タスクの完了時期を予測する

複数タスクの完了時期を予測する場合は、スループットが重要になります。残りの作業数と、過去の完了ペースを組み合わせることで、いつ頃完了しそうかを考えられます。

複数タスクの予測では、個別タスクの見積もりを積み上げるよりも、完了実績に基づく方法のほうが現実的な場合があります。特に、作業数が多い場合はスループット予測が有効です。

13.1. バックログサイズを把握する

まず、予測対象となるバックログサイズを把握します。リリース対象のチケット数、キャンペーンに必要な制作物数、デザインタスク数など、完了すべき作業項目を明確にします。

このとき、作業項目の粒度が大きくばらついている場合は注意が必要です。サイズが大きすぎる作業は分割し、スループットで扱いやすい単位に整えると予測しやすくなります。

13.2. スループットを利用する

次に、過去のスループットを確認します。たとえば、過去8週間で毎週何件完了しているかを見ることで、今後の完了ペースを考えられます。

スループットは平均だけでなく、ばらつきも重要です。完了数が安定しているチームほど、複数タスクの完了時期を予測しやすくなります。

13.3. キャパシティを考慮する

予測では、現在のキャパシティも考慮する必要があります。メンバーの休暇、他プロジェクトへの参加、緊急対応、レビュー負荷がある場合、過去のスループットをそのまま使うと楽観的になります。

キャパシティが変わる場合は、予測を調整します。過去データは重要ですが、現在の状況と合わせて解釈することが必要です。

13.4. 不確実性を反映する

複数タスクの予測では、不確実性を反映することが重要です。残り20件を毎週5件ずつ完了する計算なら4週間ですが、実際には週ごとの完了数にばらつきがあります。

不確実性を反映するには、過去スループットの分布やモンテカルロシミュレーションを使う方法があります。単一の完了日ではなく、確率付きの範囲で説明することが望ましいです。

14. リリース予測にKanbanを活用する

リリース予測では、リリース対象の作業がいつ完了しそうかを見積もる必要があります。Kanbanを使えば、過去の完了実績や現在のフロー状態をもとに、現実的なリリース見通しを作れます。

リリース予測で重要なのは、対象範囲を明確にし、予測を継続的に更新することです。リリース直前に初めて予測するのではなく、開発中からフローを監視する必要があります。

14.1. リリース対象を明確化する

まず、リリース対象を明確にします。どの機能、修正、改善、ドキュメント、テストがリリースに必要なのかを整理します。対象が曖昧なままでは、予測も曖昧になります。

リリース対象は、できるだけ作業項目として分解します。大きな機能単位だけでなく、実際に完了判定できる単位にすることで、スループット予測に使いやすくなります。

14.2. フローを分析する

リリース予測では、現在のフローを分析します。WIPが多すぎないか、レビュー待ちが溜まっていないか、テスト工程が詰まっていないかを確認します。

フローに問題がある場合、過去データだけで予測すると楽観的になります。現在のボトルネックを反映して、予測を調整する必要があります。

14.3. 予測を更新する

リリース予測は、一度作って終わりではありません。作業が完了するたびに残作業数が変わり、スループットやWIPの状態も変化します。

定期的に予測を更新することで、ステークホルダーに最新の見通しを共有できます。予測の更新は、計画変更ではなく、現実への適応として扱うべきです。

14.4. ステークホルダーへ共有する

リリース予測は、ステークホルダーとのコミュニケーションに使います。重要なのは、日付だけでなく、確率、不確実性、リスクも一緒に伝えることです。

たとえば、「現時点では80%の確率で月末までに完了する見込み。ただし、レビュー工程の滞留が続くと遅れる可能性がある」と説明すると、より現実的な会話ができます。

15. プロダクト開発における予測

プロダクト開発では、機能提供、探索活動、実験、ロードマップ運営など、さまざまな場面で予測が必要になります。Kanbanは、これらの活動をデータに基づいて管理するために役立ちます。

特に、不確実性の高いプロダクト開発では、予測を固定計画として扱うのではなく、学習に応じて更新することが重要です。Kanbanはそのためのフロー可視化に向いています。

15.1. Feature Delivery

Feature Deliveryでは、機能がいつユーザーに届くかを予測します。リードタイムやスループットを使えば、過去の機能開発がどれくらいの期間で完了しているかを確認できます。

機能単位が大きすぎると予測が難しくなります。ユーザー価値を保ちながら小さく分割し、フローに乗せることで、予測可能性を高められます。

15.2. Product Discovery

Product Discoveryでは、調査、仮説検証、インタビュー、プロトタイプ作成などの活動があります。これらもKanbanで流れを可視化し、完了までの時間を測定できます。

Discoveryは不確実性が高いため、厳密な納期よりも学習サイクルの速さを見ることが重要です。どれくらいの期間で仮説を検証できるかを把握すれば、ロードマップの柔軟性も高まります。

15.3. 実験サイクル

プロダクト開発では、実験サイクルの速度も重要です。仮説を立て、実験を設計し、実施し、結果を分析するまでの流れを測定します。

実験サイクルが長すぎると、学習速度が落ちます。Kanbanで実験のリードタイムや待機時間を可視化すれば、学習を妨げているボトルネックを発見できます。

15.4. ロードマップ運営

ロードマップ運営では、長期的な見通しが必要です。しかし、不確実性の高いプロダクト開発では、固定的な日付だけで管理すると現実とずれやすくなります。

Kanbanの予測を使えば、過去のフロー実績をもとに、ロードマップ項目の実現可能性を説明できます。確率と範囲で伝えることで、柔軟なロードマップ運営が可能になります。

16. マーケティングチームにおける予測

Kanbanによる進捗予測は、マーケティングチームにも有効です。コンテンツ制作、キャンペーン運営、承認フロー、公開スケジュールなど、複数の工程を持つ業務で活用できます。

マーケティング業務では、制作そのものよりも確認や承認で時間がかかることがあります。Kanbanを使えば、そうした待機時間も予測に含められます。

16.1. コンテンツ制作

コンテンツ制作では、企画、執筆、編集、デザイン、レビュー、公開の工程があります。各工程のリードタイムや待機時間を測定すれば、公開までの見通しを作れます。

特に、記事やLP、メール、SNS投稿などを継続的に制作するチームでは、スループットを使った予測が有効です。一定期間に何本公開できるかを現実的に考えられます。

16.2. キャンペーン運営

キャンペーン運営では、複数の制作物や承認が関係します。広告、LP、メール、SNS、計測設定などが連動するため、どこか一つが遅れると全体に影響します。

Kanbanで各作業の状態を可視化すれば、キャンペーン全体の進捗を予測しやすくなります。リリース予測と同じように、残作業数とスループットを組み合わせて考えます。

16.3. 承認フロー

マーケティングでは、承認フローが大きなボトルネックになることがあります。法務確認、ブランド確認、予算承認、顧客確認などがある場合、待機時間が長くなりやすいです。

承認待機時間を測定すれば、予測に反映できます。承認工程が不安定な場合、公開予定を確率で表現し、リスクを早めに共有することが重要です。

16.4. 公開スケジュール

公開スケジュールを予測するには、制作だけでなく、レビュー、修正、承認、配信準備まで含めて考える必要があります。Kanbanでは、各工程の実績をもとに現実的なスケジュールを作れます。

公開日が固定されている場合は、逆算ではなく、現在のフローで間に合う確率を確認することが重要です。間に合う確率が低い場合は、スコープ調整や優先順位の見直しを行います。

17. UX/UIチームにおける予測

UX/UIチームでは、デザイン作業、レビュー、フィードバック反映、開発引き継ぎなどの工程があります。Kanbanを使えば、デザイン業務の進捗をデータに基づいて予測できます。

デザイン作業は創造的な要素が強く、見積もりが難しい場合があります。そのため、過去の完了実績やレビュー待機時間を使った予測が有効です。

17.1. デザイン作業

デザイン作業では、ワイヤーフレーム、UIデザイン、プロトタイプ、デザインシステム更新など、作業タイプによって完了までの時間が異なります。タイプ別にデータを分けると予測しやすくなります。

大きなデザインタスクは予測が難しくなります。画面単位、コンポーネント単位、検証単位に分割することで、フローに乗せやすくなります。

17.2. レビュー工程

UX/UIチームでは、レビュー工程が遅延要因になりやすいです。PM、開発者、ステークホルダー、顧客など複数の関係者が確認する場合、待機時間が長くなります。

レビュー待機時間を測定すれば、デザイン完了予測の精度が上がります。レビュー工程をカラムとして可視化し、WIPや滞留を確認することが重要です。

17.3. フィードバック対応

デザインレビュー後には、フィードバック対応が発生します。フィードバックの量や内容によって、完了までの時間は大きく変わります。

予測では、過去のフィードバック対応時間を参考にします。また、フィードバックをすべて同じ重さで扱わず、必須修正と任意改善を分けることで、予測しやすくなります。

17.4. 開発引き継ぎ

UX/UIチームの作業は、開発チームへの引き継ぎまで含めて考える必要があります。デザインが完成しても、仕様説明やアセット準備が不足していれば、開発工程で待機が発生します。

開発引き継ぎまでをDoneの定義に含めることで、予測の精度が高まります。Kanbanでは、チーム間の境界もフローとして扱うことが重要です。

18. リモートチームにおける予測

リモートチームでは、非同期作業や確認待ちが増えやすいため、進捗予測に待機時間を含めることが重要です。作業している時間だけでなく、返信待ちやレビュー待ちもフローに影響します。

Kanbanを使えば、リモート環境でも作業状態を可視化できます。フローを安定させることで、予測精度を高めやすくなります。

18.1. 非同期作業を考慮する

リモートチームでは、時差や勤務時間の違いにより、確認やレビューが非同期になります。これにより、実作業時間は短くても完了までの時間が長くなることがあります。

進捗予測では、非同期による待機時間を含める必要があります。過去のリードタイムには、こうした現実の待機時間が含まれているため、予測に有効です。

18.2. 待機時間を把握する

リモート環境では、待機時間が見えにくいことがあります。誰かの返信待ち、承認待ち、情報不足などがボード上で表現されていないと、予測が楽観的になります。

待機時間を把握するには、WaitingやBlockedの状態を明確にします。どの作業が何を待っているのかを見える化することで、予測と改善がしやすくなります。

18.3. フローを安定化する

リモートチームで予測精度を高めるには、フローを安定化する必要があります。レビューの時間帯、確認ルール、連絡方法、Doneの定義を明確にすると、作業のばらつきが減ります。

フローが安定すれば、過去データを使った予測も信頼しやすくなります。リモート環境では、暗黙のやり取りに頼らず、ルールを明文化することが重要です。

18.4. 予測精度を向上させる

リモートチームの予測精度を向上させるには、データとコミュニケーションの両方が必要です。リードタイムやスループットを測定しつつ、遅延の背景をチームで共有します。

予測精度は、単にツールを使うだけでは高まりません。ボードを見て、待機やブロッカーに早く気づき、必要な支援を行う文化が必要です。

19. AI時代の進捗予測

AI時代には、進捗予測の前提が変わります。AIによってタスク生成、コード生成、テスト案作成、ドキュメント作成が速くなる一方で、Human Reviewや品質確認が新たなボトルネックになりやすくなります。

Kanbanによる予測では、AIが生み出す作業量だけでなく、生成物がレビューされ、修正され、完了するまでのフロー全体を見る必要があります。

19.1. タスク生成量が増加する

AIを使うと、ユーザーストーリー、実装タスク、改善案、テストケースなどを短時間で大量に生成できます。しかし、生成されたタスクがすべて価値ある作業とは限りません。

進捗予測では、生成量ではなく完了量を見る必要があります。AIでタスクが増えるほど、バックログサイズやWIPが膨らみ、予測が難しくなる可能性があります。

19.2. レビュー工程が重要になる

AI生成物が増えると、レビュー工程の重要性が高まります。コード、仕様、テスト、ドキュメントを人間が確認しなければ、品質リスクが残ります。

レビュー工程がボトルネックになると、AIによる生成速度が速くても完了速度は上がりません。Kanbanでは、レビュー待ちを可視化し、予測に含める必要があります。

19.3. Human Review負荷を考慮する

AI時代の進捗予測では、Human Review負荷を考慮する必要があります。人間が確認できる量を超えてAI生成物が増えると、レビュー待機時間が長くなります。

Human Review待機時間やレビュー工程のWIPを測定すれば、AI活用が本当にフロー改善につながっているかを判断できます。生成量だけで成功を判断してはいけません。

19.4. フロー全体を予測する

AI時代には、生成、レビュー、修正、テスト、承認、リリースまでのフロー全体を予測する必要があります。AIが作る部分だけを見ても、実際の完了時期はわかりません。

Kanbanを使えば、AI生成物がどの工程で止まっているかを可視化できます。予測では、AIの速度ではなく、価値がDoneまで流れる速度を見ることが重要です。

AI導入前後における予測モデルの違い

20. 予測でよくある失敗

Kanbanで進捗予測を行うときにも、よくある失敗があります。平均値だけを使う、WIPを無視する、データ量が不足している、予測を確約として扱うといったパターンです。

こうした失敗を避けるには、予測を不確実性のあるものとして扱い、データの前提を確認する必要があります。予測は管理のためだけでなく、学習と改善のためにも使います。

20.1. 平均値だけを使う

平均値だけを使った予測は、リスクを見落としやすくなります。平均リードタイムが7日でも、一部の作業が20日かかるなら、重要案件ではそのリスクを考慮する必要があります。

予測では、平均だけでなく分布やパーセンタイルを見ることが重要です。確率で説明することで、より現実的な見通しになります。

20.2. WIPを無視する

WIPを無視した予測は、楽観的になりやすいです。過去のリードタイムが短くても、現在のWIPが多すぎる場合、作業は通常より長くかかる可能性があります。

予測を行うときは、現在のWIP、レビュー待ち、ブロッカーを確認します。フローの状態が過去と違うなら、予測も調整する必要があります。

20.3. データ量が不足している

データ量が不足していると、予測の信頼性は下がります。数件の過去データだけで予測すると、外れ値の影響を強く受ける可能性があります。

データが少ない場合は、予測の不確実性が高いことを明示します。継続的にデータを蓄積し、予測モデルを少しずつ改善することが重要です。

20.4. 予測を確約として扱う

予測を確約として扱うことは大きな失敗です。Kanbanの予測は、過去データに基づく見通しであり、未来を保証するものではありません。

ステークホルダーには、確率とリスクを含めて説明する必要があります。「必ず終わる日」ではなく、「この確率で完了する見込み」と伝えることが大切です。

21. モンテカルロシミュレーションの活用

モンテカルロシミュレーションは、過去のスループットやリードタイムを使って、将来の完了時期や完了量を確率的に予測する方法です。Kanbanの進捗予測と相性が良いアプローチです。

この方法を使うと、単一の予定日ではなく、「何%の確率でいつまでに終わるか」を示しやすくなります。特に複数タスクやリリース予測に有効です。

21.1. モンテカルロ法の概要

モンテカルロ法とは、過去データのばらつきを使って多数のシミュレーションを行い、将来の結果の分布を推定する方法です。Kanbanでは、過去のスループットやリードタイムを入力データとして使えます。

たとえば、過去の週ごとの完了数をもとに、今後何週間で残りタスクが完了するかを何千回も試算します。その結果から、50%、85%、95%の確率での完了時期を考えられます。

21.2. スループット予測への応用

スループット予測では、過去の完了数を使って、将来の完了量をシミュレーションします。これにより、「今後4週間で何件完了できそうか」を確率付きで考えられます。

単純な平均を使うよりも、過去のばらつきを反映できる点がメリットです。完了数が安定していないチームほど、確率的な予測が役立ちます。

21.3. 完了日予測への応用

完了日予測では、残り作業数と過去のスループットを使って、いつすべての作業が完了しそうかをシミュレーションします。リリース予測やプロジェクト完了予測に使えます。

たとえば、残り40件の作業があり、過去の週次スループットを使ってシミュレーションすれば、何週後に完了する可能性が高いかを推定できます。日付を確定するのではなく、確率で示すことが重要です。

21.4. リスク評価への活用

モンテカルロシミュレーションは、リスク評価にも役立ちます。予測結果の幅が広い場合、完了時期の不確実性が高いことを示します。

リスクが高い場合は、WIPを減らす、スコープを調整する、ボトルネックを改善するなどの対策が必要です。シミュレーションは、意思決定の材料として活用します。

モンテカルロシミュレーションの予測イメージ

22. データ駆動型の予測文化を作る

Kanbanで進捗予測を成功させるには、データ駆動型の予測文化が必要です。個人の感覚や希望だけでなく、実績データを見て判断する習慣を作ることが重要です。

予測文化は、一度のダッシュボード作成で完成するものではありません。データを蓄積し、定期的に分析し、予測を更新し、学習を続けることで育ちます。

22.1. 実績データを蓄積する

まず、実績データを蓄積する必要があります。作業の開始日、完了日、作業タイプ、待機時間、レビュー時間、スループットなどを継続的に記録します。

データがなければ、予測は感覚に頼ることになります。最初から完璧なデータを集める必要はありませんが、継続的に記録する仕組みを作ることが大切です。

22.2. 定期的に分析する

データは、集めるだけでは意味がありません。定期的に分析し、リードタイムのばらつき、WIPの増加、スループットの変化、ボトルネックの傾向を確認します。

分析の場は、チームの振り返りや計画会議と連動させると効果的です。データを見ながら、次に何を改善するかを話し合います。

22.3. 予測を更新する

予測は、最新データに基づいて更新する必要があります。新しい作業が完了すればスループットが変わり、ボトルネックが改善されればリードタイムも変わる可能性があります。

予測を更新することは、計画が失敗したという意味ではありません。現実に合わせて見通しを調整することが、データ駆動型の予測では重要です。

22.4. 学習を継続する

データ駆動型の予測文化では、予測の当たり外れから学ぶことが重要です。なぜ予測より遅れたのか、なぜ早く完了したのかを確認することで、次の予測精度を高められます。

予測は、単なる報告ではなく学習の機会です。チームが予測と実績の差を前向きに扱えるようになると、Kanbanの価値は大きく高まります。

23. ステークホルダーとのコミュニケーション

Kanbanによる進捗予測は、ステークホルダーとのコミュニケーションにも役立ちます。重要なのは、予測を断定的に伝えるのではなく、確率、不確実性、リスクを含めて共有することです。

データに基づいた説明ができれば、過度な期待や無理な納期設定を避けやすくなります。予測は、合意形成と期待値調整のための道具です。

23.1. 確率で説明する

ステークホルダーには、予測を確率で説明することが有効です。「必ず月末に終わる」ではなく、「過去データでは85%の確率で月末までに完了する見込み」のように伝えます。

確率で説明することで、不確実性を隠さず共有できます。ビジネス判断では、リスクの低い見通しと早い見通しを分けて考えやすくなります。

23.2. 不確実性を共有する

進捗予測には必ず不確実性があります。仕様変更、レビュー遅延、外部依存、緊急対応などによって予測は変化します。

不確実性を共有することは、弱さではありません。むしろ、現実的な判断をするために必要です。何が予測に影響するのかを明示することで、ステークホルダーとの信頼関係が高まります。

23.3. リスクを明示する

予測を共有するときは、リスクも明示します。たとえば、レビュー工程が詰まっている、WIPが多い、外部承認が未確定、データ量が少ないといった条件を説明します。

リスクを明示すれば、ステークホルダーは必要な判断をしやすくなります。スコープを減らす、優先順位を変える、追加支援を出すなどの選択肢を検討できます。

23.4. 期待値を調整する

Kanbanの予測は、期待値調整に役立ちます。過去データに基づいて現実的な見通しを示すことで、無理な約束や直前の混乱を防ぎやすくなります。

期待値を調整するには、単に遅れる可能性を伝えるだけでなく、選択肢を提示することが重要です。納期を守るために何を削るか、品質を守るために何を延ばすかを話し合います。

24. Kanbanによる予測精度向上の条件

Kanbanによる予測精度を高めるには、いくつかの条件があります。フローが安定していること、十分なデータがあること、WIP制限が機能していること、継続的改善が行われていることが重要です。

これらの条件が整っていない場合、予測は不安定になります。予測精度を高めるには、予測手法だけでなく、フローそのものを改善する必要があります。

24.1. フローが安定している

予測精度を高めるには、フローが安定していることが重要です。リードタイムやスループットのばらつきが大きい状態では、将来の完了時期を予測しにくくなります。

フローを安定させるには、WIPを管理し、ボトルネックを改善し、作業項目の粒度を整える必要があります。安定したフローは、信頼できる予測の前提です。

24.2. データが十分にある

十分なデータがなければ、予測の信頼性は下がります。数件の過去データだけでは、作業のばらつきやリスクを十分に把握できません。

データが少ない場合は、予測の不確実性が高いことを明示します。継続的にデータを蓄積し、予測を少しずつ改善していくことが重要です。

24.3. WIP制限が機能している

WIP制限が機能しているチームは、フローが安定しやすくなります。作業を始めすぎず、完了に集中できるため、リードタイムやスループットも予測しやすくなります。

WIP制限が守られていない場合、予測は不安定になります。進捗予測を改善するには、まずWIPの状態を確認し、必要に応じて制限を見直します。

24.4. 継続的改善が行われている

予測精度は、継続的改善によって高まります。ボトルネックを改善し、レビュー待ちを減らし、作業サイズを整えることで、フローのばらつきが小さくなります。

予測は、改善の結果として良くなります。予測手法だけを高度にしても、フローが不安定なままでは精度は上がりません。

25. Kanbanを活用した現実的な進捗予測

Kanbanを活用した進捗予測では、見積もり依存を減らし、データに基づいて判断し、予測可能性を高め、継続的に学習することが重要です。これは、計画を不要にするという意味ではありません。

むしろ、Kanbanは計画を現実に近づけるための方法です。過去データと現在のフロー状態を組み合わせることで、より信頼できる見通しを作れます。

25.1. 見積もり依存を減らす

Kanbanでは、個別タスクの見積もりだけに依存しない予測ができます。リードタイムやスループットを使えば、過去の完了実績をもとに現実的な見通しを作れます。

見積もりを完全になくす必要はありませんが、見積もりだけを予測の根拠にしないことが重要です。実績データを使うことで、予測の説得力が高まります。

25.2. データに基づいて判断する

Kanbanの進捗予測では、データに基づいて判断します。リードタイム分布、スループット、WIP、累積フロー図を見れば、現在の状況と今後の見通しをより客観的に説明できます。

データに基づく判断は、感覚や希望に左右されにくい点がメリットです。ただし、データの背景を理解し、現場の文脈と合わせて解釈する必要があります。

25.3. 予測可能性を高める

Kanbanの目的は、単に早く終わらせることではなく、予測可能に価値を届けることです。リードタイムやスループットが安定すれば、ステークホルダーとの約束もしやすくなります。

予測可能性を高めるには、WIP制限、ボトルネック改善、作業項目の分割、レビュー工程の安定化が必要です。進捗予測は、フロー改善と一体で考えるべきです。

25.4. 継続的に学習する

Kanbanの進捗予測は、継続的に学習する活動です。予測と実績を比較し、なぜ差が生まれたのかを確認することで、次の予測が改善されます。

予測が外れた場合も、それは失敗ではなく学習の機会です。データを蓄積し、フローを改善し、予測を更新し続けることで、Kanbanによる進捗予測はより実用的になります。

おわりに

Kanbanで進捗を予測する方法は、勘や希望的観測に頼るのではなく、実際のフローデータを使って現実的な見通しを作るアプローチです。リードタイム、スループット、WIP、サイクルタイム、SLE、累積フロー図などを活用することで、作業がいつ完了しそうか、どれくらいの確率でリリースできそうかを説明しやすくなります。

重要なのは、予測を確約として扱わないことです。Kanbanの予測は、過去データと現在のフロー状態に基づく確率的な見通しです。平均値だけを見たり、WIPを無視したり、データ不足のまま断定したりすると、予測は楽観的になりやすくなります。

AI時代には、進捗予測の重要性がさらに高まります。AIによってタスクやコードの生成速度は上がりますが、Human Review、品質確認、レビュー待ちが新しいボトルネックになる可能性があります。だからこそ、生成量ではなく、完了までのフロー全体を見ることが必要です。

Kanbanを活用した進捗予測を成功させるには、フローを安定させ、実績データを蓄積し、予測を継続的に更新することが重要です。データに基づいて学習し続けるチームほど、現実的な計画を立て、ステークホルダーと信頼性の高いコミュニケーションを行えるようになります。