biz-toc について
biz-tocは、制約理論を業務や運用システムに適用するスキルです。5つの集中ステップとドラム・バッファ・ロープを用い、処理量を制限するボトルネックの特定・改善と、他の工程の調整を支援します。
主な機能
- 015つの集中ステップの適用
- 02待ち行列と稼働率による制約特定
- 03ドラム・バッファ・ロープ方式の説明
- 04スループット会計指標の定義
- 05体系的なTOC分析の作成
活用シーン
- 01生産工程のボトルネック特定
- 02制約工程に合わせた仕掛品の管理
- 03スループットと運用費用の評価
- 04能力変更後の制約再評価
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ asgard-ai-platform/ skills --skill biz-tocインストール後、Claude Code で/biz-tocを入力して読み込まれたか確認します。
同梱ファイルexamples/sample_scenario.mdreferences/dbr-scheduling.md
詳細
制約理論(TOC)
概要
TOCでは、すべてのシステムには総スループットを制限する制約(ボトルネック)が少なくとも1つ存在するとされています。ボトルネックではないプロセスを改善しても、システムの出力は向上しません。ボトルネックを改善した場合にのみ向上します。5つの集中ステップは、制約を特定して管理するための体系的な方法です。
フレームワーク
IRON LAW: The System Is Only as Strong as Its Weakest Link
Improving a non-bottleneck process is a WASTE of resources — it produces
more work-in-progress that piles up at the bottleneck. Before optimizing
any process, verify it IS the bottleneck. If it's not, stop.
5つの集中ステップ
- 特定する — ボトルネックを見つけます(稼働率が最も高い、待ち行列が最も長い、仕掛品(WIP)の蓄積が最も多い工程)。
- 最大限に活用する — リソースを追加せずに、ボトルネックのスループットを最大化します(ダウンタイムを減らし、この工程の無駄を排除し、入力が途切れないようにします)。
- 他のすべてを従属させる — 他のすべてのプロセスのペースを、ボトルネックのリズムに合わせます。ボトルネックではない工程を最大能力で稼働させてはいけません。
- 制約を強化する — 最大限に活用しても不十分な場合、ボトルネックの能力を高めるために投資します(設備の追加、採用、外部委託)。
- 繰り返す — 強化後、制約が別の工程に移ることがあります。ステップ1に戻ります。
ドラム・バッファ・ロープ(DBR)スケジューリング
| 要素 | 内容 | 目的 |
|---|---|---|
| ドラム | ボトルネックのペース | システム全体のリズムを決めます |
| バッファ | ボトルネックの手前に設ける時間バッファ | ボトルネックの作業が途切れないようにします |
| ロープ | 始点で作業の投入を指示するシグナル | 投入速度をボトルネックのペースに結び付け、WIPを制御します |
スループット会計(TOCの財務指標)
| 指標 | 定義 |
|---|---|
| スループット(T) | 売上高 - 真に変動するコスト(材料費のみ) |
| 投資(I) | システム内に拘束されている資金(在庫、設備) |
| 営業費用(OE) | システムの運用にかかるその他すべてのコスト |
| 純利益 | T - OE |
| ROI | (T - OE) / I |
出力形式
# TOC Analysis: {System/Process}
## System Map
{Process A} → {Process B} → {**Process C (bottleneck)**} → {Process D} → Output
## Constraint Identification
- Bottleneck: {process step}
- Evidence: {utilization %, queue length, WIP accumulation}
- Current throughput: {units/period}
## Five Focusing Steps
| Step | Action | Expected Impact |
|------|--------|----------------|
| 1. Identify | {bottleneck location} | — |
| 2. Exploit | {optimize without investment} | +X% throughput |
| 3. Subordinate | {pace other processes} | Reduce WIP by X% |
| 4. Elevate | {investment if needed} | +X% throughput |
| 5. Repeat | {new constraint location} | — |
## DBR Implementation
- Drum: {bottleneck pace = X units/hour}
- Buffer: {X hours of WIP before bottleneck}
- Rope: {release new work every X minutes}
例
正しい適用例
シナリオ: PCB組み立てライン(5つの工程)にTOCを適用
- 工程ごとのスループット:はんだペースト印刷(100個/時)→ ピックアンドプレース(80個/時)→ リフロー炉(50個/時) → 検査(90個/時)→ 梱包(120個/時)
- ボトルネック:リフロー炉(50個/時)— スループットが最も低く、稼働率が最も高い工程
- 最大限に活用する: 炉の段取り替え時間を30分から10分に短縮 → 実効能力が15%向上
- 従属させる: ピックアンドプレースを55個/時に減速します(炉の前でWIPを過剰に生産しないようにします)
- 強化する: 必要に応じて、2台目のリフロー炉を追加します → 能力が2倍になります
誤った適用例
- より高速なピックアンドプレース機を購入(80→120個/時) → リフロー炉(50個/時)が依然としてボトルネックのため、システムのスループットは変わりません。投資が無駄になりました。鉄則に反しています。
注意点
- 制約は物理的なものとは限りません: 市場の需要、方針、経営陣の注意が真の制約である場合があります。工場が1,000個生産できても、販売数が500個にとどまるなら、市場が制約です。
- ボトルネックの移動: 1つの制約を強化すると、ボトルネックが移動します。チームはステップ5(繰り返す)を忘れて、達成を祝ってしまいがちです。
- 従属させることは直感に反します: ボトルネックではない機械を最大能力未満で稼働させるのは、無駄に感じられます。しかし、そうではありません。ボトルネックではない工程での過剰生産は、システムを滞らせるWIPを生み出します。
- TOCとリーンの違い: リーンはあらゆる場所の無駄を排除します。TOCは制約のみに焦点を当てます。この2つは互いを補完します。TOCで注力すべき場所を見つけ、リーンでその方法を最適化します。
参考資料
- ドラム・バッファ・ロープの実装の詳細については、
references/dbr-scheduling.mdを参照してください。
コメント
Markdown 対応