序文
2008年に、エリヤフ・ゴールドラット博士は、「巨人の肩の上に立って」という、生産概念に対する生産アプリケーションの歴史に関する画期的な論文を記しました。この論文で、ゴールドラット博士は、彼以前の２人の産業界の巨人であるヘンリー・フォード氏と大野耐一氏の偉業に基づき「フローの４つの概念」を言語化しました。この論文の中で博士は、フォードとトヨタシステム（安定的な環境）と、TOCのDBR（ドラム・バッファ・ロープ）ソリューションを開発する動機となった製造過程の不安定な現実では条件が違う事を見事なまでに説明しました。[1]
ゴールドラット博士は、DBRアプリケーションはあらゆる環境に適しているわけではないだろうと述べて論文を締め括りました。DBRは従来型の生産環境に関して仮定（時には隠れた仮定）を置いているため、その仮定が有効ではない環境下でアプリケーションが機能することを期待すべきではありません。DBRの重要な仮定の１つは、生産タッチタイムが既定のリードタイムと比較して非常に小さいことです（10％未満）。この仮定は多くの典型的な受注生産環境（MTO）では有効ですが、慣習的にプロジェクト環境と呼ばれる、非常に広範囲な環境では有効ではありません。この環境に対し、ゴールドラット博士はCCPM（クリティカルチェーン・プロジェクトマネジメント）を開発しました。また長年に渡り、TOCコミュニティは、（鉄鋼業の冶金工程のように）生産工程が長時間で固定的な環境に対処するためのハイタッチタイムアプリケーション（HTT-DBR）を紹介してきました。
この論文では、日本の売上2,200億円規模の製造会社において、オリジナルのDBRアプリケーションに、付加的なレイヤーを追加した経験を共有したいと思います。この会社は大手製造業、金融業、公共セクター向けに技術システムを設計・製造する企業です。ほとんどの製品への要求は、非標準（特殊品）かつ不定期なもので、海外のベンダーからの部品納入リードタイムが長くなることもありました。各ワークセンター（約25か所のワークセンター）では、チームがいくつかのワークオーダーを同時に処理することができました。
ほとんどの生産環境におけるワークセンターは、一台あるいは複数台の機械で構成されていて、ほとんどの場合、各機械は一度に一つのオーダーを処理します。各ワークセンターにある個々の機械は一つのオーダーだけ処理するというのが、DBRが作られた時に仮定された環境です。このケースでは、各ワークセンターで、作業者は一つ以上、時には二つか三つ、のオーダーを同時に処理することにスペースや設備を使われていた。しかし私たちは、この事が、負荷（または予期される負荷）が二倍、三倍に増加した場合、生産リードタイムをさらに長くしていることに気づきました。この現象は組立工場でよく発生し得るものであるため、私たちはこの新たな条件に合うアプローチ方法を開発した方が良いと考えました。
私たちは論文「巨人の肩の上に立って」に記されているフローの４つの概念を適用することで、生産ラインの１つにTOCの原理原則を適用しました。
- オペレーションの主要な目的は、フローを向上させること（あるいはリードタイムを短くすること）である ： 企業の経営層へフローの向上に集中するよう説得した結果、彼らは６カ月のコンセプト検証期間中にリードタイムの20％短縮に成功するという野心的なKPIを設定しました。
- この目的は、（過剰生産を防ぐため）いつ生産してはいけないのかを示す具体的な生産メカニズムに変換されなければいけない ： その手段として、フォード氏はスペースを、大野氏は在庫を、ゴールドラット博士は時間を使いました。私たちは、製造現場へのオーダーの投入を絞る（投入して良いオーダーの数を制限する）ことで、過剰生産を防ぎました。
- 局所的な効率は無視しなければいけない ： 私たちには限られた時間しかなかったため、私たちが実施した重要な対策は、フルキットがされるまでは絶対に開始しないことようにするというものでした。
- フローをバランスさせるためには集中プロセスが不可欠である ： コンセプト検証期間が限られていたため、私たちは上述のオーダー数を制限することを続けることを除き、プロセスをバランスさせるということは実施しませんでした。
成果：わずか4ヶ月で生産リードタイムを40％削減
コンセプト検証におけるリードタイムの劇的な削減により、クライアントは全ての生産ラインでソリューションを導入したいと依頼せずにはいられませんでした。
全体のソリューションの詳細設計中に判明した二つの新しい課題：
- 動的な工順メカニズムの必要性。その企業には約25のワークセンターがあり、個々の製品の工順は顧客の要望に従って設定され、かつ、オーダーごとに異なるものであった。（通常これらはERPシステムによって処理されるが、私たちのケースではそうではなかった。）私たちはこの課題について、（この論文の主旨ではないが）私たちのソフトウェアに動的な工順ソリューションを開発することで解決しました。
- 生産環境における根本的な違いの認識 －追加的なメカニズムを付け加えるなど、TOCソリューションによって期待される高い成果をもたらすために、DBRアプリケーションの再考が必要になるほどの違い。私たちにとっては、フォード氏、大野氏、そしてゴールドラット博士によって定義されたフローの概念は有効であること、この環境（主に組立工場）におけるギャップをよりよく理解すること、ミッシングリンクを見つけるためには「巨人の肩」の上に立つ必要があることは、最初から自明のことでした。
環境の違い
ソリューションを導入した際、フローの４つの概念に従ったにも関わらず、そしてコンセプト検証において「信じられないほど素晴らしい」成果を上げたにも関わらず、ワークセンターの作業者にはマルチタスクをしなければならないという絶え間ないプレッシャーがありました。マルチタスクがキャパシティに対して非常に悪い影響を与えることは数多くの言葉が書かれており、とてもシンプルな実作業でさえマルチタスキングがネガティブな影響をもたらすことは多くのグループエクササイズで実証されています。現実的な問題は、なぜそれが起こってしまうのか、どうすれば強固な手段でそれを克服することができるのか、ということです。
ソリューションの詳細設計中に私たちが見つけた違いとは、決してこの企業に限った事象ではありません。これは過去数年以上に渡りTOCコミュニティのリーディングメンバー達によって発見、説明された事象であると思っていますが、今回のケースでは、顧客の高い期待に応えるには、このことに専念して、これを解決する素早いメカニズムを見つけなければなりませんでした。
一般的に、マルチタスクをしてしまうのは、「早く始めれば、早く終わるだろう」、さらに言うと「もっと多く始めれば、もっとたくさん終えることができるだろう」と信じている事が原因です。さらに、一般的な理由は、マルチタスク自体がより効率的でスピードとキャパシティを増大させるという、根本的かつ間違った信念です。もう一つの事象は、ワークステーションにおける仕事の「枯渇」です。現場の従業員は、暇であると見られたくないために、マネージャーや同僚に有能さをアピールするために、不要な仕事を始めます。もっとひどい場合は、暇であると思われないために、作業ペースを下げる作業者が出てきます。
フルキットのようなメカニズムは、このような状況を防ぐためのものであり、ワークセンターに作業が溜まり過ぎないようにするためのものです。しかし私たちのケースでは、ワークセンターの前で停滞している作業のバッファによって、フルキッティングのルールを「緩和」して、より多くの作業を始めてしまう傾向があることが明らかになりました。私は、マルチタスクに陥ってしまう根本原因は、早く始めればもっと作れるだろうという信念ではなく、世界中の製造現場における効率性という主要な評価指標が非常に強く影響していると信じています。効率性という非常に強い影は、マルチタスクを防ごうとする如何なる真の試みも潰してしまいます。全てのオペレーション層は（組織全体の有効性によって評価される経営層とは反して）効率性という尺度で評価され、そのことが、マルチタスクをすることへの大きなプレッシャーとなっています。
ソリューション：DBRかんばんアプリケーション
TOCは、オーダーを投入するドラムビート（訳注：オーダーを投入するペースを決める）として適しているボトルネックにDBR（ドラムバッファロープ）の概念を用いることで、不安定な環境に対応しています。「タイムバッファ」が「納期」から「投入日」を導き出し、投入を絞るというアクションがオーダーと投入日をつなぐ「ロープ」になります。しかし、このソリューションはいくつかのワークステーションの前に（ボトルネックの前には常に）に仕掛品を置くことを許容（そして奨励）するので、特定のワークステーションでは最適なリソース割り当て以上の仕事をすることへのプレッシャーが大きく、悪いマルチタスクへの道が待ち構えています。
これを防ぐための解決策は、時間を巻き戻して、非常に効果的なDBRソリューション上に、個々のワークセンターごとに問題を解決し得る付加的な要素を加えることでした。私たちは各作業現場で処理できるオーダー数を人為的に制限しました。特定のワークセンターで処理する全てのワークオーダーは、それらの工順によって到着し、そして作業者はMTOと同じ色による優先順位システムに従ってそれらを処理します。唯一の変更点は、個々のワークセンターにある「処理中」のワークオーダーの数をコンピューターで制限すること、その数をワークセンターにおける利用可能なリソースと最適なリソース配置に従って設定することでした。
まさにかんばんシステムのように、ワークオーダーが完了した時のみ（優先順位の色に従って）新しいワークオーダーが待ちリストから投入されるのです。オリジナルのかんばんシステムであるTPSのように、この手法はワークセンター内の作業負荷が「とても」異なる場合において、更なる思考や追加的なツールを必要とするかもしれません。しかしほとんどの場合において、DBRかんばんというソリューションは、フローを向上し、誤った評価指標によってマルチタスクをしてしまうという人間の特性を克服するものです。私たちは、過剰生産とマルチタスクを防ぐための最善の方法は、幅広い同意形成、教育、そして最も重要なこととしては、正しい評価指標を設定することによるものだと信じています。しかし生産DBR環境において、（組立工場のように）ワークセンターの従業員が同時にいくつかのオーダーを処理できてしまう場合は、ソフトウェアで補助されたDBRかんばんは、フローを向上し、そして「効率的」であろうとする（それゆえにマルチタスクをしようとする）人間の行動特性と、会社全体の有効性を損なうことを防ぐための最善の手法です。
[1] TOCの概念とそのアプリケーション群の間には混同があるかもしれません。ゴールドラット博士は論文の中でDBRを使っていますが、DBRとはTOCの思考、概念から派生した一般的な原理原則です。アプリケーションのエッセンスとして、MTO（受注生産）が知られています。TOCにはCCPM（ドラムやバッファと似ている専門用語と感じられますが）のように、DBRの概念を用いた多くの付随的なアプリケーションがありますが、それらは事なる方法で適用されるだけで、そのことで定義上全く異なっている訳ではありません。
ぜひこちらの問い合わせフォームからご意見やご感想をお寄せください。また、弊社SNSへの投稿もお気軽にどうぞ。
