制約理論（ToC）入門 2026版

2026年度リクルート エンジニアコース新人研修の講義資料です。

Transcript

1. 制約理論（ToC）入門 2026版 上島 賢士（Satoshi UEJIMA）
2. 株式会社リクルート 販促領域プロダクトディベロップメント1ユニット（住まい） Vice President 上島 賢士（Satoshi UEJIMA） ▪経歴 2007年：大手SIer 新卒入社 2013年：株式会社リクルートテクノロジーズ 入社 2015年：株式会社リクルートテクノロジーズ エンジニアリングG グループマネージャー 2016年：同上 兼 株式会社リクルートマーケティングパートナーズ 2017年：同上 兼 株式会社リクルート住まいカンパニー 2019年：株式会社リクルートテクノロジーズ ライフイベント領域エンジニアリング部 兼 株式会社リクルート住まいカンパニー 2020年：株式会社リクルート 住まい領域エンジニアリング部 兼 部長 部長 住まい領域開発ディレクション部 2022年：株式会社リクルート 販促領域（住まい・M&F・自動車・旅行）エンジニアリング部 兼 住まい領域開発ディレクション部 2023年：株式会社リクルート 住まい領域開発ディレクション部 兼 事業開発領域開発ディレクション部 兼 新規事業開発室 部長 2024年〜：株式会社リクルート 住まい領域プロダクトディベロップメントU VP 部長
3. なぜ今、制約理論（ToC）を学ぶのか AIにより「実装」の処理能力が、桁で伸び始めています。 しかしチームの事業価値は、桁では増えていません。 実装は工程の一部に過ぎず、他工程の速度は変わっていません。 AIで実装だけを速くしても、能力差が広がるだけです。 「制約と非制約の区別」が、これまでより強く効く時代に入りました。
4. Agenda 1. 制約理論（TOC）とは 2. 企業のゴール（目標）とは 3. 制約（ボトルネック）とスループット 4. バッチサイズとリードタイム 5. ソフトウェア開発現場での話 6. まとめ
5. 1. TOC（Theory of Constraints：制約理論）とは イスラエルの物理学者エリヤフ・ゴールドラット博士によって提唱された 生産管理や経営の全体最適化の改善手法 “どんなシステムであれ、常にごく少数の要素/因子によって、 その目的達成に向けたパフォーマンスが制限されている” “制約にフォーカスして問題解決を行えば、小さな変化と 小さな努力で短時間のうちに著しい成果が得られる” ※本研修ではゴールドラット博士の著書「ザ・ゴール」のエッセンスの紹介と、 ソフトウェア開発の現場における例を交えた説明をしていきます。 出典：https://promo.diamond.jp/books/the-goal/
6. 2. 企業のゴール（目標）とは 『お金を儲け続けること』
7. 2. 企業のゴール（目標）とは 『お金を儲け続けること』 経営の指標 現場の指標 • 純利益 • 投資回収率 • キャッシュフロー ？？？
8. 2. 企業のゴール（目標）とは 『お金を儲け続けること』 経営の指標 • 純利益 • 投資回収率 • キャッシュフロー Not 生産 現場の指標 • スループット：販売を通じてお金を作り出す割合。時間あたりの速度。 • 在庫：販売しようとする物を購入するために投資した全てのお金。 • 業務費用：在庫をスループットに変えるために費やす全てのお金。
9. 3. 制約（ボトルネック）とスループット • ハイキング • とある工場 • 継続改善に向けた5ステップ
10. ハイキング（隊列を組み目的地を目指す）
11. しばらくすると… 列の長さがどんどん長くなる
12. 統計的変動と依存的事象 統計的変動（ばらつき） 平均3km/時 依存的事象（つながり） 8km/時の能力 3km/時の能力 靴紐を直したり、ぬかるみを避けたりで たとえ8km/時で歩けたとしても、 2km/時で進むこともあれば、前との距離 前の人が3km/時しか歩けなければ を縮めるために4km/時で進むこともある 1時間に3kmしか進むことができない （進む速さにはバラつきがある） （速く進むには制限がある）
13. 統計的変動と依存的事象 依存 遅く歩く 依存 依存 遅く歩く 止まる 靴紐結ぶために 止まる 歩く 速く歩く （= 変動） （3km/時） （= 変動） 変動により広がった間隔 速く進むには制限があるが、遅く進む分には制限が無いため、隊列は無制限に長くなっていく。 一度長くなってしまった隊列を元の長さに戻すためには、後ろを歩く全ての人が 自身の前に広がった間隔の合計（変動の蓄積）を先頭の人の平均速度より速く歩く必要がある。
14. しばらくすると…（再掲） ※歩くのが 一番遅い （少しリカバリ） 列の長さがどんどん長くなる
15. 3. 制約（ボトルネック）とスループット 【製品の販売】 【材料の投入】 スループット（ ） 歩くのに必要なエネルギー = 業務費用（ 列の長さ = 在庫（ ） ） この隊列を「歩いた道」という製品を作っているとみなすと、先頭が未踏の道を歩く = 生産を開始、 最後尾が歩いてはじめて製品が販売されることになる。よって、最後尾の歩くスピード = スループット。 ↗︎ ↘︎ ↗︎ 先頭が歩き始め、最後尾が歩き終わるまでの道は仕掛品や部品の在庫になる。
16. 3. 制約（ボトルネック）とスループット 【製品の販売】 速度制限 隊列全体のスループットを決めている = 制約（ボトルネック） 制約（ボトルネック）以外のプロセスの能力を向上させてもスループットの増加には寄与しない。 それどころか、在庫や業務費用を増加させキャッシュフローの悪化をもたらす場合もある。 制約（ボトルネック）にだけフォーカスして対処していくことが全体最適をもたらす。 【材料の投入】
17. 3. 制約（ボトルネック）とスループット 【製品の販売】 速度制限 隊列全体のスループットを決めている = 制約（ボトルネック） 制約（ボトルネック）以外のプロセスの能力を向上させてもスループットの増加には寄与しない。 それどころか、在庫や業務費用を増加させキャッシュフローの悪化をもたらす場合もある。 制約（ボトルネック）にだけフォーカスして対処していくことが全体最適をもたらす。 【材料の投入】
18. 3. 制約（ボトルネック）とスループット 制約に他を従属させる 隊列の先頭へ 頼む 遅 はよ おそ 列の長さ = 在庫（ 遅い ） ↘︎ 隊列全体の速度を一番歩くのが遅い人に従わせることで列が長くなってしまうことを抑制。 しかし、スループットを上げるためには、先頭の人のスピードを如何に上げるかが鍵。
19. 3. 制約（ボトルネック）とスループット スループット（ ） 負荷（重い荷物）を分散 = 速度UP 制約（ボトルネック）の負荷を軽くして能力を向上させたことによりスループットが向上した。 制約とそれ以外（非制約）の区別をつけることが重要。エリヤフ・ゴールドラット氏曰く、 ↗︎ 『制約と非制約の区別を欠いた如何なる努力も決して実を結ばない』
20. 3. 制約（ボトルネック）とスループット • ハイキング • とある工場 • 継続改善に向けた5ステップ
21. とある工場（機械+人手でモノを作る） 「今日の17時までに100個作って出荷せよ」 組み立て（平均25個/時） 12時 13時 14時 15時 組み立て 組み立て 組み立て 組み立て 25個 25個 25個 25個 16時 出荷 100個 溶接 溶接 溶接 溶接 25個 25個 25個 25個 溶接（平均25個/時） 出荷までの工程は「組み立て」と「溶接」のみ。 各工程の平均処理量から計算すると17時までに100個は作ることができるはず… 17時 組み立て・ 溶接済み
22. とある工場（機械+人手でモノを作る） 「今日の17時までに100個作って出荷せよ」 組み立て（平均25個/時） 12時 13時 14時 15時 組み立て 組み立て 組み立て 組み立て 2519個 2521個 2528個 2532個 16時 17時 出荷 10090個 溶接 溶接 溶接 溶接 2519個 2521個 25個 25個 組み立て・ 溶接済み 溶接（平均25個/時） 組み立て工程にばらつき（統計的変動）があり、そこにつながり（依存的事象）のある溶接工程に • 12時台と13時台：処理能力よりも少ない部品しか流れてこなかった。 • 14時台と15時台：処理能力を超えた部品が流れてきたが、超過分は処理できなかった。
23. ① 制約（ボトルネック）を発見する 処理能力：100 処理能力：80 処理能力：60 処理能力：100 稼働率：100% 稼働率：100% 稼働率：80% 稼働率：48% 資材投入 100 出荷 48 工程A 工程B 在庫：20 工程C 在庫：32 工程D
24. ① 制約（ボトルネック）を発見する 制約（ボトルネック） スループットを決めている 処理能力：100 処理能力：80 処理能力：60 処理能力：100 稼働率：100% 稼働率：100% 稼働率：80% 稼働率：48% 資材投入 100 出荷 48 工程A 工程B 在庫：20 工程C 在庫：32 工程D
25. ② 制約（ボトルネック）を最大活用する 最大活用を考える 追加投資の前にまず徹底的に活用する方法を考える 処理能力：100 処理能力：80 処理能力：60 処理能力：100 稼働率：100% 稼働率：100% 稼働率：80% 稼働率：48% 資材投入 100 出荷 48 工程A 工程B 工程C 工程D • 稼働率が80%→100%を目指す 在庫：20 在庫：32 • いま必要なモノだけ作る • B工程への負荷分散
26. ② 制約（ボトルネック）を最大活用する （非制約リソースで制約リソースを助けることで） こうなるはず 制約の性能を上げる 処理能力：100 処理能力：80 処理能力：60 処理能力：100 稼働率：100% 稼働率：85% 稼働率：100% 稼働率：60% 資材投入 100 出荷 60 工程A 工程B 工程C +12 -24 在庫：32 在庫：8 非制約を制約の能力を超えて働かせているため発生する余剰在庫 → 工程D 減らしたい（一定のバッファは必要だけど）
27. ③ 他の決定を制約（ボトルネック）に従わせる ボトルネックに合わせて資材投入 制約に他を従属させる ※バッファ（在庫・期間）も考慮 処理能力：100 処理能力：80 処理能力：60 処理能力：100 稼働率：80% 稼働率：85% 稼働率：100% 稼働率：60% 資材投入 出荷 100→80 60 工程A 工程B 工程C -20 在庫：12 在庫の減少 = キャッシュフローの良化 在庫：8 工程D
28. ④ 制約の能力を高める +10 資材投入 処理能力：100 処理能力：80 • 設備投資 • 作業改善 • 工程改善 処理能力：80→90 +30？ 処理能力：100 どうなるか？ 出荷 80→90 60 工程A 工程B 工程C 工程D ムダが最小化された状態で、投資によりボトルネックの能力向上 = スループット向上を狙う。
29. ⑤ 制約が解消したら①制約を見つける、に戻る 制約（ボトルネック） 処理能力：100 処理能力：80 処理能力：90 処理能力：100 稼働率：90% 稼働率：85% 稼働率：75.5% 稼働率：68% +8 資材投入 出荷 80→90 68 工程A 工程B 工程C 工程D +10 在庫：22 在庫：8 制約が移るとシステムは以前と全く別物になり、古い方針自体が制約になる。 ※惰性に気をつけて継続的に改善する必要がある。
30. 3. 制約（ボトルネック）とスループット • ハイキング • とある工場 • 継続改善に向けた5ステップ
31. 5 Focusing Steps ① 制約を見つける ⑤ ② 制約が解消したら 制約をどう徹底活用 ①に戻る するか決める ④ 制約の能力を高める ③ 他の全てを②の決定に 従属させる
32. 制約のタイプ・特徴 物理的制約 装置や設備、人的リソースに起因するもの 市場の制約 需要や顧客などの市場要素に起因するもの 方針の制約 会社の方針や慣習に起因するもの ※圧倒的にこの制約が多い！ 制約の特徴 ✓ 在庫が溜まる ✓ 処理時間が長い ✓ 問題やトラブルが多い ✓ 稼働率は高い
33. 制約のタイプ・特徴 物理的制約 装置や設備、人的リソースに起因するもの 市場の制約 需要や顧客などの市場要素に起因するもの ✓制約は「悪」ではなく「事実」 方針の制約 会社の方針や慣習に起因するもの ※圧倒的にこの制約が多い！ ✓把握してコントロールすることが大事 制約の特徴 ✓ 在庫が溜まる ✓ 処理時間が長い ✓ 問題やトラブルが多い ✓ 稼働率は高い
34. 4. バッチサイズとリードタイム • 一回あたりの処理量のことを「バッチ」 • バッチの大きさを「バッチサイズ」 • バッチサイズを小さくすることでリードタイムが短くなる = スループットが上がる（場合がある）
35. 作業の流れ 多くの作業は 「①セットアップタイム（段取りの時間）→②プロセスタイム（処理の時間） → ③キュータイム&ウェイトタイム（作業待ちの時間）」の連続 ※そして大体において「キュータイム&ウェイトタイム」が長くかかりがち、とされている ①セットアップタイム （バッチサイズによる変動なし） 工程A ②プロセスタイム 工程B ③キュータイム&ウェイトタイム （バッチサイズで変動） （バッチサイズで変動） 工程C
36. バッチサイズによるLT比較（例） 工程A 工程B 工程C 工程A 工程B 工程C 工程A 工程B 工程C ﾊﾞｯﾁｻｲｽﾞ:1 工程B 工程C 工程A 工程B 工程C セットアップタイムが小さい。 バッチサイズが小さい方が、 待ち時間が少なくなる。 工程A ﾊﾞｯﾁｻｲｽﾞ:5 工程A 工程B 工程C
37. バッチサイズ小さくてもLTが短くならないことも バッチサイズが大きい方が 逆にプロセスタイムを 小さくできる場合もある。 ✓ 大きなバッチで大量に処理した方がプロセスタイムが短くなる例 → 同時並行で大量生産できる機械を導入するなど（人手だと基本1つずつしか処理できない）
38. ソフトウェア開発で言うと
39. バッチサイズを小さくするメリット① • スループットが上がる（場合がある） • 早期に出荷することで根雪構造的に事業アウトカムの最大化に寄与する
40. バッチサイズを小さくするメリット① • スループットが上がる（場合がある） • 早期に出荷することで根雪構造的に事業アウトカムの最大化に寄与する オーバーヘッドがあったとしても、価値の積み上げを早期に開始することでアウトカムに寄与する場合も
41. バッチサイズを小さくするメリット② • 不確実性によるムダを少なくする - ミスや不具合、認識違い、想定外の事象などを早期に検知することで、ムダを最小化する ムダになる量が多い ※非定型作業や、新しい取り組み、品質的なばらつき、実験的要素が強いなどの場合は有効 （不確実性が低ければ大きなバッチで進めてしまう方が良い）
42. 5章の前に：AI時代に何が変わったか 1〜4章のTOCの内容は、AI時代でもそのまま成立します。 変わるのは「制約の場所」です。 AIで「実装」工程の処理能力が大きく伸びています。 実装は工程の一部に過ぎないので、他工程との能力差が広がります。 結果、ボトルネックは実装の外側（検証・運用・意思決定etc）に移りやすくなります。 3章で見た通り、制約以外の能力を上げてもスループットは増えず、 むしろ在庫と業務費用が増えキャッシュフローを悪化させます。 AI時代に「実装を速くする」だけの取り組みは、まさにこの状態を作りかねません。
43. 5. ソフトウェア開発現場の話
44. 5. ソフトウェア開発現場の話 黒田さん資料のこのへんの話 黒田樹 / 事業価値とエンジニアリング・リソース効率性とフロー効率性
45. 5. ソフトウェア開発現場の話 例）CSアクション最大化をしていくプロダクトチーム 黒田さん資料のこのへんの話 「スループット」「在庫」「業務費用」を計測・モニタリング ※スループットは価値を市場に提供するまで（to Cash）なので、 開発だけでの計測ではなく「企画~開発~検証」（BMLサイクル）の全体を対象 黒田樹 / 事業価値とエンジニアリング・リソース効率性とフロー効率性
46. 5. ソフトウェア開発現場の話 とあるプロダクトチーム 制約（ボトルネック）
47. 5. ソフトウェア開発現場の話 制約（ボトルネック）
48. 5. ソフトウェア開発現場の話
49. 5. ソフトウェア開発現場の話 Before Now 検証面の「稼働率」可視化
50. 5. ソフトウェア開発現場の話 Before Now 「検証」に合わせた着手 • 検証の性能を超えて着手しない • （逆に）検証面が空かないように ・80％超の水準で検証面を活用 ・リリース待ちの減少
51. 5. ソフトウェア開発現場の話 Before Now 「検証」に合わせた着手 • 検証の性能を超えて着手しない • （逆に）検証面が空かないように ・80％超の水準で検証面を活用 ・リリース待ちの減少 検証面（画面）の追加開発
52. 5. ソフトウェア開発現場の話 Before Now ① 制約を見つける ② ③ 制約をどう徹底活用 他の全てを②の決定 するか決める に従属させる 「検証」に合わせた着手 • 検証の性能を超えて着手しない • （逆に）検証面が空かないように ・80％超の水準で検証面を活用 ・リリース待ちの減少 ⑤ 制約が解消したら ①に戻る ④ 検証面（画面）の追加開発 制約の能力を高める
53. 5. ソフトウェア開発現場の話 Before Now ① 制約を見つける ② ③ 制約をどう徹底活用 他の全てを②の決定 するか決める に従属させる 継続的改善サイクルを回して 案件LTおよそ30%短縮！！ 「検証」に合わせた着手 • 検証の性能を超えて着手しない • （逆に）検証面が空かないように ・80％超の水準で検証面を活用 ・リリース待ちの減少 ⑤ 制約が解消したら ①に戻る ④ 検証面（画面）の追加開発 制約の能力を高める
54. この事例はAI時代に何を意味するか いま見た事例は数年前のものです。 しかし同じ構造が、AI時代に全プロダクトで再演されます。 違いは「制約の移動速度」です。 開発 → 検証 → 運用 → 意思決定と、制約はこれまでよりも速く動きます。 一度改善しても、すぐ次のボトルネックが現れます。 だから、必要なのは2つです。 ① 制約がどこに移ったかを観測できる仕組みを持つこと ② 5 Focusing Stepsを、これまでより高い頻度で回すこと
55. 5. ソフトウェア開発現場の話 クリティカルチェーン 出典：https://promo.diamond.jp/books/the-goal/ （作業工程の従属関係とリソースの従属関係の両方を考慮に入れて、 タスクA タスクB タスクC タスクD タスクE タスクF タスクG プロジェクトバッファ 作業所要期間を決めている最も長い作業の流れ） バッファタスク毎ではなくはPJ全体として持ち、 クリティカルチェーン上のタスクに遅延が発生した際に取り崩す
56. 6. まとめ ✓企業のゴール = お金を儲け続けること ✓スループット・在庫・業務費用 ✓統計的変動（ばらつき）と依存的事象（つながり）の組み合わせ ✓制約（ボトルネック）が全体のスループットを決める ✓制約と非制約を区別して、制約にだけフォーカス ✓『制約と非制約の区別を欠いた如何なる努力も決して実を結ばない』 ✓惰性に気をつけて継続的に改善する（5 Focusing Steps） ✓『制約が移るとシステムは以前と全く別物になり、古い方針自体が制約になる』 ✓制約は「悪」ではなく「事実」。コントロールすることが大事。 ✓バッチサイズを小さくするとリードタイムが短くなる = スループットあがる ✓ 作業時間が短くなる（場合がある）。 ✓ 不確実性によるムダが減る。
57. 6. まとめ ゴールドラット博士曰く “ TOCを一言で言えというなら、それは「フォーカス」 だ。 しかし、大事なのは、フォーカスするとは、何をす べきか知っていると同時に、何をすべきでないか知って いるということだ。 なぜなら、すべてにフォーカスする のは、どれにもフォーカスしないのと同じだからだ。”
58. 6. まとめ 個別最適化 全体最適 エンジニアリングで制約をコントロールして 事業価値を高めていきましょう
59. AI時代のTOC：自分への5つの問い 1. 自分のチームの今の制約はどこか。実装ではない可能性が高い。 2. AIで非制約ばかりを速くしていないか。 3. 在庫が見えなくなっていないか。未検証のAI生成物、価値を生まないコード。 4. 実装の外側（検証・運用・意思決定など）の力を意識しているか。 5. 制約の移動速度が上がっている前提で、観測サイクルを回せているか。 『制約と非制約の区別を欠いた如何なる努力も決して実を結ばない』