RIPPLEアプローチ
さて、皆様はソフトウェア・プロダクトライン(SPL)についてどのようなイメージをお持ちですか?我々は、お客様から以下のようなご意見をよく伺います。
- SPLには取り組みたいが、ハードルが高そう
- コア資産が重要なのはわかるが、ソフトウェアの再構築をやっている暇はない
- 組織やプロセスまで変えるのは、リスクが大きすぎる
確かに、SPLは総合的な取り組みを必要とするため、ハードルが高く感じますし、その全てを一度に実践することは極めて困難です。しかし、皆様の企業・組織にとって重要な部分から、段階的に進めていくこともできるのです。
特に近年では、extractive & reactiveアプローチでの適用事例が増えています。これは、既存のソフトウェアから再利用資産化できそうなものを抽出し、製品開発時に新たな要件等を加えて資産を増やしていく方法です。こうすることで、ソフトウェアの設計を全て見直したり、全ての再利用資産を事前に揃えたりというような、非常に工数のかかる作業を行うことなく、PL開発に移行することが可能となります。
RIPPLEアプローチ
弊社では、この手法を更に詳細化した"RIPPLEアプローチ"を推奨しています。本アプローチでは、以下の3つのステップを経て、既存のソフトウェア開発をPL開発へと移行させて行きます。
※RIPPLEアプローチが適しているかどうかは、事前にSPL移行診断を行うことで判定します。
資産の統合(Rapid Integration)
最初のステップでは、既存資産を1つに統合していきます。まず、皆様が現在開発している製品ファミリの資産(主としてコード)が、どのように構成管理されているかを把握することから始めます。具体的には、以下の3つのパターン(およびその組み合わせ)のいずれに該当するかを調べます。
個別開発

- 同系列の製品を、部署(事業部)毎に個別に開発している
- 製品間での流用は行われていない
派生開発

- 同系列の新製品を開発する際、既存製品のコードを複製して、追加&変更しながら開発している
- 複製したコードは独自に進化し、既存のコードと統合されることはない
統合開発

- 同系列の製品に対して、共通のコードリポジトリが存在している
- 新製品を開発する際、リポジトリからコードを複製して、追加&変更しながら開発している
- 複製したコードでの追加&変更はリポジトリへと反映されるが、製品間の差異を分析・管理するまでには至っていない
個別開発 or 派生開発の場合は、このステップを通じて1つの資産へとマージしていきます。これにより、統合開発と同じ状態へ到達することになります。
※統合開発の場合は、本ステップはスキップします。
製品導出(Production)の仕組み作り
次に、統合された資産の中に存在する可変点(製品毎に異なる点)について、それらが生じる要因(可変性)を特定していきます。通常、可変性が整理されていない状態では、本来同じ要因であるにも関わらず、異なるものとして実装されていることがほとんどです。これらを整理することで、フィーチャモデルに代表される可変性モデルが作成できます。
可変性の整理ができたら、資産中の可変点をこの可変性に置き換えていきます。これにより、製品開発時には可変性を決定(解決)していくことで、自動的に再利用資産から製品資産を導出することができるようになります。
資産の洗練・進化(Product Line Evolution)
PL開発は、一度再利用資産を揃えたら終わりというわけではありません。対象とする製品ファミリの寿命が尽きるまで、開発は延々と続いていくため、これに合わせて再利用資産も進化・洗練していかなければなりません。これが、本アプローチの最後のステップに相当します。
製品開発時には、新規要件への対応や仕様変更など、様々な要求が発生します。これら全てに対して、製品開発前に再利用資産として整備できる場合もあれば、工数や納期的に困難な場合もあります。後者の場合は、一度製品として開発し、その後に再利用資産へフィードバックしながら、1つの統合された資産を維持管理していくことになります。これにより、当該ファミリに属する全ての製品は、1つの資産から導出可能な状態を維持していきます。
SPL導入へ向けて
この3つのステップを通じて、既存のソフトウェアをベースに当該製品ファミリのプロダクトラインアーキテクチャ(PLA)が構築され、再利用コンポーネントが整備されていきます。即ち、PL開発の技術的側面をカバーすることができるようになります。
ここまで来れば、PLAに沿った開発プロセスやメンバーの役割・組織体制のあり方について、具体的なイメージを持って議論することができるようになります。
SPLの実施に当たり、プロセスや組織体制を最初に変える例も見受けられますが、この場合は経営層およびリーダに確固たる意志と権限がないと上手くいきません。それよりも、技術的基盤を先に構築し、SPLによる製品開発の効率化が具体的にイメージできる状況にすることで、より多くのメンバーを容易に巻き込むことが可能になります。プロセスや組織体制の見直しは、それから始めても遅くはありません。
SPLの導入に関してお悩みの方々は、本アプローチを採られてみてはいかがでしょうか?
SPLプロダクトライン開発の関連サービス
人材育成
ソフトウェアプロダクトライン工学(SPLE)の概要から、その中心となる理論・技術までを総合的に学習できます。開発者・品質担当・プロセス改善従事者など製品開発に携わる全ての方への教育にご利用ください。
EurekaBoxは、オンラインで学べる総合学習&実践プラットフォームです。このコースでは、これからSPLを学んでいきたいという人から、実践している人に向けて、コンテンツを用意しています。SPLの基礎から応用までをわかりやすく解説します。
適用支援
"RIPPLEアプローチ"とは、既存のソフトウェアから再利用資産化できそうなものを抽出し、製品開発時に新たな要件等を加えて資産を増やしていく方法です。既存ソフトウェアの調査、プロダクトライン化計画の作成、実施の全ての活動を総合的に支援します。
診断
RIPPLEアプローチに基づくPL開発への移行を目的とし、このアプローチが適切かどうか、システムのどの部分から対応していくべきか、どの程度の工数がかかるのかを診断します。
SPL関連コラム
プロダクトライン開発をアップグレードさせた『新たなプロダクトライン開発』でソフトウェアファースト時代に備える!
ソフトウェアを共通化する方法として、プロダクトライン開発がありますが、OTAを考慮するとプロダクトラ...
ソフトウェアファースト時代に不可欠な新たなプロダクトライン開発とは
自動車業界を中心に「ソフトウェアファースト」という言葉がもてはやされています。それは、目指すべき方向...
SPL(ソフトウェアプロダクトライン)化で「派生開発」の効率化
近年のユーザニーズの多様化、国際的な競争の激化等で、組込み製品のバリエーションは増える一方です。そし...
SimulinkモデルにおけるSPL(プロダクトライン開発)可変点の設計・実装テクニック
可変性の実現(可変点の設計・実装) コア資産は、スコープに含まれる複数の製品での利用を想定して開発さ...
頑張ってるけど、ちっとも楽にならない…何で?
すぐに成果を出すために頑張ってるけど、自前ではもう限界
効果的だろうけど高額なコンサルには手がでない…
あなたに合う一番最適な解決方法を
エクスモーションがご提案いたします。
SPL(プロダクトライン)開発に関する記事を見る
他のソリューションを見る
システムアーキテクチャ
USDM要求の定義と仕様化 既存資産の解説書 レガシー救済プロジェクト 「レガシーシステム」の可視化 レガシーリファクタリング プロセス・アーキテクチャ XDDPによる「派生開発」 「UML」+「オブジェクト指向」
モデリング
最新コラム
CASE時代に不可欠なサイバーセキュリティ& 機能安全
自動車産業における「CASE」は、便利さや効率性を向上させる一方で、セキュリティや安全上の問題を引き...
新しい事業の未来を左右するソフトウェア人財への実践的リスキリングとは
車載分野では自動運転やEV化などの技術革新やビジネスモデルの変化に対応するために従来のハード・メカ開...
プロダクトライン開発をアップグレードさせた『新たなプロダクトライン開発』でソフトウェアファースト時代に備える!
ソフトウェアを共通化する方法として、プロダクトライン開発がありますが、OTAを考慮するとプロダクトラ...
ソフトウェアファースト時代に不可欠な新たなプロダクトライン開発とは
自動車業界を中心に「ソフトウェアファースト」という言葉がもてはやされています。それは、目指すべき方向...