第9章: リーン、シックスシグマ、DevOpsとTOC ── 現代における意義
2013 年、シリコンバレーで1冊の本が話題になった。
Gene Kim 著『The Phoenix Project』。表紙には「A Novel about IT, DevOps, and Helping Your Business Win」。 中身は、IT 部門の責任者が炎上中のプロジェクトを救う物語。 多くの読者は気づく ── 「これは『ザ・ゴール』の IT 版だ」と。
実際、Kim は明示的に『ザ・ゴール』への敬意を表明している。 ボトルネック、フロー、WIP 制限、3 つの指標、5 つの集中ステップ ── TOC の発想がそのまま IT に持ち込まれていた。
ゴールドラットが1984 年に工場で見つけた構造は、2013 年のソフトウェア開発で再発見された。 これが TOC の真の遺産だ。
最終章では、TOC を現代の他のフレームワークと並べて、それぞれの違いと共通点、そして TOC が現代でどう活かされているかを見る。
9.1 TPS / リーンとの比較
TOC とリーン（Lean Manufacturing、TPS = トヨタ生産方式の世界版）は、しばしば「ライバル 」として語られる。だが本質的には、同じ問題を別の角度から解こうとした 兄弟のような関係だ。
共通点
| 観点 | 両者の共通点 |
|---|---|
| 全体最適志向 | 個別効率より、全体スループットを優先 |
| 仕掛品（WIP）を悪と見る | 大量在庫は問題の隠蔽源 |
| フロー重視 | 物が止まる時間を減らす |
| 顧客起点 | 売れた物だけが価値 |
違い
| 観点 | TOC | リーン (TPS) |
|---|---|---|
| 出発点 | 物理学的視点（ばらつきと依存） | 観察的視点（トヨタの実践） |
| 中心概念 | 制約（ボトルネック） | ムダ（7 つのムダ） |
| ばらつきへの態度 | 受け入れて バッファで吸収 | 徹底的に減らす（標準化、ジドウカ） |
| 主要ツール | DBR、5 ステップ、TP | 5S、カンバン、ジドウカ、改善 |
| 会計への踏み込み | スループット会計を提案 | 会計には踏み込まず |
| 改善の主体 | コンサル / 経営層 | 全社員、現場主導 |
| 認定文化 | Goldratt Institute 中心 | トヨタ流の OJT、特定の認定なし |
| 普及度 | 中（一部業界） | 大（世界中の製造業に浸透） |
TPS は 「ばらつきを下げて」 リードタイムを縮める道。
TOC は 「ばらつきを受け入れて」 バッファで守る道。
両者は 互いに排他的ではない。実際、リーン+TOC のハイブリッド（TLS = TOC + Lean + Six Sigma）という統合手法を提唱する論者もいる。
TLS（TOC + Lean + Six Sigma）
Reza Pirasteh は2010 年代に TLS という統合フレームワークを提唱した:
- TOC で制約を特定する（「どこに集中するか」）
- Lean でムダを削減する（「そこで何を直すか」）
- Six Sigma でばらつきを減らす（「ばらつきの源は何か」）
理論的には魅力的だが、実務では 「TOC か Lean か」の派閥意識 が強く、TLS が広く普及したわけではない。とはいえ 現場では暗黙的に併用 されている。
9.2 シックスシグマとの比較
シックスシグマ は1986 年にモトローラで生まれ、1990 年代以降 GE が大々的に展開して企業改革ツールになった。DMAIC（Define-Measure-Analyze-Improve-Control）というプロセスで品質欠陥を統計的に減らす手法。
| 観点 | TOC | シックスシグマ |
|---|---|---|
| 焦点 | フロー（スループット） | 品質（欠陥率） |
| 主要数学 | 待ち行列、制約理論 | 統計（正規分布、 〜 ） |
| 改善対象 | 制約のみに集中 | あらゆるプロセス |
| 認定 | 限定的 | グリーンベルト、ブラックベルト等 |
| GE 等での適用 | 限定的 | 大規模採用 |
| 適した課題 | リードタイム、フロー | 不良率、変動 |
シックスシグマは「ばらつきを統計的に下げる」のが得意。TOC は「ばらつきを受け入れて制約を守る」のが得意。組み合わせの相性は良い。
GE のジャック・ウェルチは1995 年にシックスシグマを全社導入した。 これはアメリカ製造業のシックスシグマ普及を決定づけた。 逆に言うと、GE が TOC を採用していたら歴史は変わっていた かもしれない。 ゴールドラット個人とウェルチが折り合えなかった、というのが当時の業界話。
9.3 アジャイル / スクラム / カンバンとの関係
ソフトウェア開発の世界で TOC の発想は 別の名前で再発明 された。これが現代における TOC の最大の影響かもしれない。
スクラムの中の TOC 要素
スクラム自体は TOC を直接引用しないが、共通する発想がある:
| スクラムの要素 | TOC との対応 |
|---|---|
| スプリント（時間枠） | DBR の「ドラム」に近い概念 |
| WIP 制限（タスクボード） | ロープに相当 |
| バーンダウンチャート | バッファ消費の可視化 |
| プロダクトオーナーの優先順位付け | スループット最大化判断 |
ソフトウェアカンバン（David Anderson）
ソフトウェア開発のカンバン手法を整理した David Anderson の『Kanban: Successful Evolutionary Change for Your Technology Business』（2010）は、明示的に TOC と Lean を統合 して説明している。
中核原則:
- 可視化: 仕事をボードで見える化
- WIP 制限: 同時進行タスクに上限
- フローを管理: リードタイム短縮を主指標
- 明示的なポリシー: ルールを明文化
- 継続的改善: 5 ステップに類似のループ
これは DBR とほぼ同じ発想 だ。WIP 制限 = ロープ、フローを管理 = ドラム、明示ポリシー = TOC の評価指標変更。
カンバン手法 (ソフトウェア) は、 TOC を意識しないユーザーにも TOC を実装させる仕組み になっている。
「Jira でカンバンボードを使い、WIP 制限を設定している」という現代のソフトウェアチームは、知らないうちにゴールドラットの教えを実践している。
9.4 DevOps と Phoenix Project
ゴールドラットの最大の弟子は、おそらく Gene Kim だ。
Kim は『The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win』（2013）で、『ザ・ゴール』の構造を IT 部門にそっくり移植した。物語の構造、登場人物、対立の解消法 ── すべてが意図的に対応する。
Phoenix Project の中の TOC
| TOC（ザ・ゴール） | DevOps（Phoenix Project） |
|---|---|
| 工場のボトルネック工程 | IT 運用のボトルネック担当者 |
| 仕掛品の山 | 未完了のチケットの山 |
| MRP のプッシュ計画 | ウォーターフォール開発 |
| DBR | デプロイパイプラインの制御 |
| スループット会計 | 開発の Value Stream |
| 5 つの集中ステップ | DevOps の Three Ways |
The Three Ways（DevOps の3 原則）
Kim はこれを「The Three Ways」として定式化した:
- The First Way（Flow）: 開発→運用へのフローを最適化（左から右へ）
- The Second Way（Feedback）: 運用→開発へのフィードバックを最適化（右から左へ）
- The Third Way（Continuous Learning）: 実験と学習の文化
これらは TOC の影響をストレートに受けている。「最も遅い工程に集中する」「フィードバックでばらつきを早期検出」「inertia を制約にしない」 ── 全部 TOC の発想。
DevOps Handbook
Kim らの続編『The DevOps Handbook』（2016）では、ボトルネック分析、Value Stream Map、WIP 制限、デプロイ頻度の最適化など、TOC の運用フレームワークがそのまま IT 運用に適用 されている。
現代の Google SRE、Netflix のエンジニアリング文化、AWS のサービス運用 ── これらの DevOps 文化は TOC の系譜上にある。
9.5 SaaS / Cloud 時代の TOC
製造業を離れて、現代の SaaS / クラウドビジネスでも TOC の発想は強力に効く。
キャパシティプランニング
クラウドサービスの キャパシティプランニング は、まさに TOC 的:
- どのコンポーネントが制約か（DB? API? ネットワーク?）
- 制約に集中投資する（横展開で全体最適化）
- 制約以外は遊ばせて OK（オートスケールで縮退）
これは TOC の純度の高い適用例だ。
営業ファネルのボトルネック分析
セールスファネル（Lead → MQL → SQL → Opportunity → Customer）の各段階で 歩留まり を計測し、最も低いステージに集中投資する ── これも TOC のステップ 1〜4 そのもの。
エンジニアリングのキャパシティ
開発チームの スプリント計画 で「これ全部できるはず」と詰め込み、毎回未完了が残る ── これはマルチタスクの罠（第6 章）。TOC 的には「WIP 制限を厳格化し、リレー走者の規律を持つ」が答え。
9.6 TOC が「気づかれない」のはなぜか
ここまで見てきたとおり、TOC の発想は現代に深く浸透している。だが「TOC」というブランドはあまり登場しない。なぜか?
TOC は 思想として勝った ため、固有名詞の必要性が薄れた。
「ボトルネック」「フロー」「WIP」が日常語になった瞬間に、それが TOC 由来だという出典は薄れる。これは エポニミー（命名の喪失） と呼ばれる現象で、本当に普及した概念にはよく起きる。
ニュートン力学を「ニュートン力学」と意識する人は物理学者だけ。一般人は「物が落ちる」と言う。TOC も同じ運命を辿った。
9.7 TOC を現代でどう活かすか
最終章として、本書の実践的な締めくくり。現代のビジネスパーソンが TOC をどう使うか の指針を3 つ。
指針 1: 「ボトルネック思考」を意思決定の出発点にする
何か改善したいときに、最初に問うべき:
- 全体のスループットを律速しているのはどこか?
- そこに集中投資した場合のリターンはいくらか?
- 他で改善しても、全体は変わらないのではないか?
これだけで、多くのプロジェクトの優先順位が変わる。
指針 2: 部分最適の罠を疑う
KPI が分かれている組織では、必ず部分最適の罠が起きる。
- 機械稼働率を上げよ → 仕掛品の山
- リードを多く取れ → 質の悪いリードで営業時間が浪費
- バグを少なくせよ → 慎重になりすぎてリリースが遅れる
「この KPI を最大化したら、別の何かが悪化しないか?」を常に問う。
指針 3: ジレンマには第三の解がある
対立解消図の発想を、日常の意思決定に持ち込む。
- 速度 vs 品質
- 短期 vs 長期
- 個人 vs チーム
- 効率 vs 創造性
これらの対立は、前提を疑えば 第三の解が見つかることが多い。「両方取る」ではなく「両者の前提を解体する」のがゴールドラット流。
9.8 本書のまとめ
本書を通じて、私たちは:
- そもそもゴールは何か を腑に落とした（お金を稼ぐこと）
- 3 つの指標 で測ることを学んだ（T, I, OE）
- 制約は自然発生する ことを物理的に理解した（依存とばらつき）
- 5 つの集中ステップ を運用ループとして学んだ
- DBR で工場を太鼓のリズムで動かす方法を見た
- CCPM でプロジェクトに TOC を持ち込む方法を学んだ
- 思考プロセス で工場以外への適用を見た
- 本当に効いたか を事例とメタアナリシスで検証した
- 現代でどう活きているか を他フレームワークと並べて整理した
最大のメッセージ
TOC は 「制約に集中せよ」 という一行に集約できる思想だが、その背後には:
- 会計の歪み を直撃した洞察
- 全体最適 vs 部分最適 の理論的決着
- ばらつきを受け入れる という勇気
- 改善エネルギーの1 点集中 という覚悟
- 対立を蒸発させる 第三の解の発想
がある。これらは2026 年のいま、製造業を超えて IT、組織、人生 の意思決定に効く道具だ。
「制約に着目する」は、当時は革命だった。今は当たり前。 だが「制約に集中する勇気」は、いつの時代も希少なリソースだ。
9.9 第9章の振り返り
- TOC と Lean は同じ問題を別の角度から解く兄弟。TLS で統合を試みる動きも
- シックスシグマは品質・統計、TOC はフロー・制約。相性は良い
- アジャイル / カンバンは TOC を 別の名前で再発明 した
- Gene Kim の Phoenix Project が TOC を IT に移植し、DevOps の核に
- SaaS、キャパシティプランニング、営業ファネルにも TOC は直接適用可能
- TOC は 思想として勝ち、ブランドは霞んだ（エポニミーの喪失）
- 現代の実践指針: ボトルネック思考、部分最適の罠、第三の解
この章で読めるようになるニュース
- 「DevOps 改革で開発生産性 2 倍」── TOC の系譜として読める
- 「リーン+TOC のハイブリッド導入」── 統合フレームワーク TLS の試み
- 「Value Stream Mapping で全体最適」── TOC の3 指標と Lean の統合
ここで本書の本編は終わる。次の付録（用語集）は、ここまでに登場した TOC の主要概念をリファレンスとして整理した。読み返し用に活用してほしい。
そして、もし可能であれば ── 本物の『ザ・ゴール』をぜひ手に取ってほしい。本書はあくまで早回しの教科書。原著の物語の熱量は、要約では伝わらない。