タスクが多いほど進まない──開発が詰まる“WIP過多”の落とし穴

「忙しいのに、進んでいない気がする」
スプリントの後半になるほど、PRは溜まり、レビューは滞り、会議は増え、チャットは鳴り続ける。
なのに、マージされた成果物の数は伸びない。リリースも遅れる。焦りだけが残る。

この状態を、能力不足とか集中力の問題にしてしまうと、だいたい悪化します。
原因はもっと構造的で、そして多くの場合、手が打てます。

結論から言うと、詰まりの正体は「タスク量」そのものではなく、WIP（Work In Progress：進行中作業）の過多です。
WIPが増えるほど、開発は“忙しくなるのに遅くなる”。ここに落とし穴があります。

今日は、エンジニア目線で「WIP過多がなぜ詰まるのか」「どう減らすと流れが戻るのか」を、現場で再現できる形でまとめます。
スクラムでもカンバンでもウォーターフォールでも、ツールが何でも使える話にします。

WIP過多とは何か（ざっくり言うと「同時に抱えすぎ」）

WIP過多は、単に「タスクが多い」ではありません。
ポイントは、“同時に進めている”タスクが多いことです。

• PR(プルリクエスト)を3本並行で書いている

• バグ修正と機能追加と調査を同時に抱えている

• 「このタスクは待ち」状態が大量にある（依頼待ち、確認待ち、レビュー待ち）

• 進捗ボードの「In Progress」が膨らみ続ける

これらが積み上がると、開発のスループットが落ちます。
直感に反して、「頑張って並行するほど遅くなる」。

なぜか。理由は技術ではなく、人間とチームの仕組みにあります。

なぜWIPが増えると遅くなるのか：3つのメカニズム

1) コンテキストスイッチのコストが“見えない税金”になる

1つの作業に没入している状態から別の作業へ切り替えるとき、脳内で状態復元が発生します。
「どこまで考えたか」「前提は何か」「何が未解決か」を、再ロードする。

この時間は、チケット管理にもGitにも記録されません。
でも確実に消費されます。

WIPが増えるほど、この“見えない税金”が増え、実作業の時間が削られます。
しかも、切り替えが増えるほどバグ率も上がる。
結果として、さらにレビューが詰まり、手戻りが増え、またWIPが増える。

負のループです。

2) 待ち行列が発生し、ボトルネックが詰まる

チームには必ずボトルネックがあります。

• レビューできる人が限られている

• QA環境が混む

• 仕様確認できるPMが忙しい

• インフラ変更の承認に時間がかかる

WIPが少ないと、ボトルネックは「詰まってもすぐ空く」。
でもWIPが多いと、ボトルネック前に待ち行列が伸びます。

ここで起きるのが、“止まっているタスクを抱えたまま、次のタスクに着手する”という自然な行動。
そしてさらにWIPが増える。
これが、開発が詰まる典型です。

3) 品質が落ち、統合が遅れ、最後に爆発する

WIPが多いと、個々のタスクは小さく見えても、統合が遅れます。

• ブランチが長生きする

• 差分が大きくなる

• 依存が増える

• コンフリクトが増える

• 結果的にマージが怖くなる

最後にまとめて統合しようとすると、爆発します。
そして「もっと早くから統合しておけば…」となる。

WIP過多は、統合遅延を引き起こし、最後にコストとして回収される構造です。

ありがちな“WIP過多を生む動き”チェックリスト

WIP過多は、善意で発生します。
次の行動に心当たりがあると、かなりの確率でWIPが膨らんでいます。

• 依頼が来たら、とりあえず着手して“安心”する

• PRレビュー待ちの間に、新しいブランチを切る

• 会議の宿題が積まれたまま、別タスクを始める

• 「今しかない」案件を優先して、元タスクが宙ぶらりんになる

• “進捗”を見せるために、手を広げる

どれも悪ではありません。
でもチームとして見ると、流れが止まる方向へ働きます。

WIPを減らすと何が起きるか：チームが速くなる“逆説”

WIPを減らすと、最初は不安になります。
手を広げないと進んでいない気がするからです。

でも、WIPを絞ると次が起きます。

• 1本のPRが早くマージされる

• リリースが前に進む

• 待ち行列が短くなる

• “完了”が増える

• 完了が増えると、心理的安全性が上がる（焦りが減る）

つまり、スループットが上がる。
忙しさではなく、完成が増える。

この「完成が増える」感覚が、チームの呼吸を整えます。

実務で使える：WIP過多を解消する5つの打ち手

1) WIPの“見える化”を先にやる（測れないものは直せない）

まず、事実を取ります。難しくなくていい。

• 個人単位：同時に抱えているタスク数（進行中＋待ち）

• チーム単位：ボードのIn Progress列の数

• レビュー待ちPR数、平均滞留時間

• “待ち”の理由の内訳（レビュー待ち、仕様待ち、環境待ち）

数字が出ると、議論が「気合い」から「設計」に変わります。

2) WIPリミットを“列”にかける（個人にかけるより効く）

個人に「抱えすぎないで」と言っても、現場は守りにくい。
効くのは、フローに制約を入れることです。

例：

• In Progress：最大N枚

• Review：最大M枚

• QA：最大K枚

列が溢れたら、新規着手は禁止。
代わりに、詰まりを解消する作業を優先します。

ここで重要なのは、WIPリミットは“守れたら偉い”ルールではなく、
詰まりを発見するセンサーだという理解です。

3) 「新規着手」より「完了」を優先する合図を作る

WIPを減らす最短の言葉はこれです。

“Start finishing, stop starting.”（始めるのを止めて、終わらせ始める）

具体的には、朝会で毎回これを確認するだけでも変わります。

• 今日新しく始めるのは何？（ゼロでもいい）

• 今日終わらせるのは何？（必ず1つ以上）

「終わらせる」を会話の中心に置くと、流れが生まれます。

4) PRを小さくし、レビューを“先に”取る

WIP過多の中心に、レビュー滞留があることは多いです。
だからレビューの流れを整えると一気に改善します。

実務のコツ：

• PRは小さく（変更行数よりも“論点”を小さく）

• 先にレビューを取りたい論点は、実装前に提案書/ADRで共有

• レビュー担当を固定しすぎない（属人化で詰まる）

• レビュー時間の枠をカレンダーに置く（“いつやるか問題”を消す）

レビューが流れれば、マージが増え、WIPが勝手に減ります。

5) “待ち”を「止める」ではなく「潰す」優先順位へ

WIP過多の厄介さは、タスクが“止まっているのに進行中扱い”になることです。

おすすめは、待ちが発生したら次のどれかに必ず寄せること。

• 依頼を出しに行く（仕様確認を取りに行く、レビューを取りに行く）

• 代替案で進める（仮実装、モック、フラグで切る）

• いったんクローズする（やらない判断、次スプリントへ戻す）

“待ち”を抱えたまま新規着手すると、WIPが増えます。
待ちを潰す動きが、結果的に最短ルートになります。

個人エンジニアとして、今日からできる小さな一手

チームの制度を変えるのは時間がかかる。
でも個人でできることもあります。最小で効くのは次の3つです。

1. 自分のWIPを数える（進行中＋待ちを含めて）

2. レビュー待ちのPRを“放置しない”（取りに行く／分割する／補足を書く）

3. 新規着手の前に「完了できること」を探す（1つでも終わらせる）

これを1週間続けるだけで、「忙しいのに進まない」感覚が薄くなる人が多いです。
なぜなら、完成が増えるからです。

おわりに：開発を詰まらせるのは、仕事量ではなく“同時進行”だった

タスクが多いほど進まない。
この矛盾は、あなたの能力のせいではありません。
WIPが増えると、コンテキストスイッチ、待ち行列、統合遅延が増え、構造的に遅くなる。

だから、対策も構造で打てます。

• 見える化する

• 列にWIPリミットをかける

• 完了を優先する

• レビューを流す

• 待ちを潰す

開発がスムーズなチームは、根性で速いのではなく、
流れが速いだけです。

「忙しい」の手触りではなく、「完了が増える」手触りを取り戻す。
そのために、まずはWIPを減らす。
それが、詰まりをほどく最短ルートです。

次に読む