第 7 章 タイム・マネジメントによる設計開発期間の短縮
7.4 クリティカル・チェーンの適用手順
7.4.1 適用にあたって
本節では図7.6のPERTモデル(Cook, 1998; Yeo & Ning, 2002)を利用して、プロジェクトへ のクリティカル・チェーンの適用手順を示す。このPERTモデルでは二つのタスク・スケジ ュールの枝が一つの枝に合流するが、実際のプロジェクトでは枝の数や合流点の数は多く、
複雑に接続している。このPERTモデルは基本構成であり、この基本構成の論理的な組合せ で実際のPERTは構築される(Goldratt, 1997; Steyn, 2000 and 2002)。
図7.6(a)のPERTモデルは、クリティカル・チェーンを適用する前の作業工程を表す。PERT
モデルのブロック内の①〜⑥の数字はタスク名を表す。a.〜e.のアルファベットはリソース 名を表す。それに続く数字はそのタスクの所要期間を表し、この例では単位を日数とする。
7.4.2 プロジェクト・バッファ
クリティカル・チェーンの適用手順として、まず作業を遂行する実践者はプロジェクト のスケジュールの平均値 tmを所要期間と想定して計画を進めることを Goldratt は指示して いる。平均値 tmの所要期間でプロジェクトのスケジュールを計画すると確かに短縮は可能 である。しかし遅延する確率も50%ある。
そこで計画を確実に信頼できるものにするために、バッファという概念を考える。7.3.2 項で議論したとおり、目標値 tgによる所要期間の見積りでは、個々の作業毎に安全余裕時 間が含まれていた。これを平均値 tmによる見積りに変更すると、個々の安全余裕時間が浮 くことになる(Goldratt, 1997)。この浮いた安全余裕時間をプロジェクト全体で集め、遅延し た時のバッファとして使うことができる。すなわちバッファとは遅延したときの吸収「し ろ」として利用されるものである。
Goldrattはこのバッファの量は総合計の半分で十分としている。その理由については後述
する。
プロジェクト・バッファの適用について述べる。まず全ての作業についてその所要時間 を目標値tgから平均値tmに設定する。図7.6(a)のタスク①〜タスク⑥の所要時間はそれぞれ の目標値tgである。これらをそれぞれの平均値 tm、ここではそれぞれ目標値 tgの半分の時 間に設定する。以後図7.6(b)〜図7.6(d)に示すようにこれらの時間は変わらない。次にプロ ジェクト全体の遅延保護を目的として、プロジェクトの最終段にプロジェクト・バッファ を付け足す。図7.6(a)では、タスク①、タスク②、タスク③、タスク⑥の経路の所要時間の 合計は 64日であった。これが各タスクの所要時間の設定変更により 32日となったので、
図7.6(b)に示すように、削減された分すなわち 32日をプロジェクト・バッファとしてタス
ク⑥の後段に付け足す。
図7.6 クリティカル・チェーン適用手順(Cook, 1998; Yeo & Ning, 2002)
①a.20
⑥e.20
③c.14
②b.10
⑤b.16
④d.16
.a.10 b.5 c.7
e.10 b.8
d.8 合流ﾊﾞｯﾌｧPB16
ﾌﾟﾛｼﾞｪｸﾄ･ﾊﾞｯﾌｧPB32
a.10 b.5 c.7
e.10 b.8
d.8 FB8
PB16
a.10 b.5 c.7
e.10
d.8 b.8
PB19 FB5
(a)
(b)
(c)
(d)
クリティカル・チェーン
7.4.3 合流(Feeding)・バッファ
クリティカル・パスの流れを守るために、クリティカル・パス以外の経路がクリティカ ル・パスに合流する点に「合流バッファ」を入れる。これはクリティカル・パスを遅延さ せないための方策である。クリティカル・パス以外の経路が、万が一遅延したとしても、
この合流バッファで吸収できる。つまりクリティカル・パスは合流バッファによりその存 在は保証される。
図7.6(a)において、クリティカル・パスはタスク①、タスク②、タスク③、タスク⑥の経 路である。タスク④とタスク⑤の経路がクリティカル・パス以外の経路となるので、クリ ティカル・パスと合流するタスク⑤の後段に合流バッファを挿入する。図7.6(a)では、タス ク④とタスク⑤の経路の所要時間の合計は32日であった。これが各タスクの所要時間の設 定変更により16日となったので、図7.6(b)に示すように、削減された分すなわち16日を合流 バッファの量とする。
7.4.4 リソース競合の回避
Goldratt は適切なバッファ量として総合計の半分を推奨している。図7.6(b)の場合で考え
るなら、プロジェクト・バッファと合流バッファの二つの所要期間を半分にすれば良い。
それを図7.6(c)に示す。プロジェクト・バッファは16日、合流バッファは8日となり、合計は 48日となる。尚、合流バッファを考慮するなら最大で50日となる。
しかし図7.6(c)では、リソースbは二つの経路上に存在していることが認められる。そし て同時期に双方の作業の一部が競合する様に配置されている。この状態はマルチタスキン グである。CPM や多くのプロジェクト・マネジメント・ソフトウエアはその扱いを可能と している(Cook, 1998)。しかしマルチタスキングは7.3.2項で述べた通り、現実的には大きな 生産性は得られない。従ってできる限りリソース競合は回避すべきと考えられる。
リソース競合が発生する場合には、競合するタスク間を合流点とし、最長経路ではない 経路に合流バッファを早めに置くことで解決できる。図7.6(c)では、d.8とb.8からb.5にかけ てクリティカル・チェーンがあるので、b.5の直前に b.8を先行タスクとして置く。そして
d.8から b.5にかけてのクリティカル・チェーンの不確実性を保護するために、クリティカ
ル・チェーンに影響を及ぼしうるa.10から合流点の間に合流バッファを挿入する。そして合 流バッファの量は、a.10と合流バッファが、d.8からb.5にかけての経路を超えない量に設定 する。すなわち合流バッファは5日となる。図7.6(c)で設定していた合流バッファは8日であ ったので、残りの3日分については最終段のプロジェクト・バッファに付け加えて調整する。
CCMによって最終的に図7.6(d)を得る。
結果として、リソース競合の為に合流バッファが挿入され、クリティカル・チェーンの 調整と延長が行われた。最終的には所要期間の合計は57日となる。
7.4.5 バッファ量のサイズ
Goldrattが強く提案しているのは、前述の通りプロジェクト・バッファの量を半分にする
ことである。バッファ量を半分にする提案はGoldrattの恣意的数値である。バッファ量のサ イズを半分にさせる根拠は示されていないとの批判(Yeo & Ning, 2002)がある。この欠点を 克服する為に、Herroelen & Leusは経験則の利用を提言している。プロジェクト・マネジメ ントは過去の経験や類似のプロジェクトを参考に実践されることが多い。従ってその都度、
適切なバッファ・サイズを決めて、適用することを薦めている(Herroelen & Leus, 2001)。
それではなぜバッファ量を減少させることができるのであろうか。これはプロジェクト 全体の分散は各作業の分散の総和に比べて小さいという定理で容易に解釈される(Herroelen
& Leus, 2001) (Steyn, 2000)。つまり、プロジェクト全体で遅延を保護するのに必要なバッフ ァ量は、各作業の安全余裕度を取り除いた各作業の総和より小さいという意である。
これは一つのアナロジーとしてリスクに対する保険の原理で説明できる。この場合、分 散はリスクとして解釈される。まずx人の資産家がそれぞれy円の資産を所有していたと仮 定する。各資産家は不測の事態に備えてy円に相当する保険金を付保していたとする。もし 資産家全てが、一度に保険支払いの対象となることを想定するなら、保険会社はx・y円相 当の積立金を用意しなければならない。しかしx人の資産家が同時に資産を失うことは考え にくいので、積立金は明らかにx・y円より少なくて済む。つまり個々の資産家にとって不 測の事態が起きるのは事前には判らないが、同じリスクに直面している人を多く集めると その集団全体としての不測の事態の発生数はほぼ確定する。そして保険会社の支払う保険 金額の合計は正規分布になると言うことである。
これは中心極限定理から説明ができる。本定理によれば、独立な確率変数の和の分布は、
その項数が大きくなると、各々の確率変数の分布の型には無関係に、一定の正規分布に近 づくことが知られている。
そこでまず各作業の分散の総和を求めてみる。ここでは n 個の独立した確率変数の分布 が全て同じ分散Vであると仮定する。分散の総和VΣは次式で表される。
VΣ = n・V (7.1)
プロジェクトのスケジュールのリスクは分散又は標準偏差によって表現できる。散らば り具合が大きいほど期待値からのずれが大きく、リスクが大きくなる。逆に散らばりが小 さければリスクは小さい。スケジュールの不確実性は明らかに散らばりの大きさに依存し ている。ここでは標準偏差をリスク指標として議論を進めてみる。各作業の標準偏差を σ とするなら、分散は標準偏差の二乗であるので、V＝σ2である。ここでプロジェクト全体の 標準偏差をσΣとするなら、
σΣ = (VΣ)1/2 = (n・V)1/2 = n1/2・σ (7.2)
となる。そしてn1/2・σ < n・σであるので、
σΣ < n・σ (7.3)
である。つまり、独立したリスクをまとめて同質的な集団として捉えるなら、その全体リ スクは低減するということを意味する。n1/2と n の関係から、nが大きくなるほどその効果 は大きい。CCMのアプローチはこの中心極限定理の性質から、プロジェクトのスケジュー ル・リスクを低減させるものと言える。