なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine
製造業の管理職、経営者と話していると、彼らはTOCやCCPMが大好きだ。
確かに、TOCの発想はアジャイル開発にも通じるし、TOCの考え方は生産効率の向上にも使える。
CCPMの考え方も、ガントチャートの工程管理では有用だ。
しかし、実際の現場でTOCやCCPMを使おうとすると、ほとんど失敗する。
教科書通りの運用がとても難しい。
そこで、なぜ製造業の経営者はTOCやCCPMが大好きなのか、考えてみた。
ラフなメモ書き。
【参考】
Amazon.co.jp: TOC/CCPM標準ハンドブック クリティカルチェーン・プロジェクトマネジメント入門 : 西原 隆, 栗山 潤: 本
Project Management進化論 クリティカルチェーン・プロジェクトマネジメント | 後藤 智博, 渡瀬 智, 西郷 智史 |本 | 通販 | Amazon
最短で達成する 全体最適のプロジェクトマネジメント | 岸良裕司 |本 | 通販 | Amazon
【1】なぜ製造業の経営者はTOCやCCPMが大好きなのか?
理由は2つある。
1つは、ボトルネック工程を見つける発想が製造業の工程管理と相性が良いこと。
もう1つは、CCPMのフィーバーチャート分析を使えば、事業部内の全ての案件からバッファを集めてマネジメントバッファに集約することで、事業部内の要員管理に役立つことだ。
前者については当たり前だろう。
後者について考えてみる。
【2】TOCの理論を実際の現場でPJ管理に使おうとする場合、CCPMを適用することになる。
では、CCPMの本質とは一体何だろうか?
CCPMの本質は全てのタスクの残工数、つまりバッファをPJバッファに集約し、プロマネが一括管理して、PJ管理の進捗をコントロールする点にある。
CCPMでは、各タスクを見積もった時、各タスクの予定工数からバッファをバッサリ切り捨てて短縮する。
教科書では、各タスクが予定通りに終わる確率が50%になるまで、予定工数をバッサリ切り捨てる。
各タスクのバッファはPJバッファとして一括集約し、プロマネが管理する。
プロマネは、各タスクが遅れたら、PJバッファから余った工数を渡して、本来の予定工数通りに終了させる。
もちろん、各タスクがバッサリ切り捨てた予定工数で完了できれば、問題ない。
むしろ、担当者がサバを読んで見積もりを膨らませたことになるだろう。
プロマネは、PJバッファの出し入れを管理することで、PJの進捗管理を行う。
プロマネは、時系列でPJバッファ消費度合いを見ることで、PJのリスクを管理することになる。
そこで、フィーバーチャートを使って、PJが危険な領域に入ったか否かを定量的に判断する。
フィーバーチャート分析では、PJ進捗率xPJバッファ消費率のグラフを見て、PJ消費率が異常に高すぎるゾーンに入ると危険とみなし、早めに対策を打つべきだ、という意思決定に使う。
大抵の案件では、仕様変更や手戻り作業で当初の予定よりも遅延する場合が多いので、PJバッファをどんどん消費してしまう。
もちろん、PJバッファを全て使い切れば、予算オーバーの案件になる。
ここまでは、CCPMは一般的なPJ管理の手法だ。
CCPMがすごい点は、複数の案件の現状をフィーバーチャートにプロットし、その経緯をグラフ化することで、複数の案件管理を横串で意思決定できる点だ。
つまり、事業部内の全ての案件のPJバッファを集約することで、PJバッファをマネジメントバッファとみなし、事業部内の余裕リソースをどの案件に割り当てればよいか、という意思決定に使える。
ここで、
事業部内のマネジメントバッファ=ΣPJバッファ=ΣPJの各タスクの予定工数
より、
事業部が持つマネジメントバッファ費用=ΣPJの各タスクの予定工数x人月単価
になる。
一般に、事業部が持つマネジメントバッファ費用は、製造業ならば当初予算からリスク費用として取り出し、別で保持しているだろう。
一般に、リスク費用は、どこかの案件で赤字になってリカバリーする場合や、戦略的な案件に投資として使いたい場合などに使うだろう
よって、事業部が持つマネジメントバッファ費用、つまりリスク費用は、事業部長が戦略的意思決定で用いるお金に相当する。
このリスク費は、事業部長という強力な権力を持つ人だけが使える「へそくり」みたいなものだ。
へそくりであるからには、むやみやたらに使うべきではなく、大事な状況で使うべきだ。
それが、事業部長の戦略的意思決定に相当する。
すなわち、CCPMを事業部内の案件管理で使いたい欲求は、事業部長がリスク費用を事業部内の要員管理として意思決定する時に、定量的な根拠して使えるからだろう。
【3】しかし、CCPMの運用はExcelでやるのは事実上無理だ。
まず、残工数を入力する運用は現場で浸透させづらい。
残工数を把握するには、タスクの予定工数を見積もる能力、実績工数を入力する運用がセットになる。
そもそも、正確に見積もり工数を出せる担当者は少ない。
また、各タスクの実績工数を入力させる運用は、現場では非常に面倒だ。
1日のタスクは10個以上に及ぶときもあるから、勤怠時間と照合させようとすると破綻する。
次に、案件にある各タスクの残工数を収集し、PJバッファに集めて、PJバッファ消費率を追跡する処理は実装しづらいからだ。
Excelではフィーバーチャートをプロットするのは非常に難しい。
データを1個のシートに集めればフィーバーチャートを描けるだろうが、綺麗に出力しようとすると、Excelマクロを駆使することになるだろう。
本気でやれば、ExcelマクロでCCPMツールを自作するくらいのレベルになるだろう。
よって、CCPM専用の管理ツールをパッケージ製品やSaaSで利用することになるだろう。
しかし、CCPM専用の管理ツールは非常に高価であり、UIがダサくて使いづらいツールが多い。
肝心のガントチャート画面で操作がモッサリしていたり、WBS詳細化する操作が使いづらかったり、WBSの属性を登録する手間が多すぎたりして、使いづらいケースが多い。
結局、CCPMは教科書ではすごいけれども、実際の現場では使えないね、という結論になる。
【4】一方、CCPMを運用するツールの一つとして、LycheeRedmineのCCPMプラグインは使いやすいツールだろうと考える。
なぜならば、Redmineのチケット入力機能を上手く流用することで、CCPMが持つ複雑さを和らげて、CCPMを運用しやすくしているからだ。
CCPMツールならLychee Redmine|フィーバーチャートでバッファ消費率を自動で可視化
LycheeRedmineでは、CCPMを運用したい時に上手く工夫されている機能がある。
たとえば、残工数を入力するIFとしては、チケット属性の「残工数(Lychee)」になる。
チケット属性の「残工数(Lychee)」に入力すれば、各タスクの残工数を把握できる。
LycheeRedmineでは、Redmine標準の予定工数・実績工数の機能を流用し、残工数を集めて、フィーバーチャートへ自動集計してくれる。
LycheeRedmineのCCPM設定画面では、「日次バッチでフィーバーチャート分析する」設定をONにすれば、日々でフィーバーチャートをプロットしてくれる。
LycheeRedmineのCCPM設定画面では、PJバッファをPJからどれくらい集めるかを設定する機能、フィーバーチャートの危険・警告・正常領域の閾値を設定する機能があるので、色々カスタマイズできる。
さらに、バージョンごとにPJバッファを登録する機能があるので、たとえば、各工程ごとにバッファを設けて、バッファ消費率を追跡する運用も可能だ。
フィーバーチャートを出せれば、プロマネはPJリスクを定量的に意思決定できるようになる。
これがやりたいことだ。
ただし、CCPM運用の前提は、作業者がチケットの残工数を毎日入力する運用を徹底できていることだ。
そこさえクリアできれば、教科書でしか運用できなかったCCPMが、Redmineの優れたチケット管理を使って簡単に運用できるようになる。
【5】そんなことを思うと、LycheeRedmineは非常に優れたツールだと思う。
なぜならば、Redmine標準の優れたチケット管理機能を流用して、CCPM運用をよく考えて機能実装できているからだ。
LycheeRedmineでは他にも、Scrumに特化した機能、つまり、カンバンやバックログもあるので、Scrumも運用可能だ。
Lychee Redmine、アジャイル開発向け新機能「Neoカンバン」をリリース| 株式会社アジャイルウェア
すなわち、LycheeRedmineを使えば、各PJでテーラリングすることで、CCPMをやるPJもあれば、ScrumをやるPJも併存して運用可能だ。
これはすごいことだと思う。
【6】LycheeRedmineの機能については、別記事で詳しく解剖してみたいと思う。
| 固定リンク
« 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁 | トップページ | Redmineのバージョンはなぜ使われないのか? »
「プロジェクトマネジメント」カテゴリの記事
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
- 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁(2026.06.27)
- Redmine × AIがプロジェクト管理を変える:祝・Redmine20周年!RedmineJapan Vol.5の司会を全うして見えた「AI連携」と「製造業マネジメント」の未来 #RedmineJapan(2026.06.27)
- プロセスには「学習のループ」が必要だ(2026.06.20)
- JTCの壁を壊す「Redmine参謀本部」という戦略~現場の職人気質を活かす組織論(2026.05.19)
「Redmine」カテゴリの記事
- Redmineのバージョンはなぜ使われないのか?(2026.07.08)
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
- 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁(2026.06.27)
- Redmine × AIがプロジェクト管理を変える:祝・Redmine20周年!RedmineJapan Vol.5の司会を全うして見えた「AI連携」と「製造業マネジメント」の未来 #RedmineJapan(2026.06.27)
- JTCの壁を壊す「Redmine参謀本部」という戦略~現場の職人気質を活かす組織論(2026.05.19)
「ソフトウェア工学」カテゴリの記事
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
- 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁(2026.06.27)
- Redmine × AIがプロジェクト管理を変える:祝・Redmine20周年!RedmineJapan Vol.5の司会を全うして見えた「AI連携」と「製造業マネジメント」の未来 #RedmineJapan(2026.06.27)
- プロセスには「学習のループ」が必要だ(2026.06.20)
- JTCの壁を壊す「Redmine参謀本部」という戦略~現場の職人気質を活かす組織論(2026.05.19)
「チケット駆動開発」カテゴリの記事
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
- 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁(2026.06.27)
- マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet(2026.04.26)
- 第29回東京Redmine勉強会の感想~今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet(2025.11.09)
- RedmineJapan vol.4の感想part1~Redmine AI HeplerプラグインはRedmineのナレッジ活用を強化してくれる #RedmineJapan(2025.07.31)


コメント