【リトルの法則とは？】物流の待ち時間や滞留時間を削減するための使い方
リトルの法則は在庫日数の求め方と同じ
リトルの法則は待ち行列理論の１つで、単純な法則ながらシックスシグマを始めとする業務改善においてよく使われます。
勿論、ロジスティクスの業務改善においても有用ですが、あまり知られていないようです。
ウィキペディアには次のように書かれています。
安定な系において長時間平均化した顧客数 L (与えられた負荷、offered load)は、長時間平均化した到着率λと、長時間平均化した顧客が系に費やす時間 W の積に等しい、すなわち
L =λW
という法則である。
リトルの法則 – Wikipedia から抜粋
これだけ読んでも何のことだかわかりませんが、考え方自体は簡単で、在庫日数の求め方と同じです。
ある商品について、倉庫に３,０００個の在庫があり、１日当たりの出荷数が１００個だとすると、在庫日数は３０日ですね。
この時、私たちは
在庫日数＝在庫数／１日当たりの出荷数
と計算しています。
これがリトルの法則だと
W＝L ／λ
のように計算していることになります。
もう一度、先ほどのリトルの法則の定義を見てみましょう。
まず目につくのは「安定な系」や「長時間平均化した」という単語ですね。
定番の商品であれば毎日の売れ行きは安定していますし、倉庫の中の平均在庫数もあまり変わりません。
ですので、「安定な系」や「長時間平均化した」という前提は満たされていると考えることができます。
尚、この例では倉庫の中が「系」になります。
次に、各変数の定義を見てみましょう。
L ：顧客数
λ：到着率
W：顧客が系で費やす時間
まず、顧客＝商品と考えます。
すると、到着率＝（１日当たりの）入荷数となりますが、倉庫内の在庫数が一定ということは
入荷数＝出荷数
成り立っているので、
到着率＝（１日当たりの）出荷数
となります。
また「商品が倉庫内で費やす時間」は在庫日数そのものですので、
W＝L ／λ
で在庫日数が求められることになります。
このようにリトルの法則とは、私たちが在庫日数を計算しているやり方そのものです。
リトルの法則で店内の平均滞在時間を求める
リトルの法則は、店内にいる顧客の平均滞在時間を求めたい時によく使われます。
例えば、スーパーにおいてこれをやることを考えてみて下さい。
一人ひとりの顧客について追跡調査をやるのは、現実的に難しいですね。
これがリトルの法則を使えば簡単に求められます。
スーパー内での顧客の滞在時間は、
W：顧客が系で費やす時間
に相当します。
すると、
W＝L ／λ
ですから、ある時点で店内にいる顧客の数÷顧客の到着率で計算できます。
定常状態（スーパー内で顧客が増えも減りもしない状態）では店内にいる顧客の数は一定と考えられますので、ある一瞬のスナップショットを撮れば、店内にいる顧客の人数は数えることができます。
また顧客の到着率は、入り口で１０分間当たりの入店数を数えれば求まります。
従って、店内での顧客の平均滞在時間がリトルの法則で簡単に求められます。
リトルの法則で行列の待ち時間を求める
次に、行列ができる人気店があるとして、入店できるまでの待ち時間を求めてみましょう。
これは一見、リトルの法則が使えなさそうに思えますが、「系」の考え方を変えれば使えます。
どういうことかというと、先ほどは「店内」を系と考えていましたが、今回は「行列」を系と捉えます。
つまり、
L ：行列に並んでいる人数
λ：行列に並んでくる人のスピード
W：行列に滞在する時間
と考えるのです、
すると、行列に並んでいる人数（L ）は簡単に数えられ。５分間に行列に加わった人数（λ）も簡単に数えられますので、L ／λにより行列に滞在する時間＝行列に並んでから入店するまでの時間が求められることになります。
リトルの法則で物流現場の待ち時間を削減する
工程間の貨物は絶対に滞留する
では次に、物流で使える場面を紹介しましょう。
ピッキング⇒出荷検品という簡単なフローを想定します。
倉庫業務の経験者なら誰でも想像がつくように、出荷検品の前には貨物が必ず滞留します。
「いや、ピッキングと出荷検品の作業スピードが同じになるように作業配分をすれば、同期化されるので滞留は起こらないはずだ」
という考えは机上の空論です。
なぜでしょうか？
確かに、
- 作業員１人当たりのピッキングスピードが一定
- 作業員１人当たりの出荷検品スピードが一定
- 作業員１人当たりのピッキングスピードと出荷検品スピードが等しい（両工程の作業バッチが等しい）
という条件がすべて揃えば、出荷検品の前で貨物の滞留は起きません。
例えば、次のような場合です。
しかし、実際の現場でこうなる可能性はゼロといっていいでしょう。
実際には、先の３つの条件がすべて満たされないケースがほとんどで、次のようになります。
このように、工程間で貨物は絶対に滞留します。
サイクルタイムをリトルの法則で求めてみる
貨物１個をピッキングして出荷検品が終わるまでの時間をサイクルタイムといいます。
そして容易に想像できるように、貨物が多く滞留すればするほどサイクルタイムは長くなります。
それでは、上図のように出荷検品の前で２０個の貨物が滞留する場合のサイクルタイムは何分になるでしょうか？
リトルの法則を使えば計算できます。
この場合、３つの系から業務が成り立っていると考えます。
ピッキング、工程間の滞留、出荷検品の３つです。
ピッキングと出荷検品は平均作業スピードがどちらも２００個／時ですので、貨物１個を処理する時間は逆数を取って、
６０分÷２００個＝０.３３分／個
と計算できます。
つまり、ピッキングのサイクルタイムは０.３３分、出荷検品のサイクルタイムも０.３３分です。
では工程間の滞留のサイクルタイムは何分でしょうか？
これは言い方を変えると、１個の貨物が工程間に平均何分間滞留しているかということです。
ここでリトルの法則を使います。
L ：顧客数
λ：到着率
W：顧客が系で費やす時間
をこの系に適用すると、
L ：滞留している貨物の個数
λ：ピッキングスピード（＝出荷検品のスピード）
W：貨物が滞留している時間
となります。
従って、１個の貨物が滞留している時間は、
W＝L ／λ
＝２０個／（２００個÷６０分）
＝６分
となります。
従って、貨物１個をピッキングして出荷検品が終わるまでのサイクルタイムは
０.３３分＋６分＋０.３３分＝６.６６分
となります。
待ち時間を短縮するための条件とは？
ここで、
「１個の貨物を処理するのに６分４０秒か。まあまあだね。」
と考えるのは並みの管理者です。
リーンな物流を目指す意識の高い管理者は次のように考えます。
「６分４０秒の中で付加価値を生んでいる作業時間は、ピッキングの０.３３分と出荷検品の０.３３分だけだ。つまりサイクルタイムの９０％はムダな作業に費やされている」
よくよく考えるとその通りですね。
ピッキングをしている４人と出荷検品をしている２人は全員休みなく働いているのに、工程管理者の力量不足により、業務効率は極めて低いのです。
なぜこのようなことになってしまうのでしょうか？
ここで、最初の図をもう一度見てみましょう。
ピッキングスピードと出荷検品スピードが常に同じで、ピッキングした貨物をすぐに出荷検品できる状態にあれば、貨物の滞留は起こらずサイクルタイムは０.３３分＋０.３３分＝０.６６分になり、業務効率は１００％になります。
しかし、実際には遠くにある商品をピッキングする時や、フォークリフトで高い位置に保管してある商品をピッキングする時等では、そうでない時と比べて明らかに時間がかかってしまいます。
また出荷検品においては、ピッキングほど大きくばらつかなそうに思えますが、誤ピッキングがあった時や、大口出荷の個数を数える時には、どうしても時間がかかってしまいます。
このように作業スピードを完全に一定に保つことは不可能で、どうしてもばらつきは生じてしまいます。
また２つの工程で作業バッチが異なることも、業務効率を下げる要因です。
一度に２０個まとめてピッキングして出荷検品に渡すよりも、１個ピッキングしたらすぐに出荷検品に渡す方が、滞留が少なることは感覚的にも想像できますね。
でも、そうするとピッキング単独で見た場合のスピードは落ちるので、それとのトレードオフになります。
このように、各工程での作業スピードのばらつきが小さくなるように、また各工程での作業バッチもできるだけ小さくするようなカイゼン活動を積み重ねることにより貨物の滞留が減り、サイクルタイムの中に占める付加価値作業の割合が高まります。
リトルの法則はそのための指標を示してくれます。
Udemyの関連講座
Optimization with Excel: Operations Research without Coding
Optimization with Gurobi, CBC, IPOPT. Linear programming, nonlinear, genetic algorithm. Using Excel, without coding
Assignment and Transportation Problem Operations Research 01
The Hungarian Assignment Problem and Transportation Problem
Optimization with Python: Solve Operations Research Problems
Solve optimization problems with CPLEX, Gurobi, Pyomo… using linear programming, nonlinear, evolutionary algorithms…