私が計画負荷（Planned-Load）という概念を考えついた当時は、私のMICSSシミュレータにも「あったら便利だが無くても済む」おまけ機能くらいにしか思っていませんでした。 そのMICSSは、生産管理に関わる様々なポリシーやアイデアを吟味する機会を与えてくれたものです。しかし、私もその計画負荷がいかに重要か理解するのに何年もかかりました。
実は、遥かに複雑なDBR（ドラム・バッファ・ロープ）に取って代わった簡易DBR（S-DBR：Simplified-Drum-Buffer-Rope）も、計画負荷の概念無しで使うのは無理です。にも拘らず、TOCのソフトウェア開発者を含むTOCの人々のほとんどが、その重要性と明らかな潜在的価値に気付いておらず、まだ完全に実現してもいないように思えます。
クリティカルなリソースの計画負荷は、予定が確定しているすべての仕事を処理するのに必要な時間の積算です。その目的は、負荷と使用可能なキャパシティ、応答時間の関係を知るのを助けることです！
例として、裁判所を考えましょう。やらないといけない仕事（すでに予定に入っている審理で合計160時間）を確認している裁判官を想像してみてください。その他に、以前の審理記録を読んで判決文を書くのに80時間必要です。つまり、既に分かっている仕事の量は全部で240時間です。
その裁判官が週40時間勤務だとすれば、現在彼を待つすべての審理は、理論的には6週間で終わるはずです。だとすると、彼が正味約40時間かかる仕事量の審理が一つ追加で入っても、まあまあの確度で10週で終わるだろうと予想できます。ここで私は、いくつかの審理でやり直し審理が必要になったり、裁判官が数日病気になったり、何かうまくいかない事が起きるのに備えて、3週間のバッファを追加しました（訳注：既存の仕事6週間＋バッファ3週間＋追加の審理1週間＝10週間）。このバッファは、今後新しく追加される審理のおおよその完了日を見積もるのに必要です。
しかし、実は、新しく入る審理の平均リードタイムは50週だと直ぐに分かりました。一体どうしたのでしょう？
計画負荷を根拠にした予想が当たらないとしたら、理由は次のどれかのはずです：
- 我々が目に付けたのは、実は非制約リソースで、それで空き時間がたくさんあった。裁判の場合、ひょっとしたら、本当のボトルネックは、審理の中断を要求して長く遅らせる弁護士かもしれない。
- リソースが制約なのに、リソースの扱い、特にそのキャパシティの使い方がひどくて、相当のキャパシティが無駄に浪費されている。
- 現実の需要には、事前の予定がなくて最新の計画負荷に入っていない緊急の事案が高い割合で含まれている。そういう緊急な事案が頻繁に現れて、既に正規の予定に入っている仕事を遅らせる。
オペレーションの中で「最も弱いリンク」の計画負荷は、作業指示や普段の活動の正味の待ち時間の概算速報として重要です。待ち時間が比較的長い場合、キャパシティの大きな浪費が無いとすれば、計画負荷が実際のリードタイムの概算値になります。つまり、計画負荷は、これから新しく入る注文に対する組織としての潜在的な応答時間を測る指標になるのです。
ある製造組織の6種類のリソース（訳注：ワークセンター）の計画負荷（赤のバー）を示した下の図をちょっと見てください。バーの右側の数字は平均の段取り時間を含む作業時間（単位は時間）です。
どのリソースも週40時間稼働だとすると、一つのリソース（PK 包装ライン）は、正味の仕事がほぼ3週間分あることが分かります。
緑のバーは、当該リソースのところに既に到着して処理待ちの作業指示の仕事量です。生産ラインであれ普段の活動であれ、複数のリソースを必要とする環境では、ある作業がすでに予定に入っていても、当該リソースのところにはまだ届いていないことがあります。つまり、その作業は、計画負荷には含まれるが、緑のバーにはまだ含まれていません。図を見ると、ワークセンターPKは最後の工程で、それが行う予定の作業指示のほとんどが、上流のあちこちのリソースに留まっているか、ひょっとしたらまだ現場に投入されてすらいないかもしれません。
本当に重要な情報は、赤のバーに含まれる計画負荷です。その意図を理解するには、もう一つ新しい情報が必要です。それは納入リードタイム（customer lead time）で、この場合は6～7週間です。
この情報は、間違いなくこの工場の運用は非常に下手だと判断するに十分です。
実際のリードタイムはおおよそ3週間のはずです。ですから、4週間で納期回答すれば、もっと受注できる可能性があります。もちろん、需要が急に上昇したら、計画負荷を慎重に再チェックして、4週間の納期が安全かどうか確認しなければなりません。
計画負荷のパワーをちょっと説明するために、生産現場に必要な変化を実行して4ヶ月後の同じ製造組織の計画的負荷を示しておきましょう：
今度は納入リードタイムを4週間にしています。そのお陰で注文が25％増えて、ワークセンターMBがアクティブな能力制約になりました。今度は正しいTOCの原則に則ってシミュレーションしているので、仕掛り（WIP）のほとんどが自然に能力制約のところに集まっています。見てのとおり、制約より下流の非制約リソースでは、自分のところにほんの少しか仕掛りがありません。
最長の計画負荷は3週間（MBでの約120時間の作業）です。 4週間の納期回答には、MB自体に起きた問題を解決し、下流の工程を通り抜けるに必要な時間のバッファを含みます。
これは、計画負荷という情報の重要さのほんの一端にすぎません。ゴールドラット博士は、その情報に隠れた価値に腹落ちするや、タイムバッファの一部を計画負荷に加算するやり方を「安全な納期」を見積もるアルゴリズムのベースにしました。
計画負荷の挙動を時系列で表示したグラフは啓発的かもしれません。グラフが上昇する場合は、出るより入る注文の方が多いので、新たなボトルネックが現れる危険性が高いということです。反対に、グラフが下降しているときは、増えた余剰のキャパを使えばもっと速く応答できるということです。販売も生産も、それに沿った計画を立てるべきです。
その他の大きな強みは、信頼性の高いデリバリを維持するための残業のコントロールに、計画負荷への直近の短期的な影響が使えることです。その対象期間はタイムバッファと同じで、その期間の注文をすべて約束どおり納入できるキャパシティが十分あるのを保証することです。そうすれば、バッファ管理から「赤オーダーが多すぎる」という警告が出る前に問題を発見できます。ですから、実行をうまくコントロールするには、計画負荷とバッファ管理の両方を常に監視すべきです。
S-DBRと計画負荷は製造に適すのは確かです。しかし、ほとんどすべての組織では、様々な活動（ミッション）がタイミングよく終わるようコントロールするには、計画負荷とバッファ管理の両方を含むS-DBRを使うべきです。
TOC仲間の間では、多くのリソースを必要とする大きなミッションはすべて、CCPM（クリティカルチェーン・プロジェクトマネジメント）で管理しないといけないプロジェクトだと考える傾向があります。そう思うのは可能でよい結果が出るかもしれませんが、そういうミッション（訳注：改善や企画など、中長期にわたる重要な活動）を管理するには、必ずしも最善のやり方とは限らず、明らかに最も簡単な方法ではありません。
日常のミッションを行うにとって、どういうときS-DBRが効果的で、どういうときにCCPMが本当に必要か、明確に区別する努力をすべきだと私は思います。因みに、鍵を握る重要なリソースのキャパシティをマルチプロジェクト環境でどう管理したらよいか、我々はちゃんと考えてもいいでしょう。長すぎる遅延を避ける十分なキャパシティがあるのか、あるいはキャパシティを増やさないといけない差し迫った必要性があるのかどうか示す指標として、なんとか計画負荷を使えないもんでしょうか？
著者：エリ・シュラーゲンハイム
飽くなき挑戦心こそが私の人生をより興味深いものにしてくれます。私は組織が不確実性を無視しているのを見ると心配でたまりませんし、またそのようなリーダーに盲目的に従っている人々を理解することができません。
