PowerPoint プレゼンテーション

2016年1月27日

情報システム部 共通基盤G

グループ長

米田 徳幸

継続的改善によるフルキットプロセスの改善

Project Flow2016 in Japan

プロジェクトマネジメント事業部

事業部長 竹添 芳孝

本日の内容

1. CCPM取り組みの経緯

2. 昨年までのCCPMによる成果

3. 2015年度の情報システム部の組織改革

4. ワークショップ事前準備

5. FWEST/Reaｌｉｚａｔｉｏｎ社コンサルによるワーク

ショップ

6. 具体的実行プランの策定と実行

7. 2016年1月中旬までの成果

8. 今後の取り組み

２

６

９

１２

２０

２７

４４

４９

CCPM取り組みの経緯

■

2010年1月

に開始した経理・人事の基幹システム（SAP ERP）の開発プロ

ジェクトに、CCPMを採用する。一時は計画が延伸し、暗礁に乗り上げかけ

ましたが、CCPMで25％以上の期間短縮を実現し、予算通り、計画通りにサ

ービスインを果たしました。

■この成功を機に、情報システム部は全てのITプロジェクトをCCPMでマネ

ジメントする方針を打ち出しました。

■

2012年10月

には、情報システム部は、部内にプロジェクトマネジメント

室（約３０名体制）を新設し、開発の全体最適チェックを行うとともに、

ITプロジェクトを運用チームから新設したPM室に移管する構造改革を行い

ました。



米

InfoWorld誌

記事



日経

ITpro誌記事

メディアでの取り上げ

継続的改善プロセス

富士通システムズウエスト（FWEST）、Ｒｅａｌｉｚａｔｉｏｎ社コンサルによるサンノ

ゼワークショップと、ゴールドラット・リサーチ・ラボCEOのAlan Barnard博士に

よるワークショップを定期的に実施。

2011

2012

2013

2014

2015

2012/8

・構造改革

・ＳＡＰロールアウト

2014/8

・再学習

・Ｌａｒｇｅ Ｐｒｏｊｅｃｔ

2015/10

・Ｗｉｎ

-Ｗｉｎ-Ｗｉｎ

・ＦＫ２改善

2015/11

Dr. Aｌan

2014/11

Dr. Aｌan

2014/2

Dr. Aｌan

本日の発表

■FWEST 、Ｒｅａｌｉｚａｔｉｏｎ社コンサルによるワークショップ

■ゴールドラット・リサーチ・ラボCEOのAlan Barnard博士によるワークショップ

2011/7

・ＳＡＰロールアウト

2011/12

Dr. Aｌan

Dr. Aｌan

2012/5

2012/12

Dr. Aｌan

Dr. Aｌan

2013/5

2010

2010/8

・１

O1教育

・CCPM

今期上期までのスループット

342

505

800

898

425

2011年度

2012年度

2013年度

2014年度

2015年度上期

プロジェクト完了数（TP）の推移

+48%

+58%

プロジェクト完了件数は大幅に向上

'12/10～ 構造改革

+12%

27

%

8%

11

%

22

%

21

%

11

%

年度毎プロジェクトのバッファ消費状況

2013年度

26

%

12

%

17

%

31

%

14

%

2014年度

39

%

12

%

7%

22

%

15

%

5%

2015年度上期

46%

55%

58%

今期上期までの工期短縮

黒＞200%

茶≦200%

オレンジ≦150%

赤≦100%

黄色＜93%

緑＜83%

【バッファ消費率】

【工期短縮率】

25%以上工期短縮

25%未満工期短縮

工期遅れ

55%

49

%

51

%

参考：2011年度

５１%

インターネットＢ

ＥＣＭ

ソリューション

次のステージへ 組織改革

グループ経営戦略

大阪

情報システム部

東京

情報システム部

商品ＩＴ業務部

プロジェクトマネジメント

事業部

開発1部

開発2部

開発3部

開発4部

情報企画室

情報技術管理

共通基盤

技術系基盤

管理系基盤

住宅事業Ｓ

集合事業Ｓ

建築系事業Ｓ

多角化事業Ｓ

ネットビジネスＳ

企画設計

集合設計

生産設計

生産情報管理

部品管理

ＩＴ戦略

ＩＴ基盤

セキュリティ

ユーザー窓口

ＩＴ企画・運用

設計ＣＡＤ

_{開発・運用}

_{プロジェクトマネジメント}

事業戦略

商品戦略

全社IT戦略

大和ハウス工業 情報システム部門

（株）メディアテック

社内の開発プロセス

ソリューションG

_{マネジメント室}

プロジェクト

大和ハウス工業 情報システム部

プロジェクト

マネジメント室

ソリューションG

（ユーザ部門）

大和ハウス工業

ユーザ部門

各ベンダー

システム

開発要望

FullKit1(FK1)

（要求定義）

FullKit2(FK2)

（概要設計）

Project（PJ）

（詳細設計・開発）

受入検証

運用保守

大和ハウス工業

ユーザ部門

ソリューションG

_{マネジメント事業部}

プロジェクト

大和ハウス工業

情報システム部

プロジェクト

マネジメント事業部

ソリューションG

（ユーザ部門）

大和ハウス工業

ユーザ部門

各ベンダー

システム

開発要望

FullKit1(FK1)

（要求定義）

FullKit2(FK2)

（概要設計）

Project（PJ）

（詳細設計・開発）

受入検証

運用保守

大和ハウス工業

ユーザ部門

（株）メディアテック

■組織改革後の開発プロセス

■組織改革前の開発プロセス

４．ワークショップ事前準備

（TOC思考プロセス活用）

今回のワークショップのターゲットを『

D-SMART

』

システムとしました。

『

D-SMART

』とは

・探客から引渡後まで各事業を網羅した事業推進システム（２００５年運用開始）

・開発保守ベンダー：伊藤忠テクノソリューションズ株式会社様（CTC） ※以降敬称略

ワークショップの対象システム

・開発案件のBacklogに、多くの

D-SMART案件の待ち

がある。

・2014年実績で開発案件の約５０％が

D-SMART案件

であった。

・プロジェクトマネジメント室がメディアテックの事業部に移管され、事業部として

売上を増やす必要がある。（TPを上げたい）

ワークショップの目的・参加者・日程

大和ハウス、CTC、 メディアテックが、プロジェクトのスループットを５０％

向上させる目標を共有化し、WIN-WIN-WINの関係を強化する。

大和ハウス工業

ユーザ要望

_FK1

_FK2

メディアテック

PJ

受入・運用

CTC

大和ハウス工業

ワークショップの目的

ワークショップの参加者

ワークショップの日程

CTC：２名

メディアテック：３名

大和ハウス工業：５名

FWEST：１名

（コンサル支援）

2015年 10月5日～10月9日

Ｒｅａｌｉｚａｔｉｏｎ社＠サンノゼ

ワークショップ前に準備・検討したこと（TOC思考プロセス活用）

① TP５０％UPに向けて各社の主要

ＵＤＥ(望ましくない現象)

・大和ハウスのUDE ６２件

・メディアテックUDE ７４件

・CTCのUDE ５２件

大和ハウス：概算見積もり・納期（FK2のアウトプット）をもっと早く

ユーザ部門に提示したい

メディアテック：優先度が高い案件からスピーディにFK2リソースを

アサインしたい

ＣＴＣ：急に求められる開発要員の追加を無理なくフレキシブルに

対応したい。

② Ｃｏｒｅ Ｃｌｏｕｄの作成

17

③ Ｃｏｒｅ Ｃｌｏｕｄからインジェクションを作成

ワークショップ前に準備・検討したこと（TOC思考プロセス活用）

ワークショップ前に準備・検討したこと

大和ハウス工業

ユーザ要望

_FK1

_FK2

メディアテック

PJ

受入・運用

CTC

大和ハウス工業

FK2あたりがボトルネック？

開発プロセス（詳細）

目的達成に向けて作成したインジェクションをワークショップを通じて

FWEST社、 Realization社のエキスパートと検討するためアメリカ・サンノ

ゼへ旅立ちました。

５．2015年度のFWEST/Ｒｅａｌｉｚａｔｉｏｎ社

コンサルによるワークショップ

最初に実施したこと（過去のデータ分析）

・過去のスループット、サイクルタイム、ＷＩＰの推移を分析

⇒ソリューションを検討する上でのベースラインとなる

FY2013

FY2014

FY2015

TP/Month

14.6

9.3

12.0

CT(days)

3.8

5.5

7.0

WIP

2.7

2.5

4.1

TP/Month

14.6

9.3

12.0

CT(days)

18.5

19.8

15.8

WIP

14.3

9.2

9.7

TP/Month

11.3

7.0

6.8

CT(days)

37.1

40.6

40.5

WIP

21.3

13.7

13.6

FK1

FK2

PJ

（前提）

・Ｄ

-SMART以外も含めた全プロジェクトの集計

・ＦＫ１，ＦＫ２はＣｏｎｃｅｒｔｏ管理していないため、管理表Ｅｘｃｅｌから算出

プロジェクト全体

平均18.5

平均4.3

(D-SMART)

（要求定義）

（概要設計）

（詳細設計・

開発）

最初に実施したこと（現状のデータ分析）

・現時点のＦＫ１，ＦＫ２，ＰＪのＷＩＰと、間のQueueの数をカウント

⇒ソリューションを検討する上でのベースラインとなる

大和ハウス工業

ユーザ要望

_FK1

FK2

メディアテック

PJ

受入・運用

CTC

大和ハウス工業

FK1

FK 2

PJ

FK1

Queue1

FK2

Queue2

PJ

CAP

ー

ー

１８

ー

１８

WIP

２０

５

１８

０

１０

Queue1

Queue2

Back Log

プロジェクト全体

BackLog

１１０

FK1

Queue1

_FK2

Queue2

_PJ

CAP

ー

ー

１８

ー

１８

WIP

２０

０

１８

０

１０

Small-PJ全体

BackLog

１１０

（分析ポイント）

①バックログは溜まっている（需要はある）

②ＦＫ２の後ろ（ＰＪの前）のＱｕｅｕｅが「0」

③ＰＪの開発体制には余力がある

（解決の方向性・仮説）

・ＦＫ２がボトルネックになっており、

ＦＫ２を加速させる必要がある

ＦＫ２を加速させることで、各社の課題も解決に向かいそう

FK1

FK 2

PJ

Queue1

Queue2

Back Log

ボトルネック

分析から見えてきたこと

FK1

FK 2

PJ

D-SMARTのターゲットの設定

FK1

FK 2

PJ

Back Log

Queue1

Queue2

Queue管理台帳で管理 Queue管理台帳で管理

（Base line）

ＴＰ=4

ＷＩＰ＝４（平均）

ＣＴ=１９d

（Target）

TP＝

６

（５０%ＵＰ）

ＷＩＰ＝４

ＣＴ＝

１３ｄ

（Little‘s lawから算出）

FK2の工期を短縮する（平均１３日とする）

D-SMARTのFK2

※リトルの法則:ＴＰ＝ＷＩＰ／ＣＴ

Queue1

Queue2

Back Log

ＰＪ待ちのＱｕｅｕｅはいくつが最適か？

ＦＫ２が加速し、ＰＪの前のＱｕｅｕｅが溜まり過ぎるのもよくない。

（ボトルネックがＰＪに移動するだけ）

では、Ｑｕｅｕｅはいくつ溜まっているのがよい状態なのか？

FK1

FK 2

PJ

Back Log

Queue1

Queue2

FK1

FK 2

PJ

Back Log

Queue1

Queue2

６．具体的実行プランの策定と実行

①FK2を加速させる

FK2（D-SMART案件）のＷＩＰ制限

WIPの制限を設ける

WIP=４に固定する

今日現在１２案件が動いているが、下記の対策の２）を選択する。

１）Freeze（今FK２進行中の案件を止める）

２）Bleed（投入をやめて、今進行中のものが終わるのを待つ）

（理由：今動いている案件のつは完了間近のため）

WIP

FK1

FK 2

PJ

Queue1

Queue2

Back Log

10月21日現在のCTC案件状況

FK2待ちのQueueの優先順位づけ

FK2待ちのQueueの優先順位づけ

決定機関：パイプラインコントロールミーティング

参加者；

・大和ハウス 情報システム部 部長・次長

・メディアテック プロジェクトマネジメント事業部長

OUTPUT：優先順位が付けられたQueue

FK1

FK 2

PJ

Queue1

Queue2

Back Log

優先順位付け

FK2待ちのQueueの優先順位づけ

・案件のQueuesを各グループ長

間で共有して優先順位付けを行い

ます。

ポートフォリオ状態による優先順位づけ（FK2フェーズ）

ポートフォリオ状態 のハードコピー

（優先順位

つけの説明）

_{・案件の納期、想定LT、優先度、PM}

リソースを勘案してパイプライン計算

をした結果により、着手順序を決定。

FK2をバッファを持ったアグレッシブプランで実施

FK2にConcertoを導入することにより、バッファ管理を行う。

LT＝１３日を基本とする。

１日遅れると３０%のバッファを失う。

今までPJのみConcertoを導入してアグレッシブプランで実施していた。

FK1

FK 2

PJ

Queue1

Queue2

Back Log

今回Concertoを導入

FK2の会議体

①タスクアップミーティング

②問題解決ミーティング

③バッファマネジメントミーティング

④オペレーションレビュー

FK1

FK 2

PJ

Queue1

Queue2

Back Log

4つの会議体

FK2の会議体（①タスクアップミーティング）

①タスクアップミーティング（電話

9:15-9:30 ）

目的(ゴール)

：

・残り日数の更新

・要支援項目(問題発見)

メンバー

：タスクマネージャ(ﾒﾃｨｱﾃｯｸPM)、作業者(CTC_FK2エキスパート)

アジェンダ

：

・質問

１．このタスク（またはチェック リスト項目）はあと何日で終わりますか？

２．必要に応じて：私に何か手伝えることはありませんか？

・タスクマネージャは、可能であれば担当部分におけるあらゆる問題を解決します。

できないのであれば、 エスカレーションします。

・タスクマネージャは予め決めたターゲット（今日なにをやるのか）を各作業者に伝

える。

エスカレーション経路

作業者

↓

タスクマネージャー （メディアテックPM）

↓

メディアテック ４部長

↓

メディアテック PM事業部長

↓

情報システム部・次長

FK2をバッファを持ったアグレッシブプランで実施

１日遅れると３０%のバッファを失うので問題発生時には

迅速にエスカレーションを行う為に明確な経路を決めました。

【目的】

FK2 KICKOFFミーティングを行うことで、改めてシステム導入

による目的や最終成果物を関係者で確認し、全員が短期間

の間、集中してフロー（流れ）を良くすることで、生産性をあげる。

【参加者】

ユーザ部門、メディアテック、情報システム部、ＣＴＣ

【メリット】

①PJの見える化（PJの状況が見える）

②参画すべき時期が明確になる

③齟齬の回避（思っていたのと違う、ほんとはこんなイメージなのに）

④ユーザ部門が早期にIT投資の効果を享受できる

FK2 キックオフミーティング

FK1

FK 2

PJ

Queue1

Queue2

Back Log

キックオフミーティング

①FK1シート読みあわせ、目的共有

（担当：情報S）

→開発起案書、FK1シート、システム概要

※事前準備としてシステム概要に関しては、

CTCに事前送付

②FK2スケジュール・成果物確認

（担当：PM）

→FK2コンチェルト投入※SOLに参照権限付与→済

・システム化案

・WBS（作業分解図）

・内部リソースアサイン

・開発環境の計画と手配

③FK2ミーティング日程設定(ex.週2回朝15分)

（担当：PM）

参加者：ＰＭ、SOL、ユーザ部門、CTCエキスパート

内容：進捗確認 → コンチェルト

問題解決 → ＱＡ表

ユーザレビュー日程確認

④FK2レビュー日程設定

（担当：PM）

→コンチェルト

FK2 キックオフミーティングの内容と役割

具体的実行プランのまとめ

１．FK2（D-SMART案件）のＷＩＰ制限

２．FK2をバッファを持ったアグレッシブプランで実施

（ Concertoを導入）

３．FK2の４つの会議体の定義

４．エスカレーション経路を明確化

５．FK2キックオフミーティングの実施

（解決の方向性・仮説）

ＦＫ２がボトルネックになっており、ＦＫ２を加速させる必要がある

具体的解決策を持って、帰国の途に

案件番号

Kick Off

FK2_St

FK2_LT BF消費

7720400

△

（個別で開催）

10/23

12日

50%

7733900

○

11/25

１５日

１７５％

7708100

○

11/2

33日

650％

１０月から１２月までのFK2の成果(サンプル)

2016年1月中旬までの成果（WIQ、WIPの推移）

サンノゼWS

FK1

FK 2

PJ

Back Log

Queue1

Queue2

Queue２に案件がたまりだした

新たな課題と今後の方策

今回のサンノゼ研修にもとづく試行と成果を踏まえて、

下記のような方向性で更なる改善を試みる。

■パイプラインＷＩＰ４の緩和

案件によっては、２名入れてもスピードが上がらないことがある。

１名で十分であったり、３名必要な場合があったりすることが分かった。

内容によって割り当てるエキスパートリソースの人数は可変にする。

ＷＩＰ制限についても、４～８の範囲に緩和する。

■ボトルネックがFK2からPJへ移りつつある。

Queue２が想定以上にたまりつつある。全体フローの流れをよく

するためにPJを加速させる必要がある。

今後の取り組み

2010年から繰り返し行っている改善で、各フェーズ（PJ、FK2）

個別の生産性は飛躍的に向上しているが、一方でプロジェクト全体

の生産性は必ずしも上がっているとは言えない現状です。

今回の取り組みで、全体フローの流れを止めない為には、各フェーズ

毎のマネジメントだけではなく、各フェーズ間にあるQueueマネジメン

トの重要性が解りました。

具体的な取り組み

１．FK2の取り組みをD-SMART以外の開発案件にも展開

２．全体フローの流れを意識したQueueマネジメントの実施