今回からは、TOCのプロジェクト管理手法である、CCPMについて書いてゆきます。
CCPM ： Critical Chain Project Management
（クリティカルチェーン・プロジェクトマネジメント）
CCPMは、エリヤフ・ゴールドラット博士により１９９７年、著書「Critical Chain（ｸﾘﾃｨｶﾙﾁｪｰﾝ）」により発表されました。サブタイトルは、「なぜ、プロジェクトは予定通りに進まないのか？」です。
この著書は、DBRを紹介した著書「ザ・ゴール」と同様に改善物語として書かれており、今までのプロジェクト管理方法の問題点を浮き彫りにし、プロジェクト業務特有の問題に対しどのように対処したらよいかを、分かりやすく説明しています。
ただし、著書「クリティカルチェーン」では、不確実性の高い業務に対するスケジューリング方法はなんとなく分かりますが、プロジェクトの管理方法については、詳しく書いていません。
そのため、この本通りにプロジェクト業務を管理しようとしても、成果を得ることが出来ないだろうというのが、私の本音です。
しかしTOCの中でプロジェクト管理手法として出ている名前は、「CC」ではなく「CCPM」です。要するにCCPMは、クリティカルチェーンの計画・管理だけではないということです。
CCPMは、
CC：Critical Chain
（クリティカルチェーン）と呼ばれる「プロジェクトのスケジューリング方法」
PM：Project Management
（プロジェクトマネージメント）と呼ばれる「プロジェクトの管理統制方法」
この２つの機能を持った、管理手法であるといえます。
そのため、このTOC講座では、まず、CCPMの概要と、プロジェクト業務の特性（問題点）を提起します。
次に、CCPMによるプロジェクトの「スケジューリング方法と考え方」を説明します。
そして最後に、プロジェクトを成功させるためのキーとなるマネジャーの仕事を、CCPMによる「プロジェクトのマネージメント方法」として説明します。
下図は、CCPMによるプロジェクト業務のスケジューリングイメージを表わしています。
図の中にあるBFとは、バッファーを意味します。
CCPMでは、タスクの合流ポイントに「合流BF]を、同一リソースが連続して使われる場所に「リソースBF」を、プロジェクトの一番後ろに「プロジェクトBF」を配置します。
ここで、CCPMの説明に入る前に、「プロジェクト業務（活動）とは、どのような業務なのか？」を定義しておきましょう。
プロジェクト業務とは？
Wikipediaで検索しますと、
プロジェクト（英: project）は、何らかの目標を達成するための計画を指す。
どちらかと言えば、小さな目標の達成のためのものではなくて、大きな目標を集団で実行するものを指すことが多い。
その計画の実現のためのタスク（仕事）の実行までを含めて指すこともある。
PMIが制定しているPMBOK(第３版）の定義では、「プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務である。」とされている。
つまり、会社などの通常業務や、継続的な運用管理、あるいは改善活動などは、特に開始と終了が定義されていないため、「プロジェクト」とは呼ばない。
ただし、特定の期限までに特定の建築を行う、製品を開発する、システムを構築するなどは、個々のプロジェクトになりうる。このように定義されています。
簡単にまとめると、「ある特定の目的を達成するための活動で、開始と終了が明確に定義されており、比較的大きな目標を集団で実行する活動」であるといえます。
１．CCPMとは？
新製品の開発やシステムの開発、土木事業や橋の建設工事といった公共事業などの、二度と同じ作業の無い活動で「業務内容や作業時間などに不確実性の高い業務」や、航空機・船舶・鉄道車両などの製造活動で、「製造期間の長い製品の製造業務」など、プロジェクト業務に適応した管理手法です。
CCPMが、今までの計画管理方法と大きく違う点は、
- 「クリティカルパス」ではなく「クリティカルチェーン」を管理する。
- 各タスク（業務）の時間見積り方法。
- 生産の揺らぎを吸収する３種類のバッファ。
- 重要なリソースの管理・活用方法。
- プロジェクトの進捗管理方法。
- マネジャーの重要業務（プロジェクトの進捗状況によるアクション）
などです。（詳しくは、別途説明します）
特に、人間が中心に進められる業務への対応策や、どの時点でアクションを起こすか？など、不確定性の高い業務をどのように、計画・管理して行くかが明確にされています。
ではまず、従来のプロジェクト業務に対するスケジューリング方法と問題点について、書いて行きます。
２．プロジェクトのスケジューリング方法
プロジェクト業務のスケジューリングは、高い不確実性に対し、出来る限り「見積り精度」を上げることで対応しようとしてきました。しかし、初めて取組む仕事から「不確実性」を無くすことは不可能であるため、時間見積りには「時間的余裕（サバ）」が入ります。
１）従来のプロジェクト業務のスケジューリング方法と問題点
現在、プロジェクト業務のスケジューリング技法としては、ガントチャートやPERTが有名です。
そして、この二つの工程管理技法で重要とされるものが「クリティカルパス」と呼ばれる、一番時間の長いタスク（仕事）のつながりです。
そしてプロジェクトは、ガントチャートやPERTなどにより「見積り時間の一番長い工程」が遅れないように、実は十分な時間的余裕を考慮して計画されてきました。
しかし、十分な時間的余裕を考慮しているにもかかわらず、ほとんどのプロジェクトは、予定時間を大幅にオーバーしてしまいます。
これに対しCCPMは、外部に見えないように入れられている時間的余裕（サバ）を、最初から見えるようにすることで、プロジェクト全体を守るための余裕として位置付け、この余裕がどれだけ減っているのかを管理します。
また、いままでクリティカルパスと呼ばれる固定的な業務（時間）を管理するのではなく、全体業務を見て、今、全体の時間を決めている変動する業務（クリティカルチェーン）を、管理することにより、プロジェクト期間全体を守ります。
では次に、プロジェクト業務の特徴（問題点）を挙げてみます。
２）プロジェクト業務の問題点
プロジェクト業務は、定義にも書かれていたように「ある特定の目的」を達成するための活動であるため、計画の遅れが企業の存続を左右することも、多々あるのです。
しかし、このプロジェクトと呼ばれる業務は「いつも遅れる」のでしょうか？
なぜ、プロジェクトはいつも遅れるのでしょうか？
プロジェクトが遅れる代表的な理由
- 業務内容のほとんどが、初めて取組む作業であり、時間的見積りの精度が低い。
- 初めて取組む作業のため、予期しない問題が多々発生する。
- 業務内容の多くが、人を中心とした作業であるため、時間的なバラツキが大きい。
- 一部の人にしかできない業務内容がある。（人的リソースが限られる）
- 作業途中での予定変更が、多々発生する。（やってみないと分からない点が多い）
このように、不確実性の高い業務を予定通りに進めるため、多くの関係者は「十分な時間的余裕（サバ）」を各タスクに入れています。
しかし、十分な時間的余裕はプロジェクト全体の期間を長期化させ、目的で重要な「他社よりも早く開発する・少しでも早く市場に投入する」といった部分で、根拠の無い妥協により、時間的な余裕はバッサリと計画段階で切り落とされてしまうことも事実です。
ここで、プロジェクト業務で頻繁に発生する問題を挙げてみます。
ﾌﾟﾛｼﾞｪｸﾄ業務で頻繁に発生する問題
- 必要な時に、必要な資源（人・設備・物・材料・金など）が足らない。
- 予定の変更が頻繁に行われる。
- 時間（期間）が足らない。
- 作業内容が途中で変更される。
- 熟練者が不足する。
この問題のほとんどは、「人間が中心となって進める業務＝プロジェクト」であるからこそ、引き起こされる問題と、云えるのです。
CCPMでは、このような問題を下記のような方法で排除します。
《 CCPMの機能概要 》
- 各タスクに割り当てられている、時間的余裕（サバ）を取り除きます。
- 各タスクの開始と終了の状態を、ハッキリ定義します。
- プロジェクトのフローを、完了時点から開始時点に向かい、フローを順に書きます。
- リソースを個人名ではなく、同一スキルのプール名で設定します。
- 合流BF、リソースBF、プロジェクトBFを配置します。
- マルチタスクを出来る限り、排除します。
- プロジェクトのスタートを、出来る限り遅くさせます。
- クリティカルパスではなく、クリティカルチェーンを管理します。
- 各ﾀｽｸの遅れにアクションと取るのではなく、プロジェクト全体の遅れにアクションを取る。
- 作業は効率ではなく、通過速度（リードタイム）を優先させる。
- 作業終了後は、直ちに次工程へ引き渡す。
- 複数プロジェクトには、必ず優先順位を付ける。
CCPMの機能概要の説明については２つに分け、まず次回は、スケジューリングの方法で活用される部分を説明します。
その後に、マネージメントで使われる部分を書きます。
