プラクティス名（別名）
WIP制限 （Work In Progress Limits、Work In Process Limits）
プラクティスの目的・狙い
- フロー効率の改善（リードタイム、スループットの向上）
- ボトルネックの特定と解消
- コンテキストスイッチ（切替負荷）の削減
どんな時に使うか
- チームが色々な作業を抱えすぎていて、タスクがなかなか掃けない時
- 開発プロセスの中でどの工程がボトルネックになっているのかが見えない時
実施手順
- タスクボードの工程（レーン）ごとに同時に着手してよいタスク数の上限を明示する
- 新たなタスクに着手する時、そのレーンのWIP制限を超えていないことを確認する
- WIP制限を超えてしまう場合は、すでに着手中の別タスクを終わらせることを手伝う
- タスクが滞留しがちな工程が分かってきたら、WIP制限を調整し、様子を見る
- 以降、調整を繰り返すことで、チームにとって最適なバランスを見つけ出す
| 調整方法 | メリット | デメリット |
|---|---|---|
| WIP制限を小さくする | フロー効率が上がる | メンバーの待ち時間が増える |
| WIP制限を大きくする | メンバーの待ち時間が減る | フロー効率が下がる |
WIP制限はいくつから始めてもよいのですが、目安としては合計値がチーム人数の1～2倍に収まるのがよいでしょう。それ以上だと実質的に制限なくタスクに着手できてしまう状況が生まれやすく、そもそも制限をかける意味が薄れてしまいます。
アレンジ例
- WIP制限の合計値をチーム人数よりも小さく設定することでペア作業を促進する
- 突発的な緊急タスクを処理するための専用スイムレーンを設ける（そのレーンにあるタスクはWIP制限にカウントしない）
- WIP制限を工程ごとではなく別の単位で設定する
例1：チーム全体でいくつと制限する（＝トータルコントロール）
例2：ユーザストーリー（PBI数）で制限する（＝フィーチャにフォーカス）
例3：メンバーごとに制限する（＝属人化防止）
アンチパターン
- WIP制限＝1（通称1個流し）を理想とし、マルチタスクの完全撲滅を目標にする（フロー効率は最大化するがメンバーの待ち時間が増えるデメリットがある）
- WIP制限を超えて新たなタスクに着手するために、すでに着手中のタスクを１つ前のレーンに差し戻す（ボード上でつじつま合わせしたにすぎず、かえってタスク状況が分からなくなる）
参考情報
書籍『カンバン仕事術』
WIP制限のベースにある「ToC理論（制約理論）」とカンバンの関係については @hamachi4708 (はまちよ) さんの記事が端的にまとまっていて分かりやすいと思いましたので、ご紹介させていただきます。
こぼれ話（私的コメント）
タスクがどれだけ待ち時間無くスムーズに流れていくかをフロー効率と呼びます。一方、タスクを処理するリソース（人や機械）がどれだけ手隙にならずに稼働しているかをリソース効率と呼びます。フロー効率とリソース効率はトレードオフの関係にあり、どちらを高めるのが正解とは一概に言えません。大切なのはそのバランスです。ただ伝統的な企業において、とくに「人」はリソース効率を最大化するように最適化されているケースが多いので、フロー効率の観点からバランスをとり直す必要があります。カンバン界隈にはそのことを端的に表す「始めるのをやめて、終わらせることを始めよう」というスローガンがあります。またWIP制限はあくまでもチームを改善するための手段なので「制限をかけないことが最終的なゴール」になるそうです。
働きアリと揶揄される日本人はリソース効率重視で、空いてる人がいる＝悪、という思い込みが強いように感じます。実は自然界においてはそうではないみたい。アリの世界では全員が常に仕事に従事している状態が続くと逆に群れとしての寿命は短くなってしまうらしい。そのためアリは仕事する個体としない個体が8:2になるような仕組みが備わっているそうです（ただし交代制）。日頃から多少の余剰人員を抱えておくことで突発的なタスクにも対処できるようになり、群れとしては安定的に存続できるわけですね。（出典：『働かないアリに意義がある』長谷川英祐：著）