1. CCPM+(日本語版)ホーム
  2. TOCの概要
  3. No.002 生産管理とプロジェクト管理の統合アプローチ

TOC資料

No.002 生産管理とプロジェクト管理の統合アプローチ

イントロダクション

エリ・シュラーゲンハイム、および、ダニエル・ウオルシュが書いたこの論文には、生産のスケジューリングと複数プロジェクトのスケジューリングの違いが書かれています。この二人の著者は、これらの二つの環境の重要な相違点をよく認識することが非常に重要であること、そして、その認識の上に立ち、これらの二つの環境ごとに、それぞれの環境に適したアルゴリズムを使い、スケジュールすることの重要性を指摘しています。著者たちは、また、現実の場でよく見られる二つの環境のハイブリッドである環境、すなわち、プロジェクトと生産の両方の側面を持つ環境についても議論しています。これらのハイブリッド環境には、全体を考えた「統合スケジューリング・シナリオ」が必要です。エリ・シュラーゲンハイム氏、および、ダニエル・ウオルシュ氏は、一流のTOC専門家として世界的に知られています。

なお、さらに詳しい情報を知りたい方は、Vector Strategies社のURL: www.vectorstrategies.com をご覧下さい。

デーブ・アプデグローブ

生産管理とプロジェクト管理の統合アプローチ

エリM.シュラーゲンハイム、ダニエルP.ウオルシュ

現状

プロジェクトの計画作成とスケジューリングは、基本的にPERT/CPMに基づくアプローチにより行われています。そして、生産業務の計画作成とスケジューリングは、主として、MRP IIに手を加えたもので行われています。

この二つの方法論は、作業やタスクの順序についての基本的な考え方が類似しているものの、明確に、二つの異なる別個の方法論です。この二つの方法では、その両方において、す。作業のアウトプットが次の作業のインプットです。という意味で、作業やタスクの明確な順序の存在が認識されています。両者において、いくつかのインプットを、たった一つのアウトプットに統合する作業や組立作業が存在します。分解(disassembly)の概念は、MRP IIよりも、プロジェクトにおいてより一般的ですが、生産においても、まったく皆無ではありません。実際、この概念は、再製(remanufacturing)、修理(repair)、オーバーホール(overhaul)を行う環境では、非常に、一般的な概念です。

しかし、両者の差異は、非常に大きなものです。PERT/CPMは、プロジェクト全体にまたがる、順番に行われる作業の連鎖の中で、いちばん長い連鎖であるクリティカル・パスの概念を中心にして構築されているのにたいして、MRP IIシステムやAPSシステムは、これを完全に無視しています。PERT/CPMのもう一つの特徴は、作業の最小必要時間、最大必要時間の推定値を必要とすることです。しかし、MRP IIでは、時間の推定にこのような推定値を使うことは、経験的に見てまずありません。実際、時間の推定を行うことは、方法論としてのMRP IIの一部としては存在していません。MRP IIは、原材料管理の果たす重要な役割を強調しているのにたいして、PERT/CPMでは、それを強調していません。MRP IIは、特定された時間枠の中で、すべてのオーダーをどのように完成させるかを対象とするものです。それに対して、伝統的なPERT/CPMは、複数プロジェクトではなく、単一プロジェクトの管理を目標として開発されたものです。

勿論、この二つの方法には、たくさんの素晴らしいアイディアが内包されており、これらの二つの方法から、多くの利点を引き出し、それを享受できます。しかし、これら二つの計画作成方法のユーザは、結果として得られる計画が持つ脆弱性と、マーフィー(すなわち、不確実性、リスク要因、予期せぬ出来事)により、計画が台無しになってしてしまうことに不満です。

これらの二つの方法論の相違点は、生産環境と複数プロジェクト環境の基本的な相違に由来するものなのでしょうか。環境の相違が、なぜ、異なる計画作成方法論を必要とさせるかということを掘り下げ、よく理解すると、下記の二つの事柄についての理解が深まり、便利です。

1.よりよい全体的な計画作成の方法論:
「よりよい全体的な計画作成の方法論」とは、かなりな程度に頑健で、必要ならば、対象としている生産システムからアクションのための多くの情報が引き出せる方法論。
2.特定の方法論を「どのような場合に使ったらよいか」についてのより深い理解:
研究開発部門は、勿論、プロジェクト志向であり、消費財の生産者は、当然、生産をプロジェクトとしては考えませんが、このようにははっきりと断定できないケースもあります。このようなケースのよい例は、例えば、大きなハイテクシステムの生産です。ハイテクシステムのような製品の生産者は、「プロジェクト」を行っているのか、それとも、「製品」を生産しているのか。そして、このような場合、どちらの計画作成方式を採るべきなのでしょうか。

ここで、仮に、複数プロジェクトにも対応でき、また、生産の場合にも対応できる「一つに統一された計画作成方法」を見出すことができたとすると、上記の「二つについての理解の深まり」のうちの二番目の「理解」は、どうでもよいことになります。しかし、なにか、特別な理由が存在し、どちらか特定の方法論が必要であると結論するなら、自分の環境には、どちらの方法論がよりよく適合するかをはっきりとさせることが、もちろん非常に重要となり、それによってさまざまな利点が得られます。

そして、仮に、二つの方法論の両方が必要だとするなら、もう一つの疑問が生じます。すなわち、二つの環境の「交配環境」というものは存在するのだろうか、という疑問です。製品によっては、「複数プロジェクトの計画」と「生産計画」の両方のアウトプットを必要とするのでしょうか。

TOCの視点

TOCは、上述の二つの計画作成方法論の両方に挑戦するものです。TOCの生産計画作成の方式は、ドラム・バッファ・ロープ(DBR)と呼ばれています。DBRは、明確にMRP IIともAPSとも異なります。

DBR方式は、現在のTOCの諸概念が生まれる前に開発されたものです。しかし、その考え方は、TOCの思考方法に、完全に適合しています。そして、計画実行のコントロール・メカニズムであり、バッファ管理(BM)と呼ばれる方式も開発されました。バッファ管理は計画作成を補完するものであり、これにより、計画作成と実行が区別されました。

複数プロジェクトの計画作成とコントロールのためのTOC方法論は、比較的に後になってから開発されたものです。既に、当初の段階において、複数プロジェクトの計画作成とコントロールの問題に関する考察の中で、DBRは、プロジェクト管理のための計画作成方法論には全面的には適合しないものであると認識されていました。それ故に、TOCの観点から見ると、生産についての計画作成と複数プロジェクトの計画作成の間には、厳密な区分が存在します。この区分を調べることで、両者の相違をよりよく理解でき、なにがこの区分を重要なものとしているかが理解できます。

TOCにより、複数プロジェクトの計画を作成する場合、いくつかの、DBRで使われているのと同一のTOC用語、特に、「ドラム」、および、「バッファ」という概念が使われます。しかし、複数プロジェクト環境で使われる場合、これらの用語の実際の定義は、抽象的な意味で考えれば、同一用語を使う理由は十分に正当化できるものの、DBRでのそれとは同一ではありません。

ここで、DBRと、TOC方式での複数プロジェクトの計画作成の定義を行うつもりはありません。ここで言いたいのは、複数プロジェクト環境と生産環境の相違により、それぞれ、異なるタイプの計画作成方式が必要であるということです。必要となる計画作成のタイプが異なる理由を理解すれば、プロジェクトと生産の間にどのように線を引いたらよいかについての結論を導出できます。

そして、産出物が、プロジェクト環境と生産環境の「真の交配物」であるような環境を探し、DBRと複数プロジェクトの計画作成方式の結合について考察します。

プロジェクト環境と生産環境の重要な相違点

ここで、最初に開発されたDBRを使い、これを、研究開発部部門のような環境で見られる典型的な複数プロジェクト環境に適用した場合に、どんなことが起こるかを調べましょう。

まず、実際に効いているCCR(capacity-constraint resource)を識別する必要があります。また、下の例では、工程が同一ではすが、最終製品が別個のものである二つのプロジェクトについて考えます。

この例では、下図の青い資源がCCRだとします。以下では、通常のように、DBRは、制約でない資源での処理時間を無視します。


図 1: 各オーダーをDBR形式で図示

ここで、CCRのスケジュール作成プロセスの説明は行いませんが、普通に行われるプロセスに従えば、例えば、次のようなCCRのスケジュールが得られます。


図 2: CCR スケジュール

ここで、フロー図の上段のフローで行われ、10日間の処理作業を必要とする「全体としての最初のCCR作業」となる「オーダー1(すなわち、プロジェクト1)の最初のCCRでの処理」は、第30日に開始されるようにスケジュールされています。このようにスケジュールすると、フロー図の上段のフローの入り口工程へのオーダー1の投入は、30日のタイムバッファを念頭に、第0日に行います。その結果、CCRが、オーダー1の処理作業を確実に予定通りに開始できるようになります。次に、このCCRで行う作業は、同一の処理をオーダー2(すなわち、プロジェクト1)にたいして行なう作業です。(訳注:カーキ色はオーダー1、青色はオーダー2を示す)

DBRのルールにより、10日間を要する最初の処理作業と、最初の処理作業よりも下流にあって、最初の処理作業がフィードする、15日間を必要とする作業との間には、少なくともCCRバッファの半分である15日のバッファが必要です。上図のスケジュールは、この条件を満たしています。

このスケジュールは、果たして、満足のいくものでしょうか。それは、タイムバッファの長さ次第です。このスケジュールの持つ問題をはっきりと見るために、同じオーダーを、今度は、プロジェクトと考えて見ましょう。


図 3: 同じ例を、同一の構造を持った二つのプロジェクトとして見る

DBRの形式で表示したときは、制約でない資源に関するデータは無視されていました。しかし、プロジェクトの場合は、そうではありません。TOCのプロジェクトへのアプローチでは、各資源での競合問題を解決することが求められ、そして、クリティカル・チェーンがどこであるかを明示することが求められます。それに次いで、ドラムにより、プロジェクトの開始時間が決定されます。図4は、今度は、プロジェクトとして表示されている、同一の二つのオーダーにたいするTOCによるスケジュールを示しています。ここで、クリティカル・チェーンの考え方に基づき、処理時間は、各タスク(作業)の作業時間の推定値の50%にされています。


図 4: TOCに基づく複数プロジェクトのスケジュール

上図では、各プロジェクトのクリティカル・チェーン(資源の競合を考慮したクリティカル・パス)は、作業(タスク)の箱の中に縦縞模様で示されています。

もっとも顕著な相違点は、制約でないタスクがスケジュールされていることです。また、クリティカル・チェーンに沿って、実際の順序を決定することが如何に重要であるかが読み取れます。ここで、最初の資源が、上にあるフローAではなく、下のフローBの最初の作業(タスク)から開始したとすると、多分、プロジェクト全体の大きな遅延が惹き起されるでしょう。

もう一つの大きな相違点は、「青い」資源(CCR)が「ムダ」にされることです。この資源での三つの作業がまとめられることはけっしてありません。三回行われるCCR資源での、最初の10日間の作業は、クリティカル・チェーンの一部ではありません。そして、5日間の作業が始まるまでに、5日間の差(空き)が出ます。この空きが、なにか他のことに使われるとは考えにくいことです。この「空き」の有効活用を図ろうとして、2番目のプロジェクトには向けられることはありません。それは、2番目のプロジェクトの各作業がばらばらにならず、相互に離れないようにまとめておくため、また、全体的な資源の競合を減らすためです。それに加え、プロジェクト間のドラム資源の利用の間に、小さな「キャパシティ・バッファ」が意図的に置かれています。

ここまで見てきて、果たして、どちらの計画作成が「正しい」のでしょうか。

このケースは、明らかに、「複数プロジェクト」の計画作成のケースです。このケースから、プロジェクトでは、制約でない資源での作業の順序を無視できないことが判ります。なぜなら、それを無視すると、大きな遅延が起こるかも知れないからです。このケースの場合、30日間のバッファは不適切でしょう。バッファを大きくすると、二つのオーダーを、計画通りに完了することができなくなるでしょう。この複数プロジェクトの計画は、二つのプロジェクトが、両方とも、納期どおりに完了できることを示しています。そして、プロジェクトは、両方とも、よく防護されています。

このことから、今度は、逆に、複数プロジェクト計画作成方式のほうが、どんな場合でも、望ましいといえるのでしょうか。また、通常の生産現場で行われる生産のスケジュール作成にも、複数プロジェクトに使うアプローチを使うべきなのでしょうか。

複数プロジェクト計画作成方式を使うと、どのような場合に誤りを犯してしまうかを示すために、上述の二つのオーダーと同じ構造を持つオーダーの場合を考えましょう。しかし、今度は、処理時間は、日数ではなく、分単位です。とする。もちろん、たった、二つのオーダーしか持たないなんていうことはありえません。何百というオーダーです。ここでは、見積納品リードタイムは、分単位ではありませんが、せいぜい、何日というように、日数単位です。出荷バッファは4日、CCRバッファは2日とします。この場合、上のプロジェクトの例で見たように、仮に、行A(上段のフロー)ではなく、行B(下段のフロー)の最初の作業から開始すると、どんな影響がでるのでしょうか。例えば、そうすることで、出荷が20分遅れてしまうのでしょうか。 実際のところ、各オーダーのリードタイムは、「クリティカル・チェーン」に沿った処理時間が合計で1時間より短いとしても、何日というように日単位のものとなるでしょう。何故でしょうか。何百というオーダーを処理しなければならないとき、人はみな、CCRのキャパシティを徹底的に利用しようとします。したがって、CCRのスケジュールの「空き」も上手く使おうとします。そして、制約でない資源の未利用キャパシティとタイムバッファを使い、CCRのスケジュールと納期のスケジュールを防護しようとします。

こうして、複数プロジェクト方式に従って計画されるべき環境と、DBR方式に従って計画されるべき環境の重要な違いは、作業(タスク)の平均処理時間であることが判ります。もし、平均的に作業時間が分単位であれば、これは、明らかに、生産環境です。また、もし、平均的に作業時間が週単位であれば、これは、明らかに、複数プロジェクト環境です。確かに、「グレイ・エイリア」に属すケースもあります。グレイ・エイリアにある環境が、どちらに属すかを判断する基準をもっとはっきりと定義するためには、さらに研究を深めなければなりませんが、平均作業時間が数時間ならば、それは、まだ、生産環境であり、平均作業時間が数日ならば、それは、プロジェクト環境だと考えるべきでしょう。

この違いにより、焦点となる部分が変わってきます。プロジェクト環境では、各プロジェクトの全体的なリードタイムを短くすることが、常に、重要です。したがって、クリティカル・チェーンに沿って、作業を連続的に行うことに力が注がれます。すなわち、前の作業が済むや否や、すぐに、次の作業を開始することを重視します。しかし、実際には、必ずしも、このようには行でしょう。これは、そのようにしたいという願望です。

勿論、生産環境でも、リードタイムを短くしたいという願望がありますが、この場合は、個々のオーダーを単独で見て、リードタイムを短くしたいと考えるのではなく、また、生産量を大きく減らしてまでも、それを行おうとするものでもありません。したがって、一つの特定のオーダーのフローに注目すれば、そのオーダーは、投入されてから完成するまでの殆どの時間、そのオーダーの処理に資源が使えるようになるのを待っています。MRP IIの用語で言えば、これらの時間は待ち時間であり、生産リードタイムの大きな部分を占めています。したがって、この待ち時間を短縮することにより、生産リードタイムに非常に大きなインパクトを与えることができますが、個々のオーダーのクリティカル・チェーンを重視してもうまく行きません。

我々は、ある環境が、複数プロジェクト環境か、または、生産環境のどちらに近いかを評価するとき、あるオーダーの最長のチェーンに沿った純処理時間とリードタイム全体の長さの比率を見るように薦めます。もし、この比率が1/3以上ならば、それは、複数プロジェクト環境であると考えます。もし、そうでないとすると、その環境は、生産環境により近いものと考えます。

在庫管理の役割

理由はなんであれ、伝統的なプロジェクト管理計画作成では、在庫管理について、一切、触れていません。確かに、多くのプロジェクトでは、このことで大きな影響を受けず、また、通常の原材料の在庫保有を必要としないでしょう。しかし、そうではないプロジェクトもあります。上の基準に合致するプロジェクト環境では、原材料が必要です。例えば、船を建造する場合です。造船所は、通常、複数プロジェクト環境であると考えられます。そして、複数プロジェクト環境でありながら、造船という作業は、原材料の利用可能量に支配され、したがって、かなり、大規模に在庫を管理しなくてはならなりません。

プロジェクト環境では、現在、通常、2種類の別個のソフトウエアを使います。その一つは、ERPシステムであり、このシステムは、在庫、および、プロジェクトの経済性の側面を扱うものです。もう一つは、プロジェクト管理のプログラムで、ERPシステムとは、通常、切り離されており、プロジェクトのスケジュールとコントロールを行うためのものです。

この状態は、好ましいものではありません。第一に、プロジェクトのスケジュールに加えられた変更は、効果的にERPのMRP IIモジュールに伝達されません。明らかに、複数プロジェクトの計画作成と、ERPの中でのコントロールを統合し、スケジュール、在庫、予算の所要量の補足が行えるようにすべきであるという強い必要性があります。このとき、難しいことの一つは、MRP IIが、本来的に、生産環境指向であることです。各レベルが、それぞれ、そのレベルのリードタイムを持っている部品表の概念により、ワークセンターの数に従って在庫が累積してゆきます。待ち時間という概念は、複数プロジェクト環境ではなく、生産環境でのものごとの考え方に由来する哲学の中に組み込まれているものです。

我々は、「TOCのDBR方式」と、「TOCの考えに基づく複数プロジェクトの計画作成方式」を「結婚」させることは可能であり、これにより、複数プロジェクトの計画作成方式の持つ考え方中心に置き、高いレベルから低いレベルまで、企業組織全体を強力に結合できると考えています。以下で、複数プロジェクト管理の考え方の中で、この二つの別個の計画作成の方法を統合することの必要性を示します。

生産の要素を持つプロジェクト

船舶、航空機、コミュニケーション・システムのような大きなシステムを生産することを考えて見ましょう。このような製品を生産する場合の作業タスクの基本構造の中には、多様な部品の設計、多数の部品の統合(統合して出来上がる物自体が、大きなサブシステムかもしれません)、最終テストのような典型的なプロジェクト型の作業タスクがあります。これらのタスクは、特定の資源を長時間使うので、プロジェクト型のタスクとして分類されます。もし、これらの資源が、優先順位が最も高いものではない作業タスクを実行しており、この間、他の作業タスクには使えず、かつ、これにより、優先順位の高い作業タスクが遅延してしまうとするならば、その結果として、プロジェクト全体が大きく遅延してしまうかも知れません。プロジェクトでは、特に、資源の割振りが重要です。なぜならば、このような理由での遅延が、プロジェクト環境よりも重要ではない通常の生産環境では通常は見られない「多重タスク」の現象を引き起こすからです。

しかし、同一のプロジェクトが、例えば、同一の船舶のいくつかの場所で必要となる多数の構成部品の生産や、コントラクターから購入するサブシステムの品質検査のような、生産オーダーのように見える作業タスクも持っています。これらの作業タスクは、通常、「現場」で行われます。どの現場も「小さな工場」であり、そこでは、すべてのプロジェクト、場合によっては、プロジェクトではない需要に対応する、多様なジョブを行っています。構成部品の生産は、通常、たくさんの別個の作業タスクを遂行する、いくつかのワークセンターを通過しながら行われます。これらのワークセンターでの、実際の個々の「処理時間」は短いでしょうが、一組の構成部品を生産するには数週間が必要になるかも知れません。プロジェクトの全体的な構造の中で、このような作業タスクは生産タスクです。

我々は、以下のように強く主張します。すなわち、高いレベルでの計画作成を複数プロジェクトの方法論を用いて行い、現場で行う生産タスクの計画作成をDBRに基づいて行うことにより、TOCの複数プロジェクトに関する方法論とDBR方法論を結合すべきです。我々は、さらに、これら二つのモジュール、および、これらのモジュールのリンクは、ERPシステムの一部であるべきであり、こうして、プロジェクト、および、生産の資源計画作成を、真の意味で在庫管理にも統合させるべきです。

大きなシステムの統合スケジュールは、プロジェクトとして考えるべきです。そして、プロジェクトの中のタスクのつながりは、「終了後即開始リンク(finish-to-start links)」によってリンクされるべきであると考えます。こうすることで、プロジェクトの構造を、すべてのタスクが、あたかも、部品表の中の部品であるような「部品表構造」に変換できからです。

資源は、プロジェクト向けの資源と、生産向けの資源に明確に区分されます。そして、生産向けの資源の詳細は、生産部分の生産計画の中にしか存在しません。

ここで提案する複数プロジェクト方式、すなわち、プロジェクト的タスクと生産的タスクの両方を包含するクリティカル・チェーンでは、どの作業タスクがプロジェクト的タスクであり、そして、それらがどのような資源を必要とするプロジェクト的タスクであるか、また、どの作業タスクが生産的タスクであるか、そして、それはどこの現場で行われる生産的タスクであるかを明確に意識したものでなければなりません。

そして、各生産的タスクには、すべて、その生産的タスクで生産する部品に対応する「生産詳細表の識別番号(bill-of -manufacturing id)」の情報が対応していなければならなりません。その中には、その部品に対するディフォルト・バッファについての情報も含まれていなければなりません。ディフォルト・バッファ、すなわち、このタスクを実行するのに必要な時間のディフォルトとしては、出荷バッファにCCRバッファを加えたものを使います。

生産的タスクを実行する各現場は、DBR方法論を使ってスケジュールします。もし、ある現場の持つCCRへの負荷が大きいために、プロジェクトの求めるオーダーのあるものが遅延せざるを得ない場合、影響を受けるプロジェクトのバッファへの浸透の度合い(訳注:どこまでバッファに穴が空くか)を見て、どのオーダーを督促しなければならないかを判定します。

プロジェクトのフレームワークの中にある生産的タスクを行う場合、プロジェクトの他のタスクにより生産されるものを、一つ、もしくは、それ以上、インプットとして必要とすることもあります。DBRのアルゴリズムでは、これらのインプットを、「最早リリース日 ("don't release before" date)」 を持つ、通常の原材料として扱います。変更が必要な場合、DBRを変更することにより、インプット日(リリース日)も「最早リリース日」も変更され、必要に応じ、CCRから下流に伝達されます。ここでの一つの仮定は、原材料の殆どは、生産的タスクで使われ、それ故に、DBR計画により管理されているということです。下記の図は、高いレベルでの概念的なプロジェクト計画を示し、また、一つの生産的タスクが、どのようにして「生産詳細表 (bill-of-manufacturing) 」に変換されるかを示すものです。この生産詳細表は、対応する現場のDBR計画作成の際に、一つのオーダーとして扱われます。



図 5: クリティカル・チェーン内のプロジェクト的タスクにフィードされ、 DBRによってスケジュールされている生産的タスク

図5で示されているクリティカル・チェーン表示のプロジェクトでは、DBRを使って、必要となる数千の構成部品がスケジュールされます。換言すれば、構成部品は、上位のクリティカル・チェーンのスケジュールのニーズに従属して生産されることになります。これらの生産的タスクは、組立フェーズを通して、適切な順序になるようにクリティカル・チェーンにより管理されており、組立フェーズを構成している多様な組立タスクのタイミングに同期して、構成部品が到着するようにします。もし、これらの構成部品が、優先順位を考慮せずに生産されているとすると、これらの構成部品は、組立区域をボトルネックにしてしまうでしょう。構成部品のオーダーは、プロジェクトの組立タスクにより必要とされるタイミングよりも、出荷バッファだけ早く完成するように、現場にリリースされます。これらの構成部品の「顧客」は、プロジェクトのタスクであり、このケースの場合、組立タスクが顧客です。

結合バッファ管理

プロジェクトでは、タスクの所要時間は、クリティカル・チェーンの考え方に従い、処理時間の推定値の50%を使います。DBRでは、バッファの大きさを、納期どおりの納入が90%以上の信頼性で行えるように設定します。したがって、通常の計画作成メカニズムに従うと、生産的タスクは二重に防護されることになります。クリティカル・チェーンではない生産的タスクが、クリティカル・チェーン上のタスクに直接的に統合される上の例のような場合、一つの方法は、クリティカル・チェーンに入ってくる、すべての合流点の前に、通常は置かれる合流バッファ(feeding buffer)を置かないことです。このことは、生産的タスクの出荷バッファが、十分な防護を与えていると考えることを意味します。この問題に対応するためのもうひとつの方法は、プロジェクトにより生成される生産的タスクへのオーダーの出荷バッファを小さくすることです。しかし、これらの防護の問題は、下記の問題に較べ、それほど重要な問題ではありません。

もっと重要なことは、生産現場での不必要な督促を行わないようにすることです。バッファ管理を行っていて、計画バッファが殆どなくなっている状態が識別されたとします。その時点で、オーダーが予定通りに出荷できるような、極端な方法が取られがちです。仮に、その需要が内部的なものであるとすると、緊急性が本当に緊急なもので、督促が必要なものかどうかを確認できます。プロジェクトの中の一つのチェーンが、もともと食われるために置かれている合流バッファの一部を食ってしまうことを回避するために、生産部品の督促が行われるような状況を避けるようにしなければなりません。

このような理由から、(クリティカル・チェーン方式とDBR方式の)二つのシステムが持つバッファ管理の方式を全体的な観点から考えて、相互に全体としてリンクし、管理すべきです。プロジェクトにより生成される生産的タスクへのオーダーの督促は、督促を行う二つの必要性の少なくとも一つが存在する場合にのみ行うようにします。その一は、DBRシステム自体が督促を必要とする場合、その二は、プロジェクトのバッファ管理コントロールの観点から判断して督促が必要と考えられる場合です。

結論

複数プロジェクト環境と生産環境の間の関係を正しく把握するには、両者の計画作成方法の背後にある基本的な前提やルールを明確に理解することが重要です。我々が見出した両者間の違いは、「プロジェクトはすべてユニークであるが、生産は、概して反復的である」という古典的な定義では説明できません。もう一つ、「(生産は多数の単位の産出物のためのものであるのに対して)プロジェクトは、通常、一単位の産出物のためのみのものである」ということがよく引用され、それによってプロジェクトの計画作成に使うアルゴリズム、生産のためのアルゴリズムが(自動的に)決ってくると考えられていますが、実は、必ずしも、産出物の数によって、計画作成のアルゴリズムが決定されるとは限りません。また、「プロジェクトで計画される資源は主として人的資源であり、他方、生産では機械が計画される主たる資源である」とも言われますが、これも、必ずしも正しくありません。

複数プロジェクト環境と生産環境の重要な相違点は、ある資源が、特定のタスクや作業に専有的に振り向けられなければならない時間フレーム違いです。プロジェクトでは、多くのタスクを行うには、何日も、何週も、何ヶ月もの時間が必要です。しかし、生産では、通常、分とか時間の単位です。この相違により、焦点が異なってくるので、計画作成に使うアルゴリズムも変わってくるのです。ある環境が「複数プロジェクト環境」に近いか、それとも、「生産環境」に近いかを評価する簡便法は、クリティカル・チェーン/クリティカル・パスに沿う純処理時間が、実際のリードタイムに近いかどうかを調べることです。

生産環境では、DBRによる計画作成により、最も負荷の高い資源のキャパシティを最大限に活用することができ、リードタイムを上手にコントロールでき、そして、大きくリードタイムを短くすることができます。我々は、DBRは、生産環境での計画作成のための健全なアプローチであると確信します。

複数プロジェクト環境と生産環境の違いが明確になると、誰しもが抱く次の疑問は、典型的なプロジェクトであり、しかも、そのプロジェクトの中に、典型的な生産タスクを持つ「ハイブリッド環境」での計画作成をどうすべきかということです。我々は、以上、述べて来たことから、プロジェクトの中の生産タスクはDBRにより計画するようにお勧めします。このとき、上位にあるプロジェクト計画より、必要納期日と原材料のインプット日を生成します。そして、プロジェクト環境部分と生産環境部分のバッファ管理を、全体的な観点からしっかりとリンクさせます。このようなアプローチを採ることにより、高いレベルの計画作成を「TOCの複数プロジェクトの計画作成方式」で行い、生産環境である各現場を「TOCのDBRによる計画作成メカニズム」により行い、高いレベルの計画と低いレベルの計画を整合させた全体的な計画を得ることができると考えています。

MSI 小林 英三訳(2001年9月16日)

このページの先頭へ