さて、皆様はソフトウェア・プロダクトライン(SPL)についてどのようなイメージをお持ちですか?我々は、お客様から以下のようなご意見をよく伺います。
- SPLには取り組みたいが、ハードルが高そう
- コア資産が重要なのはわかるが、ソフトウェアの再構築をやっている暇はない
- 組織やプロセスまで変えるのは、リスクが大きすぎる
確かに、SPLは総合的な取り組みを必要とするため、ハードルが高く感じますし、その全てを一度に実践することは極めて困難です。しかし、皆様の企業・組織にとって重要な部分から、段階的に進めていくこともできるのです。
特に近年では、extractive & reactiveアプローチでの適用事例が増えています。これは、既存のソフトウェアから再利用資産化できそうなものを抽出し、製品開発時に新たな要件等を加えて資産を増やしていく方法です。こうすることで、ソフトウェアの設計を全て見直したり、全ての再利用資産を事前に揃えたりというような、非常に工数のかかる作業を行うことなく、PL開発に移行することが可能となります。
弊社では、この手法を更に詳細化した"RIPPLEアプローチ"を推奨しています。本アプローチでは、以下の3つのステップを経て、既存のソフトウェア開発をPL開発へと移行させて行きます。
1. 製品群を既存資産の統合による、資産の一元化(Rapid Integration)
2. 一元化した資産の可変性分析と整理による、製品導出(Production)の仕組み作り
3. 製品開発との協調による、資産の洗練・進化(Product Line Evolution)
![RIPPLEアプローチ(既存のソフトウェアから再利用資産化できそうなものを抽出し、製品開発時に新たな要件等を加えて資産を増やしていく方法)に基づくSPL「プロダクトライン開発」への移行支援](img/ripple/img_ripple_steps.jpg)
※RIPPLEアプローチが適しているかどうかは、事前にSPL移行診断を行うことで判定します。
最初のステップでは、既存資産を1つに統合していきます。まず、皆様が現在開発している製品ファミリの資産(主としてコード)が、どのように構成管理されているかを把握することから始めます。具体的には、以下の3つのパターン(およびその組み合わせ)のいずれに該当するかを調べます。
![]() |
|
![]() |
|
![]() |
|
個別開発 or 派生開発の場合は、このステップを通じて1つの資産へとマージしていきます。これにより、統合開発と同じ状態へ到達することになります。
※統合開発の場合は、本ステップはスキップします。
次に、統合された資産の中に存在する可変点(製品毎に異なる点)について、それらが生じる要因(可変性)を特定していきます。通常、可変性が整理されていない状態では、本来同じ要因であるにも関わらず、異なるものとして実装されていることがほとんどです。これらを整理することで、フィーチャモデルに代表される可変性モデルが作成できます。
可変性の整理ができたら、資産中の可変点をこの可変性に置き換えていきます。これにより、製品開発時には可変性を決定(解決)していくことで、自動的に再利用資産から製品資産を導出することができるようになります。
![RIPPLEアプローチ(既存のソフトウェアから再利用資産化できそうなものを抽出し、製品開発時に新たな要件等を加えて資産を増やしていく方法)に基づくSPL「プロダクトライン開発」への移行支援](img/ripple/img_production.jpg)
PL開発は、一度再利用資産を揃えたら終わりというわけではありません。対象とする製品ファミリの寿命が尽きるまで、開発は延々と続いていくため、これに合わせて再利用資産も進化・洗練していかなければなりません。これが、本アプローチの最後のステップに相当します。
製品開発時には、新規要件への対応や仕様変更など、様々な要求が発生します。これら全てに対して、製品開発前に再利用資産として整備できる場合もあれば、工数や納期的に困難な場合もあります。後者の場合は、一度製品として開発し、その後に再利用資産へフィードバックしながら、1つの統合された資産を維持管理していくことになります。これにより、当該ファミリに属する全ての製品は、1つの資産から導出可能な状態を維持していきます。
![RIPPLEアプローチ(既存のソフトウェアから再利用資産化できそうなものを抽出し、製品開発時に新たな要件等を加えて資産を増やしていく方法)に基づくSPL「プロダクトライン開発」への移行支援](img/ripple/img_ripple_whole.jpg)
この3つのステップを通じて、既存のソフトウェアをベースに当該製品ファミリのプロダクトラインアーキテクチャ(PLA)が構築され、再利用コンポーネントが整備されていきます。即ち、PL開発の技術的側面をカバーすることができるようになります。
ここまで来れば、PLAに沿った開発プロセスやメンバーの役割・組織体制のあり方について、具体的なイメージを持って議論することができるようになります。
SPLの実施に当たり、プロセスや組織体制を最初に変える例も見受けられますが、この場合は経営層およびリーダに確固たる意志と権限がないと上手くいきません。それよりも、技術的基盤を先に構築し、SPLによる製品開発の効率化が具体的にイメージできる状況にすることで、より多くのメンバーを容易に巻き込むことが可能になります。プロセスや組織体制の見直しは、それから始めても遅くはありません。
SPLの導入に関してお悩みの方々は、本アプローチを採られてみてはいかがでしょうか?
RIPPLEアプローチについて、より詳しく知りたい方は、以下よりお問い合わせ下さい。