仕事が進まないチームへ──WIP制限で流れを取り戻す運用

タスクは積まれている。
やる気もある。会議もしている。進捗報告もしている。
それでも、なぜか前に進まない。

気づくと、誰もが忙しい顔をしているのに、完了が増えていない。
途中までの作業が増え、確認待ちが増え、差し戻しが増え、最後に炎上する。

この手の停滞は、個人の能力や気合では解けないことが多い。
理由はシンプルで、チームが動いていないのではなく、滞留しているからだ。

今日は、滞留を減らして流れを取り戻すための運用として、WIP制限（Work In Progress制限）をPMの型としてまとめる。
スクラムやカンバンの教科書ではなく、現場導入で揉めない形に寄せる。

1. 進まない原因は仕事量ではなく同時進行の量

現場でよくある錯覚はこれ。

タスクが多いから進まない
忙しいから遅い
人が足りないから詰まる

もちろん要因の一つではある。
でも、同じ人数でも突然進み始めるチームがある。違いは、同時に抱えている途中の量だ。

途中の作業が増えると、次のコストが増える。

• 切り替えコスト（脳のタブが増える）

• 依存待ち（レビュー待ち、確認待ちが溜まる）

• コミュニケーションコスト（状況説明が増える）

• 手戻りコスト（前提が変わったときの被害が大きい）

つまり、進まないのは働いていないからではなく、途中が多すぎるから起きる。

2. WIP制限は仕事を減らすのではなく完了を増やす

WIP制限は、同時に進めてよい作業数を制限する運用だ。
直感に反するけど、これで速度が上がることがある。

なぜか。
途中を減らすと、完了が増えるから。

完了が増えると、次が起きる。

• 実績データが増える（見積もりが当たる）

• 学習が増える（改善が回る）

• 不確実性が減る（火種が早く見える）

• チームが安心する（心理的負荷が下がる）

忙しさは減らなくても、進んでいる感覚が戻る。
これが現場には効く。

3. まずはボトルネックを見つける

WIP制限は、ただ絞ればいいわけじゃない。
どこが詰まっているかを見ないと、単に待ちが増える。

最初に見るべきは、いちばん滞留が長い工程。たとえばこう。

• 要件確認の待ち

• 設計レビュー待ち

• 実装レビュー待ち

• テスト環境待ち

• 受け入れ確認待ち

• 承認待ち

カンバンでもスプレッドシートでもいい。
各工程に、着手中が何件あり、平均で何日止まっているかを見える化する。

ボトルネックが見えたら、WIP制限はそこに合わせて設計する。

4. 導入しやすいWIP制限の決め方

現場で揉めにくい決め方は、次の順番。

ステップ1：工程ごとに上限を置く

一気に全体を制限すると反発されやすい。
まずは詰まりやすい工程だけ、上限を置く。

例

• レビュー待ち：最大3件

• テスト中：最大2件

• 受け入れ確認待ち：最大2件

ステップ2：上限は少なすぎず多すぎず

最初から最適化しない。試運転で調整する。

目安は、担当者数×1〜2。
レビュー担当が2人ならレビュー待ちは2〜4件くらいから始める、みたいな感覚。

ステップ3：上限を超えたら新規着手は禁止

ここが運用の核心。
上限を超えているのに新規着手を許すと、WIP制限は形骸化する。

代わりにやることは決めておく。

• 既存の滞留を解消する

• ボトルネック工程を手伝う

• 前倒しで障害を潰す（環境整備、テストデータ準備）

• 未確定を潰す（仕様確認、合意取り）

これができると、チームは強くなる。

5. 重要なのは例外ルールを先に決めること

WIP制限が崩れる最大の原因は、例外が無限に発生することだ。

• これは急ぎだから例外

• これは重要だから例外

• これは小さいから例外

例外が増えると、結局いつも通りに戻る。

だから、例外は最初からルールにする。おすすめは2種類だけ。

• 緊急（インシデント、障害、売上直撃）

• 期限固定（法令、監査、外部リリース日が動かない）

そして例外を入れるときは、必ず何かを落とす。
入れるだけだとWIP制限の意味が消える。

6. WIP制限で起きる反発への対処

導入すると、だいたい同じ反発が出る。

反発A：みんな暇になるのでは

実際は逆で、暇になるのはごく短期間。
すぐにボトルネック工程の支援や、未確定潰しに時間が回る。

暇が怖いのは、仕事を増やす文化の名残だ。
でもチームで見るべき指標は稼働率ではなく完了率。

反発B：待ちが増えるのでは

待ちは増える可能性がある。
ただし、その待ちは可視化された待ちになる。

見えない待ちは炎上に直結する。
見える待ちは改善につながる。ここは価値が違う。

反発C：個人の裁量が減る

裁量を減らすのが目的ではない。
チームの流れを守るための最低限の制約だ。

裁量は、仕組みが回ってから増やしたほうがいい。
最初から自由にすると、途中が増えて全員が不自由になる。

7. PMが持つべきKPIは完了数と滞留時間

WIP制限を入れたら、見る指標を変える。
進捗率や稼働率ではなく、次の2つを見る。

• 週あたりの完了数（Doneがいくつ増えたか）

• 工程別の滞留時間（どこで止まっているか）

完了数が増え、滞留時間が短くなるなら成功。
完了数が増えないなら、制限が強すぎるか、ボトルネックが別にある。

ここを週次で軽く振り返るだけで、運用が回り始める。

まとめ：速くするには始めない、終わらせる

仕事が進まないチームは、たいてい始めすぎている。
途中を増やして安心しようとして、逆に遅くなっている。

WIP制限は、完了を増やすための運用だ。

• ボトルネック工程を見つける

• 工程ごとに上限を置く

• 上限超過時は新規着手を止める

• 例外ルールは先に固定する

• 指標は完了数と滞留時間を見る

最後に問いを置く。
いまあなたのチームで一番滞留している工程はどこで、そこにWIP制限を入れるなら上限はいくつが現実的だろう？

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！