派生開発で実践する TPS131112)デンソー技研...This information is the exclusive property of DENSO CORPORATION. Without their consent, it may not be reproduced or given

This information is the exclusive property of DENSO CORPORATION. Without their consent, it may not be reproduced or given to third parties.

Confidential

(株) デンソー技研センター

プロジェクトマネージャー

古畑慶次

組込みソフトウェアにおける Agile 開発

～派生開発で実践する TPS ～

[email protected]

2013年 11月 12日＠ウィンクあいち

TPS/Agile 組込みソフト開発セミナー： (社) 持続可能なモノづくり・人づくり支援協会

持続可能なモノづくり・人づくり支援協会

TPS/Agile 組込みソフト開発セミナー


古畑慶次（こばたけいじ）

＜所属＞： (株) デンソー技研センター

プロジェクト・マネージャー / 産業カウンセラー

＜業務＞：技術支援・指導、研修企画、研修講師

－派生開発、プロセス設計、仕様化技術の技術支援・指導

－高度技術者（トップガン）研修の企画、運営

－産業カウンセラーとしてカウンセリングも行う

自己紹介 1 / 42

＜略歴＞

1988年： (株) デンソー入社（日本電装株式会社）

研究開発部・・・デジタル信号処理

1990年：基礎研究所・・・音声認識

1994年：通信技術部・・・ソフトウェア設計 / ハードウェア設計

（携帯電話 / PHS 親機）

2002年： ITS 技術部・・・プロセス改善（CMM / 現場改善）

2004年：デンソー技研センター＜現在に至る＞


デンソーにおける人づくり、価値づくり、物づくり

▪ 今枝誠・古畑慶次［著］

• 2013年9月26日発刊

• 日科技連出版社

• 定価（本体2,400円＋税）

▪ 主要目次

第１章時代の大きな変化

第２章日本流のものづくりの原動力

第３章日本のものづくりの課題

第４章人づくり

第５章価値づくり

第６章物づくり

第７章デンソーにおけるものづくり研修の実際

第８章次世代への提言

2,520円 2,000 円

2 / 42


Softec 2013 Asia 9/2-5 (2013)

▪ Software Testing Conference

場所：Sunway Resort Hotel & SPA

（クアラルンプール＠マレーシア）

• MSTB（Malaysian Software Testing Board）

主催によるテストカンファレンス

• ASQN（ Asia Software Quality Network）の

セッションで発表

http://www.qportal.com.my/softec/softecasia2013/SitePages/viewallspeakers.aspx

“ Process Improvement using XDDP ”

3 / 42


“ Best Paper award”（最優秀論文賞） 4 / 42

Process Improvement using XDDP- Application of XDDP to the Car Navigation System -

Keiji Kobata, Eiji Nakai, Takahiro Tsuda

5WCSQ Best Paper award


5WCSQ（第５回世界ソフトウェア品質会議） 5 / 42

http://www.xddp.jp/info_5wcsq.shtml

清水吉男氏システムクリエイツ

XDDPの提唱者

古畑慶次

デンソー技研センター

XDDPの実践者


▪ アジャイル開発と言えば・・・

本日の話題 6 / 42

「派生開発と Agile開発」＊ XDDPをTPSの視点でお話します

この本を推薦します

▪ アジャイル開発の教科書 • 前川直也、西河誠、細谷泰夫［著］

• ソフトバンククリエイティブ

• 定価（本体2,300円＋税）

アジャイル開発とXDDPを組み合わせる際には、それぞれの

本質を理解した上で、たとえば変更の実施をできるだけ遅

らせたり、影響を見極めるための “工夫” が必要になるだろう。

TPS（Toyota Production System）


Agenda

１. 派生開発を把握する

２. Agile 開発としての XDDP

３. XDDP における TPS

４. XDDP から TPS そして競争優位へ

7 / 42

“ Software Driven Innovation beyond TPS ”


１. 派生開発を把握する 8 / 42

１.１派生開発とは何か？

１.２ソフトウェア開発の現状

１.３派生開発の現実

１.４要求の多様性

１.５プロセスの問題

１.６派生開発の難しさ

１.７混乱する派生開発

１.８派生開発に対するソリューション


１.１派生開発とは何か？

▪ 「派生開発」：新規開発に対峙させた概念

• 従来製品（プログラムコード）に、製品の価値を高めるために

新しい機能を追加したり、これまでの機能を改善する開発

▪ 保守開発［JIS X 0161］［ISO14764］（http://www.jisc.go.jp/ ）

• ソースコードの修正／変更は、ソフトウェア・エンジニアリングでは

「保守」あるいは「保守プロセス」として扱われている

– 是正保守、予防保守、緊急保守、適応保守、完全化保守、改良保守

▪ 派生開発 vs 保守開発

• 組込みシステムの開発は「保守」では説明がつかない

9 / 42

「派生開発」＝保守開発＋（機能追加＋仕様変更＋バグ修正）


１.２ソフトウェア開発の現状 10 / 42

▪ ソフトウェア開発の大半は「派生開発」

開発新規開発

派生開発

新規開発：12%

派生開発：88%

＜ 2009年度開発行数＞

03年 05年 08年 11年

機種 D

機種 E

機種 A

機種 F

機種 B

機種 C

＜製品展開＞

既存製品への機能追加や

機能の変更・削除による製品開発

派生開発とは？

出典： 2009年組込みソフトウェア産業実態調査（IPA）

例）初期の携帯電話 → 今日のケータイ端末


▪ 開発プロセス

• 新規開発のプロセスで対応

１.３派生開発の現実 11 / 42

▪ 派生開発での開発項目

• ｢追加｣と｢変更｣の開発が混在

派生元の

ソフトウェア

変更

変更

削除

追加

※ 削除は変更に含む

要求書

追加変更

要求仕様書

設計書

ソースコード

プロセスの問題要求の多様性への対応


１.４要求の多様性

▪ 派生開発の要求は多種多様

• 機能･･･追加、削除、移植

• 仕様･･･変更、追加、削除

• 規模･･･小規模～大規模（様々）

• 制約･･･納期、コスト、要員、作業

▪ 要求への対応の難しさ

• ソースコードの状態や担当者の知見レベルの差

• 変更量によっては作業を分割 ← 情報共有の問題

• 要件によって完成状態を定義する必要も生じる

12 / 42

派生開発では多種多様な要求に対応しなければならない

合理的なプロセス、

成果物が求められる


▪ 新規開発と同じプロセスで開発

• 仕様書から設計ドキュメント、ソースコードを順に作成（変更）する

– 変更と機能追加は、要求が異なるにもかかわらず同じプロセス

• 新規開発のプロセスでは限界がある

– 変更点の影響範囲や関連箇所に気づくにくく、

変更モレや間違った変更が生じやすい

– 時間切れとなり、途中のプロセスを飛ばすケースも・・・

１.５プロセスの問題 13 / 42

【開発プロセス】＜機能追加＞＜変更＞

要件定義

設計

実装

テスト

要求仕様書

設計書

ソースコード

テスト

・・・新規作成・・・変更



「部分理解」


１.６派生開発の難しさ

▪ 既存のソフトウェアの変更

• 関係する機能の特定：仕様上、影響を受ける機能の抽出

• ソースコード変更の影響：ソースコード修正による影響範囲の特定

▪ 技術者の問題

• 技術力：ソースコードの読解力

• 経験：ドメイン知識（機能理解）

▪ ソースコード

• 劣化した派生元のソースコード

– 保守性を無視した開発

14 / 42

派生元のソフトウェア

変更

変更

削除

追加


１.７混乱する派生開発

▪ 混乱のメカニズム：ムリ・ムダ・ムラ

• 品質を確保する技術、ドメイン知識を持たない状態で

納期やコストの削減が求められている → 技術者の疲弊

15 / 42

手戻り・新規開発プロセス

（追加・抽出）

【ムダ】

・必要なプロセス（ルール・規定）

【ムラ】

部分理解（思い込み・勘違い）

・影響範囲の特定（仕様、ソースコード）

【ムリ】

開発プロセス【ムダ】と影響範囲の特定【ムリ】が問題


１.８派生開発に対するソリューション

▪ 派生開発の混乱要因

• 「開発プロセス」と「影響範囲の特定」

▪ 「現状」と「XDDP」

16 / 42

混乱要因現状 XDDP

開発プロセス・新規開発のプロセスを適用

（新規開発崩し）

・派生開発（変更・追加）に

対応したプロセス

影響範囲の特定・部分理解での作業

（思い込み、勘違い）

・思い込み、勘違いを

成果物とレビューでカバー

XDDP は派生開発に対する有効なソリューション


２. Agile 開発としての XDDP 17 / 42

２.１ Agile Software 開発宣言

２.２ Agile 開発とは？

２.３ Agile 開発から見た XDDP

２.４ XDDP とは？

２.５ XDDP における開発技術

２.６従来開発との比較

２.７ XDDP の開発プロセス

２.８変更プロセスの３点セット

２.９ XDDP の効果

２.10 XDDP における Agile 開発


２.１ Agile Software 開発宣言

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

18 / 42

Individuals and interactions “over” processes and tools

Working software “over“ comprehensive documentation

Customer collaboration “over“ contract negotiation

Responding to change “over“ following a plan


２.２ Agile 開発とは？

▪ 「Agile Software 開発」とは、

ある特定の開発手法を指すものではなく、

ソフトウェアの価値を最大限に高めるために、

エンジニア、マネージャ、顧客も含めて

取り組むべき「考え方」や「姿勢」です。

（前川直也他「アジャイル開発の教科書」より引用）

▪ ソフトウェアの価値を最大限に高める

• ソフトウェアの価値とは何か？

▪ 取り組むべき「考え方」や「姿勢」

• 「考え方」「姿勢」とは何か？

19 / 42

ソフトウェアの “価値”

「考え方」「姿勢」

＜keywords＞


２.３ Agile 開発から見た XDDP

▪ ソフトウェアの価値を最大限に高める（アジャイルの教科書）

• XDDP：QCD の同時達成（顧客価値）＝リードタイムの短縮

– Q（品質）：機能性、信頼性、使用性、効率性、保守性、移植性（ISO/IEC 9126）

– Quality in Use ：利用時の品質（ISO/IEC 25010）

▪ 取り組むべき「考え方」や「姿勢」（アジャイルの教科書）

• XDDP：問題解決（派生開発）へのアプローチ

– 開発プロセス：新規開発プロセスから脱却＝ムダの排除

– 影響範囲の特定：成果物とレビューでカバー＝自工程完結

▪ プロセス、開発技術

• プロセス：派生開発に対応（変更要求仕様書／TM(*)／変更設計書）

• 開発技術： USDM（仕様化技術）、PFD （プロセス設計のツール）

20 / 42

現場の工夫

実現

実現

TM (*) ：トレーサビリティ・マトリクス


２.４ XDDP とは？

▪ XDDP ： eXtreme Derivative Development Process

• 派生開発の要求に合った開発プロセス

• 清水吉男氏（システムクリエイツ）が提案

▪ 合理的なプロセス

• ２つの独立したプロセス

– 「変更」と「追加」のプロセス

• 品質と生産性を追求したプロセス

– 差分情報に基づいた開発

– ムダの徹底排除： Just in Time （TPS）

「必要なものを」「必要なとき」「必要なだけ」

• 部分理解を成果物とレビューでカバー

– 担当者の「思い込み」と「勘違い」は前提

21 / 42

派生元のソースコード

変更

変更

削除

追加

機能追加を受け

入れるための “変更”

技術評論社 (2007)

清水吉男氏著

「派生開発」を成功させる

プロセス改善の技術と極意


２.５ XDDP における開発技術

▪ XDDP トライアングル

• USDM （Universal Specification Describing Manner）

‒ 要求を適切に表現し、必要な仕様を引き出す表記法

‒ 要求と仕様を階層関係の中で捉え、仕様が漏れにくい構成

• PFD （Process Flow Diagram）

‒ 合理的な “成果物とプロセスの連鎖” を設計する技術

‒ 開発途中の変化に対して、「別案」のプロセスを考え出すツール

22 / 42

XDDP

PFD USDM

派生開発向けプロセス

プロセス設計技術

要求開発仕様化技術


２.６従来開発との比較 23 / 42

＜従来の派生開発＞

要求仕様書

設計書

追加機能

＜要件定義＞

＜設計＞

＜実装＞

＜ XDDP ＞

変更設計書

追加機能要求仕様書

変更要求

仕様書＋ＴＭ(*)

変更 (追加・変更・削除）

設計書

追加機能

ソースコード

要求

ＴＭ(*) ：トレーサビリティ・マトリックス

要求

変更

(追加・変更・削除）

＜追加＞＜変更＞

ソースコード


２.７ XDDP の開発プロセス 24 / 42

変更要求

仕様書を

作成する

変更要求仕様書＋TM (*)

元のソースファイル＊

関数

設計書

モジュール情報

設計書等

変更

要求書

追加機能

要求書追加機能の

要求仕様書

を作成する

機能実現

に関する

資料等＊

追加機能

を設計する

変更設計書

を作成する

変更

設計書

ソースコード

を変更する

更新後のソースファイル

追加機能をコーディング

する

追加機能の

ソースファイル

機能実現に関する資料等＊

ソースファイル

を結合して

テストする


元のソースファイル＊

テスト

ケース

ソース

ファイル

追加機能

要求仕様書

スペック

アウト資料

・・・テスト終了後に派生元の

機能仕様書、設計書にマージする

設計書

ＴＭ(*) ：トレーサビリティ・マトリクス

＜追加のプロセス＞

＜変更のプロセス＞


２.８変更プロセスの３点セット

▪ 変更に着目した成果物

• ソースコードの変更前に、３つの成果物で全ての変更内容を

それぞれの視点で抽出し、レビューする

25 / 42

TM (*) ：トレーサビリティ・マトリクス

レビュー(**) ：変更要求仕様書と TM は一緒にレビューをしてもよい

成果物カバー範囲内容レビュー(**)

変更要求仕様書 What Why

何をなぜ変更するか

どのような振る舞いをするか ○

○

TM (*) Where 変更仕様がどこにあるか ○

変更設計書 How 変更仕様をどのように修正するか ○ ○

TM

変更設計書


２.８.１変更要求仕様書－USDM－ 26 / 42

▪ 要求と仕様を階層構造で表現

• 要求

仕様

仕様

▪ 変更の理由を記述

• 適切な変更仕様を引き出す

▪ 表現の工夫（変更の表現）

• Before ／ After

・「～を ○○ に変更する」

・「～を削除する」

・「～を △△ に追加する」

Req.1

理由

説明

仕様

仕様

< グループ C> Req.1-2-1

Req.1-2-2

要求

説明

Req.1-2

理由

< グループ A>

< グループ B>

要求

< グループ D>

Req.1-1-1

Req.1-1-2

Req.1-1-3

Req.1-1-4

Req.1-2-3

Req.1-2-4

<Group 2>

要求

説明

Req.1-1

理由

<Group 1>

USDM：Universal Specification Describing Manner


２.８.２ TM －トレーサビリティ・マトリクス－ 27 / 42

▪ TM 上で変更仕様と変更設計書を対応させる

• 変更仕様に該当する箇所を TM 上に表す

• 変更箇所の関連性から影響範囲の気付きが得られる

＃ＡＢＣＤＥＦＧＨ

5

5.1 接続状況の表示の大きさを・・・に変更する ○ ●

・　・・・

5.4 表示用メモリの配置を・・・に変える

5.5 受信用データの区切りにコードを挿入する ○

変更要求仕様書

画面に通信記録の表示を追加する

変更設計書

A

変更設計書

D.1

変更設計書

D.2

変更設計書

F

変更設計書

H


２.８.３変更設計書

▪ 具体的なソースコードの変更方法を記述する

• 「関数名」単位で、具体的な変更方法を文章で記述する

– 「差分」（before/after）の記述に徹する ※ 変更設計書 ≠ 関数仕様書

• 変更に伴うテスト内容（単体テスト）も記述する

▪ 変更設計書の構成

（１）へッダー部・・・ TM の交点の情報、修正方針など

（２）構造の変更・・・データ構造、処理構造（関数呼び出し）の変更

（３）関数外の変更・・・関数外の「定義」の変更

（４）関数の変更・・・関数内の変更箇所

（５）確認内容・・・変更を確認する単体テスト項目

28 / 42

※ 『「派生開発」を成功させるプロセス改善の技術と極意』付録変更設計書テンプレート（P406-410）参照


２.９ XDDP の効果

▪ 工数分布の比較

• テストで不具合を摘出

• 設計、コーディング、テストを繰り返すことで品質を確保

• 上流に重点を置いた開発

• コーディングは、ほぼ1回で完了

29 / 42

＜従来のプロセス＞＜ XDDP ＞

第１週第２週第３週第４週第５週第６週第７週第８週

工数

第１週第２週第３週第４週第５週第６週第７週第８週

工数

第

１

第

２

第

３

第

４

第

５

第

６

第

７

第

８

man

-hou

r

テスト

テスト設計レビュー

テスト設計

コードレビューコーディング

設計レビュー

設計

XDDP は派生開発の有効なソリューションである

テストにより品質確保適切な仕様化により後戻りなし


私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

２.10 XDDP における Agile 開発 30 / 42

★XDDP：

対話できる成果物：変更の３点セット

★XDDP：

影響範囲を確実に修正：プロセスと技術

★XDDP：

★XDDP：プロセス設計：PFD （プロセスを設計するツール）

顧客とはFIXではなく合意：USDM （仕様化技術）


３. XDDP におけるTPS 31 / 42

３.１ソフトウェア開発における TPS

３.２ TPS の２本柱

３.３ Just-In-Time：開発プロセス

３.４プロセス設計：PFD

３.５自働化：自工程完結

３.６仕様化技術：USDM


３.１ソフトウェア開発における TPS

▪ 生産現場とソフトウェア開発

• フォード生産方式は、T型フォード（一車種）を生産するために最適化

• ウォータフォール型（1970年：Winston W. Royce）はフォード生産方式に匹敵

▪ フォード式の衰退原因

• 労働者のモチベーション低下

– 分業と標準化による単調な反復作業

• 多様化する消費者ニーズへの対応の遅れ

– 消費者が生産活動の活発化により裕福に

32 / 42

年代生産現場ソフトウェア開発

19世紀手工業家内 (問屋) 制手工業

20世紀

前半

大量生産フォード式

後半多品種生産トヨタ式（TPS）

－

ウォータフォール型

Lean／Agile 型

・TPS ・ Lean/Agile 開発

・・・

ソフトウェア開発の現状と似ていませんか？

分業と標準化／移動組立ライン


３.２ TPS における２本柱

▪ TPSの基本概念

• 基本理念：お客様第一

• 人材育成

– 「あるべき姿」に向かって改善し続ける能力の向上＝企業の持続的成長

① Just-In-Time

• リードタイムの短縮

– 必要なモノを､必要な量､必要な時に作る

② 自働化

• 品質の向上

– 品質は工程で作り込む＝自工程完結

33 / 42

① Just-In-Time ② 自働化人的能力の向上

実践

育成

・ムダの徹底排除・見える化・モノと情報の流れ・システム全体の俯瞰・乱流から清流へ・平準化・自己完結作業・ Push／Pull ・ TLSC

＜考え方・ツール＞


３.３ Just-In-Time：開発プロセス

▪ XDDP における Just-In-Time

• 必要なモノを､必要な量､必要な時に作るプロセス

• 変更のプロセス

34 / 42 XDDP


トレーサビリティ

マトリクス

変更設計書

① 必要なモノ・・・変更情報

② 必要な量・・・成果物のムダのない構成

③ 必要な時・・・開発中は変更情報に関する

成果物を各工程で作成

＜成果物＞

テスト終了後に派生元の

機能仕様書、設計書に統合

・変更内容の確認（What）

・変更場所の特定（Where）

・変更方法の検討（How）

＜変更手順＞

リードタイムの短縮（QCDの同時達成）を実現


３.4 プロセス設計：PFD

▪ XDDP が提供するプロセス表記法：PFD

• 情報の流れの見える化

• システム全体の俯瞰

35 / 42

変更要求

仕様書を

作成する

モジュール情報

設計書等

変更

要求書

機能実現

に関する

資料等＊

変更設計書

を作成する


変更

設計書


＋TM (*)

スペック

アウト資料

ソースコード

を変更する

更新後のソースファイル

元のソースファイル

ＴＭ(*) ：トレーサビリティ・マトリクス

追加機能

要求仕様書

XDDP

＜ PFDで表現した変更プロセス＞

ムダの徹底排除／平準化

乱流からの清流へ／ Value Stream

Pull に対応した仕事の流れ


３.５自働化：成果物とレビュー

▪ XDDP における自働化

• 品質は工程で作り込む＝自工程完結

– 不具合を作らない

– 不具合を次の工程に流さない

– 工程の問題を顕在化させ再発防止する

• 変更点のトレーサービリティを確保

36 / 42 XDDP

成果物の工夫とトレーサビリティの確保による品質向上

「思い込み」と「勘違い」をレビューで防ぐ成果物

＜XDDP＞

＊変更の3点セット

・変更要求仕様書／TM／変更設計書

Req.1

理由

説明

仕様

仕様

Req.1-2-1

Req.1-2-2

説明

Req.1-2

理由

<グループ A>

<グループ B>

<グループ C>

Req.1-2-3

Req.1-2-4

<Group 1>

要求

要求

<グループ D>

Req.1-1-1

Req.1-1-2

Req.1-1-3

Req.1-1-4

<Group 2>

要求

説明

Req.1-1

理由

③ 変更設計書

＃変更要求・仕様 A B C D E F G H

５画面に通信記録の表示を追加する

5.1 接続状況の表示の大きさを・・に変更する

. ・・・

5.4 表示用メモリの配置を・・に変える

5.5 受信時データの区切りにコードを挿入する

② TM （トレーサビリティ・マトリクス） ① 変更要求仕様書


３.６仕様化技術：USDM

▪ XDDP が提供する仕様表記法：USDM

• 要求と仕様を構造化して表現することにより、

顧客要求 (Push) から本当に必要な仕様 (Pull) を引き出す

– 要求と理由により顧客要求の妥当性を確認

– 顧客要求を要求に書き換え仕様を抽出 → 顧客から仕様を引き出す

37 / 42 XDDP

顧客要求 C-Req.1

要求

Req.1

理由

説明

＜グループ１＞

仕様

Req.1-1

Req.1-2

Req.1-3

＜グループ２＞

仕様

Req.2-1

Req.2-2

Req.2-3

＜顧客要求＞

USDM

・顧客からの仕様の抽出

・抜け漏れのない仕様化

＜要求仕様書＞


４. XDDP から TPS そして競争優位へ 38 / 42

４.１ Agile､ XDDP､ TPS

４.２派生開発における競争優位

４.３人的能力の向上

４.４競争優位の実現－XDDP､TPSを越えて－


４.１ Agile､XDDP､TPS 39 / 42

派生開発

Agile 開発

ソフトウェアの

価値を最大限に

高めるための

「考え方」「姿勢」

XDDP

お客様第一

① Just-In -Time

② 自働化

人的能力の向上

基本的な「考え方」

・プロセス・成果物

＜Lean 開発＞

TPS

＊SCRUM ＊TDD

＊朝会＊アンドン＊XP

＊CI ＊かんばん

＊ユーザーストーリー

＊プラニングポーカー

＊バーダウンチャート

＊見える化

＊TLSC ＊ムダ取り

＊PFD ＊USDM ＊TM


４.２派生開発における競争優位 40 / 42

時間

成

果

レッドオーシャン

ブルーオーシャン

XDDP

負けないための手法

＝

ブレークスルー

・日立・ NEC ・富士ゼロックス他

5WCSQ Best Paper

TPS

Agile 開発

＝人的能力の向上

・「あるべき姿」を求めて改善し続ける人間集団を作る・ TPS実現のツールや技術方法論の実践を通して、改善力、現場力を向上する

＜人材育成＞

企業の持続的成長


４.３人的能力の向上

▪ 「あるべき姿」を目指し改善し続ける人間集団を作る

41 / 42

顧客重視

ＴＱＭ活動

継続的改善

全員参加改善意識の

高揚仲間意識の醸成

問題意識の共有化

コミュニケーション

現場のTQM活動４つのマネジメント革新の思想

人間性尊重による基づく自律と共助＝調和型自律分散システム


４.４競争優位の実現－XDDP､TPSを越えて－ 42 / 42

“ Software Driven Innovation beyond TPS ”

実現

プロセス、開発技術

考え方、姿勢

ソフトウェアの

価値の最大化

Agile 開発

人的能力の向上

実践

現場の工夫

XDDP “ 愚者は経験に学び、賢者は歴史に学ぶ“

・すべての活動は人間・機械系（ICTを含む）で成立

・全ての活動は人に依存

（ビスマルク：初代ドイツ帝国宰相）

改善し続ける人間集団

TPS

育成実現


参考文献 References / 42

▪ 清水吉男：「派生開発」を成功させるプロセス改善の技術と極意, 技術評論社, 2007

▪ 前川直也、西河誠、細谷泰夫：アジャイル開発の教科書, ソフトバンククリエイティブ, 2013

▪ 古畑慶次：開発現場で使うXDDP ～XDDPのエッセンスから導入、展開まで～, ソフトウェア品質シンポジウム 2013 併設チュートリアルテキスト

▪ 古畑慶次：そうなんだ！XDDP, 派生開発カンファレンス2013 チュートリアルテキスト • http://www.xddp.jp/conference2013/xddp2013_tutorial.pdf

▪ 古畑慶次：現場へのXDDPの適用と効果－プロセス改善によるQCDの同時達成－, 第４回組込みシステム技術講演会（組込みシステム技術協会中部支部）, 2013

▪ 加藤由之他： XDDP によるソフト派生開発のQCD 向上活動, ソフトウェア品質シンポジウム 2008 • http://www.juse.or.jp/software/pdf/sqip2008/ippan_06_1.pdf

▪ 黒岩惠： TPS/リーン方式の基本原則とアジャイルソフトウェア開発への適用, (社) 持続可能なモノづくり・人づくり支援協会(ESD21), 2012

▪ 黒岩惠：モノづくりのトヨタ生産方式を越えて “競争優位のTPS/リーン方式とIT化によるビジネスイノベーション”, TECH Biz EXPO 2011, これからの「モノづくり」を考える4日間講演会 • https://www.esd21.jp/news/Biz-TECH10月19日講演(黒岩).pdf


Confidential

ご静聴ありがとうございました

(株) デンソー技研センター

プロジェクトマネージャー

古畑慶次

[email protected]

2013年 11月 12日＠ウィンクあいち

TPS/Agile 組込みソフト開発セミナー： (社) 持続可能なモノづくり・人づくり支援協会

Documents

派生開発で実践する TPS131112)デンソー技研...This information is the exclusive property of DENSO CORPORATION. Without their consent, it may not be reproduced or given