Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

制約理論 TOCTheory of Constraints) 紹介 by pharmphresh26

VIEWS: 8 PAGES: 17

									          制約理論
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% で完了す
る「悲観的見積」で見積もる。その結果、計画
期間は2~3倍に延びる

この余裕はどこに消えてしまうの?
余裕を食いつぶす原因 (1)
学生症候群
 期限ぎりぎりにならないと作業を開始しない
作業のかけもちによる工期長期化
 一人で複数作業の同時並行処理はリードタイム
 が倍増する




ステップ間の従属関係
 早く終わっても別の作業の待ちになり次の作業
 に着手できない。遅れれば遅れは累積する
余裕を食いつぶす原因 (2)
作業時間は見積時間を中心に正規分布的に分布す
るはずなのに、どうして早く終わることがない
の?
パーキンソンの法則
 仕事は予定工数をすべて使い切るように
 拡大する
 予定より早く終わると、手直しや改良、
 将来に向けての予備機能の追加等を行う
期間短縮は後に伝わらない
 部分工程が予定より早く完了しても評価
 されない
余裕が無駄にならない方法
個々の工程に余裕を見込むのではなく、そ
の余裕をプロジェクト全体に配置する
個々の工程の時間は、たとえば、確率 50%
で完了する時間に短縮する




 作業を早く完了したら次工程を開始する。これ
 により余裕時間の無駄が無くなり、余裕を半減
 しても大丈夫かもしれない(最下の図)
工程に複数のパスがある場合
全体の工期を決める、「クリティカルパ
ス」を探す
「合流バッファ」を設ける
 ステップ A1 が若干遅れても、 FB のおかげで、
 ステップ 3 の開始は遅れず、クリティカルパス
 を守ることができる




 合流バッファを消費してしまっても、プロジェ
 クトバッファが遅れを吸収してくれる
リソースの競合に注意
X さんの作業がシーケンシャルになるた
め、工期が遅れる




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

 点線:クリティカルチェイン
リソースバッファ
事前に作業を予約し、開始時期にはクリ
ティカルパスを最優先にしてもらう
 担当者が空かないためクリティカルパスの作業
 が遅れるのを避ける、
管理方法
各バッファの消費具合を管理する
 各担当者は、現在の仕事の完了予定残日数を
 申告する
 クリティカルパス上の仕事が予定より延びた
 ら、プロジェクトバッファをその分減らす。
 逆に早めに終わったら、プロジェクトバッ
 ファを増やす
 同様に、非クリティカルパス上の仕事の進捗
 は、合流バッファの残量に反映させる
 バッファを侵食するまで( 50% 確度の見積範
 囲内)は、せかさない。バッファを侵食しは
 じめたら警戒を行う
TOC を支援する管理ツール
CCPM+
 MS-Project に組み込んで、 TOC に基づくプロジェ
 クト管理(クリティカルパスの設定、各バッファ
 の管理等)を行う( MSI 社。 95000 円)

								
To top