TOC-CCPM

CCPM-FAQ；プロジェクトバッファーを短くしても良いですか？

よくある質問への回答
　
質問；プロジェクトバッファーを配置すると顧客の納期をオーバーしてしまう。プロジェクトバッファーを納期内でおさまるまで短くしてプロジェクトを開始してもよいか？
　
回答；だめ。
　
　
　
　
と、冷たく突き放しても困るでしょうから、論理的に解説を試みます。
　
結論から言うと、
プロジェクトバッファーはルール通りのサイズで配置すべきです。
ただし、どうやっても納期内に入らなければ、それはやっぱり無理なので、バッファーがすでに消費された状態として配置します。
　
これでとりあえずプロジェクトを開始します。
実行管理の際にバッファーが赤になれば、バッファー回復策をとらなければなりませんので、バッファーが最初から消費されているということは、それだけ早い段階でバッファー回復策が必要となるということになります。
赤になったら、バッファー回復策を実施してください。
　
プロジェクト開始当初からバッファーが赤の場合は、現実的なバッファー回復策は納期を延長することくらいしかありません。
納期延長の最低限度の目安は、当初計画で見積もった（ちゃんとバッファーをつけた場合の）納期です。
それ以下の延長は、再延長を行うことになり信頼を失うことになるでしょう。
　
　
まとめると、バッファーが消費された状態でスタートし、適切な段階で納期交渉をし、手遅れにならないうちに納期の再設定をすることが現実的な対応ということになります。
　
　
なぜ、そうするのか少しくどいですが理由を書いておきます。
　
計画段階での見積もり時間というものは、もともと将来の推定に過ぎず、本当にどれくらい時間がかかるのかは、やってみなければわからないものです。そのため、CCPMでは安全側の見積をしておいて、それを挑戦的にするというプロセスを踏んでいます。
　
挑戦的見積日数はタスク内の安全余裕を取り払った状態であるため、五分五分かそれ以上の可能性で遅れます。
そのため、プロジェクトの納期を守るためには、適切なサイズのバッファーが必要です。
　
では、適切な量とはどれくらいでしょうか？
　
経験的なガイドラインでは、クリティカルチェーンの長さの２分の１以上であるとしています。
クリティカルチェーンの２分の１以下とすることは、納期遅れのリスクを大いに高めるため、好ましくありません。
　
よって、バッファーを短くすることはやめましょう。
　
　

CCPM導入Tips；バッファーの回復策で主体的に制約（Constraints）を徹底活用する

　CCPMでは、納期を確実に守るために、プロジェクトバッファーを監視する。
　
　プロジェクトバッファーの残り時間が少なくなればなるほど、納期を守るための保護が少なくなる。　
　納期を確実に守るためには、プロジェクトの進捗状況にあった適切な保護時間を、常に保持していなければならない。

　CCPMでは、プロジェクトバッファーの減り具合をプロジェクトの進捗状況にあわせて色分けによって識別することを提案している。

　

　緑色の範囲（グリーンゾーン）はそのまま進めて大丈夫そうなエリア。
　黄色の範囲（イエローゾーン）は、それ以上バッファー消費しそうか調査が必要なエリア。
　赤色の範囲（レッドゾーン）は納期順守が危険な状況であり、対策をとる必要があるエリア。
　消費率が１００％を超える範囲は、黒色（ブラックゾーン）とし、すでに納期遅れの可能性が顕在化しており、早急に対策が必要なエリア。

　バッファーが赤色以上の範囲（レッドゾーン、ブラックゾーン）に入ったら、バッファーを十分な量まで回復する対策とる。
　
　CCPMの標準的な知識では、「イエローゾーンの時に調査をし、レッドゾーンに入ったら対策を実行する」ということになっている。
　
　しかし、イエローゾーンに入ったらすぐにレッドゾーンに入ってしまう場合もあるだろうし、イエローゾーンを経ずに突然レッドゾーンに入る場合もある。
　バッファーの回復策を、困ってからその場で考えていたのでは間に合わない。回復策のリストは、計画の段階から作成しておく必要がある。
　
　計画から実行管理を通じて、実際にバッファーの回復策が必要な状況にいたるまでの間に、さまざまな対策案が見つかっていることが多い。その数ある回復策の中から、最も適切な対策を講じることが良い。

　例えば、計画時点で、もし、リソースが必要なだけ十分に配置できるのであれば、リソースの競合は起こらない。すなわち、クリティカルチェーンは発生しない。したがって、クリティカルパスとクリティカルチェーンの差の分だけ、バッファーを回復する選択肢があることがすでにわかっている。
　
　また、例えば、計画時点で依存関係があると仮定したタスク間に依存関係がないことが実行段階でわかったのであれば、十分なリソースがあれば、タスクを並列で処理できる可能性があることがわかる。

　こうしたバッファー回復（期間短縮）のアイデアをリストに保存しておく。

　リストには、アイデアの内容と期待されるバッファー回復日数のほかに、実行するための障害、実行された場合に想定されるリスク（特に品質やコストに対する影響）をあらかじめ記載しておくことが良い。
　
　このリストは、実行段階を通じて常に見直されていく動的なリストである必要がある。
　
　常に前向きに、よりバッファー消費を少なくプロジェクトを終わらせることは、プロジェクトのマネージャーにとっても、プロジェクトのオーナーにとっても有益である。
　
　バッファー回復策リストの動的な更新は、クリティカルチェーンという制約（Constraints）を実行管理段階を通じて徹底活用する上で非常に重要である。
　
　バッファーのレッドゾーン対策については、多くの場合「赤になったから対策を打たなければ・・・」と反応的（消極的）な対応が中心になりがちだが、「制約（Constraints）を徹底活用するのだ」という主体的（積極的）な姿勢が成果を生みだす。
　
　

CCPM導入Tips；最優先タスクをスケジュールにいれる

　CCPMを導入する前によく聞かれる保留意見に以下のものがある。
　
　「タスクが遅れるということは、先の工程（タスクのスケジュール）がくるってしまうので問題だ。」
　「スケジュール変更が頻繁になって、工程表を度々変更しなければならなくなり大変そうだ。」
　「スケジュール変更が頻繁になって、リソースの事前予約ができなくなり困りそうだ。」

　タスクの実施予定日が変更になること、特にプロジェクト期間のあとの方になればなるほど、変更が大きくなることを心配する。

　なぜだろうか？

　それは我々が現在、”スケジュール管理の常識”としている考え方に依存している。
　
　
　ここで、セルフマネジメントの分野で大変著名な本『７つの習慣』（スティーブン・R・コヴィー著）から次の文を紹介したい。
　
　”大事なのは、スケジュール課題に優先順位をつけるのではなく、優先課題をスケジュールに入れることである。”
　
　人生というプロジェクトをより実り多いものにするために、個人の価値観から決定される優先課題をいかに実行するべきかを示した名言である。
　
　そのときに最も重要なタスクへの集中を求めている。

　集中をしなければ卓越した成果は上がらないからである。
　
　この集中の考え方は、まさにTOCの目指すところである。
　
　CCPMにおけるスケジュールも、この考え方（パラダイム）に従っていると考えると理解しやすい。
　
　
　では、優先順位は何に従ってつけたら良いのだろうか？

　先に紹介した『７つの習慣』では人生における個人のタスクを扱っているが、優先順位を付けるためにはその価値判断基準となるもの（個人の価値観）を明確にする必要を説いている。
　
　では、プロジェクトにおいては、何によって優先順位をつけたら良いのだろうか？
　

　私の考えでは、プロジェクトの価値判断基準としては、安全、品質、時間（納期）、コストである。
　
　確保すべき安全、品質はタスクの依存関係図で作り込む。

　これを実行し成果をあげるための”制約（Constraints）”となるのが時間である。
　
　そしてその時間（納期）は、バッファーによって守られる。
　
　バッファーが優先順位を与えるのである。
　
　
　
　
　CCPMでは、プロジェクト全体の進捗具合はどんな状態なのか、すなわち納期内に完了できそうかどうかはバッファーで監視している。
　
　実行管理部隊は、タスクの依存関係図で設計したプロジェクトの流れに従って、優先タスクをスケジュールに入れる。
　
　タスクの優先順位は、バッファーの状態で自動的に決まる。
　
　タスクを優先順に並べ、その遂行時間を見積もれば、各タスクの開始予定日はわかる。
　
　優先順位は、一つタスクが終わる毎に見直され、その時にもっとも優先されるべきタスクが常に実行される。
　
　
　実施予定日が変更になるのは、CCPMに限った話ではない。CCPMをやらなくても変わる。
　
　そしてそれに対応するためのツール（月間工程表、週間工程表、翌日の作業打合せなど）はすでに使っている場合が多い。
　
　優先タスクのリストと、これらのツールを組み合わせれば良いだけである。
　
　
　重要なことなので繰り返すが、”優先タスクをスケジュールに入れる”　のである。
　
　スケジュールを守ることが重要なのではない。
　優先タスクをできるだけ早く処理することが重要なのである。
　

CCPM導入Tips；継続的改善のための評価基準とバッファーマネジメント

◆評価基準について
　
　個々のプロジェクトにCCPMを適用する例がすこしずつ増えてきているが、CCPMによって何がどのように改善されたかを明確に答えられるだろうか？

　
　よく見かけるのは「あるプロジェクトが計画期間に対して２５％短縮して完了した」というような成果である。
　
　「あるプロジェクトが計画に対して２５％短くなった。なぜならば、CCPMを導入したからだ。」という因果関係がなりたっているという主張であるが、このロジックは本当に通っているだろうか？
　
　一つや二つのプロジェクトだけでは、なんとも因果関係が弱い。

　「CCPM導入後のすべてのプロジェクトの平均値として、計画期間に対して２５％短縮して完了している」というならば、それは間違いなくCCPMの成果と行ってよいだろう。
　
　このように因果関係を証明するためには、データを取っていなければならないということになる。
　
　CCPMの導入に限った話ではないが、何がどのように改善されたのかを適切に評価できる数字を記録する必要がある。
　
　
　ゴールドラットスクール発行の図書『Project Management The TOC Way』の中で、Oded Cohen氏は２つの指標の追跡を提案している。
　
　「納期遵守率」と「スループット・ダラー・デイズ」である。
　後者はTOCで用いられる特有の指標である。
　「スループット・ダラー・デイズ」は、「プロジェクトの価値（金額）」に「遅れ日数」を乗じたもので、納期遅れによる悪影響を表現したものである。プロジェクトの価値が高いほど、遅れ日数が大きいほど、指標値が大きくなり、悪影響が大きいことを示す。

　企業によっては、このほかに「残業時間」などを評価指標としているところもある。
　
　いずれの指標を採用するにしても、改善への意欲を継続させるためには、何を改善するのか目的を持つことは当然のこと、それだけでなく「測り」、「評価する」ことが重要である。
　

　

◆バッファーマネジメントについて
　
　個々のプロジェクトの目標を達成することが大事なのは当然だが、次のプロジェクトはもっとうまく行いたい。
　そのために現在のプロジェクトから得られた教訓をフィードバックしたいと皆考える。
　しかし、これがなかなか上手くいかないという声を聞く。

　プロジェクトの反省やフィードバックは、プロジェクト完了後にわざわざ会議を開催して行おうとしている例が多い。　
　しかし、プロジェクト完了後にはすでに次のプロジェクトが開始されていたり、記録が不十分だったり、過去のことをいちいち正確に覚えていられなかったりなど、十分なフィードバックをできないままにやり過ごしてしまうことが多い。

　TOCでは、継続的改善のための情報を日常的にフィードバックするための仕組みを提供している。
　CCPMでは、プロジェクト実行中毎週１回、継続的改善のためのフィードバックの機会を作ることを推奨している。
　
　
　継続的改善のために最も重要な情報は何だろうか？
　
　
　この問いに答えない”反省”をしても意味がない。
　
　TOCではシステムのパフォーマンスを左右するもっとも重要なポイント、すなわち制約（Constraints）の徹底活用のための情報にフォーカスする。
　意味のないデータを集めても、マネジメントの時間を無駄にするだけである。
　もっとも大事なデータだけをピンポイントで集める。
　
　
　制約（Constraints）の徹底活用のための情報はバッファーをモニターすることで得られる。
　なぜならば、バッファーは制約（Constraints）を守るためにおかれているからだ。
　バッファーの減り具合を監視することで、制約（Constraints）に悪影響を及ぼしている事項を特定することができる。

　CCPMでは、プロジェクトバッファーの減り具合を監視し、適時その消費原因をサンプリング調査し、分析する。
　これによって、プロジェクトの進行中にフィードバックを行い、速やかに改善を行うことが可能となる。

　プロジェクトがすべて完了した後で、次のプロジェクトに向けてフィードバックするのでは遅すぎる。
　
　プロジェクト進行中からタイムリーに改善を行うことができるのが、バッファーマネジメントを用いた継続的改善のメリットであり、またそれがCCPMのメリットでもある。
　
　CCPMを運用してバッファーが管理できていいるのであれば、これを継続改善に活かさないのはもったいない。
　

TOC導入Tips；「The Job Shop Game」で仕事の詰め込みすぎの弊害を理解する

　ゴールドラットスクール発行の図書『Project Management The TOC Way』の中で、「システム内への仕事の投入を制限すること」の必要性について理解を進めるための簡単なゲーム；「ジョブ ショップ ゲーム（The Job Shop Game）」が紹介されている。

　このゲームは生産環境にかかわりなく、「仕事の詰め込みすぎ」という悪弊による影響の大きさと、その簡単な解消策と効果の大きさを体感することができる優れたゲームである。
　
　CCPMだけでなく、S-DBRの導入の際にも用いるので、あえてタイトルは「TOC導入Tips；・・・」とした。
　
　
　

◆◆◆ジョブ ショップ ゲーム（The Job Shop Game）◆◆◆

◆ゲームの目的
　システム内のリソースの処理能力を超えて仕事を投入することによって、生産システムが混乱する状況を体感する。
　もっとも負荷のかかるリソースの処理能力にあわせて仕事を投入することによって、生産システムが安定する状況を体感する。
　
◆ゲームの準備
　所要時間はおよそ３０分程度
　プレーヤーは６人（最低４人でも実施可能）

　「ジョブ オーダー カード」を作成する

　 ジョブ オーダーは４種類、それぞれ処理すべき４つの工程が記載されている
　　オーダー１；A　→　B　→　C　→　D
　　オーダー２；B　→　C　→　B　→　D
　　オーダー３；A　→　C　→　D　→　B
　　オーダー４；A　→　B　→　B　→　C
　４種を各１０枚ずつ用意する。
　　
　プレーヤーの役割を決める
　　１、オーダー投入係；司会者の合図でカードに投入日を記入し、次工程に回す
　　２、A工程担当；A工程を実施する（回ってきたカードのA欄に処理日を記入し、次工程に回す）
　　３、B工程担当；B工程を実施する（回ってきたカードのB欄に処理日を記入し、次工程に回す）
　　４、C工程担当；C工程を実施する（回ってきたカードのC欄に処理日を記入し、次工程に回す）
　　５、D工程担当；D工程を実施する（回ってきたカードのD欄に処理日を記入し、次工程に回す）
　　６、出荷係；全工程を完了したカードを受け取り、投入から処理完了までの日数を計算し記入する。集計グラフに結果をプロットする。
　　１の役割はA工程、６の役割はD工程が兼ねても良い。
　
　
　

◆ゲームの概要
　４０枚のジョブ オーダーを処理する。
　司会者の合図（◯日目、記入、パス）にあわせて、それぞれの工程を進める。

　各工程は１日に１つだけ処理する（１マスだけ記入する）。
　手元に複数枚のカードがあっても処理できるのは１つだけ。

　４０枚のジョブ オーダーがすべて出荷完了するまで続ける。

◆ゲーム１；毎日１オーダーを投入、先入れ先出しで処理する
　単純に毎日１枚づつ入れる。
　早く投入されたオーダーが早く出荷されるように、先入れ先出しで処理する。
　
　結果はグラフ１、２のようになる。

　グラフ１　
　


　
　
　グラフ２
　


　
　
　
◆ゲーム２；投入コントロール
　
　もっとも負荷の高い工程（B工程）に仕事がたまらないように投入をコントロールする。
　このゲームでは、B工程の処理待ち仕事の数をカウントする。
　司会者の合図（◯日目、記入、Bカウント、パス）にあわせて、それぞれの工程を進める。
　ゲーム２では、Bカウントの合図で進行中のオーダーカード（投入済みでまだ完了していないもの）すべての中に含まれる、未処理のB工程の数をカウントする。
　未処理のB工程の数が５以下であれば、次の日の投入を許可し、超えていれば次の日の投入をストップする。
　ストップするのは投入だけで、他のすべての工程はカードがある限り休まず実施する。

　結果はグラフ３，４のようになる。
　
　
　グラフ３
　


　
　
　
　グラフ４
　


　
　
　
　

◆投入コントロールの効果
　
　結果のグラフから明らかなように、投入コントロールを行うと、投入から作業を完了するまでの時間（リードタイム）が短くなり、かつ、ばらつきの少ない安定した状態になる。
　
　これは「システムの安定性が高い」状態といえる。
　システムが安定してれば、新しいオーダーが入ったときにそれをいつなら出荷可能であるかを高い精度で予測でき、自信を持って市場（顧客）に約束することができる。しかも、短いリードタイムで。

　システムの安定性が高いことは、新しいオーダーを受注する上で非常に重要な競合優位性である。
　
　また、一つ一つにオーダーが短い期間で完了するため、システム内に滞留するオーダーの数が少なく、混乱が起こりにくい。
　混乱なくスムーズに処理されることによって、品質が高まったり、コストが減ったりという良い効果が得られる。

　投入を遅らせることは、納期遅れのリスクを増やす印象があり躊躇しがちであるが、このゲームの結果ではすべてのオーダーが出荷完了した日数には変化がない。
　この理由は、処理能力に限界があるためいずれにしろ待ち時間が発生するのだが、その待ち時間をオーダー投入後にシステム内で発生させるか、それともオーダーを投入しないでシステム外で発生させるかの違いだけで、トータル日数に代わりがないからである。

　わざわざ早くシステム内に投入して混乱を起こすことは、現実の環境ではもっといろいろな悪影響があることは想像に難くないだろう。
　是非このゲームから得られる教訓を活かしたい。
　
　

※このゲームは、ワシントン大学のJames R. Holt教授が開発されたゲームです。
　少し前までWEB上でも本ゲームの詳しい解説書が公開されていたのですが、現在は残念ながら公開されていないようです
　いつの間にか復活してました。↓
http://public.wsu.edu/~engrmgmt/holt/em530/Docs/JSGInstinfo.htm