開催報告へ 戻る
			
			基調講演
XDDPから「IoT」に挑む - 困難な状況をチャンスに変える -
| 時 間 | : | 16:35〜17:25 | |
| 講演者 | : | 株式会社システムクリエイツ、派生開発推進協議会代表 清水吉男(しみず よしお)  | |
					 
					1968年からソフトウェアの世界に入り、汎用機による企業システムやオンラインシステムの開発を手掛ける。  | |||
| 概 要 | : | 
					多くのソフトウェアの開発組織では長期にわたって派生開発を外部に依存してきました。その結果、ソースコードは劣化し、開発技術も空洞化しています。このような状況の中で「IoT」の波に遭遇しているのです。 IoTに対応するには強い保守性や勝つための仕掛けが必要であり、劣化したソースコードで戦い続けることは難しいでしょう。その結果、多くの組織では派生開発に取り組みながら新規開発に対応するという難しい課題に直面しています。「XDDP」は、その取り組みによって、この難しい課題に応えることができます。今回、その方法を紹介します。 基調講演:講演資料(pdf:2,559KB) 
					
				 | 
			|
本セッション
1.レビューを成功させるためのトレーサビリティーマトリックス活用法
   〜トレーサビリティーマトリックスにこだわり続けてたどり着いたノウハウ〜
			| 時 間 | : | 10:10〜10:50 | 
| 発表者 | : | セイコーエプソン株式会社 井口 雅人 | 
 
					派生開発カンファレンス2013で変更要求に対する影響箇所の気づきについての報告を行った。その時点ではTMを使ってようやく検証ができるようになったが、どうやって問題を見つけるのかのノウハウ部分については継続検討とした。また、TMで検証するためには作業者の手間が発生し、効果が明確になっていない現状では、現場に定着しないという課題がある。今回の発表では、TMを活用するためのメリットを明確にし、実際に現場で導入するための工夫を発表し、TMの活用により更なる問題の事前発見を促したい。プログラム1:講演資料(pdf:1,787KB) 
				 | 
			
2. 並行開発におけるSCRUMを応用したリソース最適化手法の提案
   〜車載ソフトウェアの派生開発(車両展開)への適用とその効果〜
			| 時 間 | : | 10:50〜11:30 | 
| 発表者 | : | 株式会社デンソー 林健吾 | 
 
					XDDPを採用したとき、変更仕様を特定する調査・分析工数が開発の大部分を占めるため、開発量が正確に見積れないという問題がある。特に、並行開発においては開発量の変動が大きくなり、限られたリソースを各開発に最適に配置することは困難である。この課題に対処するため、現状を把握するためのフレームワークであるSCRUMをXDDPに応用した。最初に、SCRUMのタイムボックスと仮想のストーリポイントで開発量を相対的に見積る。次に、実績をフィードバックすることにより、見積り精度を向上し、並行開発の計画を策定する。このプロセスを繰り返すことで、作業量を平準化してリソースを最適に配置することが可能となった。 プログラム2:講演資料(pdf:2,373KB) 
				 | 
			
3. Agile型開発へのPFD適用とXDDPによる連携開発事例
| 時 間 | : | 11:30〜12:10 | 
| 発表者 | : | 派生開発推進協議会 T6研究会 星野 充史 | 
 
					T6研究会では、AgileとXDDPの連携について研究しており、今回はその事例発表である。複数の機器と連携するシステムの派生開発の場合、関係者が多方面に渡ることで仕様に関する認識の違いから仕様漏れや解釈ミスによる手戻りのリスクがある。このような問題を早期に確認しながら進めるにはAgile開発が適している。また、仕様がほぼ確定している部分でも開発者にその部分の知見がない場合はXDDPが適している。 本発表では、Agile開発とXDDPの両方とも初めての開発現場に、それぞれの手法の特徴を活かして連携させながら導入した事例について紹介する。 プログラム3:講演資料(pdf:1,074KB) 
				 | 
			
4. 「テスト設計にUSDMを使ってみた。」
| 時 間 | : | 13:30〜14:10 | 
| 発表者 | : | アイエックス・ナレッジ株式会社 宮田 一平 | 
 
					私のプロジェクトでは、受入テストを行っていて、お客様の要件定義書から要件を理解し、試験観点を出しているが、曖昧な表現が多く、試験担当者によって同じ試験観点が出せないという課題があった。そこでUSDMによって、「要求」と「仕様」の対応付けによる曖昧な表現の抽出と明確化ができ、
					誰がやっても同じ試験観点が出せるようになると考え、昨年から要件理解時にUSDMを用いた変更要求仕様書を作成することとした。本発表では、導入時の工夫点や得られた気づき、今後の展望ついて紹介する。 プログラム4:講演資料(pdf:1,477KB) 
				 | 
			
5. USDMを用いた非機能要求の抽出 〜設計仕様に基づいた非機能要求作成手法の提案〜
| 時 間 | : | 14:10〜14:50 | 
| 発表者 | : | 株式会社デンソー 水藤 倫彰 | 
 
					設計、実装以降の段階で非機能要求に関する問題が指摘されると、システムレベルの設計、実装の後戻りが必要となる。
					しかし、現実の開発では、設計、実装前に非機能要求を十分検討できていない。本発表では、設計、実装時のレビューの指摘である設計仕様から、非機能要求を抽出する方法を提案する。 USDMのフレームワークを分析に活用し、ISO25010とロジカルシンキングの抽象化の考え方を用いて非機能要求を文書化する方法を紹介する. プログラム5:講演資料(pdf:1,751KB) 
				 | 
			
6. プロダクトライン開発を見据えたシステム全体最適設計の取組み
   〜自動車:パワーステアリング開発における事例〜
			| 時 間 | : | 15:05〜15:45 | 
| 発表者 | : | 日本精工株式会社 高橋 寛之 | 
 
					弊社では、複数のカーメーカ向け製品に対し“一品一様開発”を続けており、そのバリエーションの多さからコスト増大に直面している。そこで“プロダクトライン開発”への変革を目指し、ボトムアップによる現状の整理とトップダウンによる理想の追求を行い、システム全体の要求仕様およびアーキテクチャのコア資産化に取り組んでいる。本発表では、双方向の視点から要求仕様を最適化する様子と、資産の可変性表現としてUSDMを拡張する手法、またそれとアーキテクチャを対応させる事例について紹介する。 プログラム6:講演資料(pdf:4,876KB) 
				 | 
			
7.  PFDを活用したドキュメント再構成による開発プロセスの改善
   〜車載通信モジュール開発における実施と効果予測〜
			| 時 間 | : | 15:45〜16:25 | 
| 発表者 | : | 株式会社デンソー 小島 裕次 | 
 
					車載通信モジュールは、車のインターネット常時接続に不可欠な製品である。搭載する機能は年々、高度化・多様化し、開発コストと不具合の増大が大きな問題となっている。そこで、不具合情報から問題プロセスを特定し、PFDにより開発プロセスの分析を行った。不具合の原因であるドキュメント内容を、後工程に対する貢献度に基づいて再構成することによりプロセス改善を進めた。発表では取り組み内容とその効果について紹介する。 プログラム7:講演資料(pdf:1,632KB) 
				 | 
			
プログラム委員長賞
ベストプレゼンテーション賞
ワークショップ
品質要求をUSDMで表現してみよう!
| 時 間 | : | 10:00〜12:15 | 
| 講演者 | : | 派生開発推進協議会 T12研究会 | 
 
					皆さんの現場では品質要求を要求仕様書に記述できていますか?また、品質要求を設計に織り込めていますか?自信がないなぁと思われた方は、是非ご参加ください!「USDM」は要求仕様の表記法として考案されたものですが、要求と仕様の階層構造を使うことで品質要求を表現することができます。また「USDM」だからできる表現もあります。本ワークショップを通して一緒に考え議論をしながら、この技術を手に入れてみませんか?「USDM」を使ったことがないという方も、この機会に自分のものにしましょう!  | 
			
えくす・でぃ・でぃ・ぴぃ概論&入門ワークショップ
| 時 間 | : | 10:00〜12:15 | 
| 講演者 | : | 株式会社日立製作所 八木将計 | 
 
					XDDPを詳しく知らない方、派生開発で困っている方などに向けて、XDDPの全体像や考え方をわかりやすく解説します。また、単に解説だけではなく、実際に手を動かすワークショップも実施します。前提知識はあまり必要ではありませんので、お気軽にご参加ください。 | 
			
はじめてのPFD
| 時 間 | : | 10:50〜12:15 | 
| 講演者 | : | アンリツエンジニアリング株式会社 派生開発WG 井貝智行 | 
 
					プロセスを設計することは派生開発で重要なポイントですが、複雑なソフトウェア開発プロセスをいきなりPFDに描くのは難しいのが現実です。そこで本ワークショップでは、日常生活で慣れ親しんでいる作業をPFDに描き表しレビューしあいプロセスを表現することに慣れることを目標とします。 その後は、実際にどうやって業務に展開すべきか、どう活用すべきかなど悩んでいることについて意見交換したいと思います。 ワークショップ:テキスト(pdf:1,716KB) 
				 | 
			
ポスターセッション
| PRタイム | : | 12:10〜12:15 | 
| 展 示 | : | 12:15〜17:25 | 
ポスター1.障壁の克服方法パート2
| 発表者 | : | 派生開発推進協議会 T1/T19研究会 | 
 
					派生開発では既存のソースコードをスペックアウトする技術が重要ですが、その方法は確立しておらず、これがXDDPの導入障壁になる場合も少なくありません。そこで、T1研究会とT19研究会でコラボとして、導入障壁の克服(T1研究会担当)とスペックアウト(T19研究会担当)を同時に考えていく「一粒で二度おいしい」ポスター発表をすることにしました。 みなさんがXDDP導入やスペックアウトで困ったことをお話して頂き、整理することで一緒に考えていきたいと思います。  | 
			
ポスター1-1:障壁の克服方法(1)(pdf:1,299KB)
ポスター1-2:障壁の克服方法(2)(pdf:1,006KB)
ポスター1-3:派生開発におけるスペックアウトの仕方(pdf:193KB)
ポスター1-4:アンケート調査結果(pdf:212KB)
ポスター1-2:障壁の克服方法(2)(pdf:1,006KB)
ポスター1-3:派生開発におけるスペックアウトの仕方(pdf:193KB)
ポスター1-4:アンケート調査結果(pdf:212KB)
ポスター2.XDDPの導入/定着に失敗しないためのT22からの提案
| 発表者 | : | 派生開発推進協議会 T22研究会 | 
 
					本研究会では、派生開発の現場において実際にあったXDDP導入/定着の失敗事例を、失敗学で知られている「原因まんだら」を使い研究している。その結果、同じカテゴリに分類された幾つかの失敗事例には、共通の「治療策」や「予防策」があることがわかった。 本発表では、それら事例を病理診断になぞらえて整理した一覧を提示しながら、カンファレンス参加者からの率直なご意見を頂き、一緒に対策を考える機会にしたいと思う。  | 
			
ポスター2:
			失敗事例研究(pdf:3,812KB)
			ポスター3.USDM、XDDPとスープカレー表の融合
| 発表者 | : | 派生開発推進協議会 T4研究会 | 
 
				  ソフトウェアの機能変更に対して十分にレビュー・テストを実施しても、市場で容易に不具合が見つかるケースは少なくない。T4研究会では、Jasst‘09 Hokkaidoで紹介されたスープカレー表とUSDM、XDDPを組み合わせて顧客観点でのテストを実施することで、製品へのバグの混入を未然に防止出来ないか研究を行っている。今回は、ポスター展示を通じて、本研究のねらいと進捗状況を報告したい。
				 | 
			
ポスター3:潜在バグへのアプローチ(pdf:395KB)
			ポスター4.これで広めよう! USDM入門小冊子の紹介
| 発表者 | : | 派生開発推進協議会 T2研究会 | 
 
					本研究会では、「USDMの入門」の活動を通し参加者からの疑問を取りまとめ、USDMを理解するための小冊子を作成しました。清水さんの著書のエッセンスを抽出しましたので、理解の一助になればと思います。また、「USDMを展開したいが、書籍を一度に読ませるのはハードルが高い」とお悩みの方は、本小冊子を活用して広めていただきたいです。 本セッションでは、USDM小冊子の紹介とともに、USDMの実際の導入に際した悩みを一緒に考えてみたいと思います。  | 
			
ポスター4:
			USDM入門小冊子の紹介(pdf:2,506KB)
			




					
					派生開発カンファレンス2013で変更要求に対する影響箇所の気づきについての報告を行った。その時点ではTMを使ってようやく検証ができるようになったが、どうやって問題を見つけるのかのノウハウ部分については継続検討とした。また、TMで検証するためには作業者の手間が発生し、効果が明確になっていない現状では、現場に定着しないという課題がある。今回の発表では、TMを活用するためのメリットを明確にし、実際に現場で導入するための工夫を発表し、TMの活用により更なる問題の事前発見を促したい。
					XDDPを採用したとき、変更仕様を特定する調査・分析工数が開発の大部分を占めるため、開発量が正確に見積れないという問題がある。特に、並行開発においては開発量の変動が大きくなり、限られたリソースを各開発に最適に配置することは困難である。
					T6研究会では、AgileとXDDPの連携について研究しており、今回はその事例発表である。
					私のプロジェクトでは、受入テストを行っていて、お客様の要件定義書から要件を理解し、試験観点を出しているが、曖昧な表現が多く、試験担当者によって同じ試験観点が出せないという課題があった。そこでUSDMによって、「要求」と「仕様」の対応付けによる曖昧な表現の抽出と明確化ができ、
					誰がやっても同じ試験観点が出せるようになると考え、昨年から要件理解時にUSDMを用いた変更要求仕様書を作成することとした。
					設計、実装以降の段階で非機能要求に関する問題が指摘されると、システムレベルの設計、実装の後戻りが必要となる。
					しかし、現実の開発では、設計、実装前に非機能要求を十分検討できていない。
					弊社では、複数のカーメーカ向け製品に対し“一品一様開発”を続けており、そのバリエーションの多さからコスト増大に直面している。そこで“プロダクトライン開発”への変革を目指し、ボトムアップによる現状の整理とトップダウンによる理想の追求を行い、システム全体の要求仕様およびアーキテクチャのコア資産化に取り組んでいる。
					車載通信モジュールは、車のインターネット常時接続に不可欠な製品である。搭載する機能は年々、高度化・多様化し、開発コストと不具合の増大が大きな問題となっている。
				
				
					皆さんの現場では品質要求を要求仕様書に記述できていますか?また、品質要求を設計に織り込めていますか?自信がないなぁと思われた方は、是非ご参加ください!
					XDDPを詳しく知らない方、派生開発で困っている方などに向けて、XDDPの全体像や考え方をわかりやすく解説します。また、単に解説だけではなく、実際に手を動かすワークショップも実施します。前提知識はあまり必要ではありませんので、お気軽にご参加ください。
					プロセスを設計することは派生開発で重要なポイントですが、複雑なソフトウェア開発プロセスをいきなりPFDに描くのは難しいのが現実です。
					派生開発では既存のソースコードをスペックアウトする技術が重要ですが、その方法は確立しておらず、これがXDDPの導入障壁になる場合も少なくありません。
					本研究会では、派生開発の現場において実際にあったXDDP導入/定着の失敗事例を、失敗学で知られている「原因まんだら」を使い研究している。
				  ソフトウェアの機能変更に対して十分にレビュー・テストを実施しても、市場で容易に不具合が見つかるケースは少なくない。T4研究会では、Jasst‘09 Hokkaidoで紹介されたスープカレー表とUSDM、XDDPを組み合わせて顧客観点でのテストを実施することで、製品へのバグの混入を未然に防止出来ないか研究を行っている。今回は、ポスター展示を通じて、本研究のねらいと進捗状況を報告したい。
				
					本研究会では、「USDMの入門」の活動を通し参加者からの疑問を取りまとめ、USDMを理解するための小冊子を作成しました。清水さんの著書のエッセンスを抽出しましたので、理解の一助になればと思います。