第5章: DBR ── ドラム・バッファ・ロープ
あなたの工場では「制約に集中する」哲学は浸透した。 皆が「ボトルネックを大切に」と言うようになった。
だが現場のラインリーダーが訊いてくる。 「OK、ボトルネックを大切にするのは分かりました。で、実際にラインをどう動かせばいいんですか?」
ここで TOC は具体的な運用パターンを提示する。それが DBR (Drum-Buffer-Rope)。 工場全体が、たった1つの太鼓のリズムで踊る ── そんなイメージから始まる。
5.1 DBR の3つの要素
DBR は3つの英単語の頭文字で、それぞれが工場運営の構成要素に対応する。
Drum（ドラム）── 工場全体のリズム
工場の 最終的なスループットは、制約工程の処理速度で決まる 。だから工場全体のリズムは、制約工程の処理計画 で決める。これがドラム（太鼓）。
ドラムは「今日 C 工程で何をどの順番でどれだけ処理するか」のスケジュールそのものだ。これさえ決まれば、他の全工程はこれに従属する（ステップ 3）。
Buffer（バッファ）── 制約を守る時間貯金
制約工程の手前に、時間バッファ を置く。これは「物のバッファ」ではなく「時間のバッファ」 ── 「制約に到着するまでの所要時間を実際より長めに見積もって、早めに投入する」ことで実現する。
なぜ必要か:
- 上流の A、B 工程は必ずばらつく
- たまにトラブルで遅れる
- もし制約 C が 原料切れで止まる と、スループット損失は永久に取り戻せない（C は工場全体の制約だから）
だから C が止まらないように、C の前に 少しの仕掛品の山を意図的に作る。これがバッファ。
Rope（ロープ）── 投入と制約をつなぐ命綱
最初の投入工程（原料投入）を、制約工程の進捗に同期させる 。文字通り「ロープでつなぐ」イメージ。
具体的には: C が1個処理したら、原料を1個投入する。C の処理ペースを超える投入はしない。これによって工場全体の仕掛品が制御される。
ドラム = 制約のリズムで全体を動かす バッファ = 制約直前にだけ時間貯金を置く ロープ = 投入を制約に同期させる
この3 つで、仕掛品の山を作らずに、制約を絶対に止めない 運用ができる。
5.2 MRP（プッシュ方式）との対比
DBR の発想を腑に落とすには、MRP（Material Requirements Planning, 資材所要量計画） との対比が効く。
MRP は1970年代に普及した工場運営のソフトウェアで、現代の ERP（SAP、Oracle）の前身。基本発想は:
- 顧客需要から逆算して、各工程に「いつ何をいくつ作る」をスケジュール
- 各工程は そのスケジュールどおりに動く ことを要求される
- 各工程は 前工程から物が来たら、すぐ着手する
これが プッシュ方式 の本質。上流から下流へ「これを作って」と物が押し込まれていく。
MRP が引き起こす典型的な問題
- 各工程のスケジュールが完璧でないと、必ずどこかで詰まる
- 上流が早めに作ると、下流の前に在庫の山ができる
- ばらつきの累積で、計画と現実が日々ずれていく
- 「全工程同時最適」を目指すので、計算量が爆発する
DBR はこれを根本から否定する。全工程をスケジュールしない 。制約だけスケジュールし、他は制約に従属。
| 観点 | MRP（プッシュ） | DBR |
|---|---|---|
| 何をスケジュールするか | 全工程 | 制約だけ |
| 各工程の指示 | 「いつまでに作れ」 | 「制約の指示に従え」 |
| 仕掛品の場所 | 工場のあちこち | 制約直前にだけ |
| ばらつき耐性 | 弱い | 強い（バッファで吸収） |
| 計算量 | 大（全工程同時最適） | 小（制約だけ） |
5.3 カンバン方式（プル方式）との対比
DBR と並んで「制約に従属させる」設計思想を持つのが カンバン方式 ── トヨタ生産方式（TPS）の中核技術だ。
カンバンの発想:
- 各工程は 後工程から「これを作ってくれ」というカンバン（カード）が来たら 着手する
- カンバンの枚数 = 工程間の在庫上限
- これによって自然にプル方式が成立し、仕掛品が制限される
DBR とカンバンは「プッシュをやめて、何かに同期する」点で似ている。違いは:
| 観点 | DBR | カンバン |
|---|---|---|
| 起点 | 制約 1 点 | 最終工程（顧客需要） |
| 信号の通り方 | 制約から原料投入へ1 本 | 各工程ペアで個別 |
| 適した状況 | ばらつき大、製品多品種 | 安定需要、製品少品種 |
| 在庫の置き場 | 制約直前にだけ集中 | 全工程ペア間に分散 |
| 立ち上げの難易度 | 比較的速い（制約だけ見ればいい） | 全工程の安定が前提 |
カンバン は 全工程が均質に動く前提 で初めて美しく機能する（だから TPS は「ばらつきを徹底的になくす」改善が必要）。 DBR は ばらつきがあっても制約直前にバッファを置く ことで対応する。
つまり TPS は「ばらつきを下げて」、TOC は「ばらつきを受け入れて」、それぞれ同じ目標（仕掛品最小、スループット最大）に違う道で迫っている。
5.4 バッファマネジメント ── DBR の運用ノウハウ
DBR の運用では バッファマネジメント という独自の管理手法を使う。
時間バッファ（例: 制約に到着する3 時間前に投入）を3 つのゾーンに分ける:
| 色 | 状態 | アクション |
|---|---|---|
| GREEN | バッファ消費が 0〜33% | OK。何もしない |
| YELLOW | 33〜67% | 注視。遅延の原因を調査開始 |
| RED | 67〜100% | 即座に介入。残業、応援、優先順位変更 |
これだけだ。現場の判断指針が3 色で済む。MRP のように毎日全工程のスケジュールを再計算する必要はない。
「OK / NG」の2 値ではなく、3 ゾーンで運用する設計に味がある。 GREEN だと現場が手を抜きすぎるし、RED だけだと「もう手遅れ」になっている。 YELLOW で予兆を捉えるのが現場の腕の見せ所。
5.5 S-DBR ── DBR の簡略化
オリジナルの DBR は「制約工程を厳密にスケジュールする」「上流のバッファを精緻に管理する」など、運用が複雑になりがちだった。
そこで2000 年代に提案されたのが S-DBR (Simplified DBR)。
主な簡略化:
| 観点 | DBR | S-DBR |
|---|---|---|
| 制約の場所 | 工場内のどこかと仮定 | 市場が制約と仮定（多くの工場で実情に合う） |
| バッファの場所 | 制約直前 | 出荷直前（注文充足バッファ） |
| 投入ロープ | 制約に同期 | 注文に同期 |
| 制御の単位 | 制約工程 | 注文（オーダー） |
S-DBR は「現代の多くの工場は能力過剰で、本当の制約は市場（受注獲得）」という観察に基づく。これがハマる工場では、運用がとてもシンプルになる。
5.6 DBR の落とし穴
DBR は強力だが、いくつかの典型的な落とし穴がある。
落とし穴 1: 制約が動いたら DBR は再設計ステップ 5 の Repeat と同じ話。制約が C から D に移ったのに、ドラムをまだ C のスケジュールで作っていると、何のメリットもなくなる。 月次でボトルネックを再確認 すべし。
落とし穴 2: バッファサイズの初期値バッファ（時間）の初期値は、過去のばらつきから経験的に決める。 大きすぎると無駄な仕掛品、小さすぎると制約が止まる。 バッファ消費の履歴 を観測しながら、3〜6 ヶ月かけて調整。
落とし穴 3: 非制約の作業員のモラルステップ 3 と同じ。「制約に従属するため意図的に遊ぶ」を組織に納得させるのが本当に難しい。 評価指標を変える ことが必要（個別稼働率 → スループット貢献）。
落とし穴 4: 段取り依存の工程段取り時間が長い工程では、ロットを大きくしたい誘惑が常にある。 ボトルネック工程では「ロットは需要に合わせて小さく 段取りを増やしてでも」という DBR の指示が、現場の感覚と衝突する。 ここで折れるとボトルネックが見かけ稼働率を上げて、結果として全体スループットが下がる。
5.7 ソフトウェア開発・DevOps への波及
ここまでは工場の話だが、DBR の発想はソフトウェア開発に そのまま 持ち込まれている。
- CI/CD パイプライン: ビルド → テスト → デプロイ。最も遅い段階が制約 → そこを「太鼓」に
- チーム間の依存: 一番遅いチームに合わせる ロープ
- WIP 制限: カンバンで広がった概念だが、TOC の発想と一致
- Gene Kim の『The Phoenix Project』: 『ザ・ゴール』を IT 部門にリブートした小説。 TOC の核がそのまま使われている
第9章で DevOps との関係を詳しく見る。
5.8 第5章の振り返り
- DBR = Drum（制約のリズム）+ Buffer（時間貯金）+ Rope（投入を制約に同期）
- MRP（プッシュ）と違い、制約だけ をスケジュールする
- カンバン（プル）と違い、1 本のロープで全工場を制御 する
- バッファマネジメントは GREEN / YELLOW / RED の3 色で運用シンプル
- S-DBR は「市場が制約」の前提で運用をさらに簡略化
- 落とし穴: 制約の移動、バッファサイズ、組織心理、段取り依存
- DevOps / CI/CD にもそのまま発想が転用されている
この章で読めるようになるニュース
- 「CI/CD パイプラインのボトルネック解消」── DBR 発想の IT 版として理解できる
- 「WIP 制限を導入してリードタイム30%短縮」── ロープによる仕掛品制御の効果
- 「全工程のスケジュール最適化」── これが MRP 的発想で、DBR とは別物と区別できる
ここまでで工場運営の TOC は完結する。次の第6章では、TOC がプロジェクトマネジメントに渡って生まれた CCPM（クリティカルチェーン） に踏み込む。製造業以外の世界での TOC の最初の大きな展開だ。