導入事例で学ぶTOC/CCPMセミナーに参加しました

概要

ゴール・システム・コンサルティングさん主催のプロジェクト管理手法CCPMの導入セミナーである導入事例で学ぶTOC/CCPMセミナーに参加しました。 コンサルティング事例の紹介ということで2名の講師の方が、合計4つの現場で導入した事例に対して紹介するものでした。 本記事では、SlideShareにアップされている同社の資料であるGsc ccpm2013から引用しながら、CCPMの概要をロールごとに整理します。

当日の講師、ゴール・システム・コンサルティングの西原さんのTOC/CCPMの書籍はこちら。

内容

開発期間の重要性

CCPMは期間を縮めるために役立つツールであることから、最初に開発期間の重要についての説明があった。

ハーバードビジネスレビューの「いかにプロジェクトを成功させるか」にもあるように、 製品開発が6ヶ月遅れる事で失う利益は平均33%、しかし50%のコストを余分に追加したときに失う利益は3.5%。 なので、製品開発を進める上で開発時間を短縮することには大きな価値がある。

大型テレビを例に考えると、発売時には20万円で発売できても、競合との兼ね合いで半年ほどで10万円まで値下がりすることがある。 そのため、半年間サービスの提供が遅れることは、利益に対して大きく損失があることは明白である。

CCPMの位置付け

TOCの「組織のゴール達成を決定づける制約条件にフォーアスした改善を行い、最小の努力で最大の効果をあげる経営手法」のうち、 「計画のリスク」と「合意形成の不確実性」の2つに分解し、「計画のリスク」を軽減するものがCCPM。 「計画のリスク」のための方法には、DBR(ドラム・バッファ・ループ),DBM(ダイナミック・バッファ・マネジメント)もある。 「合意形成の不確実性」のための方法には、「TOC思考プロセス」がある。

TOCによるプロジェクトマネジメント

TOCによるプロジェクトマネジメントとして、3つの層に分けて役割の紹介があった。 役割をマネジメント層、リーダ層、メンバー層に分割し、考えることの違いについて紹介があった。

メンバ層、プロジェクトに取り組む。 バッファを無駄に消費しないように、1週間などの短い期間で、計画作成、デイリーミーティング、振り返りを行い、 自立的な改善を促す体制を構築。

リーダ層は、単一プロジェクトのマネジメントを行う。 納期直前に配したバッファを中心にマネジメントのサイクルを回し、納期厳守と期間短縮を行なう

マネジメント層は、複数プロジェクトのマネジメントを行なう。 納期設定などを整備したり、進捗状況と納期遅延リスクを確認し、リスクが高いものに対するリソースの追加、投入量の対策を実施する。

以上の説明が中盤にあったが、先に理解して、どの部分の説明か意識して頭に入れる方が有用だと感じたため、ここに残す。

引用:Gsc ccpm2013

メンバ層

メンバ層としてプロジェクトに取り組む場合には、 学生症候群・マルチタスキング、早期完了の未報告などで、バッファを無駄に消費しないようにする。 タスクの見える化やコミュニケーション強化、ふりかえりで自己組織化する。

リーダ層

リーダ層として単一プロジェクトのマネジメントを行う方法をPDCAで確認する。

最初に、PDCAのPlanとしてバッファのスケジューリングを行う。 まず、ネットワーク工程表を作成する。 そして、山崩しによってリスクの高い作業を優先的に前倒しすることで計画を修正する。 次に、納期を決定付けているクリティカルチェーンを決定する。 最後にバッファを挿入する。 50%の確率で遅延するので全作業のプロジェクトバッファを挿入し、 合流バッファを入れることで合流時にクリティカルチェーンに遅れを出さないようにする。

次に、PDCAのDoとしてプロジェクトを進めながら適時計画を修正する。 このDoは、メンバ層の活動である。

次に、PDCAのCheckとして、バッファの傾向グラフを作成しプロジェクトの進み方を確認する。 左上ほど危険で右下ほど安全な状態である。 しかし、バッファを消費せずに上に移動せずに横にだけ進んでいるのはバッファを確保しすぎた場合で良くない。 右に進まずに上にだけ進んでいるのは大きな問題が発生していることを表わしている。 引用:Gsc ccpm2013

最後にPDCAのActionで応急処置の検討を考える。 スコープ(スコープの削減)、品質(品質過剰の確認)、資源(リソースの増加)、時間(納期の変更)、 マネジメント(計画見直しなど)において何かしらの対策を考える。 対策を考える場合には、思考プロセスを用いて問題を解決する。

マネジメント層

マネジメント層として複数プロジェクトのマネジメントを行う方法をPDCAで確認する。

PDCAのPlanとしてプロジェクトの開始タイミングで、リソースの投入調整を行う。 ドラムとキャパシティバッファの計画を行なう。

PDCAのDoとしての期間に各プロジェクトチームがプロジェクトを進行する。 この期間バッファが残っている間は実施中の作業の見直しで計画を修正する

PDCAのCheckとして、複数プロジェクトのバッファ傾向の可視化を行う。 以下の図のように、複数のプロジェクトのバッファ傾向グラフの現状を1つグラフに マッピングすることで、複数のプロジェクトの進捗率とバッファの消費率を人目で見られる。

引用:Gsc ccpm2013

最後にPDCAのActionで組織的に対策する。 バッファを共通して侵食している問題の改善を行なう。

まとめ

セミナーで各レイヤーがいつ何をすべきかまとめることで理解が深まった。

自分としては、人に説明する場合には、トップダウンのマネジメント層が何をするかよりも、 ボトムアップで現場レベルで何をするかを説明する方が分かりやすいと思った。 理由としては、マネジメント層で出てくる複数バッファ傾向のマッピングは、 チームレベルでバッファマネジメントをした成果であり、マネジメント層の話をするときには登場していないからである。

今後、活用する場合には、マネジメント層、リーダ層など対象に応じて資料を作成するのが良いと思った。