ＣＣＰＭ

CCPM：Critical Chain Project Management　クリティカル チェーン プロジェクト マネジメント　

プロジェクト型業務をどうコントロールするか

DBR（ドラムバッファーロープ）の考え方のもう一つの発展型が、クリティカルチェーンプロジェクトマネジメントです。CCPMとDBRの違いは、非繰り返し型がプロジェクトで、繰り返し型が生産業務と思われがちですが、ゴールドラット博士はCCPMとDBRの適用をリードタイムに対して、実際に加工処理を行っている時間（タッチタイム）がどれくらいかの比率によって次の二つの手法からいずれかを選択しなさいと教えています。

タッチタイムの比率が10%以下である生産環境に対してはDBRであり、タッチタイムが比較的長い環境に対してはCCPMという事です。ですから、新製品開発やソフトウェア産業などの非定型業務だけでなく、プラント建設や顧客仕様による受注設計生産などのエンジニアリング業務もCCPMの活用領域なのです。

CCPMはDBRの考え方に加えて、人間の行動特性に目を向けプロジェクト型業務を適切にコントロールし流れを作る手法なのです。

プロジェクトはなぜ遅れるのか？

タッチタイムの比率が高いプロジェクト型業務は一回限りから数回程度の反復回数になることが一般的です。このような特性から、各タスクごとの工数を見てみると、量産型工場での繰り返し作業などと違って非常にばらつきが大きいのが普通なのです。これは個々のタスク単位の工数見積がやりにくく不確実性が高い事を意味します。図のように、繰り返し性のない1度限りの作業を行うプロジェクト活動の場合ベータ分布という確率分布に近くなることが知られています。一方、繰返し行われる作業の確率分布が正規分布に近似するのです。

遅れだけの伝播

ＤＢＲのページでも説明していますが、従属性とバラツキ（変動性）の影響によって仕事が遅れるメカニズムはプロジェクト環境でも全く同じです。それに相まって不確実性の高いプロジェクト型の業務特性はバラツキが大きく、全体の効率をさらに低下させる要因になるのです。

ボトルネックリソース

開発業務などで、いわゆるエースと呼ばれるスキルの高い人物は複数のプロジェクトを掛け持ちでやらざるを得なくなります。一度にあれもこれも作業を進めることを余儀なくされ、非常に高い負荷がかかり遅延が発生しボトルネック化します。また複数のプロジェクトが恒常的に動いている開発部門などでは、試験装置などの特定のリソースがボトルネック状態になって、その影響で全体の計画が遅れることがたびたびあります。

しかし、実際に試験装置の稼働内容を分析してみると、それぞれの開発プロジェクトが実際に試験に必要な時間よりも大幅に長い時間試験機を予約しています。これは自分の仕事が試験機の影響を受けて遅れたり、予期せぬトラブルで大幅に試験項目が増えたときのために、余裕を見てリソースを確保するということです。これが恒常的に起こると、いくら試験装置があっても足らず、担当者はますます多くの余裕を見てリソースを確保することになります。

安全余裕を加算する心理

多くの人間が関わるプロジェクト環境では、従属性を持ったネットワーク型業務によって発生する遅れのほかに人間の行動特性によってさらに遅れが拡大する事を順番に見てゆきましょう。
ベータ分布という不確実なタスク見積もりを前提にプロジェクトの担当者に自分の担当する仕事（タスク）の完了期間を見積もらせるとどうなるでしょうか。

50％確率の見積もり値が10日で、90％確率では30日かかるとします。このようなケース場合、申告を10日としても20日としても、30日としても、どれも間違いとはいえません。なぜならば、これらの見積もりは不確実性を前提として「ある条件の下であれば何日である」といっているのにすぎないからです。

しかし一方で、計画が承認されれば守らなければならない。これは社会人としての常識です。ですから、ある作業を10日で申告して、もし達成できなければ上司に怒られる。これも当たり前の話です。こんな場合、皆さんならどの確率条件で自己申告するでしょうか。

50％確率である10日ですか？ これでは五分五分の確率ですから、2回に1回は怒られて評価を下げることになります。それではたまりませんから、できれば絶対に遅れない見積もりをしたいと思うのが人の常です。しかし九分九厘となると極めて大きな値になるので、上司には受け入れられないかもしれません。ということで、90％程度つまり30日程度の日数で、上司とサバ読みの攻防をするのが一般的です。

さらに悪いことに1人1人のサバ読みだけでなく、組織的なサバ読みも発生します。なぜならチームリーダーも任されている管理職ならば、チームが遅れても上司に怒られます。責任感の強いチームリーダーは、現場から上がってきた計画値に対して、さらに余裕を付加し必ず守れる計画を作ろうとするのです。このように現場で1人1人がサバを読み、さらにチームリーダーがサバを読むことで、計画はどんどん長くなっていきます

早期完了の未報告

また、心理的な要素も大きな影響を与えます。これは、いかに早く作業を完了しても、担当した本人にメリットがないことに起因しています。つまり、プロジェクトでは作業が予定どおりできるのが当たり前で、遅れたらそれこそ袋だたきに遭ってしまいます。これでは早めに終わっても、次回の日程をカットされないように、黙っている方がよいということになり、遅れのみが伝播し、早まった分は決して表面化しないのが世のプロジェクトの常となってしまうわけです。

学生シンドローム

これは、納期ぎりぎりにならないと作業を開始しないという性癖です。論文やテスト勉強をする学生が一夜漬けに追い込まれる様子からこの呼び名が付きました。もちろん開発や研究などのプロジェクトの実行段階で、エンジニアは学生のように遊びほうけているわけではなく、多くの仕事を掛け持ちしてやらなければならないために、こういった状況に追い込まれます。着手日が来ても、より優先順位が高い仕事があれば、その仕事を優先せざるを得ないのです。

悪いマルチタスク

いわゆるエースと呼ばれるスキルの高い人物は複数のプロジェクトを掛け持ちでやらざるを得なくなり、並行作業を余儀なくされます。プレッシャーを掛けられると、火の付いた部分から片付けざるを得なくなり、時間刻みであれこれの処理をやることになります。

とりわけ、3つ以上の仕事を同時に担当したときなどは顕著に問題が出ます。あれこれ切替えながら仕事を実行するために、思考の段取り替えが発生し、一定のアイドル時間が必要になります。また作業Aを一気に初めから終わりまで担当した場合は作業速度に加速が掛かる可能性があります。いわゆる学習曲線です。従って作業A、B、Cという3つの仕事を同時に進めると、シングルタスクで実行するときよりは長い時間が必要になる可能性が高いのです。

また、マルチタスクを強いられるリソースはそれだけ負荷が高く、いくら日程的な安全余裕を確保してもしょせんは何の役にも立たない場合が多いのです。

パーキンソンの法則

パーキンソンの法則は、イギリスの政治学者シリル・ノースコート・パーキンソンが提唱した「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」という法則です。これと同様に、プロジェクトの作業でも担当者が予定されている日数を必ず使い切ってしまう特性を指しています。

これまで説明してきたようにプロジェクトにおいては多くのタスクはあらかじめ織り込まれた安全余裕を使い切って期限どおりに完了します。ようするに、各タスクに割り当てられた安全余裕は各タスクを期限どおりに完了させることにのみ費やされ、たった1つのタスクが遅れただけでプロジェクト全体が遅れるのが現在のプロジェクト管理の実態なのです。

クリティカルチェーンの考え方

ゴールドラット博士のプロジェクト・マネジメントに関する洞察の本質は、「プロジェクトの計画を見積もるときに織り込むべき安全余裕の考え方を変える」という、一点につきます。それではどうすればプロジェクトが長期化する事を抑えることができるでしょうか。

PERT* -CPMのクリティカル・パスは全工程の中で一番時間のかかる経路であり、クリティカルパスを短縮すれば全体の期間は短縮できると考えます。クリティカルチェーンではクリティカルパスを短縮するために個別のタスクがそれぞれ予定を守れば全体の納期が守れるという考え方をやめ、タスクそれぞれには遅れ、進みがあっても最終的に予定通りの期間でできれば良いと考えます。つまり各タスクの見積もり時間は説明したように、三分の二の安全余裕が含まれています。そこで考え方を変えて、各タスクを守るための安全余裕をクリティカル・パス全体を守るために最後にまとめて置くようにしたのです。

こうすれば各タスクの完了予定期間は当初の三分の一になるはずです。計画期間内でできる確率は五割になりますが、その代わりにプロジェクト全体を遅れから守るプロジェクト・バッファがたっぷり取れます。これほどの安全余裕は必要ないので、プロジェクトバッファーを半分にすれば現実的な目安になります。それぞれのタスクに安全余裕を振り分けても、クリティカルパス上の１００あるタスクの１タスクでも遅れれば、その遅れは確実に全体の遅れにつながるので、まずはそれを避けるために、個別の余裕ではなく全体を遅れから守るプロジェクトバッファーほうが効果的なのです。

５０％見積でタスクを実行すれば、タスクの半分は予定より遅れます。この方式では、プロジェクトを管理するマネージャーは、各タスクの完了日が予定日より遅れているとプロジェクト全体が遅れていると考えず、プロジェクトバッファーを監視してプロジェクト・バッファーの何割がなくなったかとか、プロジェクトバッファーが何日残っているかということを管理するのです。最終的にはプロジェクト完了までに一日でもバッファーが残っていればプロジェクトは予定期間内に終了したことになります。

このようにプロジェクトバッファーは個別作業の安全余裕を集めた場所ということになります。言い換えればプロジェクトバッファは、プロジェクトの不確実性を全て集めた場所であり、これを注意深く管理する事は、プロジェクト全体の不確実性を管理する事にほかならないのです。

＊PERT（Program Evaluation and Review Technique）
仕事（プロジェクト）全体を構成する各作業の相互依存関係をネットワーク図にすることで、各作業の日程計画を作成し、さらに最長のプロジェクト経路（クリティカルパス）を明らかにして所要時間の短縮を図る手法のこと。

合流バッファー

クリティカルパス上の安全余裕はプロジェクトバッファーに集めて管理しますが、クリティカルパス上にないタスクはどのように管理すれば良いのでしょうか。
ＤＢＲでもCCPMでも制約以外は制約を保護するのがルールです。制約であるクリティカルパスが遅れれば全体が遅れるのですから、クリティカルパスを守るために、クリティカルパスに入ってくる全ての合流点の前にバッファーを設置します。

クリティカル・チェーン

もう一つ考えなければならないのは、プロジェクトのタスク間でリソースの競合がある場合の問題です。従来のクリティカル・パスの考え方はリソースの競合は考慮しておらず、タスクの掛け持ちが発生するとクリティカルパス以外のパスが大幅に遅れて、そちらの方がクリティカルパスになってしまう可能性があります。
そこでTOCでは資源の競合を考慮し、マルチタスクを回避して作った一連のタスクをクリティカル・チェーンと呼んでいます。
つまり、クリティカル・チェーンとは、従来のクリティカル・パスにタスクが競合してボトルネックが発生するリスクを避けたものなのです。

行動特性を考慮したCCPMのポイント

さらにプロジェクトの実施にあたっては説明したような、人間の問題行動が自然に排除されるよう計画し、プロジェクト管理を行います。

マルチプロジェクトを管理する

ここまで一つのプロジェクトの期間をどう短縮するかについて説明してきました。しかし、現実の企業では複数のプロジェクトが同時進行するマルチプロジェクトの環境が一般的です。
マルチプロジェクト環境では、独立したそれぞれのプロジェクトが、人や設備といったリソースを共有して仕事を進めるのが普通です。これは生産環境で多くの機械設備の中を多くのオーダーが流れるのと非常に似ており、このリソースの共有によって様々な遅れや混乱が生じるのです。これを上手にコントロールするためには、DBRと同じように「流れ」を作るために適切なペースメーカー（ドラム）を設定しなくてはなりません。
具体的には負荷の高いリソースが安定的に稼働できるようにプロジェクトの開始時期をずらし（遅らせ）て負荷の平準化を行います。さらに開始するプロジェクトは事前準備を徹底し仕様が曖昧なまま投入しない* 事を徹底します。

＊準備不足の仕事は現場に投入しないことをCCPMではフルキット（完全な準備）と呼びます。

マルチプロジェクトをCCPMで管理する事によって個別のプロジェクトで安全余裕を管理するよりも、複数のプロジェクトのバッファを共有して管理すれば、全体の安定性を高める事ができます。バッファをほとんど消費しない順調なプロジェクトとトラブルの連続で納期遅れになりそうなプロジェクトのバッファを共有できれば、両方のプロジェクトの遅れと進みを打ち消し合うことが可能なのです。

業界別導入解説とポイント

業界	導入解説とポイント	ファイル
製造業 開発部門	新製品開発におけるCCPMの導入 - 製造メーカー各社のCCPM導入
ソフトウェア 開発	IT業界での導入事例 - ソラン株式会社におけるマネジメント改革
個別受注 設計生産環境	プロジェクトで風土を変える取組み - 荏原冷熱システム株式会社