2 Tier CCPM - Japan TOC Association€¦ · “2 Tier CCPM” 適用による組織マネジメントの改善－組織レベルでの適用を促進する－株式会社NTTデータ九州

www.tocpractice.com

“2 Tier CCPM”適用による組織マネジメントの改善

－組織レベルでの適用を促進する－

株式会社ＮＴＴデータ九州

金融システム事業部開発統括部

平山久典

44th TOCPA International Conference4th JTA/TOCPA JOINT CONFERENCE 2019

18 November 2019, Tokyo, Japan

japan-toc-association.org

44th International Conference - TOCPA www.tocpractice.comjapan-toc-association.org

■所属株式会社ＮＴＴデータ九州金融システム事業部開発統括部ｅビジネス開発担当

■経歴NTTデータ九州に入社後、主に金融系のシ

ステム開発プロジェクトに従事。その中で、システム開発の全ての工程（提案・要件定義・設計・製造・試験・導入・保守）を経験。現在は培った技術力を生かし、開発案件のプロジェクトマネジメント、開発チームのマネジメントに従事している。

Email:

[email protected]

平山久典

© 2019 NTT DATA KYUSHU Corporation 3

ＮＴＴグループにおけるＮＴＴデータ

NTTグループ

総資産：21兆6,758億円

売上高：11兆7,996億円

従業員数：282,550人

連結子会社：922社

※2018年3月末現在

日本電信電話株式会社

西日本電信電話（株）

【100%】

東日本電信電話（株）

【 100% 】

NTTコミュニケーションズ（株）【100%】

Dimension Data Holdings plc.【100%】

（株）NTTドコモ【66.7%】

（株）NTTデータ【54.2%】

マネージドICT／データセンター・ネットワーク

ソフトウエア（アプリケーションレイヤー）・グループ全体の経営戦略・基盤的研究開発の推進

通信キャリア

B to BIT

サービス

※ 【】内は、NTTの議決権の所有割合（2018年3月末時点）


会社概要ＮＴＴデータ九州

社会基盤事業部

株主総会

取締役会

社長

金融システム事業部

開発統括部

営業統括部

経営企画部

弊社は社会・経済が激しく変貌する時代において、地域のお客様の声を今まで以上に身近に感じ、お客様とともに行動するために、2003年7月1日にNTTデータグループの九州地域の代表「株式会社NTTデータ九州」として誕生。

NTTデータグループでは、「Trusted Global Innovator」というブランドメッセージを掲げ、ニーズへの先見性や深いお客様理解をもとに、新たなビジネスやサービス、そしてそれを支えるソリューションを構想し、社会やビジネスの更なる発展という夢を、お客様と共有し、高度なシステム構築力や活用力を核に様々なビジネスやサービスの連携など、IT領域にとどまらないサポートを提供

名称 : 株式会社NTTデータ九州本社所在地 : 福岡市博多区博多駅前1-17-21

NTTDATA博多駅前ビル設立年月 : 1990年3月6日商号変更 : 2003年7月1日資本金 : 1億円代表者 : 代表取締役社長加藤浩治従業員数 : 約437名（2019年4月現在）

組織図会社概要

NTTデータ九州

NTTデータ四国NTTデータ関西

NTTデータ東海

NTTデータ北陸

NTTデータ信越 NTTデータ東北

NTTデータ北海道

NTTデータNTTデータビズインテグラルNTTデータイントラマートNTTデータ経営研究所NTTデータアイ・・・

NTTデータ中国

登録番号： IS 500405/ISO IEC27001(初回登録日：2006年2月2日)

グループビジネス統括部

地域ビジネス統括部


金融システム事業部開発統括部のご紹介

開発統括部の得意分野

■ システム開発に必要な技術基盤を幅広く保有・オープン系・WEB系アプリケーション開発を得意とし、TERASOLUNA自動化ツール活用に力を入れている。

API、FinTECH等の先端技術

開発統括部の開発スキーム

■ ＮＴＴデータ本社と一体になって、業務ＡＰの開発と維持を実施・九州プロパーだけでなく、経験豊富な協力会社様メンバーによる要件定義執筆を実施！（自らの手で仕事を作る！）・案件内容・規模に応じて、オンサイトまたは、オフサイトでの要件定義を実施・その他、オンサイトメンバーによるインシデント対応や顧客打ち合わせ支援、およびRFP提案支援等も実施

開発統括部の事業


1. 当社におけるTOCの歩み

2. 当部門における本適用

3. ルールの適用：計画段階/実行段階

4. 適用効果と今後の適用拡大に向けて

アジェンダ


１．当社におけるTOC活動


PM学会九州支部(TOC-WG)と当社のTOCの歩み

2003 2004 2005 20062007 -2009

2010 - 2013 2014 2015 2016 20172018 -2019

第1期TOC-WG

第2期TOC-WG

第3、4、5期TOC-WG

第6期TOC-WG

九州支部シンポジウム（TOCにフォーカスした内容）

九州支部設立九州支部シンポジウム（TOC-WG 成果発表）

第7期TOC-WG

第8期TOC-WG

第9期、第10期TOC-WG

秋季全国大会（4論文成果発表）

勉強期検証期当社

他部署適用

本適用

他部署適用拡大へ

2017年度 PM学会実施賞奨励賞（本部表彰）2018年度 PM学会文献賞（本部表彰）

2018 春季大会授与写真右）当社取締役 (当時)

PM学会教育・出版シリーズ⑱

2019 秋季大会授与写真右）当社統括部長


検証期Ⅰ：大規模プロジェクトの問題分析

2003 2004 2005 20062007 -2009

2010 - 2013 2014 2015 2016 20172018 -2019

第1期TOC-WG

第2期TOC-WG


第6期TOC-WG



第7期TOC-WG

第8期TOC-WG




他部署適用

本適用


• 直近発生した問題プロジェクトの問題分析を専門家とTOC-WGメンバーを交えて行った

• 問題プロジェクトは、当部門において大規模プロジェクトであり、大幅な遅延と予算超過を起こしたプロジェクトであった

参考文献：朝稲啓太(2017)，実プロジェクトの問題分析を通じたCCPMの適用方法に関する考察，プロジェクトマネジメント学会2017 年度秋季研究発表大会予稿集，pp.431-435.


当部署が取り扱う主なプロジェクト

お客様インターネット

バンキングシステム

Internet

外部システム

バッチ業務

• 企画型のインターネットバンキングシステムの機能拡充プロジェクト

• 競合他社の次世代システムへの切り替えが進む中で当社でも次世代サービスを展開

• 対象システムにおいてはオンライン業務の計画的な機能拡充と緊急の不具合対応、及び急ぎの仕様変更対応が五月雨的に発生

運用端末

オンライン業務


問題分析を行った大規模プロジェクトの分析対象範囲

マスタプラン要件定義設計製造試験

実行中

要件定義

設計

製造試験

マスタプラン修正

要件定義

設計

製造

製造設計試験

なぜ、多くの手戻りが発生し、プロジェクトが予定よりも長くなってしまったのか？

分析対象範囲


問題分析で用いたアクション分析の方法

ニーズ[Need]

ﾎﾟｼﾞﾃｨﾌﾞ/ﾈｶﾞﾃｨﾌﾞ結果

[Result]

マネジメントアクション[Action]

前提条件[Reality]

前提条件[Assumption]

なぜ、そのアクションで上記の結果を得たのか？

なぜ、そのアクションを選択したのか？

【ポジティブな結果の場合】Reality と Assumption が一致

【ネガティブな結果の場合】Reality と Assumption が不一致→ 不一致の理由を探り、解決策を立案


問題/課題に対するマネジメントアクションとその結果

Need

設計段階での本社へあげた懸案回答を早く獲得しなければ

ならない

Result(ﾈｶﾞﾃｨﾌﾞ)

間違った回答が頻発した（特に厄介な懸案事項）

Management Action

設計段階で、本社との懸案事項を解消するミーティングの頻度を

[１回/週→毎日]に変更した

Reality

本社はミーティングのタイミングに合わせて懸案回答をその場その場で準備する

Assumption

テレビ会議などを用いて、直接、言葉と顔の表情で危険度を訴える方法でのみ、効果的な督促が行える

なぜ、そのアクションで上記の結果を得たのか？

なぜ、そのアクションを選択したのか？

アクション分析（例）

アクション分析の結果

Reality と Assumption 不一致


ネガティブに作用したマネジメントアクションの結果分析

• インプット不足（見切り発車→やり直し、届くのを待つ）

回答が入手できない (間違った回答が頻発)

仕様調整が遅れる

業務間（機能間）での調整不足（同じ間違い）

• リソースが必要な時に利用できない（設計の手戻りと製造支援で忙しい）

業務単位で次々に開始される設計&製造作業にリソースがとられる

（多くのパス/タスクが同時に進行する）

設計の手戻り作業にリソースがとられる

製造QA対応にリソースがとられる（設計リソースが製造支援も行う）

• リーダーの支援/管理が疎かになる（課題発見/課題解決が遅れる）

同時に管理すべきパス/タスクが多い

同時に進行する製造パス/タスクが多すぎる

製造タスクでのQA対応が多すぎる


悪循環のサイクル（問題分析を通じて）

意思決定/支援を待つ間別のタスクを開始する

Or見切りでタスクを進める

リソース/リーダーマルチタスキング

タスク&パスの期間が伸びる

進捗を見せなければならない

(手空きはもったいない)

待ち時間

High WIP（進行中の作業が増える）

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

を固定する

手直しの発生


悪循環のサイクル（なぜリーダーが過負荷になるのか）

タスク進行中課題は必ず発生する

（業務間の整合、リソースへの支援）

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

リーダーは対処すべき課題を

多く抱える（High WIP）

課題の発生と同時に、リーダーは即座に課題解決に対応する

リーダーのマルチタスキング

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

(課題解決が遅れる)

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

見切りで進める（High WIP）

進捗を見せなければならない（手空きはもったいない）

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

を固定する

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


解決の方向性：悪循環のサイクルを断ち切る方策

本分析の根本問題は、リーダーのマルチタスキングである

通常：マルチタスクはリソースに焦点を当てられるが...

解決の方向性

(タスク/パスを管理する) リーダー/タスクマネジャーの把握できる範囲で

WIP(進行中タスク)をコントロールし、素早い課題解決を行う

そのために、進行中タスクにリソースを集中させる


検証期Ⅱ：問題分析に基づき、一部のチームで試行適用

2003 2004 2005 20062007 -2009

2010 - 2013 2014 2015 2016 20172018 -2019

第1期TOC-WG

第2期TOC-WG


第6期TOC-WG



第7期TOC-WG

第8期TOC-WG




他部署適用

本適用


• 1チーム(8人程度)を対象に試行実施

【結果】

• 期間：40%以上短縮

• 工数：20%以上削減

参考文献：大場輝幸(2018)，CCPMの考え方を流用した試験工程における生産性の向上プロジェクトマネジメント学会誌， Vol.20， No.3， pp.9-13.


試行した内容に関する振り返り

① 計画段階では、バッファを持った計画を作成する前に、同時進行中タスクを制限し、リソースが集中できる環境を整えることが重要。

② 実行段階では、バッファを無駄に消費しないよう、リソースが課題を抱えた時の素早い解決を行うことが重要。

③ チーム単位でも効果を発揮できる。✔生産性の向上✔時間外の削減✔リソース不足等

⇒まずは、恐れることなくトライアル的にやってみてもいいのでは？ただし、上記①②の条件は必須。

④ メンバー全員に対する事前合意、日々の状況確認・フィードバックによりチームワークが向上、更なる効率化が期待できる。

参考文献：大場輝幸(2018)，CCPMの考え方を流用した試験工程における生産性の向上プロジェクトマネジメント学会誌， Vol.20， No.3， pp.9-13.


他部署適用：2018年度カンファレンス発表内容参照

2003 2004 2005 20062007 -2009

2010 - 2013 2014 2015 2016 20172018 -2019

第1期TOC-WG

第2期TOC-WG


第6期TOC-WG



第7期TOC-WG

第8期TOC-WG




他部署適用

本適用


• 2018年度カンファレンスで発表

• 適用部署：20-30名の組織に適用

• 売上:17％増加、稼働時間:3％増加

• 生産性：約14%向上

PM学会で情報共有し、

参加していた別メンバーが自組織に適用

参考文献：峯肇史(2017)，進行中タスクを制限することの効果，プロジェクトマネジメント学会2017 年度秋季研究発表大会予稿集，pp.445-448.


2．当部門における本適用


適用の背景（ビジネスニーズ）

ビジネスエリア拡大新規の類似プロジェクト、または、新規案件を創出する必要がある

既存ビジネスの堅守開発案件を他社に奪われないために、上級SE（コアメンバー）を要件定義支援に確実に割りてる必要がある

変動ニーズへの対応トレンドの変化や制度対応に速やかに追従することが求められ、要件変更や納期の入替に柔軟に対応することが必要

屋台骨であるベースライン（既存の開発）を危険にさらすことなく、機能追加開発の生産性を高めることで、

上級SE（コアメンバー）を次の仕事（新規案件）に確実に割り当てる必要がある！

ビジネスニーズを満たすために、組織に “2 Tier CCPM” を適用する


適用した組織のプロジェクト概要

• 計画的な機能拡充は年2回のリリースに合わせて案件の絞り込みから要件の決定まで行う

• 要件の決定が遅れたり新たな案件が発生したりすることで優先順位の変更も頻発し、スケジュール遵守が厳しい状態である（見積やスケジュールのやり直しが頻発）

• そのような状況で上級SEを他へ割り当てることは到底許容できる状態ではない

（上級SEによるきめ細かな対応が必要）

管理者 BD/ST支援

基盤 Group

取引 Group

ﾛｸﾞｲﾝ Group

2p

8p

8p

18p

17p

本社支援 5p

Total：58名(導入時)


2 Tier CCPM 適用における３つのルール

RULE 3: Queue Task Control優先順位と利用可能キャパシティに従って

Tier1タスクを動的に投入する

RULE 1: 2-Tiered Planningリソースを集中させ、進行中Tier1タスクを減らす

RULE 2: IP Task ManagementTier1タスク短縮のため

Tier2タスクにリソースを柔軟に配置する


適用スケジュール

日程

5月 6月 7月 8月 9月 10-2月 3月

wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4

フェーズ

ツール関連

現状理解 (CRS)解決策の設計

データ収集 Solution

Review

FK

タスク管理実行【Rule 2&3】

ﾘｿｰｽ集中＆WIP低減準備＆実行

取引Group



基盤Group



ログインGroup

ツール開発準備

ツール開発

IT-Tool

Go-Live

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

[Rule 3]

実施評価期間

評価検証

報告会

調査/解決策の設計期間7 weeks

CCPMの仕組み構築/適用実施12 weeks


CCPM適用スケジュールと主要な実施項目

日程

5月 6月 7月 8月 9月 10-2月 3月

wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4 wk1 wk2 wk3 wk4

フェーズ

データ収集現状理解 (CRS)、解決策の設計

リソース集中/WIP低減タスク管理実行

他 2Group

タスク管理実行

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

取引Group

データ収集 (前年度の情報収集)• 月別完了件数• 作業時間• プロジェクト単位のLT (Lead Time)

現状理解・解決策の設計• プロジェクトのワークフローの整理• 各フェーズの待ち時間評価• マルチタスキングの損失評価• 解決策の概略設計• オペレーション目標の設定• 期待成果の見積り

Rule 1,2,3 実施• 実行管理プロセス策定

－ 2-Tiered Planning－ﾘｿｰｽ集中の手順－ IP Task Management－ Queue Task Control

• 役割と責任• リソース集中/WIP低減の実行• 残日数の日次更新• タスク準備の実行• 課題解決の開始

※ 1つのGroupで実施後、他 2つのGroupへタスク管理のノウハウを展開し、実施

プロジェクトコントロール(開発した)ツールを導入し、プロジェクトコントロールを実施

• バッファの優先順位によるリソース割り当て

• Group間のリソース共有

タスク管理実行


3．ルールの適用：計画段階/実行段階


【ルール1の適用】計画段階 – 2 Tiered Planning

タスク名

詳細設計

機能A

機能A-x

機能A-x-1 設計

機能A-x-2 設計

機能A-x-3 設計

機能A-x-4 設計

機能A-x-5 設計

機能A-x-6 設計

機能A-x-7 設計

機能A-x-8 設計

機能A-x-9 設計書まとめ

Task詳細設計機能A-x

TIER 1

TIER 2

Sub-Task 1

Sub-Task 2

Sub-Task 3

Sub-Task 4

Sub-Task 9

・・

現行WBS 2-Tiered Planning

2-Tiered Planning- プロジェクト単位で作成されたWBSを用い，

タスクを2階層(Tier1とTier2)に整理する。

- Original Planを基に各タスク(Tier1)の期間が最小化されるように、サブタスク(Tier2)にリソースを集め、リソース集中した場合の見積もりを立案する。

- 各タスク(Tier1)の依存関係を整理する。

Tier1 タスクにリソースを集中

Tier1 タスクの依存関係を整理

(標準的なプロジェクトをテンプレート化)


【ルール1の適用】計画段階 – パイプライニング

2018/6/26 2018/6/27 2018/6/28 2018/6/29 2018/6/30 2018/7/1 2018/7/2 2018/7/3 2018/7/4 2018/7/5

チームリーダー

リソースA 仕変97故障対応仕変97単性能測定

リソースB ST02故障対応仕変59MCL 仕変59IT

リソースC

リソースD 仕変62残作業

リソースE

リソースF 仕変59M 仕変59Mレビュー

リソースG

リソースH

リソースI

リソースJ 仕変59PCL

リソースK 仕変59UT

リソースL

リソースM

リソースN

予定が確定しているタスク暫定的に計画されているタスク

後続にあるタスク程、フレキシブルにタスクの順番が変更される

バッファを持った計画（Tier1 Level で!）従来のバッファの持ち方として、タスク／サブタスクレベルで安全余裕を持ち、タスク／サブタスクの期間見積はマルチタスクを前提としていることが多いが、プロジェクトで安全余裕を持ち、タスクの期間はマルチタスクを前提とせず、リソースが集中される計画とする。（Short Work以外の多重度は２つまでに制限）

パイプラインスケジュール（Tier1 Level で!）進行中のプロジェクトと新規プロジェクトに関して、2-Tiered

Planningで整理し、タスク単位(Tier1)で実行する順番を決める。実行する順番は以下のポイントを留意する。タスクを完了させるためのインプットが揃うまでタスクを開始し

ない。（開始できるだけのインプットが揃っていても妥協せず，見切り開始しない）

タスクに必要なリソースが揃うまでタスクを開始しない。（リソースに空きが発生しても妥協しない）

常時、数人程度、タスクにリソースを割り当てないようにする(Short Work用にキャパシティを確保するため)

割り当てられていないリソースに対しては、以下のような順番で対応を行う。① Short Work を割り当てる② 進行中のタスクを少しでも加速させるために支援する③ 次の案件、タスクの準備作業を手伝う④ 次のタスクの準備/勉強を行う

IP Task

Queue


【ルールの適用】計画段階まとめ

2-Tiered Planning法を用いてTier1とTier2に階層化

Tier1 タスクに必要なリソースを集中

Tier1 タスクで依存関係を整理

Low WIP(進行中Tier1タスクの低減)

チームリーダー/有識者マルチタスク低減

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

フレキシブルにTier1 タスクの開始をコントロール

チームリーダー/有識者キャパシティが生まれる

Tier1 タスク準備の充実

Tier1 タスクLT短縮

Low WIPの維持(進行中Tier1タスクの低減)


【ルール2-3の適用】実行段階

TaskManagement

残日数の更新

TaskManagement

フレキシブルな

リソース配置

PJ Tool

残日数の更新

PJ Tool

優先順位

PJコントロール

Rule2IP Task Management

Pipelining

パイプライン

コントロール

Rule3Queue Task Control

Task

Task

WIP

One-in

One-out

※ Task：TIER1のタスクを示す

Rule 3

Rule 2PJ-Z_TaskE

PJ-X_TaskD

PJ-Z_TaskC

PJ-Y_TaskB

PJ-X_TaskA

PJ-Z_TaskE

PJ-X_TaskD

PJ-Z_TaskC

PJ-Y_TaskB

PJ-X_TaskA

QUEUE

優先順位

Buffe

rSta

tus

R

G

Y

Input - OK

Input - NG

Input - OK

Input - OK

Input - NG

PJ-X_TaskB

PJ-Z_TaskD

PJ-Y_TaskC Input - OK

Input - OK

Input - NG


【ルール2の適用】実行段階 – IP Task Management

タスク管理（IP Task [Tier1]）

進行中タスクの遅れを最小化するため、チームリーダー/有識者は、以下のルールで日次でタスクマネジメントを行う。

【タスク管理の目的】• 進行中のサブタスクを完了させるまでに必要な残り日数を

報告してもらい、支援が必要な箇所を見つけ出す。• すべてのリソースが決めた優先順位通りの作業を行えるよう

にする。• 次に始めるサブタスクの準備が適切に行えるようにする。

（集中したリソースに無駄が発生しないように準備を行う）

【タスク管理を行う具体的な手順】タスク管理は以下の手順で実施する。① 管轄するリソースの残日数の更新（サブタスク単位）② 管轄する範囲におけるリソースの配置（サブタスク単位）③ サブタスクの準備（次に始めるサブタスク単位）④ 管轄するリソースに対して素早い課題解決

※ 進行中タスク(Tier1)の遅れを最小化するためのフレキシブルなリソース配置方法は、次頁参照。


【ルール2の適用】実行段階 – IP Task Management

Task X : 10 dST1

ST4 ST6

ST7 ST9 ST10

ST2

ST5

ST3

ST8

ST11 ST12

Task YTask X : 13 dST1

ST4 ST6

ST7 ST9 ST10

ST2

ST5

ST3

ST8

ST11 ST12

Task Y

Task X : 13 dST1

ST4 ST6

ST7 ST9 ST10

ST2

ST5

ST3

ST8

ST11 ST12

Task YTask X : 13 dST1

ST4 ST6

ST7 ST9 ST10

ST2

ST5

ST3

ST8

ST11 ST12

Task Y

ST10

Task X : 10 d Task YST1

ST4 ST6

ST7 ST9

ST2

ST5

ST3

ST8

ST11 ST12 ST10

仕事に人を割り当てる (TIER1 タスクを短縮するようリソース配置を柔軟に行う)

人に仕事を割り当てる (初めに決めたリソース割当を固定)

Task STTIER1 タスク TIER2 サブタスク


【ルール3の適用】実行段階 – Queue Task Control

リソースが必要人数揃っているか？

リソースが必要人数揃うまで当該タスクを開始しない

タスク準備が

整っているか？

タスク準備が揃うまで当該タスクを開始しない

or

タスク準備を支援する

Queue Taskの

優先順位を変更する

No

No

Yes

Yes

START

バッファの優先順位の高いタスクから

タスクの準備状況を確認

残日数をITツールへ

Queue TaskControl

ITツールへWait日数を更新し、バッファ状態を

シミュレーションする

※ Task：TIER1のタスクを示す


【ルールの適用】実行段階まとめ

上級管理者

プロジェクトリーダーリソースマネジャー

業務有識者

タスクマネジャー

部長

課長

有識者

有識者or

準有識者

Gr内リソースM 課長代理

リソース

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

（毎日）

プロジェクトコントロール

ｵﾍﾟﾚｰｼｮﾝ

ﾚﾋﾞｭｰ

Task

実行

課題の打上げ

課題の打上げ

Rule 2&3

Rule 3

RecoveryActions

Group間のフレキシブルなリソース配置

タスク単位でのリソースの移動


4．適用効果と今後の適用拡大に向けて


CCPM適用結果【定量評価】

定量的評価の検証適用前の実績と適用期間の平均値で比較

【Project Work】・月平均完了件数：15%増加・リードタイム：19%短縮

【Small Work (故障対応など)】・月平均の完了件数：25%減少・リードタイム：62%短縮※ 完了件数の減少は故障対応等が少なかったため。

【重み付けした結果】・全体完了数：13%増加・月当りの総稼働時間：14%削減・生産性：31%増加 (113%/86%)

※ 重み付けの根拠、開発規模を考慮した重み付け


CCPM適用結果【定性評価】

【良かった点】

• 進行中のプロジェクト/タスクを制限し、リーダー/有識者マルチタスクを防止することにより、－リーダーがタスクを管理しやすい（進捗や課題の発見と対処が早くなった）－有識者の問い合わせ負荷やレビュー負荷が軽減し、質も向上した－発注側からの仕様確認/懸案回答が早く得られるようになった

• タスクに集中してリソースを配置することにより、有識者でないリソースが有識者に解からないことを聞く頻度が増え、コミュニケーションが活性化した。また、有識者でないリソースのスキル（多能工化）が少しづつ高まっている

• グループ間のリソースが移動しやすくなった（Tier1 タスク単位で、リソースを出し入れするから）【以前は、グループ移動＝移籍扱いになりがちであった】⇒ リソース視点での移動から、タスク視点での移動に

• 準備をしっかり行ってから、タスクを開始することで非有識者リソースの活用範囲が広がった。

• ツールを用いてリソース移動と遅延のシミュレーションができることで、納期に対して、自信をもってタスクをずらすことができるようになった

• 製造-結合フェーズをDrum（ペースメーカー）としてずらすことで、設計フェーズの投入タイミングを決めやすく、システム全体が安定しやすい


CCPM適用結果【定性評価】

【気づき、コメント】

• 準備が完了しないとタスクを開始しないルールであるが、納期に間に合わない案件もあるただし、インプットを待たずにタスクを開始すると、結果的に変更が多発する。⇒ リソースの割当方法を工夫する必要がある (有識者を多めに割当て、手戻りを最小化)⇒ 本社との協力を取り付ける必要。

• 準備に力を入れすぎると見積工数よりも実績工数が増加するが、準備不足の場合はリソース集中がうまくいかず、実績工数がオーバーする傾向にある。⇒ 準備稼働の力の入れ具合の判断に、経験値が必要。

• 有識者に問い合わせが増えることへの、ケアが必要になった－有識者をタスクに割り当てると、そのタスクは遅延する可能性が高い（問合せや割り込み）－有識者に突発対応をお願いするためにタスクを空けているが、何もないと、手空きになる－気づきとして、タスクに有識者をあまり割り当てない方がよい


当社における今後の適用拡大に向けて

【マネジャー、上級管理者からのコメント】

• 有識者の手空きはもったいないと思ってしまうと、マルチタスク化して従来の方法に戻ってしまう。⇒手空きの時はShort Work実施か、他タスクの短期支援に回って、タスクの加速を行うのがよい。

手空きだからといって主タスクは持たせない。

• リソースマネージャは少ない方が良い。多くのリソースマネージャがいると、自チームにリソースの確保を行うよう心理が働き、リソースの集中が行いにくくなる。（複数のリソースマネージャがいる場合は、CCPMに理解があり、協力的なリソースマネージャを組み合わせる事が必要）

• 発注元も含めてCCPMルールが適用できる環境であれば、さらなる成果が期待できると思われる。または、自社がプライムとなっており、要件検討からリリースまで請け負っているような開発形態であれば、さらなる成果が期待できると思われる。

• 当社の場合、部門ごとに対象とするサービスが異なる。そのため、他部門の適用方法が、そのまま自部門へは適用できない。したがって、その部門に合わせて、問題の理解と適用方法の検討を行うことが重要であると考える。

全社展開しなさい

社長

© 2019 NTT DATA KYUSHU Corporation

Documents

2 Tier CCPM - Japan TOC Association€¦ · “2 Tier CCPM” 適用による組織マネジメントの改善 －組織レベルでの適用を促進する－ 株式会社NTTデータ九州

2 Tier CCPM - Japan TOC Association€¦ · “2 Tier CCPM” 適用による組織マネジメントの改善－組織レベルでの適用を促進する－株式会社NTTデータ九州