企業の製品開発上の制約と SPL 適用課題
加藤 正恭† 島袋 潤†
ソフトウェアプロダクトライン型開発手法（SPL）が普及し，企業での適用事例も報告されるようになり，SPL が製品開発効率化を実現する上で有効な手法であることが明らかになってきている．一方，SPL を継続的に適用するための課題も明らかになりつつある．本稿では，SPL の継続的適用に関連する企業における制約条件について述べ，企業における制約を考慮した SPL 関連技術を開発するための問題提起を行う．

Business Constraint Conditions and SPL Development
TADAHISA KATO† JUN SHIMABUKURO†
Recently, Software Product Line Engineering has spread and It's recognized that SPLE is usefulway to develop product lines. However applying SPLE for a long time, we face some problem onbusiness constraint conditions. The author would like to discuss on how to solve these problems.

1. 企業での SPL 適用事例

2. 企業の製品開発上の制約と SPL 適用

近年，組込みソフトウェア開発の大規模化・複雑化が進んでいる．ユーザニーズの多様化や市場のグローバル化に伴い，製品は多品種化しており，開発期間も短縮される傾向にある．このような状況において，ソフトウェアを計画的に再利用し，開発効率化を実現する手法として，フトウェアプロダクトライン型開発手法（Software Product Line，以下 SPL）が注目されている．
我々は，2005 年以来，製品開発効率化を目指して，エンジン制御システム[1]，医用分析装置[2]，ネットワークスイッチ[4]の開発に SPL を適用してきた．また，これらの適用事例で得られた知見をもとに，SPL 適用方
針立案のための評価手法[3]や，要求と実装のトレーサビリティ回復手法[5]を開発するなど，SPL の基礎となる技術の開発にも取り組んできた．
これらの取り組みは一定の成功を収め，SPL が製品開発効率化を実現する上で有効であることを確認した．
一方，SPL 適用開始から数年経ち，改めてこれまでの取組みを振り返ったところ，SPL の継続的適用を通して得られた課題もあり，中には企業で製品開発をする上で考慮が必要な制約が影響しているものもあった．
本稿では，企業で製品開発をする上での制約条件と，それに伴い生じる SPL を継続的に適用する上での課題について述べ，企業における制約条件を考慮したSPL 関連技術を開発するための問題提起を行う．

2.1. SPL 継続適用プロセス
図 1に SPL ソフトウェア資産概念図を示す．
製品

X1

X2

Y1

Y2

変異体

Y
X2

Y1

Y2X

フィーチャ図可変点Y
プラットフォーム

図 1 SPL ソフトウェア資産概念図
SPL では，製品間の可変性を分析し，フィーチャ図などを用いて記述する．また，ソフトウェアとしては，可変性を実装する土台となるプラットフォーム，可変性に対応するプラットフォーム上の可変点，可変点に接続される変異体を実装する．
図 2に SPL ソフトウェア変更プロセスを示す．
製品

(1)

X1X
X2Y1Y2X1X

Y2X2Y

Y1Y2Y3Y2Z1YX2Y1Y2Y3X

製品(3)
XX1YX2Y1X

製品(2)

X1X2YX1X1†（株）日立製作所 研究開発グループ システムイノベーションセンタ

X1X

Y1X2

Y

Y1Z
Y2

Z1Z2X

YZ

図 2 SPL ソフトウェア変更プロセス

Z2

SPL における理想的な製品開発では，製品変更要求（機能拡張，性能改善，不具合修正，リファクタリングなど）に応じて各可変点に変異体を割り当てて製品を作る(1)．適切な変異体がない場合は変異体を作り(2)，さらに既存の可変点で対応できない場合は新たな可変点を追加する(3)．
2.2. 企業における製品開発上の制約
企業で製品開発する上で考慮しなければならない制約と，それに由来して生じる状況を図 3に示す．
(A) 顧客への迅速対応(B) 製品開発優先

可変性実装品質より迅速な機能実現を優先

製品に直結しない資産の開発優先度低下

次善の可変性実装方法（可変点・変異体）採用
可変性実装方法の定期的な見直しが必要(C) 製品品質の維持

フィーチャ図の継続的保守が困難
矛盾

保守のための定期的な追加投資は困難

常時最新のフィーチャ図が準備できない

正常動作中の既存製品に変更を追加したくない

可変性実装の見直し（リファクタリング）が出来ない

図 3 製品開発上の制約と付随する状況
A) 顧客ニーズへの迅速対応が必須
企業では顧客ニーズへの迅速な対応が求められており，開発時は実現品質より実現速度が優先される場合がある．それにより，最善ではなく次善の可変性実現方法が採用され，その蓄積でソフトウェア構造が崩れる場合もある．そのため，可変性実装方法の定期的な見直しを行うことが望ましい．
B) 製品開発に関連するアクティビティが最優先
企業では直近の製品リリースが至上命題になりがちであり，製品開発に直結しないアクティビティの優先度が低下しやすい．そのため，ソフトウェア保守のための投資比率は相対的に低くなり，A)で述べたような可変性実装方法の見直しもしづらい．また，フィーチャ図のような製品に直接搭載されない成果物も重要度が低くなりがちであり，継続的保守のための投資が抑えられ，いざそれが必要になっても対応が後手になってしまう．
C) 製品品質の維持
企業では検証を通ってリリースされたソフトウェアに対し変更を加えることを避けがちである．これは，一旦品質保証し正常に動作しているソフトウェアが，変更を加えることでデグレードすることを恐れるからである．このようなマインドも既存ソフトウェアのリファクタリングを阻害する大きな要因となっている．
以上で述べたように，企業の製品開発においては，企業特有の制約条件が存在し，それによって SPL の継続的な適用を進める上で望ましくない状況が生じている．

3. 課題解決のためのアプローチ
表 1に，企業と大学の組織的な立ち位置を示す．
表 1 組織の立ち位置
課題技術立ち位置

応用 最先端

製品開発部

◎○

×

応用技術が欲しい

企業研究所

○○△

産学の橋渡しをしたい

大学△△◎基礎技術を応用したい企業の製品開発部は，製品開発上の様々なエンジニアリング課題を抱えており，解決可能な応用技術を求めている．大学は，基礎技術に精通し，応用技術の開発にも積極的だが，製品開発現場から距離が遠く，現場の問題意識をキャッチしづらい．我々は企業研究所の研究者として，大学との共同研究およびその成果の製品開発適用を推進して産学橋渡しをしたい．
前節で述べた，企業における製品開発上の制約を考慮した SPL 継続適用を可能にする技術を開発するために，我々がどうしていくべきかを議論したい．

参考文献
[1]

[2]

[3]

[4]

[5]

Kentaro Yoshimura et al., "Defining a Strategy to
Introduce a Software Product Line Using Existing
Embedded Systems," in Proceeding of 6th ACM& IEEE International conference on Embedded
software (EMSOFT'06), pp. 63-72, 2006.
Yasuaki Takebe et al., "Experiences with Software
Product Line Engineering in Product Development
Oriented Organization," in Proceeding of 13th
International Software Product Line Conference(SPLC2009), pp. 275-283, 2009.
Kentaro Yoshimura et al., “Key Activities forIntroducing Software Product Lines into Multiple
Divisions: Experience at Hitachi,” in Proceedingof 15th International Software Product Line
Conference (SPLC2011), pp. 261-266, 2011.
Tadahisa Kato et al., "Case Study of Applying
SPLE to Development of Network Switch
Products," in Proceeding of 17th International
Software Product Line Conference (SPLC2013),
pp. 198-207, 2013.
Ryosuke Tsuchiya et al., "Recovering Traceability
Links between Requirements and Source CodeUsing the Configuration Management Log,"
IEICE Transactions on Information and Systems,
Vol.98-D, No.4, pp. 852-862, 2015.