1 - Tomoki Katayama(FWEST)_26 TOCPA_Japan_19 May 2016_Jp

8/16/2019 1 - Tomoki Katayama(FWEST)_26 TOCPA_Japan_19 May 2016_Jp

http://slidepdf.com/reader/full/1-tomoki-katayamafwest26-tocpajapan19-may-2016jp 1/28

26th International Conference of the

TOC Practitioners Alliance - TOCPA

www.tocpractice.com 19-20 May 2016 !"#"o#a $apan

大規模ITプロジェクトへのCCPM適用CCPM implementation into big IT project

片山片山片山片山知樹知樹知樹知樹

株式会社富士通システムズ・ウエスト株式会社富士通システムズ・ウエスト株式会社富士通システムズ・ウエスト株式会社富士通システムズ・ウエスト

19th May, 2016



26th International Conference of the TOC Practitioners Alliance - TOCPAwww.tocpractice.com 2

片山知樹

Tomoki Katayama

[email protected]

株式会社富士通システムズ・ウエストに⼊社後、約13年間、システムエンジニアとしてERPパッケージ（SAP）の導⼊・サポートなどに従事。

2011年に参画した大和ハウス工業株式会社様のSAP導⼊プロジェクトにて、CCPMのマネージメントを経験。（タスクマネージャ、チームリーダとして）

その後、CCPMコンサルとして3年以上の経験を持つ。その間、10社以上の企業へのITプロジェクトでのCCPMコンサルを担当すると共に、⾃

社内・富士通グループ会社のITプロジェクトへのCCPM適用も推進。

Tomoki Katayama was the System Engineer of Fujitsu Systems

West Limited, and he had been working for implementing and

supporting ERP (SAP) package for 13 years.

In 2011, he participated in SAP project (to DAIWA HOUSE

INDUSTRY CO., LTD.) managed by CCPM as a Task Manager and

Team Leader.

Since 2013, he has been working with >10 companies for

consulting CCPM. It is specialized in an IT project. And he has been

working with internal project for consulting CCPM.




：Fujitsu Systems Global Solutions ManagementSdn. Bhd.（FSGS)

■会社名：株式会社富士通システムズ・ウエスト（FWEST）

■本社所在地：大阪市中央区城⾒2-2-6

富士通関⻄システムラボラトリ■設⽴：1981年6月20日

■資本⾦：5億円（富士通株式会社全額出資）

■売上高：1026億円（2015年度）

■代表者名：代表取締役社⻑宮田一雄

■従業員数：3,370名（2016年4月1日連結3,840名）

■関係会社：株式会社富士通山口情報（FYC）

：株式会社富士通四国インフォテック（FSIT）

：株式会社富士通インフォテックサービス（FITS）

会社概要




◆FWEST本社

■四国支社

■静岡

■沼津■豊田

■鳥取

■福山

■岡山支社■中国支社

■松山 ■和歌山

■高知

■徳島

■神⼾

■山口

■宇都宮

■東京支社

■中部支社

◆FSGS（マレーシア）

◆FYC

◆FSIT◆FITS■大阪

■大津オフィス

３社１社１４拠点

■事業所・オフィス

◆国内関係会社

◆海外関係会社

事業所・オフィス・グループ会社




【コンサルティング】・お客様が抱えるシステム課題を的確に診断・分析し、最短距離で解決へと導くソリューションを企画・⽴案します。

【システムインテグレーション(オーダーメイドの構築)】・製造、流通、⾃治体、医療、公企業、⽂教など、業種によって異なる多様なニーズに対応し、高度なSE技術と

蓄積されたノウハウで設計から構築・運用・稼働後の保守に至るトータルなサポートを実現します。

【クラウド・アウトソーシング】・安全性と信頼性の高いIDCファシリティとネットワーク、

ソリューション(PKG)を組み合わせ、24時間万全なアウトソーシングサービスを提供します。

【ソリューション(ソフトウェアパッケージ)】・幅広い業種業務に対応する製品やパソコン運用管理といった共通基盤の製品等で、お客様の経営の効率化と企業価値の向上に貢献します。

・コンサルティングからソリューション(ソフトウェアパッケージ)、システムインテグレーション(オーダーメイドのシステム構築)、アウトソーシングまで一貫した価値あるサービスをご提供します。

事業内容




大和ハウス工業株式会社様

SAPプロジェクト




2011年大和ハウス工業様向けＳＡＰ導⼊プロジェクトにおいて、お客様と共にCCPM適用による期間短縮にチャレンジ・成功

② CONCERTOクラウドサービス・CCPM適用に必要となるCONCERTOツールをクラウドサービスとして

提供開始（米国Realization社とパートナーシップ契約締結）

部内や他部門の他プロジェクトに適用を開始

2013年8月〜本格的にビジネス展開

① CCPM適用コンサルティング

・お客様のプロジェクトへのCCPM適用を支援

弊社のCCPMビジネス経緯




CCPM適用プロジェクトの概要

プロジェクト期間：１年３ヶ⽉ソリューション：パッケージ適用とスクラッチ開発の組み合わせ開発分担：パッケージ適用は外部ベンダに開発委託

スクラッチ開発は自社開発

TOCPAカンファレンス：知識と経験をシェアする

CCPM導⼊を指導する⽴場として、『大規模ITプロジェクトへのCCPM適用』

の経験をシェア

本日のご説明内容について




CCPM 導⼊プロセス

(本日のご説明箇所)

ﾋﾞｼﾞﾈｽﾆｰｽﾞの特定ﾌﾟﾛｼﾞｪｸﾄ/非ﾌﾟﾛｼﾞｪｸﾄ業務

の定義

現状のｵﾍﾟﾚｰｼｮﾝ状況の確認(CT, DDP)

過去の類似PJ

対象PJ ｵﾘｼﾞﾅﾙ計画

ﾌﾟﾛｼﾞｪｸﾄのﾜｰｸﾌﾛｰ概略の理解

現場の問題症状/ｵﾍﾟﾚｰｼｮﾝ課題の調査

問題構造の整理

ManagementReview

Current RealityStudy (CRS)

現状理解

SolutionDesign

解決策の設計

待ち時間/ﾏﾙﾁﾀｽｷﾝｸﾞの損失評価

解決策の設計ﾌﾟﾛｼﾞｪｸﾄﾌﾟﾗﾝ作成

役割と責任

ﾀｽｸﾏﾈｰｼﾞｬ WIP低減ﾏﾈｰｼﾞｬ

ﾌﾙｷｯﾄﾏﾈｰｼﾞｬ

ｵﾍﾟﾚｰｼｮﾝ目標の設定

ExecutionReadiness

実⾏準備

Task MgtImplementation

ﾀｽｸ管理の導⼊

Go-Live

Project ControlImplementation

ﾌﾟﾛｼﾞｪｸﾄｺﾝﾄﾛｰﾙ

導⼊

実⾏管理ﾌﾟﾛｾｽ策定投入ｺﾝﾄﾛｰﾙ手順

ﾌﾙｷｯﾄ手順

課題解決の手順

ﾀｽｸﾏﾈｰｼﾞｬのﾄﾚｰﾆﾝｸﾘｿｰｽ集中の実⾏

WIP低減とﾘｿｰｽ集中

決めた優先順位でのﾊﾟｽ/ﾀｽｸの実⾏

ﾊﾞｯﾌｧの優先順位によるﾘｿｰｽ割当て

残日数の日次更新

ﾀｽｸ準備の実⾏

課題解決の開始

ｵﾍﾟﾚｰｼｮﾝﾚﾋﾞｭｰ開始

ﾌﾟﾛｼﾞｪｸﾄﾏﾈｰｼﾞｬのﾄﾚｰﾆﾝｸﾞ

上級管理者のﾄﾚｰﾆﾝｸﾞ

進⾏中ﾌﾟﾛｼﾞｪｸﾄの再計画ﾌﾟﾛｾｽ策定

約2週間約1週間




＜ビジネスニーズ＞

システム要件を満たしつつ、当初計画した工数で、実現化フェーズ（詳細設計〜システム内結合テスト）を９月末までに完了させる。

＜成果＞約６ヶ月間の実現化フェーズにおいて、予定より

約１ヶ月短縮して完了（約１６％短縮）(CCPMをやってなかったら、終わっていなかったかも？）

⇒ 成果ビジネスニーズ




• 進⾏中パス/タスクが「突発業務」によって遮断される（突発業務のほとんどは、課題解決ミーティング(数回/日)）

• パス/タスクのほとんどは予定より⻑くかかる（後の工程になればなるほど...）

• ぎりぎりで仕様が変更になって修正に追われる

• 設計中、テストでのやり直しが多すぎる

• 残業が多すぎる

• 優先順位がころころ変わる• 必要な時に必要なリソースが使えないことが多い

• プロジェクトのスコープ/仕様がカットされることが多い

問題症状 –好ましくない状態–




（タスクマネジャーがなぜ過負荷になるか）

タスク実⾏中課題は必ず発生する

⾒切りで進めると課題は増大する

タスクマネジャーは対処すべき課題を

多く抱える

(High WIP) 課題の発生と同時に、タスクマネジャーは即座に課題解決に対応

する

タスクマネジャーのマルチタスキング

課題解決までの期間が⻑くなる

(課題解決が遅れる)

リソースは課題解決を待つ間別のタスクを開始する、

⾒切りで進める(High WIP)

できるところから着手すれば進捗するという思い込み

タスクの開始-終了日とリソースの割当予定を固定する

突発的な仕様確認、問合せ対応が発生する

悪循環のサイクル

（ネガティブ・ループ）




何を変えるのか?

High WIP

(進⾏中作業が多い) 進⾏中パス/タスク数が多すぎる

タスクマネジャーの高負荷状態

薄く伸ばしたリソース割り当て

固定スケジュール予定した開始日がくれば、準備が

不⼗分でもそのタスクを開始する

できるところから進捗を⾒せなければならないリソースの手空きは許容できない

業務単位で優先順位が局所的

に決められる

パイプライニング

(WIPの調整) 進⾏中パス/タスク数を制限する

タスクマネジャーの集中

リソースの集中

フルキット（万全な準備）開始日が来ても、準備が出来て

いなければタスクを開始しない

バッファの優先順位に基づいてリソースを配置する余剰キャパシティはムダではない

プロジェクト全体で共通の優先順

位

何に変えるのか?

変化の軸（解決策の方向性）




ルール 3バッファマネジメント（バッファに基づいた管理）

バッファを持った計画を⽴案する

バッファの優先順位に従ってリソースを配置する

ルール 1パイプライニング（進⾏中作業の制限）

タスク管理者の管轄できる範囲で進⾏中タスク/パスを制限し、リソースを集中させる

ルール 2フルキット（万全な準備）

準備の出来ていないタスクを開始しない

CCPMの３つのルール




【【【【計画段階計画段階計画段階計画段階】】】】

ルール 1: パイプライニング（進⾏中作業の制限）• タスクマネジャーが管轄できる範囲でWIP（進⾏中作業）を減らし、

リソースを集中させる

ルール 2: フルキット（万全な準備）• 「詳細設計」と「開発（プログラム）」の前にフルキットポイントを設ける

• 各フルキットポイントに対して、準備する項目を決める

ルール 3: バッファマネジメント（バッファに基づいた管理）

• 局所的な管理指標を取り除き、50%のバッファを持った計画を⽴てる

当プロジェクトにおける

3つのルールの適用方法




【【【【実行段階実行段階実行段階実行段階】】】】

ルール 1: パイプライニング（進⾏中作業の制限）• フェーズの開始をコントロールし、最適WIP（進⾏中作業数）を維

持する

ルール 2: フルキット（万全な準備）• 準備が出来ていないタスクを開始しない

ルール 3: バッファマネジメント（バッファに基づいた管理）• バッファの優先順位に従ってリソースを配置する

• 素早く課題を抽出し、適切に課題解決を⾏うプロセスを確⽴する

当プロジェクトにおける

3つのルールの適用方法




オリジナルプラン（High WIP Plan）のイメージ

Task1 Task2 Task3Resource X

Resource Y

Resource Z

詳細設計

(DD)

開発

(Coding)

テスト

(UT)

結合テスト

(IT)

フェーズ

機能

DD: WS-A Coding: WS-A UT: WS-AWorkstream A

DD: WS-B Coding: WS-B UT: WS-BWorkstream B

DD: WS-C Coding: WS-C UT: WS-CWorkstream C

DD: WS-D Coding: WS-D UT: WS-DWorkstream D

IntegrationTest(IT)

【計画段階】

ルール 1：パイプライニング




【計画段階】

ルール 1：パイプライニングリソース集中プラン（Low WIP Plan）を検討

機能フェーズ

オリジナルプラン（High WIP Plan）

リソース集中プラン（Low WIP Plan）

タスクマネージャ

フェーズ CT

リソース数タスクマネージャ

フェーズ CT

リソース数

××

詳細設計 AA 21 1 AA 15 2

開発 AA 39 4 AA 20 8テスト AA 20 3 AA 15 4

オリジナルプラン（High WIP Plan）

リソース集中プラン（Low WIP Plan)

ﾀｽｸﾏﾈｼﾞｬｰ(TM)が同時に管轄する

フェーズ数1－2 フェーズ / TM 1 フェーズ / TM

ﾀｽｸﾏﾈｼﾞｬｰ(TM)が

同時に管轄するタスク数 10 件程度 / TM 5 件程度 / TM




DD: WS-A Coding: WS-A UT: WS-AWorkstream A

DD: WS-B Coding: WS-B UT: WS-BWorkstream B

DD: WS-C Coding: WS-C UT: WS-CWorkstream C

DD: WS-D Coding: WS-D UT: WS-DWorkstream D

Time

DD:WS-A

Coding:WS-A

UT:WS-A

Workstream ADD:WS-B

Coding:WS-B

UT:WS-B

Workstream B

DD:WS-C

Coding:WS-C

UT:WS-C

Workstream C

DD:WS-D

Coding:WS-D

UT:WS-D

Workstream D

Time

【計画段階】





【計画段階】


機能フェーズ TM 1 2 3 4 5 6 7 8 9 1 0 1 1 12 1 3 14 1 5 16 1 7 18 1 9 20 2 1 22 2 3 24 2 5 26 2 7 28 2 9 30 3 1 32 3 3 34 3 5 36 3 7 38 3 9 40 4 1 42 4 3 44 4 5 46 4 7 48 4 9 50 5 1 52 5 3 54 5 5 56 5 7 58 5 9 60 6 1 62 6 3 64 6 5 66 6 7 68 6 9 70 7 1 72 7 3 74 7 5 76 7 7 78 7 9 80 8 1 82 8 3 84 8 5 86 8 7 88 8 9 90 9 1 92 9 3 94 9 5 96 9 7 98 9 9 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123

詳細設計 ×× 3 3 3 3 3 3 3 3 3 3 3

開発 ×× 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

テスト ×× 3 3 3 3 3 3 3 3 3 3 3

×× 5 5 5 5 5 5 5 5 5

×× 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

×× 4 4 4 4 4 4 4 4 4 4 4 4

×× 6 6 6 6 6 6

×× 5 5 5 5 5

×× 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

×× 3 3 3 3 3 3 3 3 3 3 3 3

×× 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

×× 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

×× 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

×× 3 3 3 3 3 3 3 3 3 3 3 3

×× 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

×× 3 3 3 3 3 3 3 3 3 3 3 3

×× 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

×× 5 5 5 5 5 5 5 5 5 5 5 5

×× 4 4 4 4 4 4 4 4 4 4 4 4

×× 5 5 5 5 5 5 5

×× 5 5 5 5 5

×× 4 4 4 4 4

テスト

テスト

詳細設計

開発

テスト

詳細設計

XX領域（画面）

XX領域（画面）

XX領域（バッチ）

2015/4 2015/5 2015/6 2015/7 2015/8 2015/9

詳細設計

開発XX領域（バッチ）

開発

実際にリソース集中プラン（Low WIP Plan）を検討した際に活用したワークシート（テトリス）の一例




詳細設計（DD）開発（Coding）テスト（UT）

FK1

FK2

【計画段階】

ルール 2：フルキットフルキットポイント

FK1での準備項目（一例）




オリジナルプラン

リソースの集中

50%期間カット＆ 50%のバッファ（理論値）

7week(35d) – 3人

3.5week(18d) – 6人

2.5week(13 d) – 6人

フェーズ平均：

管理者が支援を実⾏することで得られる短縮（素早い課題

解決&手直し軽減）

※各タスクの日数を半分にするのは、バッファの消

費状況でプロジェクトのリスクを早く洗いだそうとする工夫。（半分の日数で実⾏するためではない）

Buffer0.8weeks

(5d)1.6week(8d)

【計画段階】

ルール 3：バッファマネジメント




更なる短縮がどうして可能なのか？

WIP（進⾏中作業）を減らす

ﾀｽｸﾏﾈｼﾞｬｰの数名が常に解放さ

れる

ﾘｿｰｽの集中

CT短縮

ﾌｪｰｽﾞ単位のCTの更なる短縮

突発業務や手直し作業による中断の減少

ﾌｪｰｽﾞ単位で開始を後ろにずらせる

ﾀｽｸ準備の充実

課題解決待ち/指示待ちの減少

突発的な仕様確認、問合せ対応が

発生する

ﾀｽｸﾏﾈｼﾞｬｰの集中

【計画段階】





フェーズ開始の意思決定プロセス

フルキットが完了

しているか？

No フルキット項目を完了させるまで

次フェーズを開始しない（フルキットの管理プロセスに従う）

TMが追加タスクを⾏ってい

ないか？

追加タスクの割当を変更するor 担当追加タスクが完了するまで

次フェーズを開始しない

タスクメンバーが必要人数揃って

いるか？

タスクメンバーが必要人数揃うまで次フェーズを開始しないor 次フェーズを開始する意思決定を⾏う

タスク準備が整っているか？

タスク準備が揃うまで次フェーズを開始しない

or タスク準備を支援する

次フェーズの開始を

許可する

No

No

No

Yes

Yes

Yes

Yes

【実⾏段階】





2週間先までのフルキットを確認する（Concerto）

2週間先までに実施するフルキットがあるか？

Yes

何もしないNo

状態を“未開始”→“進⾏中”に更新する

“進⾏中”のフルキットに関して、残日数と要支援事項を確認する

次フェーズの開始予定に揃う？

要支援事項があれば、「要支援項目」の欄に⼊⼒し対応する（Concerto）

Yes

フルキット完了後、状態を “進⾏中”→“完了”に更新する

(次フェーズ開始基準に従って開始)

条件付き合格を認めない？

フルキットが揃うまで、準備プロセスを実施する

状態を“進⾏中”→“リリース済”残った項目を課題一覧に記載する

No

Yes

Noエスカレーションの対象

【実⾏段階】

ルール 2：フルキット




ﾀｽｸ更新ﾐｰﾃｨﾝｸﾞ

（朝会）

10分/毎日

ﾘｰﾀﾞｰ

ﾐｰﾃｨﾝｸﾞ

60分/週2回

ﾁｰﾑ内ﾐｰﾃｨﾝｸﾞ

10分/毎日

PMO

ﾐｰﾃｨﾝｸﾞ

30分/週1回

ｵﾍﾟﾚｰｼｮﾝﾚﾋﾞｭｰ

週1回ﾚﾎﾟｰﾄ送信

毎週毎日週2回（⽕、⾦）

課

題

の

打

上

げ

課

題の

打

上

げ

進

捗・

課

題

の報

告課

題

解

決

＆

課

題

共

有

①上級管理者

②PMO

③プロジェクトリーダー/ チームリーダー

/フルキットマネージャー

④タスクマネージャー

⑤タスクメンバー＝リソース

課題解決プロセス（全体像）

【実⾏段階】





A領域(XXX) 開発A領域(XXX) 詳細設計

ﾘｿｰｽ A

ﾘｿｰｽ B

ﾘｿｰｽ C

ﾘｿｰｽ D

ﾘｿｰｽ E

Task1 Task2 Task3 Task4 Task5 Task6

ﾀｽｸﾏﾈｰｼﾞｬ

ﾘｿｰｽ A

ﾘｿｰｽ B

ﾘｿｰｽ Cﾘｿｰｽ D

ﾘｿｰｽ E

ﾀｽｸﾏﾈ

ｰｼﾞｬ

A領域(XXX) 詳細設計


バラつき発生




Task1 Task2 Task3 Task4 Task5

Task6

進捗に伴い変化するメンバの残日数を⾒て調整する（フェーズ全体を短縮するよう、リソースの割当を柔軟に⾏う）

A領域(XXX) 開発

A領域(XXX) 開発平準化

【実⾏段階】





まとめ

大規模ITプロジェクトの特徴リソースは専有されることが多く、他PJやショートワーク

によるマルチタスクはあまり考慮しなくてよい。しかし、同じフェーズ内でのマルチタスク（ストリーム間のマルチタスク）が懸念され、リソース、タスクマネージャの

高WIPに注意が必要。

WIPコントロール、パイプライニングが重要！同時に動かすワークストリーム数、ストリーム内のタスク数をコントロールすることが重要

Documents

1 - Tomoki Katayama(FWEST)_26 TOCPA_Japan_19 May 2016_Jp