第 7 章 タイム・マネジメントによる設計開発期間の短縮
7.3 TOC とクリティカル・チェーン
CCMはプロジェクトの工期を短縮させるだけでなく、スケジュール・リスクを低減させ、
作業の実践者の志気と効率性を高める潜在能力を持ち合わせていることも検証されている。
しかし現在まで、半導体設計開発の領域ではCCMの適用事例の積み重ねが行われていな い。本章で提案する統合アプローチとは、スケジュール管理、CCMそしてアウトソース化 の統合したものである。7.6節ではこの統合アプローチを半導体設計開発プロジェクトに適 用して、工期短縮を検証する｡従ってこの検証は、半導体設計開発におけるCCM の事例研 究として意義あるものと言える。
TOC はシステムの対象範囲を生産現場だけでなく、サプライチェーン全体、そして工場 全体、企業全体、組織や思考法にも拡張できる。CCMは一つのプロジェクトをシステムに 見立て、管理論として適用した手法である。
7.3.2 プロジェクトにおける不確実性と人間行動特性による遅延
Goldratt (1997)はプロジェクトの計画策定とスケジューリングにおいて三種類の不確実性 を考慮している。その三つとはタスクの時間の不確実性、パス経路の時間の不確実性、そ してリソースの不確実性である。これらの不確実性の存在が作業項目の見積もり精度の問 題につながっている。実際、多くのプロジェクト・マネージャはそれらの不確実性がスケ ジュール・リスクを招来することを認識している。その為にスケジュールを策定する際に 安全性(Safety)を念頭に置き、タスクの遅延対策としてタスクに余裕時間を予め準備してお く。
それら不確実性に対しては一般的に確率論的アプローチがとられている(Vose, 2003)。図 7.4はタスクにおけるスケジュールの不確実性を確率密度関数で表現したものである。不確 実性が高いほどこの確率密度関数の歪度は0より大きくなり、右の尾の部分は長くなる。tg はプロジェクトの目標値(Goal)であり、tmは見積もりから算出した平均値(mean)である。期 日まで遂行できない可能性が高い平均値を選択し、わざわざ危険を冒す実践者は存在しな い。従って平均値に安全余裕時間を加味することで目標値としている。つまり目標値とは プロジェクトにおける安全性が組み込まれている。この目標値の実現確率は80%から95%が
図7.4 スケジュールの不確実性
確率
所要時間
tm tｇ
95%
80%
50%
一般的である(Goldratt, 1997; Vose, 2003; Steyn, 2000, 2003; Cook, 1998; 稲垣, 1997; Leach,
2001; Newbold, 1998)。平均値における実現確率は50%である。ここでΔ(tg−tm)を安全余裕時
間と考える。CCMではこの安全余裕時間を大胆に削除する。その理由は後述の人間行動の 特性を排除するためである。
プロジェクトの現場の実践者は目標値の tg を納期の期限とし、不確実性が組み込まれて いると解釈している。しかし実際の所、全てのタスクは目標値以内に遂行できるとは限ら ない。Goldrattは納期に注意を払いすぎることが無駄な時間を消耗させ、遅延を起こす原因 であると指摘している。そしてこの根拠を人間行動の特性に関連づけし、四つの因子とし て上げている。この四つの因子について述べる。
1) 学生症候群
目標値 tgが決定される時には、管理上、安全な余裕時間が付け加えられる。従って、タ スクを実行する者は自分なりに所要期間を再評価し、最尤値としてtmの平均値を採択する。
すると結果としてそのタスクとは別のタスクに手をつけてしまう。これは安全な余裕時間 を含んでいると解釈しているからである。そしてぎりぎりになるまで着手せず、最終的に は一夜漬けの集中作業となる。その時にはマーフィーの法則(Bloch, 1993)によるところの
「予期しない問題」に打ちのめされ、納期が遅延する。たとえ突貫作業で間に合わせたと しても、逆にタスクの品質又は成果物が悪くなってしまう可能性が残る。これが学生症候 群である。
逆に言うならば、納期があるから学生症候群が起こるとも言える。このことから、クリ ティカル・チェーンでは納期ではなく、所要期間を重視する。もちろんプロジェクト全体 では納期は重要であるが、作業事に細かく納期を設定することはしない。この思考は作業 が終了次第、次の作業に着手することを促す。するとぎりぎりまで着手しないことや一夜 漬け傾向を防ぐことができる。
2) 自己の予防線
タスクが予定より早めに終了した場合にはどうなるか。この場合にはその事実がプロジ ェクト・マネージャに申告されにくい。すなわち自己防衛が働き、自己に対しての予防線 を張る傾向になる(津曲, 2004)。なぜならば正直に申告すると次回のプロジェクトで作業者 は不利になると考えるからである。つまり作業が早く終了して浮いた時間は無駄に消費さ れるだけで、プロジェクト全体に反映されない。
3) マルチタスキング
プロジェクトでは掛け持ち作業が頻繁に見られる。しかしマルチタスクとは単なる掛け 持ち作業ではない。マルチタスクとは作業の実践者に対して複数の作業を同時進行させる
ことである(Fujimoto, Goldratt,1997)。この場合、それら掛け持ち作業の中での優先権が明確 にされていないことが多い。結果として一作業当たりの実践者の生産性は低下する。これ が納期遅延を招来する。
マルチタスクは納期遅延だけでなく、創造的生産が要求される作業の能力も低下させる という指摘(Fujimoto et al., 2003)もある。しかし特定の専門知識やノウハウを要求するリソ ースが限られている場合には、このリソース限定問題を解消できるアプローチであり、有 効な手段と考えられている。実際、複数の組織と複数のプロジェクトが交錯した実践的マ トリクス組織(芝尾, 1999)へ適用した場合にはマルチタスキングは必要条件となっている。
マルチアスクのもう一つの問題は、掛け持ちのタスクが同時に生じる場合である。これ をリソースの競合と言う。この問題の詳細と解決については7.3.4項で述べる。
4) パーキンソンの法則
作業者がいつまでも作業を続け、計画した作業期間が満了しても尚延長されることがあ る。すなわち計画予算は全て使い尽くすまで消費される傾向がある。これをパーキンソン の法則と言う(Parkinson, 1996)。パーキンソンは、作業の量は一定ではなく、いかようにも 変動する、従って業務効率化などということがいかに空疎であるかを述べている。つまり、
この法則に基づき組織成長が拡大する。そして組織が拡大すれば、組織内での調整作業が 幾何級数的に増大するということである。
必要不可欠な作業は計画予算を全て使い尽くすか否かによらず実行されなければならな い。むしろ不必要な仕事はいくらでも作り出せるという組織内力学が、組織の拡大を続け ていることを示唆している。
7.3.3 CCM
これまで長らく、プロジェクトの計画・管理には、PERT (Program Evaluation and Review
Technique)やCPM (Critical Path Method)が利用されてきた。これらの手法で行われるように、
クリティカル・パス上にある工程を重点的に管理することによりプロジェクト全体の納期 を制御する方法は効果的である。しかしCPMには固有の問題がある。その問題点とは（i）
作業項目の所要期間の見積もり精度の不足、（ii）総所要期間の最適化の検討不足、（iii）競 合リソースの考慮不足といったことである(建部et.al,2004)。これら問題点が指摘されていな がら、それらが解決されずに現在まで利用されてきた。
それらの問題点を解決する手法としてTOCに基づくCCMが提唱された。TOCは7.3節で 述べた通り、プロジェクトの制約条件を早期に解決する手法である。そして全体工程で制 約を発生させない様に管理する。つまり、この手法は部分最適の積み上げと言うより全体 最適を考えることである。それが最終的に短納期の開発を実現させる。また、CCMはプロ ジェクトにおける価値連鎖内の生起する不確実性事象とそれに関連したリスクを管理する
拡張型手法と言える(Yeo&Ning, 2002)。これはCPMが決定論的な手法に立っており、CPM の限界点の一つを示唆するものである。
7.3.4 遅延の伝搬と総所要期間の最適化
プロジェクトでは幾つかの作業が同時に進んでいて、それらが全て終わってはじめて次 の段階の作業に進む場合がある。この場合、一つのタスクの遅延はプロジェクトのパス経 路を通じて伝搬されてしまう。つまりこれはクリティカル・パス(PMBOK, 2000)と考えてい なかったパス経路がクリティカル・パスになる可能性を残すものである。従ってクリティ カル・パスの経路は状況に応じて変化する可能性があり、総所要期間の最適化が検討され にくい。CCMではクリティカル・パスの決定の前に、タスクの配列の修正とバッファとい う概念を用いて解決している。
7.3.5 リソース競合とクリティカル・チェーン
限られたリソースを考慮したクリティカル・チェーンの概念は、Pittman (1995)によって 初めて提唱された。そしてGoldrattがTOCの概念と関連づけした。Goldrattはそこでプロジ ェクトの所要期間を左右する競合リソースという存在事実を確認し、競合リソースを回避 するためのクリティカル・パスの配列や順列を多様に検討した。
それまでクリティカル・パスは先行タスクとの接続関係だけで決定され、競合リソース は配慮されてこなかった。つまり競合リソースの問題はクリティカル・パスが決定づけさ れてから検討されてきたのである。一方、クリティカル・チェーンは先行タスクとの関係 性と、リソースの状況が考慮されたものである。つまり競合リソースは計画段階で解消さ れている。そして後述するバッファをプロジェクトの最後部におくことで、全てのタスク の遅延問題が一箇所にまとめるられるというものである。
Goldratt (1997)、Rand (2000)、Barber et al. (1999)、Leach (1999)、 Newbold (1998)、Steyn (2000) はクリティカル・チェーンを例証している。クリティカル・チェーンの単純例を図7.5に示 す。
図7.5 クリティカル・パスとクリティカル・チェーン(Steyn, 2000)
クリティカル・パス:ABC(23日)
クリティカル・チェーン:ABDC又はADBC(28日) タスクA
8日 Ann
タスクB 10日
John
タスクD 5日 John
タスクC 5日 Peter