[レポート]
ビジネスプロセスソリューション部
池上 裕樹
今関 剛 (株式会社 豆蔵)
このセッションでは、組込みソフトウェア開発における既存の問題点の解としてプロダクトラインの紹介が行われました。
このセッションでは、以下の流れで行われました。
現在の組込みソフトウェア開発は、製品の多品種少量生産、高性能 / 多機能化、低価格化などへの対応から、再利用への要求が高くなっています。 そこで、オブジェクト指向技術などによって再利用を実現しようとしますが、必ずしもうまくいっているわけではありません。原因として以下のようなことがあげられます。
上記の問題点の解として、プロダクトラインが考えられます。
- 従来型の開発法は、スクラッチからの開発を前提としているものが多い。しかし、組込み型の開発ではある製品から派生したバージョンやバリエーション(製品ファミリ)の開発が多く差分開発がメインとなるため、従来型の開発法だけでは対応できない。
- 従来型の開発法における再利用とは、ソフトウェアの分析・設計・実装が中心であり、基本的に 1 つのプロジェクトの中に閉じている。しかし求めらているビジネス要件(多品種少量生産、高性能 / 多機能化、低価格化など)に対応するためには、1 つのプロジェクトの再利用にとどまらず、プロジェクトを横断的に再利用を推進するプロセスが必要となるため、従来の開発法では対応できない。
プロダクトラインとは、販売戦略上の共通な特性を持った製品群のことです。 プロダクトラインには、3つの活動があります。
ソフトウェア開発におけるプロダクトライン適用は、米国カーネギー・メロン大学のソフトウェア工学研究所 (以下 SEI) で現在研究が行われています。[1]SEIでは、プロダクトライン開発の実践していくための具体的な活動として、「A Framework for Software Product Line Practice Version 4.1」[2]を定義しています。そこでは、3 つの実践エリアと 29 の活動内容を定義しています。
- ドメインエンジニアリング
再利用の対象となるコア資産の開発- アプリケーションエンジニアリング
コア資産の統合による製品の開発- 管理
コア資産の共有・再利用による経済性の管理
- ソフトウェア管理 (Software Engineering Practice Areas)
- アーキテクチャ定義 (Architecture Definition)
- アーキテクチャ評価 (Architecture Evaluation)
- コンポーネント開発 (Component Development)
- 商用コンポーネント (COTS) の利用 (COTS Utilization)
- 手持ちの資産の発掘 (Mining Existing Assets)
- 要求工学 (Requirements Engineering)
- ソフトウェアシステムの統合 (Software System Integration)
- テスト (Testing)
- 関連するドメインの理解 (Understanding Relevant Domains)
- 技術管理 (Technical Management Practice Areas)
- 構成管理 (Configuration Management)
- 情報収集、メトリクス、トラッキング(Data Collection, Metrics, and Tracking)
- ソフトウェアの作成、購入、発掘、委託開発に関する分析(Make/Buy/Mine/Commission Analysis)
- プロセス定義(Process Definition)
- スコープの設定(Scoping)
- 技術的計画(Technical Planning)
- 技術的なリスク管理(Technical Risk Management)
- ツールサポート(Tool Support)
- 組織管理 (Organizational Management Practice Areas)
- ビジネスケースの構築 (Building a Business Case)
- 顧客との接点 (Customer Interface Management)
- 委託開発・購入戦略の開発 (Developing an Acquisition Strategy)
- 資金提供 (Funding)
- プロダクトラインの開始と制度化 (Launching and Institutionalizing)
- 市場分析 (Market Analysis)
- プロダクトラインの維持・運用 (Operations)
- 組織的計画 (Organizational Planning)
- 組織的なリスク管理 (Organizational Risk Management)
- 組織の組み立て (Structuring the Organization)
- 技術予測 (Technology Forecasting)
- 教育 (Training)
コア資産を作成するにあたってドメイン分析を行い、どの要素がコア資産となるかについての評価を行なう必要があります。従来開発法のドメイン分析でも共通部と可変部の分離への対応が可能ですが、ドメインの分割を行なう際の基準が不足しており、また、不変的な製品ファミリに対してどのように再利用すべきかの定義がありません。
プロダクトライン開発では、商品の機能や商品そのものの将来を予測した商品ロードマップを作成し、ビジネスの視点に基づいて検討された製品ファミリから特徴の類似している製品系列をプロダクトラインと位置付け、製品群の開発に対する経済性の観点に立ってドメイン分析を実施します。 SEI では、ドメイン分析の手法のひとつとして、FODA(Feature Oriented Domain Analysis)[3]を取り上げています。FODA とは、ユーザの目に見える観点から機能を分類し、複数製品の特徴を洗い出そうとするものです。
ソフトウェアプロダクトラインの導入にあたっては、IDEAL (Initiating, Diagnosing, Establishing, Acting & Learning) [4]を用います。
IDEAL とは、SEI で定義されている品質改善活動のモデルです。IDEAL は、ソフトウェアプロダクトラインを前提にしているわけではなく、CMM(Capability Maturity Model:能力成熟度モデル) [5]などでも使用されます。組込みソフトウェア開発の特徴を前提として、適用する必要があります。 組み込みソフトウェア開発のプロセスに関する特徴として以下のようなことがあげられます。
- 組込み開発ではハードウェア開発が主体となり、ソフトウェア開発はあらかじめ想定可能な一定の製品群に対して定常的・継続的・サイクリックに行われる。
- ソフトウェア開発の体制は、機能 / 構造 / 工程毎にチーム / グループが形成され、開発作業を分担している場合が多い。
会場は満席で質問も活発に行われて、ソフトウェアプロダクトラインに対する関心が非常に高いことがうかがえました。 今までのソフトウェア開発における再利用の話題の多くが、オブジェクト、コンポーネント、モジュールといった開発者の視点が中心でしたが、ソフトウェアプロダクトラインでは、組織的に再利用を促し企業の共有資産として活用するといった点が、今までにない新しさだと感じました。
また、ビジネス系のシステムが単発の開発が多いのに対して、組込み開発では一連の製品群を開発していくことが多く、ソフトウェアプロダクトラインとの相性の良さを感じました。 例えば、プリンタを例にとると、両面印刷可能プリンタ、FAX 付きプリンタなどのさまざまな製品群がありますが、共通部分のプリンタという機能をコア資産とすることにより、両面印刷機能や、FAX 付き機能のみの開発に注力できるといった差分開発が実現できるからです。
このような再利用、差分開発の考え方自体は新しいものではありませんが、1 つのプロジェクトにとどまらず、会社組織として再利用、差分開発を推進するという考え方と、それらの考え方を体系的にまとめ、実際に行うべき活動が定義されているところにソフトウェアプロダクトラインの価値があると思います。ソフトウェアプロダクトラインは、自社製品を複数持つメーカーの立場からの視点でとらえがちですが、SIer にとっても非常に有益な考え方ではないかと思います。SIer では似かよったドメインに対するプロジェクトが複数存在していますが、その中からコア資産を形成し(ドメインエンジニアリング)、そのコア資産を使用した開発を行う(アプリケーションエンジニアリング)ことによって、工数の短縮や、高品質な製品の提供が可能となると思います。また、現状の SIer が提供するサービスの多くは、個人の能力に依存していますが(つまり、SIer を利用する立場からするとあたりはずれがある)、コア資産を組織的に管理しその資産を活用して開発を進めることによって、高いレベルでのサービスの提供が可能になり、企業としての競争力強化につながるのではないかと思います。
ソフトウェアプロダクトラインを適用するにあたって、コア資産の開発は非常に高度な知識と経験が要求されると思います。なぜなら、コア資産は、非常に多くの場面で使われていくものだからです。コア資産が再利用性が高く、また高品質なものでなければ、結局のところ、誰にも使われない不良資産となりかねません。企業にとっては、今後コア資産を開発できる人員をどれだけ確保できるかが問われるのではないかと思います。
ソフトウェアプロダクトラインは適用事例が少ないですが、今後の動向に注目していく価値があると思います。日本語によるソフトウェアプロダクトラインの情報源はまだまだ少ないのですが、EEBOF[6]で、ソフトウェアプロダクトラインの概要の作成や、ML の運営などの活動が行われており、徐々に日本でも広がりが出てきていると思います。
なお、ソフトウェアプロダクトラインは、マルチパラダイムデザイン の考え方が取り入れられています。マルチパラダイムデザイン - 序論 - [7] もあわせてご覧いただければと思います。
[1]The Product Line Practice (PLP) Initiative
[2]A Framework for Software Product Line Practice Version 4.1
[3]FODA (Feature-Oriented Domain Analysis)
[5]CMM(Capability Maturity Model® for Software (SW-CMM®))
[6]EEBOF
[8]「ソフトウェアプロダクトライン―ユビキタスネットワーク時代のソフトウェアビジネス戦略と実践」 Paul Clements (著), Linda Northrop (著), 前田 卓雄 (翻訳)
[9]Software People vol.1」 技術評論社
© 2003 OGIS-RI Co., Ltd. |
|