TOC/CCPMインプリメンターコースのメモ書き
今年の4月にTOC/CCPMインプリメンターコースなんてものを受講したのですが、そのときに某所に書いていたメモ書きを保存のためにアップします。もうあれから半年近くたつんだねえ。
なお、TOCやCCPMをあまりご存じない方には、言葉足らずでわかりにくい部分や、誤解を生みそうな書き方になっている部分もありますが、ご容赦ください。なんせメモ書きなので(^^;
- TOC(制約条件の理論)の3原則
- 組織には達成すべきゴールがある
- 組織はごく少数のことにより制約される
- 部分の合計は全体と一致しない
- TOCは、原則があるから、どのような分野にも応用できる。行き詰まったら、原則に立ち返ること。
- 組織(営利企業)の目的は、現在から将来にわたって儲け続けること。そのためには、3つの評価尺度であるT：スループット、I：在庫、OE：業務費用(いわゆる固定費)を改善しなければならない。
- 従来型の「改善」は以下の優先順位となっている。OEを減らすこと(コスト削減)はモニタしやすいため、優先順位が上がる。
- OE(業務費用)を減らす
- I(在庫)を減らす
- T(スループット)を増やす
- TPS(トヨタ生産方式)は、以下の順(諸説ありますが…という前置きあり)。
- I(在庫)を減らす
- T(スループット)を増やす
- OE(業務費用)を減らす
- TOCは、以下の順。ただし、「TOCはコスト削減を目指さない」ので、極力OEは減らさない。スループットを増やすことに集中する。
- T(スループット)を増やす
- I(在庫)を減らす
- OE(業務費用)を減らす
- I(在庫)を減らすことと、OE(業務費用)を減らすことには限界がある(0以下にすることはできない)。ところが、T(スループット)を増やすことには限界がない。よって、現在から将来にわたって儲け続けるためには、スループットを改善し続ける必要がある。
- 全体のスループットは、ごく少数の制約条件(＝ボトルネック)によって決まる。よって、スループットを改善するためには、制約条件を集中して解決していく必要がある。
- ボトルネックは「悪」ではない。それがボトルネックだという事実があるだけ。むしろ、ボトルネックによって全体のスループットが決まるため、その組織の強みを決めるコア・コンピタンスであると言える(ただし、制約が物理制約の場合)。
- 組織のボトルネックを突き止めていくと、ほとんどの場合は物理制約や市場制約(供給＞需要の場合)ではなく、方針制約になる。間違った方針の上で組織を運営しているため、現在から将来にわたって儲け続けることができない。これを解決するための手法がTOC思考プロセス。
- 一般的なスケジューリングは、「いつ」「だれが」「なにを」やるかを決める。CCPMは、「いつ」やるかは決めない。
- 目標不達の原因は2つ。変動性と従属性。
- 投入を制約に従属させると、スループットはあがるが、ボトルネック以外の部分的な稼働率は下がる。評価基準が個別の稼働率にあると、個々が稼働率を上げるためにがんばってしまう。そうすると、全体のスループットはあがらないどころか、むしろ悪くなってしまう。個別の稼働率によって評価するという今までのやり方から、全体のスループットに注目するように考え方を変えないといけない(パラダイムシフト重要！)。
- 組織の目的は何か？スループットをあげると稼働率が下がるのであれば、稼働率が下がることは受け入れなければならない。
- プロジェクトにおいて、投入はキックオフ。どんどん投入することは、「早く納めたいから早くキックオフする」こと。しかし、早く始めたからといって早く終わるとは限らない。
- PMBOKのスケジューリングの定義は、EPST(なるはや)とLPST(なるおそ)の2つがある。CCPMはLPST(なるおそ)を使う。ちなみに、EPST(なるはや)にはいい点はない、そうだ。
- タスクを進捗率で表しても、本当にどれだけ進んでいるかはわからない。"進捗率"で計るのは、コストを計るため(EVMSなどに必要)。
- クリティカルチェーンとクリティカルパスの違いは、リソースの山崩しをするか否か。といっても、最新のPMBOKではクリティカルパスの定義がクリティカルチェーンと同じになったので、現在は名前が違うだけ。
- 企業の活動は、目的(＝将来にわたって儲け続ける＝TIOEを改善し続ける)につながっていないといけない。
- TOCは、ごく少数の制約に向かって集中して解決していく。
- 部分の合計は全体にならない。変動性と従属性があるから、理論値よりも低い能力だけしか出ない。
- 変動性と従属性によって生じる誤差の部分は、ゆとり(バッファ)を持つ。CCPMでは、各タスクの進捗を管理するのではなく、このバッファをマネジメントする。
- 「バッファを持つ」は聞こえが悪く、経営者側からとられてしまう(バッファを持てるんだったらその分早く仕上げろ！とか)。しかし、バッファは開発者を守るのではない。お客様を納期遅れから守るもの。そこを間違ってはいけない。
- 改善の5ステップの「制約条件に従属させる」と、制約より前の行程の"稼働率が下がる"。現場の人は、稼働率で評価されているため、もっと仕事をくれ！という。これが方針制約になる。つまり、稼働率を上げると全体のスループットがあがるという間違った思いこみによって、全体のスループットは下がってしまう。
- 効率よく仕事をさせる、人を遊ばせないようにうまく活用することが、マネージャーの役割、ってホント？
- これを数値を表すと、"稼働率を上げる"ことになる。これは、本当に目的にあっているのか？
- 人は遊ばせても、プロジェクトは遊ばせない。プロジェクトは遊ばせないために、人を遊ばせることが必要であれば、それを受け入れなければならない。
- お客様は、人に対してお金を払うのではない。できたもの(バリュー)に対してお金を払っている。
- CCPMでは、お客様の納期をバッファ(プロジェクトバッファ＝時間のゆとり)と保護能力(キャパシティバッファ＝能力のゆとり)を活用して守る。
- TOC思考プロセスは、「人は変化に抵抗する」ことを前提にして、合意形成をする。
- 変化に抵抗する6段階を、TOC思考プロセスの5つのツリー(現状問題構造ツリー/雲(対立解消図)/未来問題構造ツリー/前提条件ツリー/移行ツリー)で解決する。
- 変化に抵抗する6段階とは、
- 抵抗1:対応しようとしている問題を、問題として認めない
- 抵抗2:ソリューションの方向性に同意できない
- 抵抗3:ソリューションが問題を解決するとは思わない
- 抵抗4:このソリューションは、もし実行すると、マイナスの影響を引き起こしてしまう
- 抵抗5:提案されているソリューションの実行を妨げる障害がある
- 抵抗6:その結果起こる未知のことへの恐怖感
- 問題とは「対立」であり、対立が根本原因を招く。
- 一般的には対立に対して妥協の道を探ろうとするが、自然科学では妥協はしない。なぜなら、自然科学では現実には対立は存在せず、間違った前提条件があるために対立となって現れていると考えるから。間違った前提条件を改めれば、対立は解消する。
- TOC思考プロセス(の対立解消図)では、問題を対立ととらえて、対立に対する間違った前提条件を解消することで、WIN-WINの解決策を得る。
