**********************************************************************
セッションS4c
S4c ソフトウェア開発上流工程における"抽象化"の重要性
講師：浅野 雅樹 (アイシン精機株式会社)
日時：2018/8/30 11:30 - 12:20
参加人数：約20名
**********************************************************************

■セッション内容
・セッションの流れ
１.自己紹介、アイシン精機株式会社での取り組み事例紹介
２.例題を用いたグループワーク　
３.グループワークでの成果発表、情報の共有　

・自己紹介
　アイシン精機株式会社プロセス所属。監査担当からプロダクトライン開発に従事移動
　して5年。

・プロダクトライン開発とは
　製品群での共通性と相違性を捉え、共通する部分を再利用し、個別製品を構築する開
　発思想。
　このプロダクトライン開発で重要な技術としては二つあり、抽象化の技術、関心ごと
　の分離(システム仕様の中で横断的に出現する共通的な機能を抽出して独立する技術)
　がある。

・実際の事例についての紹介（本日は主に上流工程について）
　アイシン精機で扱っている製品としては主に自動車部品で主要製品は大きく分けて、
　駆動系、シャシー系、ボディ系、情報系。講師が扱っていたのはボディ系のためこの
　セッションで紹介される事例は主にボディ系についてのものとなる。

・自動車ボディ系システムの特徴の紹介
　１.ユーザから直接、作動の要求がある
　２.車両の他システムと、車載通信による連携が必要
　３.駆動されるアクチュエータは1,2個(3個以上の場合も有)
　上記のような3つの特徴の説明、また仕様変更については社外的要因
　(主にお客様の要望)、社内的要因(商品性向上やコストダウン)があり、一部その紹介
　などがあった。
　社内的要因の例として、コストダウンのためECU構成部品を安価なものにするなどがあ
　る。


・ソフトウェア開発プロセスの定着状況の紹介
　今回は上流工程であるソフトウェア要求分析についての説明となる。
　開発の流れとしては顧客要求からシステム担当者がシステム要求仕様書を作成し、
　ソフトウェア開発部門であるソフト担当者がソフトウェア要求仕様書を作成し開発に
　移るというもの。
　定着した社内プロセスにもとづきソフトウェア開発を実施しているわけだが、ソフト
　ウェア複雑化により変更箇所の把握や設計工数が増大であり効率的な派生開発を行う
　ため、ソフトウェア開発における
　改善活動が必要となった。そこでプロダクトライン開発の導入が行われた。


・議題解決方法として、プロダクトライン開発導入
【活動1】要求仕様の[目的]を抽出し、[実現手段]と分離する
【活動2】変更頻度の高い機能[個別部]と、変わらない機能[共通部]を、要求仕様レベル
　で層別する
【活動3】個別部の変更影響を局所化した、ソフトウェアアーキテクチャを設計する

それぞれの活動に対しての手法は以下のようになる。
【手法1】フィーチャーモデルによる、要求仕様の分析[目的の抽出・手段の分離]を行う
【手法2】フィーチャーモデルによる、共通部と個別部の層別を行う
　DFDによる構造化分析を行い、共通部と個別部のプロセス・データを層別する
【手法3】DFDにもとづき、ソフトウェアアーキテクチャを設計する

　プロダクトライン開発では一般的に用いられるフィーチャーモデル
　というものを使用して抽象化をしていった。

・フィーチャーモデルとは、プロダクトライン中の製品間の共通性、可溶性を各製品の
　備えるフィーチャーとして捉えそれらの関連を記述した樹形図上のモデルである。
　ツリー上にグループ化していくが、このグループ化が重要である。

　例えばボディ系システムは、イベント、制御条件からアクションを決定するイベント
　ドリブンシステムであるため、イベント、制御条件でグループ化していく。
　車載Aと車載Bにおいて、共通部分はそのまま共通化し、違いが出た部分は、
　違いを包括する共通概念を、親フィーチャーとして定義する。


・具体的な取り組み内容
　システム担当者と協力して、要求仕様書に記載されていない使用目的を抽出して
　いった。変更頻度が高いフィーチャーと、変更がないフィーチャーを分類した。
　変更がないフィーチャーから共通のフレームワークを抽出し、そこから上位階層のDFD
　を作成した。
　そして機能ごとに構造化したDFDを各ソフトウェアコンポーネントに反映していった。
　結果として取り組み内容において重要なのは以下の2点である。
１.ソフトウェアアーキテクチャの構造化設計も重要だが、
要求仕様の整理がより重要
２.要求仕様の整理を行うには、システム担当者とソフトウェア担当者の協力が
必要不可欠


・プロダクトライン開発導入の効果
１.仕様変更時に、変更箇所を特定する工数が低減可能となった
２.変更箇所が局所化できたため、ソフトウェア構造設計工数が低減可能となった
３.三車種目の展開開発にて、改善後ソフト開発部分の初期投資を回収できた
　などの効果を得ることができた。


　また開発の進め方にも変化が起き、派生元は必ず改善後ソフトをベースとする開発へ
　変化した。

・まとめ
　改善効果を得られた要因として、ソフトウェアアーキテクチャ設計ではなく、
　要求仕様の整理に重点を置いた活動をしたことにある。
　フィーチャーモデルを用いることで、システム担当者とソフトウェア担当者の理解を
　共有することができた。
　フィーチャーモデルによる、抽象化と関心ごとの分離が効果的であった。


■グループディスカッション
練習問題１，２について各自が回答後、それについて周囲のグループごとに
ディスカッションし、グループごと出た話題について発表していく。

グループディスカッション　(資料配布　配布資料の内容を以下に記載)
　＜目的＞
　簡単なテーマを題材に、フィーチャー分析を実施することで、
　抽象化の考え方を体験していただく。
　また、他参加者の実施結果と比較、議論することで、自分では気づけ
　なかった観点を取得していただく。
　＜テーマ＞
　ユーザの操作によって、前後に左右するロボット

　[システムが提供するサービス]
　・対象ユーザは、子供
　・ユーザが操作した通りに動くことで、楽しさを提供する。

　[システムへの要求仕様]
　要求-1
　　・Aスイッチを押すと、前進する
　　・Bスイッチを押すと、後退する
　要求-2
　　・リモコンのボタン①を押すと、前進する
　　・リモコンのボタン②を押すと、後退する




練習問題１：追加の仕様が発生しました。
フィーチャー図をご自身で編集してください。

要求-3
・メイン機能ボタンがONの時、作動できる
・メイン機能ボタンがOFFの時、作動できない


要求-4(車種A向け)
・前進しているときに、赤外線センサが障害物を検知すると、後退する
・後退しているときに、赤外線センサが障害物を検知すると、止まる

要求-4(車種B向け)
・前進しているときに、カメラが障害物を検知すると、後退する
・後退しているときに、カメラが障害物を検知すると、止まる



練習問題２：追加の仕様が発生しました。
フィーチャー図をご自身で編集してください。

[システムが提供するサービス]
・対象ユーザは、子供。
・ユーザが操作した通りに動くことで、楽しさを提供する。
・他のロボットと勝負することで、複数人で遊べる楽しさを提供する。

[システムへの要求仕様]
要求-5
・カメラ、もしくは赤外線で他のロボットを検知すると、じゃんけんを開始する。

要求-6
・じゃんけんは、機械音声で行う

要求-7
・じゃんけんに負けた場合は、右へ移動する。
・じゃんけんに勝った場合は、前進する。
・あいこの場合は、もう一度じゃんけんする。



□各グループの発表に移る。
以下の二点について発表
１．フィーチャー図を作るにあたり、どういうところに気を付けたか、
またどこが難しかったか。
２．(可能なら)自社で、抽象化にどのように取り組んでいるか？


あるグループの例：
１．
・グループ化の際に細かいとこに気を付けてグループ化していった。
・人それぞれで違うグループ化をしている場合も多々あり逆に
　それで戸惑うこともあり難しい。
・機能追加の際、抽象化が上手くいっていないと、
　余計なツリーなどができてしまった。
・抽象化できるとこはできるだけ抽象化する。
２．
再利用しやすい共通部分をできるだけ作っていくようにしている。