WIP制限ポリシー (WIP Limit Policy)
WIP 制限ポリシーとは、ワークフロー内の特定の状態にある作業項目の数に上限を定め、進行中の作業（WIP）を明示的に制御する方針である。この制御は、プルシステムの成立や集中・確約・協調の向上に寄与し、カンバンボード上では各列に数字として表示される。また、フロー指標の一つとしての WIP は「開始しているがまだ終了していない作業項目の数」を指す。
ワークフローの定義（DoW）の必須要素として「開始から終了までの間の WIP の制御方法」が含まれ、カンバンシステムメンバーはこの制御を明示的に行わなければならない[1]。数値による上限（WIP 制限）はその最も一般的な形であり、Open Guide to Kanban や Kanban Guide for Scrum Teams では「WIP 制限」の語で扱われる[2]。DoW で定められた制限を WIP が下回ったとき、それが新たな作業を選択してよい合図となりうる[1]。WIP 制限は、ボトルネックの特定や改善に繋げるための指標としても機能し、カンバンボード上では各列に数字として表示される[3]。WIP を制御することはワークフローの改善に役立ち、カンバンシステムメンバーの全体的な集中力、確約、協調を高めることにもつながる[1]。また、フロー指標における WIP は「開始しているがまだ終了していない作業項目の数」であり、リトルの法則により WIP を制限することは平均サイクルタイムの短縮に直結する[4]。
事例研究では、設計段階のWIPを同時並行3プロジェクトに制限することで、スループットとリソース利用の面で適切な結果を得ることを狙った[5]。
仕掛品制限ポリシーは、並行作業を抑制してフィードバックサイクルを短縮するために、チーム特性や状況に応じて柔軟に調整・検査されるべき方針である[6]。
- 所属タグ: Kanban Workflow Limit
- カテゴリー: Kanban & Flow
オントロジー上の位置
Section titled “オントロジー上の位置”- 上位クラス（直接の親から順に）: 未定義
- 兄弟クラス: 未定義
- 他の概念との関係: 未定義
- 関連する検証ルール: K1
- 関連CQ: 未対応
- 原文: 未定義
- オントロジー階層: オントロジー階層で見る
KGO における表現
Section titled “KGO における表現”KGO は WIP 制限を kgo:WIPLimitPolicy クラスで表し、次のプロパティを持つ。
| プロパティ | 意味 |
|---|---|
kgo:wipLimit | 適用対象にある作業項目数の上限値 |
kgo:appliesToState | 上限を適用する状態クラス（通常は kgo:InProcess） |
kgo:appliesToColumn | 上限を適用するワークフロー列（kgo:WorkflowColumn）。状態とは独立した軸 |
ワークフローの定義（kgo:DefinitionOfWorkflow）は kgo:hasWIPLimitPolicy で WIP 制限ポリシーを束ねる。K1 の集計は 2 通りある。kgo:appliesToState を持つポリシーは、その状態クラス（通常は kgo:InProcess）に属する作業項目だけを数える。ガイドの WIP は「開始しているが、まだ終了していない作業項目の数」なので、kgo:ToDo（開始前）や kgo:Done（終了済）にある作業項目は kgo:InProcess の集計に混ざらない。kgo:appliesToColumn を持つポリシーは、その列に kgo:inColumn で属する作業項目を状態に関わらず数える（Dev 列 3 件・Review 列 2 件のように、同じ kgo:InProcess に属する複数の列へ別々の上限を置くため）。ブロック中の作業項目（kgo:isBlocked が true）は進行中である限り WIP に含める。
Process Constraints (プロセス制約)
Section titled “Process Constraints (プロセス制約)”KGO (Kanban Guide Ontology) に基づく、この概念に関係する制約です。各制約の括弧内は、その制約が対象とするクラスです。
- K1 (WIPLimitPolicy): WIP 制限（kgo:WIPLimitPolicy の kgo:wipLimit）を超える数の作業項目が、適用対象の状態（kgo:appliesToState）または列（kgo:appliesToColumn）に存在する場合、WIP 制限違反として不適合になります。カンバンシステムメンバーは「ワークフローの開始から終了までの作業項目の数を明示的に制御しなければならない」（Kanban Guide 2025）ためです。状態単位の上限（kgo:appliesToState）は指定した状態クラスに属する作業項目だけを数え、列単位の上限（kgo:appliesToColumn）はその列にある作業項目を状態に関わらず数えます。開始前（kgo:ToDo）・終了済（kgo:Done）の作業項目は WIP（進行中）の集計には混ざりません。
- K7 (WorkflowColumn): 進行中（kgo:InProcess）の作業項目がいる列が、状態単位の WIP 制限（kgo:appliesToState が kgo:InProcess）でも、その列を対象とする列単位の WIP 制限（kgo:appliesToColumn）でも覆われていない場合、WIP 制御の被覆違反として不適合になります。DoW は「開始から終了までの間の WIP の制御方法」を求めますが（Kanban Guide 2025）、K1 は上限を超えたかどうかだけを見るため、どの制限も掛かっていない進行中の列は素通りします。この判定は入口版の点検（review_board の kanban）で行い、WIP の上限が渡されないときは評価されません。作業項目がいない列は入力に現れないため、覆われているかを確かめられません。
-
Kanban Guide 2025 — 「カンバンシステムメンバーは、ワークフローの開始から終了までの作業項目の数を明示的に制御 しなければならない。」「WIP を制御することによる効果のひとつは、プルシステムを生み出すことにある。」「WIP を制御する上で許容可能な例外は、DoW の一部として明示しておくべきである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3
-
Open Guide to Kanban — 「ナレッジワークにおけるカンバンで WIP 制限 (16) が用いられているのは、需要がチーム のキャパシティを上回る可能性があることを示している場合が多い。そのため、WIP 制限 (16) は、作業項目のフローを調整し、バランスを保ち、過負荷を防ぐために用いられる。」（ライセンス: CC BY-SA 4.0） ↩
-
12. Wikipedia (2025) ‘Kanban (development)’. Available at: https://en.wikipedia.org/wiki/Kanban_(development) (Accessed: 22 June 2025). — 「「完了待ち」と「進行中」の両方のサブカラムに対してWIPの上限を設定することで、これらの段階への流入や流出を防ぎます。」（訳）（ライセンス: CC BY-SA 4.0） ↩
-
Kanban Guide for Scrum Teams 2021 — 「スクラムチームは、自分たちが適切だと思えばどのようにWIP制限をかけても構わ ないが、いちど設定したものは守らなければいけない。」（ライセンス: CC BY-SA 4.0） ↩
-
Modern Project Management Approaches in Uncertainty Environments: A Comparative Study Based on Action Research — 「設計段階の場合、スループットとリソース利用の面で適切な結果を得るために、WIPを同時並行3プロジェクトに制限した。」（訳）（ライセンス: CC BY 4.0） ↩
-
Collaboration and Uncertainty Management in Agile Software Development: A Systematic Integrative Review and Literature-Based Positioning of CDM — 「仕掛品（WIP）制限は注意力を保護し、作業を開始してからフィードバックを得るまでの道のりを短縮することができる[17]。」（原文: “Work-in-progress limits protect attention and can shorten the path from starting work to obtaining feedback [17].”）（訳）（ライセンス: CC BY 4.0） ↩