WIP制限とは：Kanbanでの設定方法（実例つき）

仕掛り作業（WIP）制限は、チーム内で作業がどれだけ速く流れるかを改善する最も手っ取り早い方法の1つです。Kanbanボードの各列の上に数字を設定するだけで、ルールはシンプルです。すでに列が制限に達している場合、誰も新しい作業に着手しません。

重要ポイント

• Kanban Universityの実践者調査（2023年）によると、WIP制限を徹底しているチームは、そうでないチームに比べてサイクルタイムが2倍速いと報告しています。
• 中断の後に完全に集中を取り戻すまでに、働く人は平均で23分を要し、複数のタスクが同時進行しているとその影響は複合的に大きくなります（University of California, Irvine、2023年）。
• 平均的なソフトウェアチームは1人あたり同時に3〜5件のアクティブなタスクを抱えていますが、ピークのスループットは通常、1人あたり1〜2件のタスクで達成されます（State of Agile Report、第17版、2024年）。

WIP制限とは

WIP制限（仕掛り作業制限）とは、ワークフローのある段階に同時に存在できる項目数に明示的な上限を設けるものです。Kanbanシステムでは、ボードの各列が1つの段階を表し、WIP制限はその列の上に数字として置かれます。ある列が制限に達すると、何かが次の段階に進むまで、誰もそこに新しい作業を取り込みません。

この概念は、リーン生産方式に直接由来しています。トヨタは工場現場での生産の流れを制御するために「かんばんカード」と呼ばれる仕組みを使っていました。過剰生産は無駄であるという考え方であり、同じ原則は知識労働にも当てはまります。着手したものの完了させないものが増えるほど、すべての動きが遅くなるのです。

WIP制限は、次に何に取り組むべきかを教えてくれるものではありません。いつ新しいことに着手するのをやめ、既存のものを完了させることに切り替えるべきかを教えてくれるものです。

なぜ仕掛り作業を制限するのか

WIP制限の根拠は、リトルの法則と呼ばれる次の式にあります。

サイクルタイム＝WIP÷スループット

平たく言えば、チームが20件の作業を同時進行させていて、週に5件を完了させている場合、平均サイクルタイムは4週間です。WIPを10件に減らせば、チームがそれ以上頑張らなくても、サイクルタイムは2週間に短縮されます。

この計算はきれい過ぎるように聞こえるかもしれませんが、その背後にある仕組みは実在するものです。制限がない場合に何が起こるか見てみましょう。

コンテキストスイッチが集中力を奪います。 誰かが古いタスクを終える前に新しいタスクに手をつけるたびに、精神的な切り替えコストを支払うことになります。このコストは軽視できません。UC Irvineの研究では、中断1回あたり20分以上の集中力の喪失があるとされています。これを1人あたり同時進行する3〜5件のタスクに掛け合わせると、切り替えのオーバーヘッドだけで1日の労働時間の大半を静かに消費していることになります。

長い行列は問題を隠します。 作業がある列に積み重なると、それは見えなくなります。レビュー待ちのタスクが3日間手つかずのまま放置されていても、ボードが混雑しすぎていてその遅れが目立たないため、誰も気づきません。WIP制限はこうしたボトルネックを即座に露呈させます。「レビュー中」の列が上限に達すれば、チームはなぜ項目が動いていないのかを話し合わざるを得なくなります。

フロー指標にはこれが直接反映されます。 累積フロー図を使っている場合、中間段階の帯が広いことは高いWIPの視覚的な兆候です。狭く並行した帯は、WIPが制御されていて作業が流れていることを意味します。WIP制限がチームの1サイクルあたりのコミット量を安定させると、アジャイルにおけるベロシティも改善する傾向があります。

WIP制限の設定方法

すべてのチームに通用する万能の公式はありません。ただし、以下のステップは、時間をかけて調整していくための出発点になります。

ステップ1：チームのキャパシティを数える

各段階で働く人数から始めましょう。開発者が4人いる開発列は、1〜2人しかいないレビュー列よりも多くの同時進行項目を処理できます。

よくある出発点のルールは、1人あたり2項目を各列に当てはめることです。したがって開発者が4人いる開発列は、WIP制限8から始めます。

ステップ2：現在の実際のWIPを見る

制限を設定する前に、今日時点で各列に実際に何件の項目があるかを数えましょう。これがベースラインになります。3人チームの「進行中」列にすでに14件あるなら、なぜ作業の完了にそれほど時間がかかっているのかが明確に見えてきます。

ステップ3：現在の平均よりやや低めに制限を設定する

各列の平均WIPが10件であれば、制限は3ではなく7か8から始めましょう。厳しすぎる制限は、特に初期段階では、解決するよりも多くの混乱を招きます。チームが制約を感じて反応することを目指すのであって、麻痺状態に陥らせることを目指すのではありません。

ステップ4：制限を厳格な遮断ではなく対話のきっかけとして徹底する

ある列が制限に達したら、チームの仕事は、新しい作業を取り込む前に、詰まっている作業に集中して片付けることです。これこそがWIP制限がチームの行動を変える場面です。「このアイテムがレビューを通過するのを手伝えないか」という問いかけが、後回しの発想ではなく日々の習慣になります。

ステップ5：2週間ごとに見直し調整する

2スプリントまたは2週間経過したら、バーンダウンチャートとサイクルタイムのデータを確認しましょう。項目がより速く流れているなら制限を厳しくします。チームが常に詰まっていると感じているなら、少し緩めます。WIP制限は石に刻まれたルールではなく、ダイヤルのようなものです。

ボードの列ごとのWIP制限

4列のKanbanボードを使う典型的なソフトウェアチームの参考テーブルです。これらは出発点であり、絶対的な処方箋ではありません。

開発者4人のチームであれば、妥当な初期設定は、To Do（上限なし）、進行中（6）、レビュー中（3）、完了（上限なし）です。これにより開発列がボトルネックになるのを防ぎ、レビューを軽量に保てます。

チームが2週間スプリントでScrumを使っている場合、スプリントボードにも同じようにWIP制限を適用できます。呼び方は違っても、ロジックは同一です。ScrumとKanbanの比較の違いがあっても、リトルの法則の根底にある数学は変わりません。

WIP制限を設定する際のよくある間違い

制限を設定しても無視してしまう。 チームが回避できてしまうWIP制限は、存在しないのと同じです。チームが「例外」として日常的に上限を無視しているなら、その制限は徹底されていません。プロセスを構築する前に、習慣を築きましょう。

すべての列に同じ数字を当てはめてしまう。 レビュアー2人のレビュー列と、開発者5人の開発列とでは、スループットがまったく異なります。この場面では万能の一律設定は誰にも合いません。

制限を急に低くしすぎてしまう。 各列15項目から一晩で3項目に落とすと、パニックと抵抗を生みます。段階的に絞り込むことで、チームはワークフローを適応させる時間を持ち、高いWIPが隠していた問題を表面化させられます。

ブロッカーを見落としてしまう。 WIP制限はブロックされている項目もカウントします。「進行中」の6件のタスクのうち3件が外部依存関係でブロックされているなら、実質的な稼働枠は3つしかありません。ブロッカーを別途追跡することで、実態に即した把握を保てます。

ストーリーポイントに応じて調整しない。 項目数で制限を設定するチームもあれば、ストーリーポイントで設定するチームもあります。タスクの規模が大きくばらついている場合（1ポイントのタスクと13ポイントのエピックが並存する場合など）、ポイントでカウントすることで、より実態に即した負荷の把握が得られます。

WIP制限のメリット

チームが実際に制限を徹底すると、いくつかのことが一貫して起こります。

作業がより速く完了する。 項目が待機したままにならないため、サイクルタイムが短くなります。チームが同時に5件しか抱えられない場合、その5件それぞれに日々の注意が向けられます。

ボトルネックが即座に見えるようになる。 常に上限に達している列は、何かを物語っています。それが他のすべてを詰まらせるため、チームはそれを無視できません。

チームの対話が改善する。 WIP制限は、遅れを見えないままにするのではなく、「なぜこれは詰まっているのか」と問いかける自然な瞬間を作ります。デイリースタンドアップは、「今何が進捗を妨げているか」という同じ問いにより焦点を絞れるようになります。

計画がより誠実になる。 チームが埋まった列を目にすると、対応しきれない新しい作業へのコミットをやめるようになります。過剰なコミットメントが減り、予測の精度が上がります。これは、WIPが制御下に入るとアジャイルにおけるベロシティが安定することと直接つながっています。

ストレスが減る。 直感に反するようですが、「あなたは5件しか担当できません」と言われる方が、「これら15件すべてを終わらせてください」と言われるよりもストレスは少ないのです。人は何に集中すべきかが分かります。

よくある質問

Kanbanにおけるウィップ（WIP）制限とは何ですか。 WIP制限とは、Kanbanの列の上に置かれる数字で、その段階に同時に存在できる作業項目の数に上限を設けるものです。列が制限に達すると、チームメンバーは新しい作業を取り込む前に、既存の作業を片付ける手助けをしなければなりません。

適切なWIP制限はどう計算すればよいですか。 各列で1人あたり2項目から始め、2週間観察しましょう。作業が流れており、サイクルタイムが改善しているなら、制限を厳しくします。チームが慢性的に詰まっていると感じているなら、緩めます。唯一の正解となる数字はありません。目標は、スループットを麻痺させることなくボトルネックを表面化させる制約を見つけることです。

WIP制限はKanban以外にも適用できますか。 できます。Scrumチームはスプリントボードに WIP制限を適用しています。ハイブリッドな手法やシンプルなタスクリストを使うチームでさえ、各人が同時に扱う項目数に緩やかな上限を設けることで恩恵を受けられます。根底にあるロジック、リトルの法則は、あらゆる待ち行列システムに当てはまります。

WIP制限に達するとどうなりますか。 チームはその列への新しい作業の取り込みを止め、既存の項目を片付けることに集中します。実務上、これはしばしば、詰まっているタスクに集中して取り組んだり、下流の誰かのブロックを解消するために即席のレビューを行ったりすることを意味します。この制限は、マネージャーの介入を必要とせずに緊急性を生み出します。

「To Do」列にもWIP制限を設けるべきですか。 通常は不要か、少なくとも厳格なものは必要ありません。To Doはバックログとして機能します。緩やかな上限（スプリントキャパシティの2倍など）は、その列がただの投げ込み場所になるのを防げますが、厳格な制限は、まだ着手する準備ができていない項目に人為的な緊急性を生み出しがちです。

---

WIP制限は小さな変更ですが、チームのフローに与える効果は非常に大きいものです。ある列が上限に達したことで初めてボトルネックが表面化するのを目にした瞬間、その仕組みが腑に落ちます。そこから先は、数字を調整していくだけです。累積フロー図でサイクルタイムを追跡し、WIPが下がったときに帯がどう変化するかを観察してみましょう。