theory-of-constraints

制約理論

Eliyahu Goldratt の制約理論（ToC）を通じて、あらゆるプロセス（CI／ビルドパイプライン、開発のバリューストリーム、エージェントスキルやプラグイン、ランタイムのコードパス）を最適化するための診断ランブックです。

ToC の力の源となる考え方は、どのシステムにも、その時点で全体を制約する要因は必ず 1 つだけあり、全体のスループットが向上するのは、その制約を改善したときだけであるということです。それ以外の場所に費やす労力は何の成果も生みません。「ボトルネックではない工程で 1 時間節約しても、幻にすぎません」。このランブックでは、測定によって制約を見つけ、新たな問題を生み出すことなく制約を緩和するための 5 つの集中ステップを順に進めます。

適用する場面

ユーザーがプロセスやワークフローの最適化を求めており、次のいずれかに当てはまる場合は、このスキルを使ってください。

• 最適化したいものの、何から始めればよいかわからない（「これを速くして」「なぜ遅いのか」「コストを下げて」）。
• 局所的な高速化を行っても、エンドツーエンドの結果が変わらなかった（最適化の対象を間違えていた）。
• ある工程に作業、キュー、または WIP が積み上がる一方で、ほかの工程はアイドル状態になっている。
• すべての工程が稼働率 100％に見えるのに、出荷量が少ない（稼働率は高いが、スループットは低い）。
• キャパシティ、並列性、またはリソースを追加したのに、効果がなかった。
• あるボトルネックを解消すると、すぐに別のボトルネックが現れる。
• 真の制約要因がリソースではなく、ポリシーやルールである（テストスイート全体の必須実行、直列化されたレビュー、「すべてのリファレンスを読む」という指示、すべてをまとめてリリースする方式など）。
• 明らかな解決策を妨げるトレードオフから抜け出せない（「高速化か安全性か」「コンテキストを小さくするか、網羅範囲を広げるか」）。

次の場合は、このスキルを使わないでください。

• 制約箇所がすでに特定されている場合は、その修正に進んでください（例：O(n²) ループ → complexity-optimizer）。
• スループットの目標がなく、正確性や品質だけをレビューする場合は、コードレビューのスキルを使ってください。
• 制約であることがまだ実証されていない工程のマイクロ最適化。このスキルが防ぐべき、ToC における重大な誤りです。

継続的改善のプロセス（POOGI）

ToC は一度きりではなく、ループです。必ず順番に進めてください。活用よりも先に強化することが、ToC と「とにかくリソースを投入する」やり方を分けます。

        ┌─────────────────────────────────────────────────┐
        │                                                   │
        ▼                                                   │
1. IDENTIFY the constraint  ── the one stage that gates global throughput
        │
        ▼
2. EXPLOIT it               ── get the most from it with NO new spend
        │                       (remove waste/idle on the constraint)
        ▼
3. SUBORDINATE everything   ── pace all non-constraints to the constraint;
   else to the constraint      let them idle rather than build WIP
        │
        ▼
4. ELEVATE the constraint   ── only now add capacity / invest / parallelize
        │
        ▼
5. REPEAT                   ── the constraint has moved; go to step 1.
        │                       Do NOT let inertia (old policies) be the
        └───────────────────────new constraint.

よくある間違いは、ステップの飛ばし方にそのまま表れます。ステップ 2（活用）より先にステップ 4（強化）へ進んだり、ステップ 1 に一度も取り組まず、制約要因ではなく最も目につくものを最適化したりすることです。

よくある症状

まずここから始めます。症状に合う項目を見つけ、対応する判断ツリーを開いて、簡易チェックを実行してください。

症状	よくある制約	簡易チェック	ツリー
「最適化したいが、どこから手をつければよいかわからない」	不明 — まず測定する	queries/measure-stage-times.sh	find-the-constraint
ローカルでは高速化したが、全体の改善がない	制約ではない箇所を最適化した	queries/throughput-accounting.py	local-optimum
ある段階でキュー／WIPが積み上がる	制約は積み上がりの箇所、またはその直後にある	queries/measure-wip.sh	wip-accumulation
どこも忙しいのに、ほとんど出荷できない	制約ではない箇所が過剰に稼働している	queries/utilization-vs-throughput.py	utilization-trap
キャパシティを増やしたのに、改善しない	誤った箇所の能力を高めた／活用を飛ばした	queries/measure-stage-times.sh	elevation-misfire
1つのボトルネックを解消すると、別のものが現れる	制約が移動した（想定どおり）	queries/measure-stage-times.sh	moving-constraint
ルール／プロセスが制限要因になっている	ポリシー制約	queries/five-focusing-steps.sh	policy-constraint
トレードオフから抜け出せない	明らかになったジレンマが解決を妨げている	（推論 — 蒸発する雲）	conflict-resolution

Agent Skills／プラグインでは、制約となるのは多くの場合、常時読み込まれるコンテキストの予算（肥大化したSKILL.md）か、説明の弱さ（スキルが起動されず、スループットがゼロになること）です。queries/skill-context-cost.sh <skill-dir>を実行してください。

使用方法

1. 上の表から症状を特定し、references/内の対応するツリーを開きます。
2. まず目標とスループット指標を定義します。 改善する全体指標（週あたりのマージ済みPR数、リクエスト数／秒、エージェントセッションあたりのタスク完了数、ビルドの実時間）がなければ、ToCは意味をなしません。各ツリーでは、指標があることを前提としています。config.jsonで設定するか、ユーザーに尋ねてください。
3. ツリーが示す簡易チェック用クエリを実行します。クエリはreferences/queries/にあります。それぞれの冒頭に、パラメーターと出力の読み方が説明されています。
4. ツリーに従い、最終的なアクションに進みます。すべての経路は、具体的なToCの手段（活用／従属／能力強化／ポリシー変更／繰り返し）で終わります。
5. assets/templates/report.mdを使って調査結果を記録します。調査ログに1行追記し、繰り返し現れる制約が時間の経過とともに見えるようにします。

エントリーポイントと深刻度を網羅した一覧は、references/symptoms.mdを参照してください。

セットアップ

このスキルでは、調査対象システムの「スループット」の定義と、各段階の測定方法を把握するためにconfig.jsonを使用します。初回使用時にgoal_metricまたはvalue_stream_stagesが空の場合は、ユーザーに（AskUserQuestionを通じて）次の項目を尋ねてください。

• 目標指標（最大化する全体スループット）
• 最適化対象のワークフローにおける段階の順序

回答をconfig.jsonに保存してください。設定を埋められなくても、このスキルは引き続き動作します。その場合は、都度ユーザーに尋ね、段階を手動で測定してください。設定がないことを理由に処理を止めないでください。

注意点

ToCでよくある落とし穴（局所効率の測定、活用前の能力強化、最も目につく段階の最適化）はgotchas.mdにまとめられています。最初の調査を始める前に読んでください。こうした誤りを避けるためにToCがあります。

関連スキル

• complexity-optimizer — ToCによって制約がコードの段階だとわかったら、これを使ってその段階内のアルゴリズム上のホットスポットを見つけ、修正します。
• dx-harness — 制約が開発者体験に関わる作業（起動の遅さ、手作業のステップ）なら、これを使ってハーネスを監査し、修正します。
• dev-skill:evolve — 制約がAgent Skill自体（コンテキストの肥大化、起動されにくさ）なら、これを使って改善します。