 |
第１４回（2003.03.06） クリティカルチェーン〜ＴＯＣプロジェクト管理 |
| ◆ＴＯＣプロジェクト管理とは プロジェクトマネジメントの中でクリティカルパスメソッドは計画時、あるいは計画実施とそれに伴う計画変更時に重要な手法であるが、クリティカルパスを変形させた手法が最近、日本でも注目されるようになってきた。ＴＯＣ（Theory Of Constraint）に基づくクリティカルチェーンと呼ばれるスケジューリング手法を中心にしたＴＯＣプロジェクト管理である。 ＴＯＣは「ザ・ゴール」でその正体が明らかになったので、いまさら、説明の必要もないだろう。また、この後の説明もＴＯＣの知識がないと分からないということではないので、ここでは触れない。クリティカルパスの背景にＰＥＲＴがあるように、クリティカルチェーンの背景にはＴＯＣがあると考えておいて貰えばよい。 ◆クリティカルパスの問題点 ＴＯＣプロジェクト管理の発想の根底には、もちろん、ＴＯＣの考え方があるのだが、手法的にはクリティカルパスという手法に対する問題解決から出ているようである。ゴールドラットはＴＯＣプロジェクト管理を考える際にたいへん興味深い指摘をしている。それは、プロジェクトのワークパッケージの実行に要する時間のばらつきに関するものである。 例えば、工場のラインでモノを作るときにひたすら繰り返される作業に対して、人間が作業すると時間的なばらつきが生じる。そのばらつきは、平均的な時間を中心にしてプラスマイナスほぼ同じように出てくる正規分布になる。これは統計の初歩である。 ところが、プロジェクトのように一つ一つのワークパッケージが異なり、環境も変わる場合にはばらつきは、正規分布ではなく、図のようなβ分布になっているケースが多いというのだ。  ゴールドラットの指摘の本質は、ひとつひとつのワークパッケージがどのくらいの確度で所要時間を見積もられているかということにある。例えば、５０％の確度でできるという見積もりだとどうなるか？２つのワークパッケージのうちのひとつは納期遅れになる。こんな見積もりはしないというわけだ。では、どのくらいの確度を与えているか？心理的な要因が働き、９０％以上は見ているだろう。仮に９０％だったとして、上の図でどういう時間の見積もりをしているかを見て欲しい。β分布の場合、５０％の確度と９０％の確度はなんと３倍の違いがある。つまり、９０％の確度を確保するには、５０％の確度を確保する３倍の時間の見積もりをする必要があるのだ。これがＰＥＲＴとクリティカルパスの問題点だというのがゴールドラットの指摘である。著者はこの指摘はレトリック的な部分が多分にあると考えているが、プロジェクトマネジメントの本質を突いていることは間違いないだろう。 さらに、重要な指摘は、ワークパッケージのレベルで余裕時間を見ると、「学生症候群」というのが起こるという指摘である。つまり、１日のタスクに１０日間の間にやればよいとすれば、学生のごとく、最後の１日にやろうとする。すると、もし、何かのトラブルがあった場合には、余裕タスクがクリティカルタスクになってしまい、クリティカルパスが移動してプロジェクト全体に混乱をもたらす。この問題はＰＥＲＴベースでスケジューリングを行って実施する際に極めて本質的な問題である。 ◆クリティカルパスを如何に守るか そこで、ゴールドラットが考えたことは、クリティカルパスを如何に守るかである。このための、プロジェクトバッファーという概念を考えた。つまり、５０％を９０％にするために取っているバッファー時間を、プロジェクト全体としてプロジェクトバッファーという形で取る。これによって、ワークパッケージの計画時間は厳しくても、プロジェクトバッファーからの時間捻出で計画変更をしていくとクリティカルパスを守ることは従来どおりできるだろう。なおかつ、ほとんどは、５０％の時間でできるはずなので、その分はバッファー時間を削減ができるはずだというロジックである。 ただし、これだけでは不十分だ。上で述べたように余裕パスが遅れて、クリティカルパス上のタスクを止めてしまうことがあるからだ。そこで、クリティカルパスに入ってくるパス上の合流直前のタスクにもバッファーを持たせておく。これによって、全体がスムーズに流れる（これはＴＯＣの理論のひとつである。詳しく知りたい人は、ゴールでもなんでもいいので、ＴＯＣの本を読んでみて欲しい）。 ◆リソースの競合とクリティカルチェーン さて、十分なリソースがある場合には、以上の方法でプロジェクトの遅延はかなり食い止めることができる。ところが、実際には、一人の人が、複数のプロジェクトを掛け持ちしているケースも決してすくなくない。そうすると、クリティカルタスクのリソースが、別のプロジェクトで使われており、クリティカルパスが守れないという事態が考えられる。 実際にソフトウエアの開発プロジェクトを注意深く観察していると、特定の人がクリティカルパスの作業と余裕パスの作業を持っているときに、クリティカルパスの作業を優先するあまり、余裕パスの作業が遅れてプロジェクトが火を噴いているケースをよく見かける。このようなことが起こるのは、もともと、クリティカルパスは、リソースを配慮していないからである。 ＴＯＣではこの問題に対してクリティカルチェーンという考え方を提案している。クリティカルチェーンは、リソースを考えたクリティカルパスである。例えば、図のようなワークパッケージに対して、リソースが１人であれば、リソースを考えたクリティカルパスは緑の線のようになる。  ◆ゴールドラット流とＰＭＩ流 以上がＴＯＣによるプロジェクト管理の概要であるが、これ自体は納得性の高いものである。ただし、注意しないといけないことは、ＴＯＣとＰＭＩ流はそもそも比較すべきものでない。なぜなら、ＴＯＣにはリスクに対する戦略として回避（あるいは低減）だけを取るという手法だからである。 つまり、ＴＯＣは誰が行っても一定の効果の効果のある手法を提供しているのに対して、ＰＭＩ流はプロジェクトマネージャーの腕に依存する。このような２つの手法のパフォーマンスの比較はある意味、ナンセンスである。要は、使う場面が違うということだ。 ＴＯＣは比較的、小さなプロジェクトの管理に向いている。しかし、大規模な管理には向かない。規模が大きくなると、バッファが生み出すリスクが大きくなるためである。これに対して、ＰＭＩ流はどちらかといえば大規模プロジェクトに適している。 |
|
| 参考文献： 稲垣公夫「ＴＯＣクリティカル・チェーン革命」、日本能率協会マネジメントセンター 村上悟「最速で開発し最短で納めるプロジェクト・マネジメント」、中経出版 |
|
| スポンサードリンク | |
| 読者からのコメント | |
■本稿に対するご意見，ご感想をお聞かせください．■ ■は必須入力です |
|
| このコンテンツは「プロジェクトマネージャー養成マガジン」としてメルマガで配信されています．メルマガの登録はこちらからできます． | |