前回までで、CCPMについての概要は説明しました。
今回は、CCPMのまとめと説明不足と思われる点の、補足説明を行います。
CCPMのまとめ
TOCにおけるCCPMは、プロジェクト業務の計画・管理を行うための技法です。
１．CCPMの適用範囲
CCPMの適用範囲は、プロジェクトと呼ばれる業務であり、作業開始から作業完了までの期間が比較的長い業務が対象となります。
CCPMに適さない業務
研究開発のように、「何を作るか？」「いつまでに作るか？」「どのような手順で行うか？」などが、ハッキリ決まっていない業務には、あまり適していません。
また、繰返し生産される製品の生産管理や、短期間で終わる業務などにも適していません。
（例：未知のものの技術開発、新素材の研究、自動車部品のようなリピート品の生産管理など）
CCPMに適した業務
試作開発のような、目的がハッキリしており、完了すべき納期があり、目的を達成するための手順が、決まっている業務に適しています。
また、製造業で二度と同じものを作らないような個別受注生産品や、生産に長期間かかるような業務などにも、適しています。
（例：試作品の立上げ業務、ターゲットの決まっているソフト開発、航空機や船舶の製作業務、工場設立や公共事業の推進など）
２．プロジェクト型業務の問題と原因、及び対策
プロジェクト型業務で頻繁に発生する問題
- プロジェクトは、いつも遅れる
- 必要な時に、必要な資源が、必要なだけ無い
- いつも予算がオーバーする
- 頻繁な予定変更
- 熟練者が不足する
問題１：「プロジェクトはいつも遅れる」
原因：従属性と変動性による遅れの伝播と、安全余裕の持ち方
対策：仕事の半分は遅れると考え、５０％確率での計画立案と、プロジェクトバッファの活用
問題２：「必要な時に、必要な資源が、必要なだけ無い」
原因：個人や固有設備を計画段階で予定と、優先順位付け
対策：リソースマップによるスキルレベルでの予定作りと、優先順位へのマネージメント実施
問題３：「いつも予算がオーバーする」
原因：予算を残すと、次回から予算を削られるという考え方
対策：予算の棚卸と、予算のバッファ管理（残金額管理）
問題４：「頻繁な予定変更」
原因：早い段階（仕様が決まる前）での作業着手
対策：作業着手をギリギリまで待つことで、仕様精度を向上させる
問題５：「熟練者が不足する」
原因：特殊技術の偏りや、スキルを持った人材の人事異動など
対策：スキルマップによる人材育成と、部門を越えたリソースマップの作成
３．従来のプロジェクト管理技法とCCPMの違い
CCPMによるプロジェクト管理は、TOCの基本である全体最適の考え方と、人間行動への対応を中心に作られています。
《 P：計画 》
- ①計画立案の順序
- 【従来】作業開始から完了に向けて作成 → 【CCPM】完了状態から開始に向けて作成
- ②バッファ（安全余裕）の入れ方
- 【従来】各タスク毎に挿入 → 【CCPM】制約条件の前と、プロジェクト全体に対して挿入
- ③作業開始のタイミング
- 【従来】出来る限り早く開始 → 【CCPM】出来る限り遅く開始
- ④リソースのアサイン
- 【従来】固有リソース（人・設備）をアサインする → 【CCPM】リソース群（ｽｷﾙﾚﾍﾞﾙ）でアサインする
《 D:実行、A：アクション 》
- ①作業方法
- 【従来】原価基準（作業効率を重視する） → 【CCPM】スループット基準（スピードを重視する）
- ②作業の着手・完了
- 【従来】計画通り着手し、計画通り完了させる → 【CCPM】引き取り後は直ぐに着手、完了後は直ぐに引き渡す
- ③遅れへの対応方法
- 【従来】タスク単位の遅れに対応 → 【CCPM】プロジェクト全体としての遅れへ対応
- ④プロジェクトの優先度
- 【従来】定性的（責任者単位で設定） → 【CCPM】定量的（プロジェクト全体で優先順位を付け）
- ⑤Q（品質）C（コスト）D（納期）の重要度
- 【従来】自社利益を優先（C→Q→D） → 【CCPM】顧客満足を優先（Q→D→C）
《 C:管理 》
- ①プロジェクトの進捗管理方法
- 【従来】各タスクの進捗を管理する → 【CCPM】プロジェクト全体の進捗を管理する
- ②進捗報告の方法
- 【従来】定性的（残日程を消化率(％)で表現） → 【CCPM】定量的（残日程を残日数で表現）
- ③遅れの管理
- 【従来】固定的（クリティカルバスを管理） → 【CCPM】流動的（クリティカルチェーンを管理）
４．CCPMによる計画立案手順
- １）プロジェクトを定義する
- プロジェクトの目的、目標、成果物、成功要件を明確にすると共に、リスクの洗い出しを行う。
- ２）プロジェクトネットワークを作成する
- 完成時点を始点として、その直前の状態その直前の状態と、後ろから順に開始時まで遡り作成する。同時に、必要リソースと作業時間（従来通りの見積り）を入れる。
- ３）タスク予定時間からサバを取る
- 出来上がったプロジェクトネットワークの見積もり時間を、５０％確率（予定通りできる確率５０％）で見直す。また、過剰リソースの設定になっていないかもチェックする。
- ４）バッファを挿入する
- クリティカルパスを見つけ、その合計時間の半分の時間を、プロジェクトバッファとして挿入する。また、タスクの合流地点には合流バッファを、制約リソースの後ろにリソースバッファを挿入する。
- ５）作業開始日を出来る限り、後ろにずらす
- 納期にプロジェクトバッファの後ろを合わせ、プロジェクト全体を後ろにずらす。また、合流タスクも合流バッファの後ろを合流地点に合わせ、合流タスク全体をずらす。
CCPMの補足説明
１．リソースの負荷山積み・山崩し
CCPMによる計画作りの中で、バッファを挿入した後に行います。
同一リソースが重複する場合、利用可能リソース数と比較して不足していれば、タスクのずらしを行います。ずらしを行うタスクは、合流するタスク側を選びます。
２．５０％見積りの計画でも、納期が間に合わない場合
あまりにも納期が短く、プロジェクトの実行期間が取れない場合は、タスクの見直しを行い、タスクの分割・平行作業が出来ないか検討する。
また、プロジェクトバッファの削減を実施する場合は、管理グラフのゾーン切り替え角度を変更する。
３．計画のスラック現象
CCPMによる計画立案で、合流バッファまたはリソースバッファを挿入すると、クリティカルチェーン上に隙間が発生する場合があります。これが「スラック」という現象です。
このような場合は、合流する側のタスクのバッファを削減するとなくなります。しかし、この行為は同時に
プロジェクトを危険にさらしますので注意が必要です。
CCPMについての基礎知識は、今回で終了です。
次回は、TOCのディストリビューション（流通・物流）について書きます。
