WIP制限とは。同時に抱える依頼の数が、返すまでの日数を決める

コラム一覧へ戻る

20件を並行で持つチームが、1件返すのに5週間かかる

制作チームが4人いるとします。今、受けて着手済みで、まだ返していない依頼が20件あります。先週このチームが完了して返したのは4件でした。

20を4で割ると5です。着手してから依頼者に返すまで、平均で5週間かかっている計算になります。管理者の感覚では「だいたい2週間くらい」かもしれませんが、数えると5週間です。

ここで新しい依頼を受けて21件目にしても、週に返せる件数は4件のままです。増えるのは抱える件数だけで、その分だけ1件あたりの待ち時間が伸びます。

依頼者から見ると、投げた依頼はずっと「作業中」と表示されています。止まっているわけではありません。20件のうちの1件として、少しずつ進んでいます。

WIP制限とは何を指すか

WIP は work-in-process の略で、着手してから完了するまでの間にある仕掛かりの件数を指します。WIP制限は、その件数に上限を置く決め方です。

先ほどの割り算には名前がついています。John D. C. Little が1961年に証明した式で、待ち行列にいる件数の平均は、到着の速さと、1件が待つ時間の平均を掛けたものに等しい、というものです¹。Little 本人が2011年に Operations Research 誌へ書いた回顧論文で、そう説明しています。

同じ論文は、製造や業務管理の分野で使われている言い換えも並べています。完了率は仕掛数を滞留時間で割ったもの、という形です²。式を並べ替えると、滞留時間は仕掛数を完了率で割った値になります。20件を週4件で割って5週間、という先ほどの計算がこれにあたります。

上限を8件にすると、何が変わって何が変わらないか

同じチームで、同時に着手する依頼を8件までと決めたとします。8を4で割ると2です。着手した依頼は平均2週間で返るようになります。

残り12件は、着手前の列に並びます。ここで正直に書いておくと、依頼が届いてから返るまでの全体の時間は、上限を敷いただけでは短くなりません。列で待つ時間が、作業中として待つ時間に置き換わっただけです。

変わるのは2つです。1つは、着手した依頼が2週間で返ると読めるようになること。もう1つは、着手していない12件が列として見えることです。

これで、依頼者への答え方が変わります。「今は着手前の列で7番目です。着手したら2週間で返します」と言えます。20件すべてが作業中と表示されている状態では、この答えが作れません。

「上限を敷いたら、急ぎの依頼が列で待つことになる」という反論はあります。待つこと自体は今も起きています。20件を全部作業中にしておくと、急ぎの依頼も残り19件と同じ速さでしか進みません。違いは、待っていることが列として見えるかどうかです。

仕掛を減らすと、完了する件数は増えるか

この点は、増えるとも減るとも言い切れません。Little の論文は、工程そのものを変えない限り、出力を増やすには仕掛を増やすか滞留時間を縮めるかのどちらかしかない、と書いています³。上限を敷いただけでは、週4件が週5件にはなりません。

ただし同じ論文は、待ち行列が長くなると別のコストが乗ることも指摘しています。並んでいるものが増えると、誰かがそれを把握し続ける必要が出てきて、記録や置き場所の手間がかかる、という説明です⁴。

業務の依頼に置き換えると、20件を並行で持つチームでは、どれがどこまで進んでいるかを確認する作業が乗ります。朝会で20件を舐める時間、催促に答える時間、思い出すための読み返しです。上限を敷くとこの分が減り、その減った時間が作業に回ります。

どれだけ回るかは職場ごとに違うので、先に数字を置かず、上限を敷く前と後で週あたりの完了件数を数えて比べます。

上限を敷けない業務がある

到着する件数を自分で決められない業務には、この上限を敷けません。問い合わせ対応がそれにあたります。今日何件来るかを窓口が選べないので、着手する件数だけを絞ると、答えない問い合わせが溜まります。

この場合に決められるのは、着手の順番のほうです。上限ではなく、どの種類を先に取るかを決めます。

上限を何件にするかについても、割り算からは出ません。Little は、この法則は3つの量を必ず成り立つ関係で結びつけるが、どう釣り合いを取るかまでは教えてくれない、と書いています⁵。8件という数字は、返したい日数から逆算した結果であって、法則が出した答えではありません。

PATHWORKで仕掛数を数える

PATHWORK では、依頼と@メンションを「パス」という1つの単位で扱い、Inbox に自分が持っているボール、Outbox に自分が投げたボールが並びます。担当者が今いくつ持っているかは、Inbox を開けば数えられます。

パスの状態は delivered（届いた）、seen（見られた）、acknowledged（受領応答済み）、replied（返信）、escalated（エスカレート済み）、closed（完了）の6つに分かれています。受領したがまだ完了していないものが仕掛です。全部を1つの「作業中」にまとめないので、着手前と着手済みを切り分けられます。

タスクはボード表示に並べられるので、列ごとの件数を目で数えられます。月次のサイクルで区切っている場合は、その月の作業枠に入れる件数が上限の役目を果たします。

限界も書いておきます。列ごとに上限を設定して、超えたら止める機能はありません。上限はチームの取り決めとして置き、件数は人が数えます。数えるのが週1回で済むなら、この形でも運用は回ります。

運用で決めておくこと

• 今、着手済みで未完了の依頼が何件あるか（担当者ごとに数える）
• 先週または先月、完了して返したのが何件か
• 前者を後者で割った日数を、依頼者に伝えている日数と比べる
• 返したい日数から逆算して、上限を何件に置くか
• 上限を超えた依頼を、着手前の列として誰に見せるか
• 到着件数を選べない業務を、上限の対象から外すか

まとめ

着手してから返すまでの日数は、抱えている件数を週あたりの完了数で割った値です。20件を週4件で回していれば5週間かかります。上限を敷くと、この割り算の分子が小さくなり、着手した依頼が早く返ります。

依頼が届いてから返るまでの全体の時間が、上限を敷くだけで短くなるわけではありません。作業中として待っていた時間が、着手前の列で待つ時間に置き換わります。減るのは、20件を並行で抱えることに伴う確認と催促の手間のほうです。上限を何件にするかは、返したい日数から逆算します。

次の一手として、担当者1人に「今いくつ抱えていますか」と聞き、先週返した件数で割ってみてください。出てきた週数が、その担当者に依頼を投げた人が待っている平均の長さです。承認する件数のほうを数える話は承認疲れの記事で、着手の日付を決める話は実行意図の記事で書いています。

参考

本文中の番号をクリックすると、その記述の根拠にした原文にジャンプします。原文は改変せず、英語のまま載せています。

1. John D. C. Little「Little's Law as Viewed on Its 50th Anniversary」Operations Research Vol. 59, No. 3, May–June 2011

   Little's Law says that the average number of items in a queuing system, denoted L, equals the average arrival rate of items to the system, λ, multiplied by the average waiting time of an item in the system, W. Thus, L = λW

   Figure 1（待ち行列の模式図）の直後、法則を言葉で述べた箇所（記事の「待ち行列にいる件数の平均は、到着の速さと、1件が待つ時間の平均を掛けたものに等しい」の根拠。同論文の冒頭に、1961年の原論文が Operations Research 9(3) 383-387 であることも記されている） 本文の該当箇所へ戻る
2. John D. C. Little「Little's Law as Viewed on Its 50th Anniversary」Operations Research Vol. 59, No. 3, May–June 2011

   (b) Operations management (Hopp and Spearman 2000) TH = WIP/CT TH = throughput (items/unit time) WIP = work-in-process (items) CT = cycle time (time units/item)

   4.2.1節 Most Commonly Used Notations（記事の「完了率は仕掛数を滞留時間で割ったもの」「滞留時間は仕掛数を完了率で割った値」の根拠） 本文の該当箇所へ戻る
3. John D. C. Little「Little's Law as Viewed on Its 50th Anniversary」Operations Research Vol. 59, No. 3, May–June 2011

   As stated in (b), we see that any increase in output requires either an increase in work-in-process inventory or a reduction in cycle time or both, unless some change is made in the manufacturing process itself.

   4.2.2節（記事の「工程そのものを変えない限り、出力を増やすには仕掛を増やすか滞留時間を縮めるかのどちらかしかない」の根拠。文中の (b) は ref-2 に引いた記法を指す） 本文の該当箇所へ戻る
4. John D. C. Little「Little's Law as Viewed on Its 50th Anniversary」Operations Research Vol. 59, No. 3, May–June 2011

   In operations management for manufacturing, for example, as queues increase, someone has to keep track of the items. This incurs a cost. It may be extra record keeping and the people to do it, or it may be keeping track of physical objects and finding a space to store them temporarily and moving them there and back.

   4.1.1節 Queue-Related Overhead（記事の「並んでいるものが増えると、誰かがそれを把握し続ける必要が出てきて、記録や置き場所の手間がかかる」の根拠） 本文の該当箇所へ戻る
5. John D. C. Little「Little's Law as Viewed on Its 50th Anniversary」Operations Research Vol. 59, No. 3, May–June 2011

   LL locks the three measures together in a unique and consistent way for any system in which it applies. LL will not tell the managers how to handle trade-offs or provide innovations to improve their chosen measures, but it lays down a necessary relation.

   2.3節（記事の「この法則は3つの量を必ず成り立つ関係で結びつけるが、どう釣り合いを取るかまでは教えてくれない」の根拠） 本文の該当箇所へ戻る