2011年3月25日(金)のプライベートセミナー『企業価値につなげるアジャイル開発～アジャイル開発の活用ポイント、要求開発とマネジメントの視点から～』の資料です。 講演者：ゴールシステムコンサルティング（株）チーフコンサルタント西原隆 様 http://sec.tky.esm.co.jp/2011/02/07/private_seminar18/

1. 企業価値につなげるアジャイル開発
アジャイル開発の活用ポイント、要求開発とマネジメントの視点から
TOC/CCPM
＋アジャイルで不確実性をマネジメントする
ゴールシステムコンサルティング（株）
チーフコンサルタント 西原隆
© Goal-System Consultanｔs.Inc.

2. ゴール・システム・コンサルティングのご紹介
弊社クラアント マスメディア等紹介事例
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 / 中小企業診断士

3. 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第３版にクリティカルチェーン法掲載

4. リスクの高いプロジェクトマネジメントの問題：計画場面
Task Management 成果物が明確にならない
分布
β分布 PMBOKでは、WBSを活用してスコープコ
ントロールする事を推奨しているが、リス
クの高いプロジェクトでは、何を作るのか
事前に明確にならない、また途中で変更
されるという事が多発する。よって計画段
階でWBSを確定するのは難しい
タスク時間見積が困難
PMBOKでは、３点見積もりといった確率
的なデータ分析方法を紹介しているが、リ
各メンバーが、秘密裏に、悲観値を考慮 スクの高いプロジェクトにおいて、タスク時
した安全余裕を計画するため、安全余裕 間見積もりは難しい。
が過大になる。納期に間に合わすため必
要な余裕までカットすることで現場にムリ
がかかる

5. ＴＯＣ（制約条件の理論）とは？
組織のゴール達成を決定づける制約条件に中心に改善を行い
最小の努力で最大の効果をあげる経営手法
鎖の強度＝ゴール（目標）
最も弱い環＝制約条件
© Goal-System Consultanｔs.Inc.
5

6. Wf° dKによるプロジェクトマネジメント（WD%
による
Task Management Buffer Management
分布
β分布
正規分布
各メンバーが、秘密裏に、悲観値を考 安全余裕は、集中させることにより中
慮した安全余裕を計画するため、安 心極限定理の効果が発生する事から
全余裕が過大になる。納期に間に合 、過大な安全余裕を持たなくても納期
わすため必要な余裕までカットするこ 遵守が可能になる
とで現場にムリがかかる

7. dKによるプロジェクトマネジメント（WD%
による
Task Management Buffer Management
Crashing
Crashing
週１回程度計画修正をおこなおうとす 週１回程度計画修正をおこなうとき、
ると、実施中の作業だけでなく、後続 バッファが残っている間は、実施中の
作業の計画見直しをしなければ、納 作業だけの見直しで容易に修正可能
期遅れする計画になってしまう になる

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

9. n dKによるプロジェクトマネジメント（WD%
による
Task Management Buffer Management
プロジェクトバッファ プロジェクトバッファ
なぜ全部 部長 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
進捗率(%)
進捗率(%)
リーダー・個人まかせの対策実施、全 組織的に対策を実施、バッファを共通
ては現場の負担に して浸食する原因は組織的な改善を

10. それぞれの役割を連携させて全体最適マネジメントをおこなう
【
Ｐ パイプラインマネジメント
Ｍ 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
】

11. ＰＬＡＮ：バッファを計画する：ネットワーク工程表作成
プレシデンスダイアグラムの作成 プロジェクト憲章
５day １７day
設計おこなう 調達をおこなう
O:目的
設計技術A 調達係
5day 1day
D:成果物
組立をおこなう 検査をおこなう
組立B 品質管理者
７day
加工をおこなう
加工A SC:成功基準
5day リスク
加工２をおこなう
加工A
ポイント：営業・商品企画・開発・技術などを参画させ部門間コミュニケーションを充実させる

12. バッファ・スケジューリング
Plan:バッファ・スケジューリング 山崩し
山崩し
プロジェクトチーム人数に対してオーバーしている計画を修正する
1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
設計をおこなう
調達をおこなう
組立をおこなう
加工作業をおこなう
加工２をおこなう
検査をおこなう
Goal：納品する
リスクの高い作業がある場合、優先的に前倒しする

13. バッファ・スケジューリング
Plan:バッファ・スケジューリング クリティカルチェーンの決定
クリティカルチェーンを決定する
納期を決定づけているタスクはどれか？
1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
設計をおこなう
調達をおこなう
組立をおこなう
加工作業をおこなう
加工２をおこなう
検査をおこなう
Goal：納品する

14. バッファ・スケジューリング
Plan:バッファ・スケジューリング プロジェクトバッファの計画
プロジェクトバッファ
各作業見積時間は５０％確率なので納期遅れの危険性がある
1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
設計をおこなう
調達をおこなう
組立をおこなう
加工をおこなう
検査をおこなう
プロジェクトバッファ
Goal納品する

15. Plan:バッファ・スケジューリング 合流バッファの計画
バッファ・スケジューリング
合流バッファを挿入する
クリティカルチェーンが遅れないよう保護する
1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
設計をおこなう
調達をおこなう
組立をおこなう
加工をおこなう
合流バッファ
検査をおこなう
プロジェクトバッファ
Goal納品する

16. ：実績を収集し計画を修正する
Do：実績を収集し計画を修正する
＜残日数収集 例＞
朝礼を活用して、残日数把握を
おこなう。このときあわせて、学生
症候群を排除するため、タスクの
遅れへの対処法を考える
ばらし、ポストイットでの見える化
をおこなう。この朝礼を続けるた
めには、短時間に終えることがポ
イント（１５分以内）。
立ったままおこなうといった工夫
が必要。 遅れへの対処法を実施
ポイント：プロジェクトリーダとメンバーのコミュニケーションを徹底し、バッファを無駄に
使わないよう進めていく

17. ：遅れをマネジメントし全体最適へ
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
進捗率(%) 進捗率(%)

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

19. バッファ管理により学習する組織へ
バッファを管理し学びながら最適化する
人・作業を計画して最適化する
不確実性への対処方法=バッファ
Plan Plan
タスクを計画す バッファを計画す
る る
Action Action
計画を修正する
バッファ回復策
Do を実施する Do
タスク実施状
況を把握する バッファ浸食を把
握する
Check
計画からの乖離を確認する Check
バッファ状況を確認する
複雑すぎて結果が不明。沢山のタスク・人を 学習する組織へ。バッファの結果を振り返る
管理しなければならないので書類ばかりだ 事により計画すべき
が多すぎて振り返られない バッファサイズを学習する

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