ゴールドラットが提唱したDBR生産スケジューラは、盟友のエリ―・シュラ―ゲンハイムが提唱するS-DBRにGrade Up（Grade Down?）されたことで、実行可能なスケジューリングができないことを認め、MRPのスケジューリング問題を解決しようとした元々のゴールにたどり着くことはできませんでした。ただ、スケジュールがなくても、ボトルネックを中心とした管理方法は有効で、うまく使えばそれなりの効果はでるようです。
ゴールドラットが次に発表したのが「クリティカル・チェーン」。プロジェクト管理のあたらしい方法です。各タスクのバラツキ分を集めて、スケジュールの一番後ろにプロジェクトバッファーとして置きます。プロジェクトバッファーの一番後ろが納期ですので、プロジェクトバッファー以内で終了すれば、納期は守られることになります。
DBRのタイムバッファーとクリティカル・チェーンのタイムバッファーは異なります。この違いに何か特別な意味はあるんでしょうか？ ゴールドラットにしてみれば、TOCという壮大なマネジメント論のとっかかりであるDBRの考え方を踏襲したかったのではないかと思うんですが、、ね。プロジェクト管理では、負荷１００％を超える特定のリソースがボトルネックと考えることはできないんでしょうか。ボトルネックのリソース（人）には雑用を頼まない、それでも足りなければ、助っ人をあてがう、、。DBRと同じように考えることができそうですがね、、。
ゴールドラットはTOCの原点ともいえるDBRの考え方をプロジェクト管理に適用しなかったのはなぜなんでしょうか。いまさら故人に聞くわけにもいきません。いろいろと思いめぐらしてみましょう。
ゴールドラットがプロジェクト管理について考えていたのは１９９０年の中頃ではないかと思われます。１９９０年に「The Haystack Syndrome」でDBRのスケジューリングを発表し、それを真似ていくつかのDBRスケジューラが開発されました。現場で使ってみると、どれもまともに実行可能なスケジュールを組むことはできません。
そして、盟友であるエリ―・シュラ―ゲンハイムがボトルネックのスケジューリングを排したS-DBRを開発します。エリ―・シュラ―ゲンハイム他著「Supply Chain Management at Warp Speed」にS-DBRの詳細な説明が載っています。
２３ページに、ボトルネック（CCR; Capacity Constrained Resource）負荷が処理時間とWIPにどのような影響を及ぼすかの図があります。説明を加えておきますと、処理時間とは待ち時間と正味処理時間を足したものです。正味処理時間は、基本的に、負荷によって変わりませんので、指数関数的に上昇する処理時間の中身は待ち時間の増大です。
図１ CCR Load v.s. Production Time
(Reference; Supply Chain Management at Warp Speed)
エリ―・シュラ―ゲンハイムがS-DBRを提唱した大きな理由は、ボトルネック工程での待ち行列現象を回避するためだったのではないかと思われます。“ボトルネック工程の稼働率を100％でスケジューリングすることは物理的に不可能である”ことに気が付き、DBRの最も重要な概念である“ボトルネックの能力を100％引き出す”ことを断念せざるを得なかったのではないか、、。
「ボトルネック工程の１００％稼働スケジューリングはうまくいかない」
プロジェクト管理で、“DBR方式”を採らなかった理由がは、、この辺りでしょうか。
ゴールドラットを救ったのは、生産工程フローとプロジェクト・タスク・フローの違いです。以降、生産型、プロジェクト型とします。何が違うかと言いますと、生産型にはあって、プロジェクト型にはないもの、です。
図２をご覧ください。基本的なところだけをシンプルに表しております。生産ラインにオーダーがランダムに来ます。「工程１」で「オーダA」の処理が終わる前に「オーダB」が来た場合、「オーダB」は「工程１」の前で「オーダA」の処理が終わるまで待つことになります。「オーダA」の処理が終わる前に「オーダC」が投入されれば「工程１」の前では「オーダB」と「オーダC」の2つのオーダが「工程１」の前で待つことになります。この現象、お気づきのことと思います。待ち行列現象です。「工程１」の処理能力に対してオーダの投入が少ないときは待ち時間は短く、オーダが多くなると待ち時間はグンと長くなります。負荷と待ち時間の関係は図１のようになります。
待ち行列現象を起こすのは、「工程１」だけではありません。「工程２」も「工程３」も・・・ほとんどの工程で待ち現象を起こす可能性があります。。稼働率が低い間は待ち時間は短いので余り影響はありませんが、生産管理では常に稼働率を高くすることを目指していますので、いたるところで待ち行列現象を起こしてしまいます。ボトルネック工程は一カ所か二ヶ所、なんて悠長に構えているわけにはいきません。どの工程も100％の稼働率を目指すのが宿命。
図２ 生産ラインの代表的モデル
プロジェクト・タスク・フローはどうでしょうか。実は、プロジェクト・タスク・フローでも待ち行列現象は起きます。わかりやすいのは、管理者の机で山積みになるハンコを待つ書類の山。“めくら判”でも、1週間もかかる。
構造上の基本的な特徴、生産ラインとの違いに注意してプロジェクト計画の流れをみてみましょう。図３に基本的なプロジェクト計画の流れを示します。
プロジェクトXをひとつのまとまったプロジェクトとします。「タスク１」で最初の仕事をします。終わったら「タスク２」、次に「タスク３」、、、そして「最終タスク」を終えて「完成」となります。
図３ プロジェクト計画の一般的流れ
生産型とプロジェクト型の違いをまとめてみましょう。共通する部分、類似する部分、あいまいな部分、、もありますが、あえて単純化して、両者の違いをみてみます。
生産型はひとつの工程（処理ユニット）にオーダ（処理対象）が次から次と来ます。一方、プロジェクト型はひとつのプロジェクト（処理対象）に対して様々なタスク（処理ユニット）があります。単純化しますと、次のようになります。
| 処理対象、オーダ、 | 処理ユニット、工程、タスク | |
| 生産型 | 多数 | 基本単位1 |
| プロジェクト型 | 基本単位１ | 多数 |
で、待ち行列現象が起きるかどうか、の視点でみてみましょう。生産型はほとんどの工程が待ち行列現象の発生条件を満たしております。プロジェクト型はどうでしょうか。処理対象をひとつのプロジェクトとしてみますと、プロジェクトの待ちというよりは処理中という感じでしょうか。待つのは、プロジェクトではなくて、タスク（リソース、人、、）。もちろん細かくみれば、プロジェクトも複数のジョブに分けられますので、時間単位を短くしてみると、ジョブの待ちがあることが観察されます。が、全体としてみれば、待ち行列現象の程度は小さいのではないかと思われます。
もうひとつの違い。
生産型；一つの工程の処理時間が短い
プロジェクト型；一つのタスクの時間が長い
これは、管理サイクル内でどの程度の進捗管理（修正、負荷・能力調整等含む）ができるか、という視点でみるとき、生産型では個単位の時間で管理することは困難。一方、プロジェクト型の場合は、短くは朝夕、1日単位、週単位での進捗管理が可能、という違いはあるのではないか、と思われます。
これも大きな違いです。
生産型；処理時間の見積が正確
プロジェクト型；処理時間の見積精度が低い
生産型の作業時間は標準化が行われ、大量生産では、時には秒単位で標準作業時間が設定されています。プロジェクト型は、作業そのものの繰返しが少なく、作業時間の見積精度は低いのが一般的です。表１に生産型とプロジェクト型の比較をまとめてみました。
表１ 生産型とプロジェクト型の比較
生産型とプロジェクト型のスケジューリング、さらに追及していきます。