仕掛かり制限 WIP limit 仕事｜数える線引き・上限の決め方・見直し3手順
公開 2026.11.02
仕掛かり制限(WIP limit)は、仕事で同時に抱える件数に上限を置く考え方です。依頼が重なり、あちこちに手を付けたのに何も終わらないときは、能力ではなく件数を見直す場面かもしれません。この記事の数字のうち、件数の目安と完了日の比較は編集部が置いた前提つきの算出・提案で、公表された基準ではありません。定義と運用の考え方だけが、Kanban Guide と DORA の公開ページに基づきます。
この記事の要点
- 仕掛かりは「手を付けたが、まだ終わっていない仕事の件数」。未着手は数えません
- 先に決めるのは件数でなく線引き。開始点・完了点・待ちの扱いを自分で書き出します
- 上限の初期値は、会議・突発の多さと待ちの多さの2軸で引き、2週間試して見直します
- 緊急の依頼は例外として、あらかじめ決めておきます
仕掛かりとは「手を付けて未完了の件数」で、未着手は数えない
仕掛かり(WIP)は、手を付けたがまだ終わっていない仕事の件数です。まだ手を付けていない依頼は、仕掛かりに入りません。
Kanban Guide(v2025.5)は、WIP を「開始したが未完了の作業項目の数」と定義しています。どこから開始とし、どこで完了とするかは、チームが自分で定義する前提です。仕事でも同じで、開始点と完了点は自分で決めてかまいません。
仕掛かり制限の方針は、抱える量を制限して、少数の優先タスクの完了に集中することです(DORA)。効果については、Kanban Guide は WIP を管理すると集中・コミットメント・協力が「高まることが多い」と書いており、常に効くとは言っていません。DORA の研究が示すのも、ソフトウェア提供の性能の話です。事務の仕事に当てはめた効果は、公表された研究では確認できません。この記事の当てはめは編集部の提案です。
「着手ばかりで終わらない」は、頑張りの不足ではなく、仕掛かりの件数が多いことで起きている可能性があります。まずは数えるところから始めます。
数える線引きは「開始点・完了点・待ち」を自分で決めて書き出す
線引きは、開始点・完了点・待ちの3つを自分の仕事ごとに決めて書き出します。決めないまま上限だけ置くと、何件抱えているのか数えられません。
待ち(承認待ち・回答待ち)の件は、開始済みでまだ完了していないので、定義上は仕掛かりに入ります。下の表は事務の場面別の線引き例で、編集部の提案です。職場にルールがあるなら、そちらを優先してください。
| 場面 | 開始点 | 完了点 | 待ちの扱い |
|---|---|---|---|
| 依頼対応 | 依頼を受けて最初の作業を始めた時 | 依頼者に渡して確認が取れた時 | 依頼者の返事待ちも数える |
| 資料作成 | 下書きを開いた時 | 提出・共有した時 | レビュー待ちも数える |
| 問い合わせ対応 | 調査や返信の作業を始めた時 | 回答が相手に届いた時 | 他部署への確認待ちも数える |
| 申請・承認の仕事 | 申請書の作成を始めた時 | 承認が下りて処理が終わった時 | 承認待ちも数える |
見えない仕事も数えます。DORA は、見えない仕事を数えないと本当のボトルネックが見えない、としています。口頭で受けた小さな頼まれごとも、付箋に書いて数えに入れます。
見える化は、付箋に書いてボードに貼る方法が基本です(DORA)。ノートや机の上でかまいません。列は次の4つにします。
| 列 | 入れるもの | 仕掛かりに数えるか |
|---|---|---|
| 未着手 | 依頼は来たが、まだ手を付けていない | 数えない |
| 進行中 | 自分が手を動かしている | 数える |
| 待ち | 返事や承認を待っている | 数える |
| 完了 | 完了点に達した | 数えない |
洗い出しがまだなら、先にタスク管理 できない 新人の棚卸しで依頼を書き出してください。
上限は会議・突発を引いた容量から、突発と待ちの多さで初期値を引く
上限は、自分の容量から決めます。DORA は WIP 上限を容量で決めるとし、本番サポートや会議の時間も容量に含めて考えるよう書いています。事務の仕事なら、会議、問い合わせ対応、突発の依頼が、この「容量を食うもの」にあたります。この読み替えは編集部の提案です。
下の表は、2つの軸から初期値を引くための編集部の提案値です。公表された基準ではないので、2週間試して調整します。
| 待ちが少ない | 待ちが多い | |
|---|---|---|
| 会議・突発が少ない | 3件前後 | 合計4件まで(手を動かす件は2〜3件) |
| 会議・突発が多い | 2件前後 | 合計4件まで(手を動かす件は2件) |
待ちが多い場合は、待ち中の件も仕掛かりに数えるので、合計の枠を少し広く見ます。ただし手を動かす件は増やしません。
境界の見方も1つ入れます。DORA は、複数のタスクやプロジェクトに時間を分けているなら、上限が大きすぎる合図だとしています。表の初期値より少なくても、分けて進めているなら、さらに下げます。
職場に優先順位のルールがあれば、そちらが先です。上司に確認するときは、次のように聞きます。
「同時に進める件数を少なくして、1件ずつ終わらせたいです。急ぎの依頼が来たときは、どの順で対応すればよいでしょうか」
5件を同時に進めても全体の終わりは早まらず、個々の完了が遅れる
下の比較は、編集部算出の架空例です。実際の職場のデータではなく、前提を置いて計算した数字です。
前提は次のとおりです。1人で、5件の依頼があります。1件の作業は1日分です。件を切り替えるときのコスト(思い出す時間など)は入れていません。上限内の件には均等に時間を割きます。
| 進め方 | 件1 | 件2 | 件3 | 件4 | 件5 | 全件が終わる日 |
|---|---|---|---|---|---|---|
| 上限5(5件同時) | 5日目 | 5日目 | 5日目 | 5日目 | 5日目 | 5日目 |
| 上限2 | 2日目 | 2日目 | 4日目 | 4日目 | 5日目 | 5日目 |
| 上限1 | 1日目 | 2日目 | 3日目 | 4日目 | 5日目 | 5日目 |
全件が終わる日はどれも5日目で、総作業量(5日分)が同じだからです。違うのは、個々が終わる日です。5件同時だと、5日目になるまで1件も完了しません。上限を置くと、早い件から完了して依頼者に渡せます。
切り替えコストを入れると差は広がりうるとも考えられますが、定量的な根拠がないので、この例には入れていません。
上限に達したら新規を取らず完了を手伝い、緊急は例外として先に決める
上限に達したら、新しく取らずに、いまある件を終わらせます。上限に達した列には、カードを追加できません(DORA)。新しい作業に着手するのは、空き容量のシグナルがあるとき、つまり件数が上限を下回ったときです(Kanban Guide)。
手が空いたときも、上限を緩めません。DORA は、待ちが出ても上限を増やさず、手が空いた人は他の工程の滞りの解消を手伝うよう勧めています。事務なら、自分の待ちの件で相手に確認を入れる、同僚の詰まっている件を手伝う、といった動きです。
デメリットもあります。上限があると、未着手の依頼は待たされる時間が増えます。柔軟に動きにくくなる場面も出ます。依頼者には、次のように伝えます。これは編集部の例文です。
「いま○件を抱えていて、着手は△日になります。急ぎでしたら、どの件より優先か教えてください」
緊急は例外として先に決めておく
Kanban Guide は、WIP 管理の例外は明示するよう書いています。「上司の指示のとき」「締切が当日のとき」など、例外にする条件を自分で書いておき、職場のルールがあればそちらを優先します。編集部の提案として、例外を使ったときは、件数が上限を超えたことを記録し、元に戻します。また、依頼がほとんど重ならず、上限を守るために待たせる場面が多いなら、上限を置かない、または緩くする選択もあります。優先順位の付け方は優先順位 つけられない 新人で扱っています。
開始日・待ち理由・完了日をメモし、2週間で上限を見直す
見直しは3手順です。①メモする、②2週間試す、③合図を見て、下げる・そのまま・待ちの原因を直すのどれかを決める。2週間は編集部が提案する試行期間です。
- メモする: 1件ごとに、開始日・待ちに入った理由・完了日を書く
- 2週間試す: 初期値の上限で運用し、毎日その日の件数を数える
- 見直す: 下の合図表で、上限を下げる・そのまま・待ちの原因を直す、のどれかを決める
カードに開始日と終了日を書くと、完了までにかかった期間が測れます(DORA)。待ち理由は編集部の提案で、「誰の返事待ちか」を一言で書きます。
メモから、次の3つの指標が分かります(Kanban Guide)。
- 完了数(スループット): 単位時間あたりに完了した件数。週ごとに数えます
- 経過時間(ワークアイテムエイジ): 開始から現在までの経過時間。長い件は待ちが原因かもしれません
- 完了までの期間(サイクルタイム): 開始から完了までの経過時間
見直しの合図は次のとおりです。
| 合図 | 対応 | 根拠 |
|---|---|---|
| 上限が簡単に守れる | 上限を下げる | DORA。上限が簡単に守れるなら下げる |
| 複数に時間を分けている | 上限が高すぎる。下げる | DORA |
| 待ちが出て手が空く | 上限は増やさず、待ちの原因と滞りの解消を手伝う | DORA |
| 依頼がほとんど重ならず、上限のせいで待たせる場面が多い | 上限を緩める、または置かない | 編集部提案(H2-5 の例外条件) |
段取りの組み方が原因のときは、段取り 苦手 克服で逆算の手順を確認してください。
まとめ
- 仕掛かりは、手を付けて未完了の件数。未着手は数えず、待ちは数える
- 開始点・完了点・待ちを自分で書き出してから、上限を決める
- 上限の初期値は、会議・突発と待ちの多さから引く。表の件数は編集部の提案
- 5件同時と上限制の比較は編集部算出の架空例。全件が終わる日は同じで、個々の完了が早まる
- 上限到達時は新規を取らず、緊急は例外として先に決める
- メモして2週間試し、合図を見て、下げる・そのまま・待ちの原因を直すのどれかを決める
棚卸しから進めたい方は、講座業務棚卸しの進め方で、自分の仕事の洗い出しを練習できます。
参照した一次情報(取得日: 2026年11月2日)
- Orderly Disruption Limited, Daniel S. Vacanti, Inc.・The Kanban Guide (May 2025)(v2025.5・2025年5月1日更新): https://kanbanguides.org/english/
- DORA (Google Cloud)・Capabilities: Work in process limits(更新日の記載なし・2026年11月2日取得): https://dora.dev/capabilities/wip-limits/
事務・個人の仕事への当てはめ、場面別の線引き表、上限の件数の目安、2週間の試行期間、5件の完了日の比較は、編集部の提案・算出で、上記の公表値ではありません。会話例・フレーズも編集部作成の例(架空)です。
よくある質問
仕掛かりと未着手はどう違いますか
仕掛かりは、手を付けたがまだ終わっていない仕事です。未着手は、依頼は来ていても手を付けていないので、仕掛かりに数えません(Kanban Guide v2025.5の定義)。どこから「手を付けた」とするかは自分で決めてかまいません。
上限を決めたのに緊急の依頼が来たらどうしますか
Kanban Guide は、WIP 管理の例外は明示するよう書いています。「当日締切のとき」など、例外にする条件を先に決めておき、使ったら記録して上限に戻す、というのは編集部の提案です。職場に優先順位のルールがあれば、そちらを優先し、判断に迷う場合は上司に確認してください。
待ち(承認待ち・回答待ち)は件数に数えますか
手を付けて未完了なので、定義上は仕掛かりに数えます。待ちが出て手が空いても、DORA は上限を増やさず、他の件の滞りの解消を手伝うよう勧めています。待ちが多い仕事では、待ちの件と手を動かす件を分けて数える方法が編集部の提案です。
上限を守ると依頼者を待たせませんか
未着手の依頼は、着手まで待つ時間が増えることがあります。本文のとおり、着手の見込み日を伝えて、急ぎの場合は優先順位を聞く形で対応します。依頼がほとんど重ならず、待たせる場面が多いなら、上限を置かない選択もあります。
一人の仕事でも仕掛かり制限は使えますか
使えます。ただし、Kanban Guide はチームでの運用を、DORA はソフトウェア開発組織の研究を前提にしており、事務や個人の仕事での効果は示していません。個人への当てはめは編集部の提案なので、2週間試して合うか確かめてください。