ボトルネックの計算：なぜ85％の稼働率でも高すぎるのか

Inhaltsverzeichnis+

ほとんどすべてのプロセス改善プロジェクトでよく聞く二つの言葉は、どちらも間違っています。

「ボトルネックは最も時間がかかる工程だ。」

「稼働率は85％だから、余裕がある。」

なぜ間違っているかは、3つの式で示せます。これらは1ページに収まります。これを読めば、電卓でどの工程がボトルネックか見つけられ、電卓がどこで役に立たなくなるかも分かります。

この記事は一つの前提を置きます：どのプロセスを計算するかが確定していることです。どのプロセスが最もコスト高かをまず見つける必要がある場合、その選択問題にはFlowrefy.comのEngpass-Diagnoseが答えます：プロセス名を示し、背後のカスケードを示し、三つのレバーを挙げます。選択はそこにあり、計算はここにあります。

1. 稼働率：ボトルネックを示す唯一の数値

稼働率  ρ  =  需要 ÷ 能力

需要は数量×処理時間です。能力は利用可能な作業時間です。

例：工程「検査」に1日あたり120件入り、1件あたり12分かかります。3人がそれぞれ生産的に7時間働きます。

• 需要：120 × 12分 = 1440分/日
• 能力：3 × 7時間 = 21時間 = 1260分/日
• 稼働率：1440 ÷ 1260 = 114 %

100％を超えると：待ち行列は毎日増えます。「少し遅くなる」ではなく、無制限に増え続けます。誰かがエスカレーションするか、残業をするか、案件が放置されるまで続きます。

別の工程が40分かかるかどうかは、そちらに十分な能力がある限り全く関係がありません。時間の長さは稼働率ではありません。 ボトルネックは常に最も高いρの工程です。

2. Little's Law：在庫、スループット、時間の関係

在庫  L  =  スループット λ  ×  仕掛時間 W

在庫 = スループット × 仕掛時間。この関係は分布に関する仮定を必要としません。会計上の恒等式です。

実用的には次のように変形します：

仕掛時間  W  =  在庫 L  ÷  スループット λ

例：未処理の案件が40件あり、1日で20件処理できるなら、仕掛時間は2日です。プロセス文書に何と書いてあろうと関係ありません。

これが最も安上がりな計測です：在庫を数え、スループットを数え、割るだけ。ツールはいりません。どの部門長でも調達できる2つの数字だけです。

3. Kingman：境界付近でなぜ爆発するか

決定的な式は待ち行列理論の近似で、しばしば「VUT式」と呼ばれます：

待ち時間  Wq  ≈    ρ / (1 − ρ)      ×   (ca² + cs²) / 2   ×   te
                 └─ 稼働率 ─┘       └─ 変動度 ─┘        └─ 処理時間 ─┘

三つの因子があり、プロジェクトで語られるのは最後の一つだけです。

最初の因子がすべての原因です。挙動を見てください：

（中程度の変動で単一作業者の近似。複数人でプールを共有すると値は小さくなる。非線形性は残る。）

70％から85％へは15ポイントの上昇で、待ち時間はおよそ2.5倍になります。85％から95％へはさらに10ポイントで、待ち時間はさらに3倍になります。

これが「なぜプロセスが突然崩れたのか」の答えです。 突然崩れたわけではありません。稼働率が88％で動いていて、量が6％増えただけです。

第二因子：変動は有効なレバーである

中央の項はほとんど見落とされます。caとcsは到着と処理時間の変動係数（標準偏差÷平均）です。

実務上の結論：処理を速くしなくても待ち時間を減らせます。 変動を半分にすれば、待ち行列への寄与は半分から四分の一になります。具体的には：

• 単純と複雑を同じ列に混ぜず、タイプ別に分ける
• 入りを平準化する（集中流入ではなく予約や固定の引き渡し時間を使う）
• 問い合わせをなくす。問い合わせは別の案件であり、二度待つことになる

これらは投資不要の対策です。ビジネスケースに載りにくく、プロジェクト化しづらいことが多いです。

実務での計算：四つのステップ

1. 各工程で需要と能力を把握する。 数量×処理時間と利用可能作業時間。概算で最初は十分です。
2. ρを計算して並べる。 最も高い値がボトルネックです。85％超は警報、100％超は既に渋滞です。
3. 月平均ではなく繁忙日の値で計算する。 月平均で70％でも月初に130％になっている工程は問題があります。90パーセンタイルの日で計算してください。
4. 在庫を数え、Little's Lawで照合する。 計算上の仕掛時間より実測が大幅に長ければ、モデルに待ち行列が抜けています。多くは問い合わせや承認です。

手計算の限界

この計算でできないことが三つあり、いずれもプロジェクトを左右します：

連鎖を扱えません。 ある工程は前の工程の最も遅い工程以上の案件を決して見ません。検査が114％のままであれば、その先の承認は余裕があります。検査を解消すると、承認が全量を受け取ります。ボトルネックは移動します。 テーブルは各工程を独立に計算するだけで、この移動を見ません。

繁忙日を知らない。 式は到着の平均を使います。実際の損害は四半期の上位5日のような最悪日に発生します。

一点推定しか出しません。 「57分」という待ち時間は、入力が推定値である近似の結果です。信頼できるのは区間であって、P10からP90です。

これら三点に対してシミュレーションが効きます。実際に案件をプロセスに流し、何百回も繰り返し、変動やカレンダーを入れて動かします。これにより、式では答えられない問いに答えられます：ボトルネックを解消したときにどこへ移り、金額でいくらになるか。

まとめ

• ボトルネックは最も長くかかる工程ではなく、最も高い稼働率の工程です。
• 待ち時間はρ/(1−ρ)で増えます。およそ85％を超えると、追加の量は高コストになります。
• 変動は独立したレバーであり、通常もっとも安価です。
• Little's Lawは現実との照合に使える、二つのカウントだけで済む検査法です。
• 変更の効果を問うなら、手計算は不十分です。ボトルネックの移動を見られないからです。