20140630...

© Hitachi, Ltd. 2014. All rights reserved.

2014/6/30

マフィアオファー事例報告～XDDPのマフィアオファーほか～

株式会社日立製作所横浜研究所組込みソフトウェア研究部

八木将計

© Hitachi, Ltd. 2014.

皆さんに質問があります

※挙手してくださいね※


ソフト関係の方？

Question1


派生開発をご存知の方？

Question2


XDDPをご存知の方？

Question3


機種BVer.1

機種AVer.2

機種AVer.1

機種CVer.1

機種BVer.2


９３％※とあるデータ


全体(母体)の仕様欠落影響が読めない

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


短納期


短納期合わない

プロセス



プロセス

丸投げ



プロセス

丸投げ

デグレード

手戻り



プロセス

丸投げ

デグレード

手戻り品質低



プロセス

丸投げ

デグレード

手戻り品質低

納期遅延



プロセス

丸投げ

デグレード

手戻り

ヤル気低下

品質低

納期遅延


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


高品質納期遵守

部分理解

見付け次第コーディング

納期遵守



全体理解

新規開発崩し

高品質



高品質

納期遵守部分理解

全体理解



部分理解

全体理解高品質

納期遵守


部分理解を前提とした

レビュー中心の手法


コーディング

留保

変更プロセス

変更ドキュメント

PFD

USDM

TM 変更設計書


変更要求を確認する

変更箇所を探す

変更方法を考える

変更する

What/Why

Where

How

見付け次第コーディング

部分理解→まちがう

元に戻しにくい

→コード劣化

「ながら」作業

→ムダ





変更する

What/Why

Where

How

レビュー

レビュー

レビュー

部分理解

レビュー中心

コーディング留保

時間の使い方変更


コーディング

留保

変更プロセス


PFD

USDM

TM 変更設計書





変更する

What/Why

Where

How

レビュー

レビュー

レビュー





変更する

What/Why

Where

How

レビュー

レビュー

レビュー

新規開発プロセスとは

全く異なる


統合テスト

公式文書の更新

追加機能要求仕様作成

追加機能分の設計

追加機能分の実装

追加機能分のテスト




変更する

What/Why

Where

How

変更分のテスト

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

参照

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


統合テスト

公式文書の更新

追加機能要求仕様作成

追加機能分の設計

追加機能分の実装

追加機能分のテスト




変更する

What/Why

Where

How

変更分のテスト

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

参照

変更プロセスと

機能追加プロセスを

分ける

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


P1D1とD2からD3を作る

D1

D2

D3

PFDProcess Flow Diagram


1変更要求を実現する

元のソースファイル

変更要求書

機能実現に関する資料等

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

機能追加分のソースファイル

更新後のソースファイル

追加機能要求書

スペックアウト資料

変更設計書

TM

変更要求仕様書

XDDP全体像

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

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

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

設計書等モジュール情報

補足資料

追加機能分の設計書

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

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

テストケース

新バージョンのソースファイル

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

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

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

(更新)

(更新)


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

元のソースファイル*

変更要求書

補助資料他、関連資料

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

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

1.4変更要求TMを作成する

1.5変更設計書を作成する

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



更新後のソースファイル追加機能

要求仕様書

スペックアウト資料*

スペックアウト資料*

TM

変更要求仕様書

変更設計書

変更要求

変更要求

追加要求

変更仕様

変更仕様

変更仕様

調査資料

TM情報

交差情報ソースファイル単位

(参照)

(参照)

変更プロセス


2.2追加機能を設計する

追加機能要求書

その他資料

2.1要求仕様書を作成する

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

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

する

ソースファイル

追加機能分の設計書

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

(更新)

機能追加プロセス

追加機能分の関数設計書

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

変更プロセスへ


コーディング

留保

変更プロセス


PFD

USDM

TM 変更設計書





変更する

What/Why

Where

How

レビュー

レビュー

レビュー





変更する

What/Why

Where

How

レビュー

レビュー

レビュー

USDM

TM

変更設計書


要求

Req.1 ここに要求を記述

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

説明

要求

Req.1-1 ここに階層化された要求を記述

理由

説明

要求仕様

<仕様分類 Group A>

Req.1-1-1 上記の要求に含まれるべき要求仕様を記述

Req.1-1-2

<仕様分類 Group B>

Req.1-1-3

Req.1-1-4

要求


理由

説明

要求仕様

<仕様分類 Group C>


Req.1-2-2

Req.1-2-3

USDM


要求

Req.1 ここに要求を記述

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

説明

要求


理由

説明

要求仕様



Req.1-1-2


Req.1-1-3

Req.1-1-4

要求


理由

説明

要求仕様

<仕様分類 Group C>


Req.1-2-2

Req.1-2-3

USDM

階層構造理由

Before/After


A B C D E F G

要求

Req.1

理由

説明

要求Req.1-1理由説明

要求仕様


Req.1-1-1 F1()Req.1-1-2


Req.1-1-3 F5()

Req.1-1-4 F3()

要求

Req.1-2理由

説明

要求仕様<仕様分類 Group C>

Req.1-2-1 F4() F2()Req.1-2-2

TMUSDM↓


A B C D E F G

要求

Req.1

理由

説明


要求仕様


Req.1-1-1 F1()Req.1-1-2


Req.1-1-3 F5()

Req.1-1-4 F3()

要求

Req.1-2理由

説明


Req.1-2-1 F4() F2()Req.1-2-2

TMUSDM↓

仕様のコード

への影響全てのモジュール

モジュールの

固定


A B C D E F G

要求

Req.1

理由

説明


要求仕様


Req.1-1-1 F1()Req.1-1-2


Req.1-1-3 F5()

Req.1-1-4 F3()

要求

Req.1-2理由

説明


Req.1-2-1 F4() F2()Req.1-2-2

USDM↓

変更設計書

変更設計書

変更設計書変更

設計書


設計書


A B C D E F G

要求

Req.1

理由

説明


要求仕様


Req.1-1-1 F1()Req.1-1-2


Req.1-1-3 F5()

Req.1-1-4 F3()

要求

Req.1-2理由

説明


Req.1-2-1 F4() F2()Req.1-2-2

USDM↓

変更設計書

変更設計書


設計書


設計書

変更箇所毎の

設計書変更方法の

レビュー


XDDPとは，

派生開発において，品質低下，納期遅延の問題に対処する手法．

従来の変更箇所を見付け次第変更するといった

開発とは異なり，コーディングを留保し，その

間で徹底的にレビューを行うことで，手戻りがな

くなるため，納期も守りながら品質も維持することが可能になる．

そのための効率的なドキュメント(変更3点セット)や変更プロセスを含んでいる．


書籍：「派生開発」を成功させるプロセス改善の技術と極意

派生開発推進協議会HP


01. 障壁の克服方法02. 「USDM」の入門03. 「XDDP」の入門04. 「XDDP」とテストプロセスとの接続05. 影響箇所の気付き06. Agile開発との連携07. ハードの派生開発への適用08. 大規模システムへの効果的対応09. ビジネス領域での「XDDP」の活用10. 「USDM」とユースケースの連携11.上位の要件開発技法と「USDM」の連携12. ソフトウェア品質要求の定義13. 「USDM」のリスク管理への応用14. SPLと「XDDP」の連携16. 「XDDP」の支援ツール15. 「USDM」の支援ツール17. 「PFD」の支援ツール18. USDMと形式言語との接合における曖昧表現の克服19. 派生開発におけるスペックアウトの仕方20. 「XDDP」とモデル駆動開発の融合21. 「PFD」によるプロセス設計

研究

テー

マ


01. 障壁の克服方法02. 「USDM」の入門03. 「XDDP」の入門04. 「XDDP」とテストプロセスとの接続05. 影響箇所の気付き06. Agile開発との連携07. ハードの派生開発への適用08. 大規模システムへの効果的対応09. ビジネス領域での「XDDP」の活用10. 「USDM」とユースケースの連携11.上位の要件開発技法と「USDM」の連携12. ソフトウェア品質要求の定義13. 「USDM」のリスク管理への応用14. SPLと「XDDP」の連携16. 「XDDP」の支援ツール15. 「USDM」の支援ツール17. 「PFD」の支援ツール18. USDMと形式言語との接合における曖昧表現の克服19. 派生開発におけるスペックアウトの仕方20. 「XDDP」とモデル駆動開発の融合21. 「PFD」によるプロセス設計

研究

テー

マ障壁の克服方法


関係者問題質問・重大質問 KEYWORD 解決状態 KEYWORD 実行による副作用の懸念事項副作用の懸念事項への対応策

開発者，マネージャー，経営者，顧客

後工程やリリース後にデグレードや変更間違いによる手戻りが多いですか？

デグレードと変更間違いによる手戻り

コーディング後の手戻りが少ないコーディングの留保

工数が増える/追加の作業が増える

・レビューによって手戻りが減るので，工数増加はしないというロジック/事例を説明する・PFDによりプロセス・ドキュメント体系をプロジェクト毎に適切に設計するので，作業の無駄が減る・スモールスタートで検証してみる

開発者，品質保証部

開発プロセスが実情にあっておらず，無駄だと感じる作業がありますか？

開発プロセスの無駄

派生開発に適したプロセスで無理・無駄がない

変更用プロセス

コーディングを留保しすぎて，納期を守れなくなる

・サイズ見積りに基づく，工程見積りにより，コーディング開始時期を明確に定義する．これにより納期を守れないという状況は発生しづらいことを説明する

開発者，マネージャー

(時間がないや納期が怖いなどの理由で)ソースコード変更の精査は担当者任せになっていませんか？

担当者任せになる変更精査

変更方法が十分かつ効率的に設計・レビューされている

変更用ドキュメント(変更3点セット)

自組織の開発に適さない可能性がある/本当に自組織で効果があるかわからない

・スモールスタートで検証してみる・既存開発のデータを用いて，効果をシミュレーションしてみる


ささいな変更だと思われたものでも納期に間に合わないことが多いのではないですか？

納期遅延見積り通りに開発が終了している見積り通りの開発失敗のリスクがある

・スモールスタートで検証してみる・既存開発のデータを用いて，シミュレーションしてみる

開発者，マネージャー，経営者，顧客，品質保証部

ソフトの品質がどんどん劣化していませんか？

ソフト品質の低下ソフト品質が維持/改善している

ソフト品質の維持/改善

過大な効果を期待してしまう・過大な期待をさせないように，トップ，マネージャーに正確な情報を入力する・スモールスタートで早期に適用効果を見積る


開発者のモチベーションが低下していませんか？

モチベーションの低下

開発者が開発の意義を感じているモチベーションの向上

定着しない・エバンジェリストを育成する・組織的に定着化を図る・トップダウンで適用を宣言する

成功後に他プロジェクトに巻き込まれる

・トップ，マネージャーに他プロジェクトに巻き込まないという確約をもらう

中間目的障害の懸念事項への対応策(中間目的達成のためのアクション)

(1)社内関係者の合意を得る・社内関係者に対して，本マフィアオファーシートを用いて合意を取る・対象者に合せてマフィアオファーシートをカスタマイズする

(2)社外関係者の合意をとる・社外関係者に対して，本マフィアオファーシートを用いて合意を取る・Win-Winになるような方法の検討のために，対象者に合せてマフィアオファーシートをカスタマイズする

(3)組織標準や従来のやり方との対応をとる

・組織標準のドキュメントやプロセスとの対応関係を取る(USDMは○○仕様書に対応する，など)・XDDPを組織にテーラリングした事例を参考にする

(4)導入工数を確保する・工数/予算の決定権のある人物にXDDPをプレゼンして，工数/予算を貰う・スモールスタートで検証して，必要工数/コストを見積る・既存開発のデータを用いて，擬似的に検証し，必要工数/コストを見積る

(5)スキルを習得する

・AFFORDD主催の勉強会に参加する・独自の勉強会を開催する・エバンジェリストを置いて，展開を推進する・XDDPのスキルは，基本的には「書く」だけのことであることを認識してもらう

対立実行を妨げる障害の懸念事項

社内関係者(開発者/マネージャー/品質保証部/経営者)と合意を得る必要がある

社外関係者(関連会社/顧客)との調整が必要になる

組織標準や従来のやり方と異なる

導入工数が確保できない/コストが高い

スキルがない

XDDPとは，派生開発において，品質が低下し，納期も守れなくなるという問題に対処する手法．従来の変更箇所を見付け次第変更するといった開発とは異なり，コーディングを留保し，その間で徹底的にレビューを行うことで，手戻りがなくなるため，納期も守りながら品質も維持することが可能になる．そのための効率的なドキュメント(変更3点セット)や変更プロセスを含んでいる．

■提案するソリューション：XDDP■提案対象者：派生開発において納期遵守に困っているソフト開発関係者

デグレードや変更間違いによる手戻り，開発プロセスの無駄，担当任せのソースコード変更精査といった問題があるとのことですが，XDDPは，コーディングの留保，変更専用のプロセス，変更専用のドキュメント(変更3点セット)により，解決することが可能です．これらの問題が解決できれば，ソフト品質低下，納期遅延，モチベーションの低下といった重大な問題を解決できます．さらにそのことで，来たるべき新規開発への備えも可能になります．

問題質問

重大質問

ポジショニングトーク提案するソリューションと想定提案対象者コンセプト説明文

A

品質の高い製

品を納期とおり

にリリースする

B

納期を守る

C

品質を維持す

る

D

部分理解でコー

ディングする

D'

全体理解でコー

ディングする


XDDPマフィアオファーシートから説明資料を作成・提案試行してみました

・対象者：T1メンバーの組織の開発者& 派生開発推進協議会勉強会参加者

・対象者人数：23名(内アンケート回答者：22名)

・検証方法：アンケート


XDDPをやってみたいと思います

か？

非常にそう思う

3名

そう思う16名

そう思わない3名


第1階層

第2階層

第3階層

第4階層

第5階層

第6階層

XDDPやってみたい

XDDPやりたくない


Q1 提案を受ける前よりXDDPを導入してみたいですか？Q2 提案を受ける側としてどの提案方法が合意しやすいと思いますか？Q3 提案をする側として，どの提案方法が合意を得やすいと思いますか？Q4 ご自身の組織や他者にマフィアオファーできると思いますか？

XDDPマフィアオファーワークショップアンケート結果

0% 20% 40% 60% 80% 100%

Q1

Q2

Q3

Q4

そう思う

そう思う

マフィアオファー


無回答

無回答

無回答

無回答

そう思わない

0% 20% 40% 60% 80% 100%

Q1

Q2

Q3

Q4 そう思う

そう思う



無回答

無回答

無回答

無回答


非常にそう思うそう思わない

アフォードフォーラム(2014/2/21) 派生開発カンファレンス2014(2014/6/6)アンケート回答数:7名アンケート回答数:8名

XDDPマフィアオファーワークショップアンケート結果

0% 20% 40% 60% 80% 100%

Q1

Q2

Q3

Q4

そう思う

そう思う



無回答

無回答

無回答

無回答

そう思わない

0% 20% 40% 60% 80% 100%

Q1

Q2

Q3

Q4 そう思う

そう思う



無回答

無回答

無回答

無回答


非常にそう思うそう思わない

アフォードフォーラム(2014/2/21) 派生開発カンファレンス2014(2014/6/6)アンケート回答数:7名アンケート回答数:8名


[マフィアオファーの使い所]

プレゼン作りに論文執筆にその他資料作りに


プレゼン作りに


解決策 XDDP

対象派生開発において納期遵守に困っているソフト開発関係者

関係者Ｉ：問題に合意する KEYWORD III：解決策で問題が解決されることに合意する KEYWORD




コーディング後の手戻りが少ないと良いですか？

コーディングの留保






派生開発に適したプロセスで無理・無駄がないと良いですか？







変更方法が十分かつ効率的に設計・レビューされていると良いですか？






納期遅延見積り通りに開発が終了すると良いですか？

見積り通りの開発失敗のリスクがある




ソフト品質の低下

ソフト品質が維持/改善していると良いですか？






開発者が開発の意義を感じていると良いですか？

モチベーションの向上




確認質問

ソフトウェアの派生開発を行っていますか？

品質低下や納期遅延で困っていますか？

IV：解決策により重大な副作用がないことに合意する

・社内関係者に対して，本マフィアオファーシートを用いて合意を取る・対象者に合せてマフィアオファーシートをカスタマイズする

II：解決策の方向性に合意する

(1)社内関係者の合意を得る

(2)社外関係者の合意をとる


(4)導入工数を確保する





問題質問

重大質問

ポジショニングトーク提案する解決策と想定提案対象者コンセプト説明文


Ｖ：解決策の実行を妨げる障害を克服する方法に合意する

・社外関係者に対して，本マフィアオファーシートを用いて合意を取る・Win-Winになるような方法の検討のために，対象者に合せてマフィアオファーシートをカスタマイズする


・工数/予算の決定権のある人物にXDDPをプレゼンして，工数/予算を貰う・スモールスタートで検証して，必要工数/コストを見積る・既存開発のデータを用いて，擬似的に検証し，必要工数/コストを見積る

派生開発を行う

目先の作業の

完了を優先す

る

手戻りの防止を

優先する

見付け次第

コーディングす

る方法を活用す

る

XDDPを活用す

る

導入メッ

セージ

位置付け

想定問答

想定問答

ターゲット聴衆

要するに要するに


ターゲットの明確化ターゲット聴衆のプレゼン前後を想定する

3つの特徴的機能メッセージを絞り込んでシンプルにする

ストーリー構築情報伝達の最強ツール「ストーリー」を語る


“最も重要なことはメッセージを絞り込むこと”

— ガー・レイノズル(出典:書籍「シンプルプレゼン」)


“ストーリーは情報を伝える最強のツールであり，ほかのどんな芸術形態よりも効果的で，ゆるぎないものです” — ナンシー・デュアルテ

(出典:書籍「ザ・プレゼンテーション」)

“ストーリーは，聴衆と深いレベルでつながる際に欠かせません”

— ガー・レイノズル(出典:書籍「シンプルプレゼン」)


ターゲットの明確化ターゲット聴衆のプレゼン前後を想定する

3つの特徴的機能メッセージを絞り込んでシンプルにする

ストーリー構築情報伝達の最強ツール「ストーリー」を語る


問題質問良い状態特徴的機能

拙速な変更により，後のデグレードや変更間違い等の手戻りが多い

品質向上のためにレビューの時間を十分に確保できる

コーディングの留保

開発プロセスが実情に適さない



ソースコード変更の精査は担当者任せ



重大質問

ささいな変更だと思われたものでも納期に間に合わない

ソフトの品質がどんどん劣化

開発者のモチベーションが低下



プロセス

丸投げ

デグレード

手戻り

ヤル気低下

品質低

納期遅延

問題質問

問題質問

問題質問

重大質問

重大質問

重大質問


派生開発を行う

目先の作業の完了を優先する

手戻りの防止を優先する

見付け次第コーディングする方法を

活用する

XDDPを活用する

※通常の対立解消図とは用途が違います！


ソフトウェア開発を行う

顧客要求が不明な中，早期に小さく手戻らせ，後の影

響を軽減する

母体仕様が不明な中，影響範囲をできる限り考慮して

手戻りを防ぐ

アジャイル開発を活用する

XDDPを活用する

※通常の対立解消図とは用途が違います！


問題質問問題質問重大質問重大質問

特徴的機能特徴的機能



影響範囲がわからないのではないですか？

影響範囲の気付き「崩し」の情報(機能レベル/作りレベルの悪さの情報)

リスクもわからないのではないですか？

リスクの明確化(+影響範囲の気付き)

「意図」の情報(どうするか？の情報，手を入れる場所/テストする場所/してない場所など)

ベニア板バレーになってませんか？

派生開発の効率化情報の伝達/蓄積

テスト: 全部テストする／過去の回帰テスト全部やる設計: 変更箇所を見付け次第コーディングする


ターゲットの明確化 3つの特徴的機能ストーリー構築

ターゲット聴衆に合せて

特徴的機能とストーリーを整理



抵抗/歪曲される受け入れやすい抵抗の6階層

上手く伝わらないわかりやすいキーワード(呪文)

人に依存する属人性がない営業トークの手順

計画が立たない拡大戦略が立つ競争戦略

提案順が不明確手順が明確提案プロセス

型通りな押し売り個別事情に対応仮説検証

ベンチマーク不明他との差が明確ポジショニングトーク



抵抗/歪曲される受け入れやすい抵抗の6階層

上手く伝わらないわかりやすいキーワード(呪文)

人に依存する属人性がない営業トークの手順

計画が立たない拡大戦略が立つ競争戦略

提案順が不明確手順が明確提案プロセス

型通りな押し売り個別事情に対応仮説検証

ベンチマーク不明他との差が明確ポジショニングトーク

ソフトウェアシンポジウム(SS2014)

ソフトウェアプロセスエンジニアリングシンポジウム(SPES2014)

ソフトウェア品質シンポジウム(SQiP2014)

ソフトウェアプロセス改善カンファレンス(SPI Japan2014)

→ ターゲット聴衆に合せて特徴的機能とストーリーを整理


論文執筆に


関係者問題質問・重大質問 KEYWORD 解決状態 KEYWORD 実行による副作用の懸念事項副作用の懸念事項への対応策




コーディング後の手戻りが少ないコーディングの留保



















納期遅延見積り通りに開発が終了している見積り通りの開発失敗のリスクがある




ソフト品質の低下ソフト品質が維持/改善している






開発者が開発の意義を感じているモチベーションの向上




中間目的障害の懸念事項への対応策(中間目的達成のためのアクション)

(1)社内関係者の合意を得る・社内関係者に対して，本マフィアオファーシートを用いて合意を取る・対象者に合せてマフィアオファーシートをカスタマイズする

(2)社外関係者の合意をとる・社外関係者に対して，本マフィアオファーシートを用いて合意を取る・Win-Winになるような方法の検討のために，対象者に合せてマフィアオファーシートをカスタマイズする



(4)導入工数を確保する・工数/予算の決定権のある人物にXDDPをプレゼンして，工数/予算を貰う・スモールスタートで検証して，必要工数/コストを見積る・既存開発のデータを用いて，擬似的に検証し，必要工数/コストを見積る



対立実行を妨げる障害の懸念事項

社内関係者(開発者/マネージャー/品質保証部/経営者)と合意を得る必要がある

社外関係者(関連会社/顧客)との調整が必要になる

組織標準や従来のやり方と異なる

導入工数が確保できない/コストが高い

スキルがない




問題質問

重大質問

ポジショニングトーク提案するソリューションと想定提案対象者コンセプト説明文

A

品質の高い製

品を納期とおり

にリリースする

B

納期を守る

C

品質を維持す

る

D

部分理解でコー

ディングする

D'

全体理解でコー

ディングする

問題設定

(序論)

問題の対策

(3章〜)

研究アプローチ(先行研究含む)

(2章)

今後の課題など(結論前)

今後の課題など(結論前)

論文主旨は一つに絞る

アブスト/結論アブスト/結論アブスト/結論アブスト/結論


その他資料作りに


【派生開子（はせいかいこ）】

デグレがいっぱい発生して、手戻りが多かったってこと？

(問題質問)



製品AAAって、そんな感じで開発してるんだったら、機能拡張の度に品質が劣化してるんじゃないの？

(重大質問)



ＸＤＤＰを始めとした、派生開発の効果的な手法の開発と普及を目的に設立された団体よ。そのために様々な活動をしていて・・・



AFFORDDでは、年1回「派生開発カンファレンス」をやっていて事例や研究の発表があって、情報交換できるよ。



特殊な事情とか、XDDPの工夫を研究する研究会や、各地域で集って議論する地方部会っていう活動をやってるよ。



あと、ちゃんとXDDPを習得するための「勉強会」も各地で開催してるし。


• 日経SYSTEMS(2014年1月号)にXDDPマフィアオファーが掲載されました(P.55『特集２現場の困ったシーンで役立つロジカル説得術』)

• SWEST15でベストポスター賞ゴールド受賞しました

84


SWEST15 ポスター

派生開発推進協議会：AFFORDD

• 有志にて2010年に発足

– 派生開発における効果的な方法論の開発と普及

– 有効な打開策の情報交換と支援

(C) copyright 派生開発推進協議会 86

AFFORDDの活動


派生開発カンファレンス～派生開発に関する研究や、事例発表の場～

横浜開港記念館にて

横浜市の

重要文化財に指定されているよ

AFFORDDの活動


研究会活動～テーマを決めて、チームで活動～

カンファレンスでのポスターセッション

研究会での議論の様子

AFFORDDの活動


研究会主催のフォーラムの開催～ XDDPやUSDMの応用編など～

XDDPとSPLE，大規模開発でのXDDP，

XDDPの導入障壁の克服など

AFFORDDの活動


勉強会の開催～ XDDPやUSDMのミニセミナー～

首都圏以外に札幌から

福岡まで各地で開催！

地方部会への展開

• 地方には地域に根ざした事情や優先課題がある

• 同じ問題意識を持った仲間が知恵を出し合う


関西部会の様子

さいごに

「XDDP」は派生開発の現状の問題に対応する

そこで使われる技術は、その後の技術の展開に活用できる

「派生開発」を制覇しなければ明日はない

「XDDP」によって「今」に対応しながら、「次」に備える

「派生開発」の生産性は大幅に改善できる



詳しくは…http://www.xddp.jp/

AFFORDD活動に、ご興味をお持ちいただければ、ぜひご参加ください。

20140630...

Documents