thinking-theory-of-constraints

制約理論

スループットが制限されたシステムには、全体を左右する制約が1つあります。その制約だけを改善してください。制約ではない部分を局所的に最適化しても、労力が無駄になり、仕掛かり品（WIP）が増えることがよくあります。

使用する場面

• 1つの工程が時間または処理速度の大半を占めるレイテンシやスループットの目標がある。
• ある工程の手前に作業が滞留し、下流の工程がアイドル状態になる。
• ほかの場所で能力や作業者を増やしても、エンドツーエンドの出力が増えない。
• 投資して能力を高める前に、低コストで活用するための順序立った計画が必要である。

使用しない場面

• 負荷が分散していて、支配的な工程がない。相互作用を扱うシステムの手法を使ってください。
• 問題が流量ではなく正確性や障害に関するものである。障害をデバッグしてください。
• 結合や競合のためにボトルネックが実行のたびに移動し、安定した工程がない。5つの集中ステップではなく、システム思考や並行処理の設計を使ってください。
• 制約がすでに特定され、低コストの対策がすぐに実施できる。形式にこだわらず、その対策を適用してください。

手順

1. フローと目標を定義します。 作業単位（リクエスト、ジョブ、PR、レコード）と、重要な指標（エンドツーエンドの処理速度またはレイテンシ）を明確にします。
2. 根拠に基づいて制約を特定します。 稼働率、キュー／待ち時間、スループットを工程ごとに比較します。制約の兆候は、稼働率がほぼ100％、最長のキュー、最も低い工程の処理速度、ここに作業が滞留していること、入力を増やしてもシステムの出力が増えないことです。意見よりも測定した処理速度を優先します。候補が2つ並んだ場合は、改善によってシステムのスループットが先に上がる方を選びます。
3. 活用します（大きな投資はしません）。 制約の出力を最大化します。アイドル時間を減らし、制約部分で不要な作業を省き、手戻りや段取りを減らし、その時間を確保します。また、制約部分の品質を向上させて、出力を無駄にしないようにします。投資する前に効果を見積もります。
4. 制約ではない部分を制約に従わせます。 上流工程を制約の処理速度に合わせ、WIPを増やさないようにします。ほかの工程が制約に貢献するようにします（準備、明確さ、即時のプル）。制約の手前にキューを増やすような局所的な稼働率目標は退けます。
5. 不足している場合に限り、能力を高めます。 活用を最大限に進めた後、制約の処理能力を高めるために投資します（人員、ツール、シャーディング、並列経路）。必要十分な能力向上策のうち、最も低コストのものを選びます。
6. 再確認します（惰性を防ぎます）。 能力向上または大規模な活用の後、すべての工程を再測定します。制約は移動することがよくあります。ステップ2に戻ってください。以前の制約を最適化し続けないでください。

終了条件は、 制約、根拠、活用計画、従属ルール、能力向上を行うかどうかの判断が明確になったときです。または、単一の工程が全体を制約していない場合は、システム思考へ移行します。

出力

system_goal: <throughput/latency objective>
flow: <stage sequence>
constraint: <stage or resource>
evidence: <utilization / queue / rate facts>
exploit: <actions, expected gain>
subordinate:
  - stage: <name>
    change: <how it serves the constraint>
elevate: <none | option + cost/gain>
next_constraint_watch: <what to remeasure after change>

検証

• 反証： 指定した工程の能力を上げてもシステムのスループットが増えない場合（すでに別の工程が上限を決めている場合）、特定が誤っています。制約ではない部分の最適化によってエンドツーエンドの処理速度が変わる場合は、制約を特定し直してください。
• 停止： 活用をやり尽くす前に能力を高めないでください。「念のため」に複数の工程を最適化しないでください。
• 過剰適用の防止： 一度に扱う制約は1つです。上流の余剰能力は、埋めるべき問題ではありません。制約となる工程がない純粋な多重ループの創発現象には、TOCの用語を使わないでください。