制約理論による新たなアプローチ TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 1 ＴＯＣの歴史 • • • • • • イスラエル物理学者 Ｅｌｉｙａｈｕ Ｇｏｌｄｒａｔｔが開発 １９７０年後半、ＯＰＴと名づけた生産管理ソフトを発売 １９８４年、小説「Ｔｈｅ Ｇｏａｌ」を出版 １９８６年、ＴＯＣ普及のためＡＧＩを設立。 １９８０年代後半より「思考プロセス」の開発に着手。 １９９４年、小説「It’s Not Luck」を出版、思考プロセスの 全容を公開 • １９９５年、ＡＰＩＣＳにＣｏｎｓｔｒａｉｎｔｓ Ｍａｎａｇｅｍｅｎｔ ＳＩＧ 発足 • １９９７年、クリティカル・チェーンを発表 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 2 実施例：ハリス・セミコンダクター 半導体工場の建設： 今までは２９ヶ月 １１ヶ月で達成 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 3 実施例：Seagate Technology ＊業界初の 15,000 回転 HD,チータの開発 に応用 ＊予定より５週間前倒しで製造開始 ＊後続コンペチターは脱落 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 4 実施例：Ｈａｂｉｔａｔ Ｇｒｏｕｐ 家一軒を何時間で建てられるか ＊今までの記録：４時間４５分 ＣＣＰＭでの今回の記録 ＊人数は半分で ３時間４５分 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 5 プロジェクトの問題点 • 納期通りに終わらない • 予算をオーバする • 終わりがはっきりしない • 、、、、、 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 6 なぜプロジェクトってうまく行かないの ＊ 予期せぬことが起こる ＊ プロジェクトに関する複雑性のため 遅れを予期できない ＊ 優先順位がころころかわる ＊ 納期がもともと現実的でない ＊ 目的が曖昧 ＊ 人員が足りない ＊ 予算が足りない TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 7 プロジェクトの不確定性 • 完了時間の不確実性：やってみなきゃわ からない • 技術的課題達成の不確実性：ほんとにできるの？ どう やってやるの？ • 予算（費用）の不確実性 プロジェクトの２の３乗の法則 ２倍の期間、２倍の費用がかかり成果は半分 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 8 納期を見積るとき ＊悲観的な経験で決められる ＊管理層が増えると安全係数が増える ＊一律カット対策 ＊掛け持ち業務を考慮する ＊８０～９０％の達成確率で見積もる ＊仕事単位に見積もる ＊予定通り終了するように管理される ―＞ 確実に終わる納期で見積もる TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 9 繰返し業務の時間分布 ５０％ ９０％ 所要時間 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 10 非繰返し業務の時間分布 頻 度 所要時間 ５０％ TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights ９０％ 11 ５０％ ３週間の仕事を ６週間はかか ると見積もり 掛持ち仕事がある ので１０週間かかる と計画する ９０％ ３週間 ６週間 １０週間 計画を立てる時の時間見積 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 12 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 13 充分に余裕のある予定がさらに遅れる理由 １、 ２、 ３、 ４、 ５、 ６、 学生症候群 早期終了は伝わらない リソースの競合 複数業務掛け持ち パーキンソンの法則 優先順位が曖昧 ７、目的の設定が曖昧 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 14 仕 事 の 密 度 ま だ ま だ 時 間 が あ る な 開始可能時間 ぼ ち ぼ ち 始 め な い と 締め切り TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 15 早期終了が伝わらない • 予定より早く終わっても報告するメリットがない。 • 早く終わったことを報告すると、次回の納期が短くなる。 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 16 遅れだけが伝わる ‐3日 +3日 A B 3日の遅れ C 早期終了は 伝わらない A ‐3日 3日遅れ B C ＋3日 D +2日 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 17 掛け持ち業務と納期 タスクＢ ３日 ３日 タスクＣ ３日 タスクＡ 1人で３つの仕 事を抱えた Ａ こうしようかと思ったが Ｂ Ｃ こうせざるをえない A B C A 実際はこうなった A B C TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights B A C B C 18 従来の計画の立て方 ４日：部 品加工 １０日：設計 ４ 日： 設計 ６日： 実験 ８日：部品加工 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights ４日： 組立 19 クリティカル・チェーン （１）仕事の時間見積り 平均時間（５０％の確率で終了する）で見積もる （２） 開始時間を一番遅くする ５：設計 ２：設計 ３：実験 ２：部品 加工 ４：部品加工 ２：組立 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 20 クリティカル・チェーン （３） リソースの競合を解消する （４） クリティカル・チェーン（ ５：設計 ２：設計 ３：実験 ） を見つける ２：部品 加工 ４：部品加工 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights ２：組立 21 クリティカル・チェーン （５）プロジェクト・バッファーを入れる ５：設計 ２：設 ３：実験 ４：部品 計 加工 ２： 部品 ２：組 立 6.5: PB プロジェクト・バッファー（ＰＢ） TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 22 クリティカル・チェーン （６）フィーディング・バッファーを入れる フィーディング・バッファー（ＦＢ） ５：設計 2:FB ２：設 ３：実験 ４：部品 計 加工 ２： 部品 ２：組 立 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 6.5: PB 23 比較 10:設計 4:設計 4:部品加工 6:実験 8:部品加工 4:組立 計画22日（実際は２の３乗の法則で４４日で半分の達成） ５：設計 ２：設計 ３：実験 2:FB ２： 部品 ４：部品加工 ２：組立 6.5: PB 19.5日 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 24 バラツキの入れ方で違う納期（早期終了が伝わらない事を前提） A B 10日 σa:2日 C １５日 20日 σb:4日 σc:３日 バラツキをまとめた場合 σt=5.4 （10＋20＋15）＝45 合計時間 ９５%の確率で終わる日程 45＋5.4ｘ1.65＝５４日 各タスクにバラツキを入れた場合（９５％） (10+2x1.65) (20+4x1.65) (15+3x1.65) Ａ；13.3日 B;26.6日 C;20日 完了日数 ６０日 完了確率 ８６％ TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 25 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 26 仕事を進めるルール ＊クリティカル・チェーン（ＣＣ）の仕事は終了するま で、最優先で進める。 ＊non-CC の仕事は、 「仕事が来たら、すぐに、可能な限 り最短時間で処理する。」 ＊仕事が終了したら、直ちに次に渡す。 ＊non-CC の人は、CC の人を助ける。 ＊終了時期ではなく、あと何日かかるかをリポート。 TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 27 アップデート・変更・遅れ対策 フィーディング・バッファー、 プロジェクト・バッファーの管理 リソース・バッファーの管理 クリティカル・チェーン上で必要なリソースを予約 使用する前に何度か、使用可能である事を確認する TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 28 バッファー管理 特に何もしない 遅れの挽回策を取る 注意深く推移を見る TOC 制約理論のひろば Copyright 2002-2003, Toshio Sasaki All Rights 29
© Copyright 2024 ExpyDoc
