制約理論TOC:Theory of Constraints）

紹介

06/9/8　田中

制約理論とは

プロジェクト、生産等は、部分的な効率化が全体的な生産性向上につながるとは限らない

ボトルネック工程（制約）をみつけ、それを最大限に生かすことで、全体最適的なマネジメントを行う手法

イスラエルの物理学者　エリアフ・ゴールドラットが1980年代に考案し世界中に普及。2001年著書の邦訳出版以降、日本でも注目されている。

制約理論の適用例

GM,ボーイング等で、生産管理やロジスティックの効率化に適用

ハリス・セミコンダクターで、従来は29ヶ月かかっていた半導体工場建設を11ヶ月で完了した

あるソフトウェア会社で導入したところ、90%以上のプロジェクトが予定通りに完成。

新潟県中越地震の際、小千谷市の災害復興プロジェクトで罹災証明発行の窓口業務の最適化に適用し4日で発行を終えた(京大防災研究所の発表より）

“The Goal”の内容

ある工場は生産効率が高いにもかかわらず、納期遅延、在庫の山などで業績が上がらず、改善が求められた

調査の結果、NC工作機械と熱処理炉に仕掛在庫が滞留しているのに、他工程はそれを無視して自工程の効率化を優先した生産をしていることが判明した（部分最適化）

そこで、この2工程をフル稼働し強化するとともに、それ以外の工程はこの工程を止めないよう、かつ、過度の仕掛在庫ができないよう生産調整した

その結果、納期短縮と在庫の低減が実現され、業績が改善した（全体最適化）

TOCの一般的な手順

(1)制約条件（ボトルネック）を見つける(2)制約条件を徹底的に活用する(3)制約条件以外の工程を制約条件に合わせて稼動させる

(4)制約条件を強化する→ボトルネック以外を強化しても駄目(5)これを繰り返す

この「あたりまえのこと」が通常不可能。自工程の効率を上げるよう各工程では努力するから、部分最適な運用となる。

TOCをプロジェクト管理へ適用

ソフト開発は、当初見積を2倍すると適正な時間だと言われるが何故か？

見積段階で余裕を組み込んでいるはずだが、この余裕はどこに消えるのか？

「今すぐやらなくてもいい作業」は、いつ行うのがよいのか

リソース（作業員）が競合したらどうすればよいのか

ソフトウェアプロジェクトの疑問

”クリティカルチェーン”の内容あるモデム会社で開発の遅れが事業拡大の障害となることが判明し、期間短縮のプロジェクトチームが組まれ、大学のMBAゼミに送り込まれた

調査の結果、プロジェクトの各工程は余裕を加え倍程度の時間が計画されているが、その余裕は「学生症候群」「作業の掛け持ちによる待ち」「作業間の従属関係による待ち」などに消費され、開発リスク解消に役立っていないことがわかった

そこで、各工程の余裕を削り、それをクリティカルパスの遅れ防止に役立つよう配置したところ、予定通りの期間で完成した。

TOCによるプロジェクト管理手順(1)各工程は50%の確率で終了する時間で見積もる(2)スケジュールを組む(3)リソースの競合を解消し、「クリティカルチェーン」（次項で説明）をみつける

(4)クリティカルチェーンが最短になるように組みなおす

(5)プロジェクト全体のリスクに備えるため、全工程の後に「プロジェクト・バッファ」と呼ばれる余裕時間を加える

(6)クリティカルチェーンの遅れを防ぐため、クリティカルチェーンの前工程に、「合流バッファ」と呼ばれる余裕時間を入れる

通常の工数見積

確率50%で完了する「楽観的見積」ではリスク回避ができないので、確率80～90%で完了する「悲観的見積」で見積もる。その結果、計画期間は２～３倍に延びる

この余裕はどこに消えてしまうの？

余裕を食いつぶす原因(1)学生症候群期限ぎりぎりにならないと作業を開始しない

作業のかけもちによる工期長期化一人で複数作業の同時並行処理はリードタイムが倍増する

ステップ間の従属関係早く終わっても別の作業の待ちになり次の作業に着手できない。遅れれば遅れは累積する

余裕を食いつぶす原因(2)

パーキンソンの法則

仕事は予定工数をすべて使い切るように拡大する

予定より早く終わると、手直しや改良、将来に向けての予備機能の追加等を行う

期間短縮は後に伝わらない

部分工程が予定より早く完了しても評価されない

作業時間は見積時間を中心に正規分布的に分布するはずなのに、どうして早く終わることがないの？

余裕が無駄にならない方法個々の工程に余裕を見込むのではなく、その余裕をプロジェクト全体に配置する

個々の工程の時間は、たとえば、確率50%で完了する時間に短縮する

作業を早く完了したら次工程を開始する。これにより余裕時間の無駄が無くなり、余裕を半減しても大丈夫かもしれない（最下の図）

工程に複数のパスがある場合全体の工期を決める、「クリティカルパス」を探す

「合流バッファ」を設ける

ステップA1が若干遅れても、FBのおかげで、ステップ3の開始は遅れず、クリティカルパスを守ることができる

合流バッファを消費してしまっても、プロジェクトバッファが遅れを吸収してくれる

リソースの競合に注意Xさんの作業がシーケンシャルになるため、工期が遅れる

この場合は、クリティカルパスでなく、点線で示したパスが開発期間を決める

点線：クリティカルチェイン

リソースバッファ事前に作業を予約し、開始時期にはクリティカルパスを最優先にしてもらう

担当者が空かないためクリティカルパスの作業が遅れるのを避ける、

管理方法各バッファの消費具合を管理する

各担当者は、現在の仕事の完了予定残日数を申告する

クリティカルパス上の仕事が予定より延びたら、プロジェクトバッファをその分減らす。逆に早めに終わったら、プロジェクトバッファを増やす

同様に、非クリティカルパス上の仕事の進捗は、合流バッファの残量に反映させる

バッファを侵食するまで（50%確度の見積範囲内）は、せかさない。バッファを侵食しはじめたら警戒を行う

TOCを支援する管理ツールCCPM+MS-Projectに組み込んで、 TOCに基づくプロジェクト管理（クリティカルパスの設定、各バッファの管理等）を行う（MSI社。95000円）