TOC/CCPM＋アジャイルで不確実性をマネジメントする

企業価値につなげるアジャイル開発
アジャイル開発の活用ポイント、要求開発とマネジメントの視点から

TOC/CCPM
＋アジャイルで不確実性をマネジメントする

ゴールシステムコンサルティング（株）
チーフコンサルタント西原隆

© Goal-System Consultanｔs.Inc.

ゴール・システム・コンサルティングのご紹介

弊社クラアントマスメディア等紹介事例
TOCに関する日本随一ともいえる豊富な実績とノウ
ハウを活かすべく、 2002年秋ゴールシステムコンサ
ルティングはその産声を上げました。日経情報ストラテジー 2009年5月号
「成果を出す業務改善の現場」
私たちの使命は、継続的にTOCに基づく現実的な問・日本特殊陶業株式会社（TOC全ツール適用）
題解決策を提供し、お客様に短期間で、現実のビジ
ネス上の利益を得て頂く事です。私たちのソリューシ日経情報ストラテジー 2008年9月号
「改革手法ウォッチング CCPM」
ョンは、どのような産業・業種にも適用可能であり、お・オリンパス株式会社（TOC/CCPM導入）
客様の戦略的な目的を達成するための継続的改善「問題の掘り下げ力を鍛えよ！」
・日立ツール株式会社（TOC思考プロセス事例紹介）
プロセス（POOGI）をサポートするものです。
経営コンサルティング、セミナーや教育、社員研修と日経情報ストラテジー 2005年8月号
「迷走する業務改善の現場・見えてきた突破口」
いったコンサルタント派遣事業のみならず、システム・コガネイ株式会社（TOC全ツール適用）
導入支援まで、お客様の経営成果をトータルでサポ・日立ツール株式会社（TOC全ツール適用）
・株式会社砂子組（TOC/CCPM導入）等
ートいたします。
在庫ゼロリードタイム半減プロジェクト弊社村上、石田執
【プレゼンター】
プレゼンター】筆
・日立ツール株式会社（TOC/DBR導入）
西原隆（Takashi Nishihara）・セイコーエプソン株式会社（TOC/DBR導入）
・日立金属株式会社（TOC/DBR導入）
nishihara@goal-consulting.com ビデオ：わかりやすいTOC実践教室（PHP総合研究所）
ゴール･システム･コンサルティング株式会社・日立ツール株式会社（TOC/DBR導入）
・セイコーエプソン株式会社（TOC/DBR導入）
チーフコンサルタント兼マーケティンググループリーダー
２００３年ゴール・システム・コンサルティングに入社。米国ＴＯＣファーム・北越パッケージ株式会社（TOCセールス・マーケティング）
ベクターストラテジー社（当時）のイレーン・フロスト、ロジャー・モリソンから http://business.nikkeibp.co.jp/article/topics/20090319/150569/
ＴＯＣ導入方法に関する教育をうけ、その後国内大手メーカー、ＩＴ、建設業・オリンパスイメージング株式会社（TOC/CCPM導入）
などでのＴＯＣ導入コンサルティングに従事。 http://business.nikkeibp.co.jp/article/topics/20090820/168382/
TOCのプロジェクトマネジメント手法「CCPM」に関する豊富な理論的知識・株式会社丸五技研（TOCセールス・マーケティング）
http://business.nikkeibp.co.jp/article/topics/20090515/194874/
および実践スキルを持ち、インプリメンテーションの経験は日本随一である。
また、ファシリテーションに精通しており、現場スタッフのモチベーションを
向上させる技術には定評がある。 TOC-CCPM（www.toc-ccpm.net/jirei/index.html）
・執筆協力：問題解決を「見える化」する本（中経出版）・株式会社リコー／株式会社五星／ソラン株式会社
（いずれもTOC/CCPM導入）
・＠IT-monoist TOC流の開発型プロジェクト管理術『CCPM』連載
有資格：TOC-ICO Jonah / 中小企業診断士

TOC（制約条件の理論）発展の歴史

‘70年代：ゴールドラット博士がスケジューリング手法を開発
‘80年代前半：スケジューラーソフト(OPT)が米国で一躍有名に
OPTの背後のコンセプトを小説として発表
‘The Goal’ は四百万部以上の超ベストセラーに
博士がソフトウェアに疑問を
OPT導入よりThe Goalで改善した方が効果あり
１９９０ヘイスタックシンドローム発刊 Eliyahu Goldratt
博士はOPT販売会社を退職AGIを設立
The Goalで説明した手法の教育に専念
制約理論に基づく原価管理手法を開発
TOC思考プロセス（ＴＰ）の開発
変化に対する抵抗の問題
市場の制約条件の問題
方針的制約条件の問題
‘94：TPを小説として発表(It‘s Not Luck）
‘97：プロジェクト管理（Critical Chain）を発表
02: バイアブルビジョン発表
04: 戦略戦術ツリー（S&T）発表
04： PMBOK第３版にクリティカルチェーン法掲載

リスクの高いプロジェクトマネジメントの問題：計画場面

Task Management 成果物が明確にならない

分布
β分布 PMBOKでは、WBSを活用してスコープコ
ントロールする事を推奨しているが、リス
クの高いプロジェクトでは、何を作るのか
事前に明確にならない、また途中で変更
されるという事が多発する。よって計画段
階でWBSを確定するのは難しい

タスク時間見積が困難

PMBOKでは、３点見積もりといった確率
的なデータ分析方法を紹介しているが、リ
各メンバーが、秘密裏に、悲観値を考慮スクの高いプロジェクトにおいて、タスク時
した安全余裕を計画するため、安全余裕間見積もりは難しい。
が過大になる。納期に間に合わすため必
要な余裕までカットすることで現場にムリ
がかかる

ＴＯＣ（制約条件の理論）とは？
組織のゴール達成を決定づける制約条件に中心に改善を行い
最小の努力で最大の効果をあげる経営手法

鎖の強度＝ゴール（目標）

最も弱い環＝制約条件

© Goal-System Consultanｔs.Inc.
5

Wf° dKによるプロジェクトマネジメント（WD%
による
Task Management Buffer Management
分布
β分布
正規分布

各メンバーが、秘密裏に、悲観値を考安全余裕は、集中させることにより中
慮した安全余裕を計画するため、安心極限定理の効果が発生する事から
全余裕が過大になる。納期に間に合、過大な安全余裕を持たなくても納期
わすため必要な余裕までカットするこ遵守が可能になる
とで現場にムリがかかる

dKによるプロジェクトマネジメント（WD%
による


Crashing
Crashing

週１回程度計画修正をおこなおうとす週１回程度計画修正をおこなうとき、
ると、実施中の作業だけでなく、後続バッファが残っている間は、実施中の
作業の計画見直しをしなければ、納作業だけの見直しで容易に修正可能
期遅れする計画になってしまうになる

：による
n：dKによるプロジェクトマネジメント（WD%
100
90
Project E

←
80
70
バ Project F
ッ 60
フ 50
Project A
ァ 40 Project C
消
費 30 Project B
率 20
10
0
0 10 20 30 40 50 60 70 80 90 100

プロジェクト進捗率 →
ProjectB ProjectE

リーダーごとに様々な見える化をおこなっバッファ消費量とプロジェクト進捗率、及
ている。進捗報告資料は多いが、マネーび組織としての対策基準をあらわした標
ジャーからみると要するに間に合うのかど準化されたバッファ傾向グラフによって一目
うか不明確で現状が把握できるようになる

n dKによるプロジェクトマネジメント（WD%
による

プロジェクトバッファプロジェクトバッファ

なぜ全部部長 100

90
100

90

のプロジェ
80 80

70 70

バッファ消費率(%)
60 60

クトが遅れ 50 50

40 40

30
30

ているのだ Project-A Prject-B
20
20

10

0
プロジェクトA 10

0

！！気合
気合
0 10 20 30 40 50 60 70 80 90 100
0 10 20 30 40 50 60 70 80 90 100
進捗率(%)
進捗率(%)

いがたりん部長に
！！は内
プロジェクトA
初緒だが
め相当
から余裕
ムリがある
プロジェクトC ぞ。テーマAとCはBを助けられんかね？
な遅れ原因に改善すべき共通性は？
計プロジェクトB
画
なんマジちょっとヤバくな 100
プロジェクトバッファ

100

ってきた。進捗会議ど
90

だよ
90
80
80
70

うごまかそう
70

60

・・・プロジェクトD 50
60

50

40 40

30 30

20

10
Project-C 20

10 Project-D
0
0
0 10 20 30 40 50 60 70 80 90 100
0 10 20 30 40 50 60 70 80 90 100
進捗率(%)
進捗率(%)

リーダー・個人まかせの対策実施、全組織的に対策を実施、バッファを共通
ては現場の負担にして浸食する原因は組織的な改善を

それぞれの役割を連携させて全体最適マネジメントをおこなう
【
Ｐパイプラインマネジメント
Ｍ Plan
Ｏ売上計画・投入計画からキャパシティ確 Action
／認・対策実施
マ
ネ
ー
ジ Do
ャ Check
ー
】

【
プバッファマネジメント
ロ Plan
ジ各プロジェクトのバッファマネジメントをおこなう
Action
ェ 100
（対策実施）

ク 90

80 （対策検討）

ト 70

リ 60

50

ー 40

ダ
30
Do
20 Check
ー 10
（そのまま）

】
0
0 10 20 30 40 50 60 70 80 90 100

【
リチームマネジメント
ー Plan
ダチームファシリテーションによる自律的なチーム運営 Action
ー
・
メ
ン
バ Do
ー Check
】

ＰＬＡＮ：バッファを計画する：ネットワーク工程表作成

プレシデンスダイアグラムの作成プロジェクト憲章

５day １７day
設計おこなう調達をおこなう
O:目的
設計技術A 調達係

5day 1day
D:成果物
組立をおこなう検査をおこなう
組立B 品質管理者
７day
加工をおこなう
加工A SC:成功基準

5day リスク
加工２をおこなう
加工A

ポイント：営業・商品企画・開発・技術などを参画させ部門間コミュニケーションを充実させる

バッファ・スケジューリング
Plan:バッファ・スケジューリング山崩し

山崩し
プロジェクトチーム人数に対してオーバーしている計画を修正する

1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月

設計をおこなう

調達をおこなう

組立をおこなう

加工作業をおこなう


検査をおこなう

Goal：納品する

リスクの高い作業がある場合、優先的に前倒しする

Plan:バッファ・スケジューリングクリティカルチェーンの決定

クリティカルチェーンを決定する
納期を決定づけているタスクはどれか？

1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月




加工作業をおこなう



Goal：納品する

Plan:バッファ・スケジューリングプロジェクトバッファの計画

各作業見積時間は５０％確率なので納期遅れの危険性がある

1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月







Goal納品する

Plan:バッファ・スケジューリング合流バッファの計画

合流バッファを挿入する
クリティカルチェーンが遅れないよう保護する

1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月





合流バッファ



Goal納品する

：実績を収集し計画を修正する
Do：実績を収集し計画を修正する

＜残日数収集例＞
朝礼を活用して、残日数把握を
おこなう。このときあわせて、学生
症候群を排除するため、タスクの
遅れへの対処法を考える
ばらし、ポストイットでの見える化
をおこなう。この朝礼を続けるた
めには、短時間に終えることがポ
イント（１５分以内）。
立ったままおこなうといった工夫
が必要。遅れへの対処法を実施

ポイント：プロジェクトリーダとメンバーのコミュニケーションを徹底し、バッファを無駄に
使わないよう進めていく

：遅れをマネジメントし全体最適へ
Check：遅れをマネジメントし全体最適へ
プロジェクトバッファプロジェクトバッファ

100 100

90
プロジェクトA
プロジェクト 90 プロジェクトB
プロジェクト
80 80

70 70


60 60

50 50

40
40
30
30
20
20
10
10
100
0
0 90
プロジェクトAとCはプロ
0 10 20 30 40 50 60 70 80 90 100
0 10 20 30 40 50 60 70 80 90 100 Project E
80 進捗率(%)
進捗率(%)

ジェクトBを助けられん 70
60
Project F

かね？プロジェクトバッファ
50
Project A
40 Project C
100 30 Project B プロジェクトバッファ

90 20
100
10
80
プロジェクトC
プロジェクト 0
90
プロジェクトD
プロジェクト
70 80
0 10 20 30 40 50 60 70 80 90 100

60 70

50 60

50
40
40
30
30
20
20
10
10
0
0
0 10 20 30 40 50 60 70 80 90 100 0 10 20 30 40 50 60 70 80 90 100
進捗率(%) 進捗率(%)

：改善の３つのレベル
Action：改善の３つのレベル

第１段階：応急対策（結果を改善する）
製品自体にまつわる問題や、サービスを提供するときに起こる問題をただちに取り除く
第２段階：プロセスを改善する
問題の発生を許したプロセスを変える。再発防止の方法を開発する
第３段階：システムを改善する
欠陥製品やサービスを生んでしまった欠陥プロセスを作り出すようなシステム自体を改
善する（そもそも欠陥のあるプロセスがどうして放置されていたのか？対立はないか？
方針制約はないか？）出展：「第４世代の品質経営」ブライアンジョイナー

なぜ急激に
遅れているの
か？

バッファ管理により学習する組織へ

バッファを管理し学びながら最適化する
人・作業を計画して最適化する
不確実性への対処方法=バッファ

Plan Plan
タスクを計画すバッファを計画す
るる

Action Action
計画を修正する
バッファ回復策
Do を実施する Do
タスク実施状
況を把握するバッファ浸食を把
握する
Check
計画からの乖離を確認する Check
バッファ状況を確認する

複雑すぎて結果が不明。沢山のタスク・人を学習する組織へ。バッファの結果を振り返る
管理しなければならないので書類ばかりだ事により計画すべき
が多すぎて振り返られないバッファサイズを学習する

パッケージソフトウェア開発事例
（アジャイル＋CCPM）

事例についてのスライドは非公開とさせて
いただいております。
事例内容に関するお問い合わせは、ゴー
ル・システム・コンサルティング西原まで引用：TOC/CCPM
nishihara@goal-consulting.com
標準ハンドブック

20

TOC/CCPM＋アジャイルで不確実性をマネジメントする

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à TOC/CCPM＋アジャイルで不確実性をマネジメントする

Similaire à TOC/CCPM＋アジャイルで不確実性をマネジメントする (20)

Plus de ESM SEC

Plus de ESM SEC (20)

Dernier

Dernier (9)

TOC/CCPM＋アジャイルで不確実性をマネジメントする