リーンカンファレンス2014「派生開発をリーンにするXDDP」

リーンカンファレンス2014

派生開発をリーンにするXDDP

2014/1/28

© Hitachi, Ltd. 2014. All rights reserved.

皆さんに質問があります
※挙手してくださいね※


1

Question

ソフト
関係の方？

2

Question

派生開発
をご存知の方？


3

Question

XDDP
をご存知の方？


機種A
Ver.1

機種A
Ver.2

機種B
Ver.2

機種B
Ver.1
機種C
Ver.1


９３％
※とあるデータ

母体の仕様欠落
派生開発には「母体ソースコードがある」という特徴がある
そして、往々にして母体の仕様の一部もしくは全てが失われている


短納期

合わない
プロセス

短納期

丸投げ
合わない
プロセス

短納期

デグレード
手戻り

丸投げ
合わない
プロセス

短納期

デグレード
手戻り

品質低

丸投げ
合わない
プロセス

短納期

納期

遅延
デグレード
手戻り

品質低

丸投げ
合わない
プロセス

短納期

納期

遅延
デグレード
手戻り

ヤル気
低下

品質低

丸投げ
合わない
プロセス

短納期

「ソフト」で「リーン」といえば

「アジャイル開発」?

派生開発では母体の存在が
単純にアジャイル開発
することも難しくする

何故上手くいかないのか？


納期遵守
高品質
納期遵守

部分理解

見付け次第
コーディング


高品質
納期遵守

新規開発崩し

高品質

全体理解

納期遵守

部分理解

高品質
納期遵守

高品質

全体理解

部分理解を前提とした
レビュー中心の手法


コーディング

留保

変更
プロセス

USDM

PFD

変更
ドキュメント

TM

変更
設計書

What/Why

変更要求を確認する

見付け次第
コーディング

Where

変更箇所を探す
部分理解

How

変更方法を考える

→まちがう

元に戻しにくい
→コード劣化

変更する

「ながら」作業
→ムダ

What/Why

Where


レビュー

レビュー

レビュー中心

レビュー

コーディング
留保

How


変更する

部分理解

時間の使い方
変更

What/Why

Where


レビュー

レビュー

How


レビュー

変更する

What/Why

Where

レビュー

新規開発プロセスとは
全く異なる

レビュー

How


レビュー

変更する

What/Why

追加機能要求仕様作成

参照

Where


追加機能分の設計

How

追加機能分の実装
変更する
追加機能分のテスト

変更分のテスト
統合テスト

変更プロセス

公式文書の更新

機能追加プロセス
※通常の新規開発と同じでよい

What/Why

追加機能要求仕様作成

参照

Where

How

追加機能分の設計

変更プロセスと
機能追加プロセスを


追加機能分の実装

変更する

変更分のテスト

分ける

追加機能分のテスト

統合テスト

変更プロセス

公式文書の更新

※通常の新規開発と同じでよい

PFD

D1

Process Flow Diagram

P1
D2

D1とD2か
らD3を作る

D3


追加機能分の
関数設計書*
元の
ソースファイル

XDDP全体像

スペック
アウト資料

ベースの機能仕
様書、設計書等

変更要求書
5
テストで確認
した後で正
式文書を更
新する

変更設計書
設計書等
モジュール情報

1
変更要求を
実現する

3
テストケース
を変更する

機能実現に関
する資料等

追加機能
要求書

追加機能要求書
(要求仕様書)*

TM
変更
要求仕様書

補足資料

2
追加機能の
要求を実現
する

更新後の

追加機能要求書
(要求仕様書)*

追加機能分の
設計書

追加機能分の
関数設計書*

機能追加分の

(更新)

(更新)

テストケース

4
プログラムを
結合してテ
ストする

新バージョンの


変更プロセス

元の
ソースファイル*

変更要求

1.2
変更箇所に
ついてソー
ス等を調査
検討する

調査資料

スペック
アウト資料*

変更設計書

TM
変更要求書

変更仕様

変更
要求仕様書

交差情報

変更要求
補助資料
他、関連資料

1.1
変更箇所を
仕様書に記
述する

1.5
変更設計書
を作成する

変更仕様
TM情報

(参照)

追加要求
変更仕様
元の

追加機能
要求仕様書

ソース
ファイル
単位

1.4
変更要求TM
を作成する

1.3
追加要求の
変更仕様を
抽出する

1.6
ソースコード
を一斉に変
更する

(参照)

スペック
アウト資料*

元の

更新後の


変更プロセスへ

要求TM
追加機能
要求仕様書
追加機能
要求書

(更新)

2.1
要求仕様書
を作成する

その他
資料

追加機能分
の関数設計書

機能実現に関
する関連資料

2.3
追加機能の
関数設計書
を作成する

2.2
追加機能を
設計する

追加機能分
の設計書

2.4
追加機能を
コーディング
する



What/Why

USDM
Where

TM

レビュー

レビュー

How

変更設計書

レビュー

変更する

要求

Req.1
理由
説明

ここに要求を記述
要求の背景や理由について記述

USDM

Req.1-1
ここに階層化された要求を記述
要求
理由
説明
<仕様分類 Group A>
Req.1-1-1 上記の要求に含まれるべき要求仕様を記述
Req.1-1-2
要求仕様 <仕様分類 Group B>
Req.1-1-3
Req.1-1-4
Req.1-2
要求
理由
説明
<仕様分類 Group C>
要求仕様
Req.1-2-2
Req.1-2-3

要求

Req.1
理由
説明

ここに要求を記述
要求の背景や理由について記述

USDM

Req.1-1
要求
理由
説明
Req.1-1-2

階層構造

理由

Req.1-1-3

Before
/After

Req.1-1-4
Req.1-2
要求
理由
説明
要求仕様
Req.1-2-2
Req.1-2-3

USDM
↓
要求

TM
A

B

C

D

E

F

G

Req.1
理由
説明
Req.1-1
要求
理由
説明
Req.1-1-1
Req.1-1-2

F1()

Req.1-1-3

要求

Req.1-1-4
Req.1-2
理由
説明

要求仕様 Req.1-2-1
Req.1-2-2

F5()
F3()

F4()

F2()

TM

USDM
↓
要求

A

Req.1
理由
説明

Req.1-1
要求
理由
説明
への Group A>
<仕様分類
Req.1-1-1
Req.1-1-2

影響

要求

Req.1-1-4
Req.1-2
理由
説明

C

D

E

F

G

全ての

仕様のコード

Req.1-1-3

B

モジュール
F1()

モジュールの F5()

固定

Req.1-2-2

F3()

F4()

F2()

USDM
↓
要求

変更設計書
A

B

C

D

E

F

G

Req.1
理由
説明
Req.1-1
要求
理由
説明
Req.1-1-1
Req.1-1-2
変更
設計書

変更
設計書
F1()

Req.1-1-3

要求

Req.1-1-4
Req.1-2
理由
説明

Req.1-2-2

変更
設計書

F5()
F3()

変更
設計書
F4()

変更
設計書

F2()

USDM
↓
要求

変更設計書
A

B

C

D

E

F

G

Req.1
理由
説明
Req.1-1
要求
理由
説明
の
Req.1-1-1
Req.1-1-2
変更
設計書

変更
設計書

変更箇所毎

変更方法の
変更
F1()

設計書

レビュー

設計書

Req.1-1-3

要求

Req.1-1-4
Req.1-2
理由
説明

Req.1-2-2

F5()

F3()

変更
設計書
F4()

変更
設計書

F2()

「XDDP」は「リーン」とは

別に考え出されたモノ
しかし
似た考え方を持っている

XDDPとリーンの関係
リーン製品開発
目的：
手戻りを減らすこと

XDDP
目的：
手戻りを減らすこと

方針：
意思決定を遅らせる
→収束は納期から逆算

方針：
コーディングを遅らせる
→コーディング開始は納期から逆算

アプローチ：
アプローチ：
学習を小さく回す
各レビュー（学習）を小さく回す
→LAMDAプロセスや
→部分理解を集めて全体理解に
インテグレーションイベント
調査対象：
・顧客の要求・ニーズ
・実現方式

調査対象：
・顧客の要求・ニーズ
・変更実現方式
・母体ソースコード

ソフト

XDDP

アジャイル

母体の依存性

ハード

短いイテレーション

リーン
製品開発

リーン生産
(TPS)

物理的な依存性

小ロット・一個流し

依存性高

独立性高

原則1：ムダをなくす
原則2：品質を作りこむ
原則3：知識を作り出す
原則4：決定を遅らせる
原則5：速く提供する
原則6：人を尊重する
原則7：全体を最適化する

System Creates

リーンカンファレンス資料（b）

株式会社システムクリエイツ
代表取締役清水吉男
URL=http://homepage3.nifty.com/koha_hp
shimz@nifty.com


© System Creates Inc.,

Page 55

System Creates

派生開発推進協議会(AFFORDD)の紹介


派生開発を混乱なく推進するための方法を探求






派生開発カンファレンス既に４回開催（次回6/6）
１０テーマほどの研究会活動












設立２０１０年２月

障壁の克服方法
「USDM」の入門􀀁
「XDDP」の入門
「XDDP」とテストプロセスの接続
SPLと「XDDP」の連携
「XDDP」とモデル駆動開発の融合
など

（www.xddp.jp)

研究会主催の「フォーラム」
XDDPやUSDMに関する勉強会（全国に出張）
関西に「地方部会」設立



Page 56

System Creates

保守開発
保守の定義・・・
保守のタイプ
是正保守
訂
正

バグの訂正

予防保守
緊急保守 *
適応保守

改
良

完全化保守
改良保守 *
* 2007年に追加された



軽微な改良
税率の変更
社内規定の変更
など
変更の影響が拡散しない
Page 57

System Creates

保守開発と派生開発

保守開発

派生開発

システム自体は競争していない

製品が競争している

状況の変化から変更が生じる

競争の中から変更が生じる

事前に予測された箇所

事前に予測されていない箇所

保守マニュアルを参考して変更

部分理解の状態で変更

最近は業務システム自体も
競争に晒されるようになって
きた



Page 58

System Creates

新規開発と派生開発
新規開発

派生開発
整合性

網羅性

仕様

整合性

仕様

網羅性

仕様

仕様

変更仕様

？

変更仕様
変更仕様

無矛盾性

仕様

仕様

無矛盾性

該当する
箇所を
変更する

該当する
箇所を
変更する

仕様を実現する
ために設計し、
実装する
ベースの
プログラム
コード

プログラム
コード

稼働中のシステム


Page 59

System Creates

派生開発の特徴
ベースのソースコードに「派生」させながら
変更を加えていく

系統図のような
ものができる



Page 60

System Creates

派生開発の難しさ
ソースコードが古く劣化
ベース
の

規模が巨大化
仕様書は失われている

短納期化
部分理解
事前に想定していな
い箇所の変更

必要な変更箇所を拾いきれない
変更が思わぬ箇所で影響する
変更同士が影響し合う

デグレード

機能の変更が品質に影響を与える


Page 61

System Creates

派生開発でやってはいけないこと
拙速なソースコードの変更
避けたい理由

拙速になる原因

変更方法は１つではない
間違っている可能性もある
他の変更に影響を与える
他の変更の影響を受ける

変更量（行数）を見積もっていない
変更箇所を書き留める手段を持たない
生産性を使えるプロセスを配置していない

変更が追加されたり
変更自体が変更されることがある

その変更が中止されることがある
ソースコードの劣化を進行させる

派生開発の作業を困難にする
競争からの脱落



Page 62

System Creates

ソフトの変更は簡単？
たかが変更！
さっさと変更して、テストで確認しながら
間違っていれば直して行けば良いじゃないか！

部分理解

バグ

ソースコード
の劣化

リリース不可

競争の敗北
市場からの撤退



Page 63

System Creates

派生開発もアジャイルでやればいいのでは
アジャイルで作れる
作り直しが簡単
機能が独立している
簡単に動かせる環境がある
アジャイルで作った方が良い

派生開発では、
これを満たさな
いことが多い

派生開発の難しさ

早く確認したいことがある
さっさとコードを書くことだけがアジャイルではない
その状況において最大限に機敏であること


Page 64

System Creates

XDDPとは？
派生開発の難しさを克服するように考えられた開発アプローチ
機能追加
変

更

「要求」が
異なる

異なるプロ
セスで対応

「変更３点セット」の導入・・・
「変更」箇所を書き留める最小限の成果物

変更の難しさに対応
バグの大幅削減
手戻り工数の削減


ソースコードの
拙速な変更を
回避

ソースコードの
劣化を遅らせる

「品質」と「生産性」
の向上
Page 65

System Creates

XDDPのアジャイル性
公式文書の更新（作成）は後回し
「変更３点セット」は派生開発の難しさを克服する最小手段
影響の見極め
レビューで仕上がり確認
手戻りの防止



ソースコードの変更

動作確認

Page 66

System Creates

リーン開発とXDDPの関係（１）

リーンソフト開発
決定をできるだけ遅らせる

XDDP（派生開発）
ソースコードの変更を遅らせる

最適な設計方法を選択

最適な変更方法を選択

変更コストを減らす

手戻りコストを減らす

最終工程は見積もれていて必要な工数を担保している
残りの時間の中で
設計方法を検討


残りの時間の中で
変更方法を検討
Page 67

System Creates

リーン開発とXDDP関係（２）

リーンソフト開発

XDDP（派生開発）

新規開発と派生開発の違いの中で・・・
許される時間の中で最高のものを作り
品質と生産性を同時に達成する



Page 68

リーンカンファレンス2014「派生開発をリーンにするXDDP」

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to リーンカンファレンス2014「派生開発をリーンにするXDDP」

Similar to リーンカンファレンス2014「派生開発をリーンにするXDDP」 (20)

Recently uploaded

Recently uploaded (9)

リーンカンファレンス2014「派生開発をリーンにするXDDP」