プロダクトライン開発の広がりとインパクト · でペイすると考えられる Jacobson：再利用可能な資産の開発は、再利用を...

1

Japan Advanced Institute of Science and Technology

Copyright (C) 2006, 2007 Tomoji KISHI1

プロダクトライン開発の広がりとインパクト

2007/09/13

北陸先端科学技術大学院大学情報科学研究科岸知二



開発の全体像(1/2)

再利用資産の開発プロダクトラインへの要求、ドメインの経験に基づき、再利用資産(コア資産)を開発

• ドメインエンジニアリング

• Development for reuse

再利用資産に基づくプロダクトの開発個々のプロダクトへの要求に基づき、個別プロダクトを開発

• アプリケーションエンジニアリング

• Development with reuse

2



開発の全体像(2/2)

プロダクトラインアーキテクチャに基づくコア資産の体系化が重要

プロダクトラインアーキテクチャの

設計

プロダクトラインへの要求の定義

再利用可能なコンポーネントの

実現

再利用可能なコンポーネント

再利用可能な要求

プロダクトへの要求の定義

プロダクトの設計

プロダクトラインへの要求、制約、計画ドメインの経験

プロダクトへの要求、制約、計画

最終製品

トレーサビリティトレーサビリティ

再利用資産の開発

個別プロダクトの開発

コア資産

フィードバック

プロダクトの実現

プロダクトラインアーキテクチャ



再利用資産とトレーサビリティ

再利用資産(コア資産)

プロダクトライン中の製品を捉え、体系化された要求、アーキテクチャ(設計)、コンポーネント

アーキテクチャを中心としたトレーサビリティの定義と維持が重要

トレーサビリティ：ある概念について記述し、その概念をソフトウェア開発を通じて追跡する能力

正方向の追跡と逆方向の追跡がある

3



再利用技術

他のソフトウェアの構成要素や構造をソフトウェアの開発に利用する

コード再利用ライブラリ、イディオム、フレームワーク

設計再利用デザインパターン

アーキテクチャアーキテクチャパターン

ドメイン分析



再利用技術の変遷

Kang より

70年代 80年代 90年代

コード再利用

設計再利用

ソフトウェアアーキテクチャ

ドメイン分析

CBSE

ソフトウェアプロダクトライン

再利用可能なコードコンポーネントオブジェクト指向ライブラリ

デザインパターンアンチパターン

アーキテクチャスタイルアーキテクチャ記述言語

モジュール相互接続言語

CBSE: Component Base Software Engineering

4



アンケート調査

問題回答の割合

組織的な抵抗 52%

マネージメントの抵抗 36%

開発者の抵抗 32%

大きな投資への懸念 45%

訓練を受けたスタッフの不足 29%

インパクトの測定ができない 19%

長いリードタイムへの懸念 18%Cohenによる

利益回答の割合

品質改善 52%

コスト削減 45%

生産性の改善 39%

顧客要求への適合能力の改善 39%

Time to market の改善 30%



プロダクトラインの利益とコスト

なぜプロダクトラインを考えるのか Nokia：プロダクトラインアプローチで市場をリードする

Cummins：Time to Marketが1年から1週間に

Celsius Tech：50人の技術者で、従来は200人で作っていた以上のシステムを開発

HP：欠陥率が大幅に減尐

プロダクトラインのコスト Philips:試すのは大変だが、得るものが大きいのでやらないことはさらに大変だ

Cummins:パラダイムシフトに1年

Celsius Tech：最良のアーキテクト達を半年閉じ込めた

HP：プロセスと組織の変更に数年かかった

5



事例 (1/2)

分野企業名種類

自動車

リアルタイム

組込み

Cummins, Inc

Robert Bosch, GMBH

Danfuss Drives

エンジン制御

エンジン制御

電子コンポーネント

自動車、テレマティクス

Robert Bosch, GMBH

Omnifeet

Visteon Corporation

Cummins, Inc

ドライブ情報システム

サンルーフ・窓制御

商用車管理システム

電子システム

電子制御

交通制御 Raytheon Company

Thales

ALCATEL Transport Automation System, Spain

ハイウェー制御

航空制御

鉄道制御

航空、

リアルタイムシステム

Boeing Company

Honeywell

Rockwell

アビオニクスシステム

宇宙基地ナビゲーション

コックピット管理

Cohenによる



事例 (2/2)

分野企業名種類

E-コマース Monetaire

Market Maker Software AG

TenFold

AlLTEL Information System

財務計画

株価追跡

E-コマース

ソリューション

銀行・証券

その他 National Reconnaissance Office

Naval Undersea Warfare Center

U.S.Army Simulation, Training and Instrumentation Command

Lucent/Avaya Labs.

Philips Research

Saab Tech Systems

Motorola, Inc.

Nokia Group

Hewlett Packart Labs

SchlumbergerSEMA

Axis Communications AB

Siemens Corporate Research

ハイウェー制御

航空制御

鉄道制御

テレコム各種

医療・家電

海軍(Celsius)

呼出しシステム

携帯電話

医療・銀行

スマートカード

ネットワーク機器

患者管理

Cohenによる

6



投資と回収のイメージ

J.M.Thompson

インクリメンタルな方法初期投資をする方法



いつ効果が期待できるか

Lucentの報告：過去のデータからは通常2-3製品でペイすると考えられる

Jacobson：再利用可能な資産の開発は、再利用を考えない場合に比べ1.5-3倍のコストがかかるので、尐なくともコア資産を3回利用する必要がある

SPCの報告：1.67-4.86のシステムの合成がペイするポイント

他の報告でも2-3製品でペイするというものが多い

J.M.Thompson

7



Philipsでの製品系列

ハイエンドテレビのソフトウェア

機能の拡大や多様化、対象地域の広がりでソフトウェア規模も拡大、多様化

製品毎の変動性が大きいため、フレームワークではなく、コンポーネントを組み合わせるアプローチを採用

1980 1990 2000

100000

10000

1000

100

10

1

Kb

yte

s

Year of Market Introduction

品質の維持

多様性の扱い

リードタイム短縮

ソフトウェア再利用

ソフトウェアコンポーネント

ソフトウェアアーキテクチャ

ソフトウェアプロダクトライン

Ommeringより



Koalaコンポーネント

家電ソフトウェア用のコンポーネント

実行時の負荷を減らすために静的結合が主体

インタフェース記述言語の提供

m

provides interface

requires interface

Koalaコンポーネントコンポーネントの結合

直接結合スイッチ結合モジュール(コンパイル時に切替)

Ommeringより

8



アーキテクチャ

主要なサブシステム構造

変動性への対応サブシステムの選択(ex. tvapiは3種類のHW上で定義）インタフェースで対応(ex.パラメータで指定等)

製品ごとに、必要な結合モジュールを用意

Applications

EPG TV Service Fact. Dealer

Teletext TV Platform

UIMS

Infratvapi

Ｔｒｅｗより



開発体制とプロセス

体制：各サイトは特定のサブシステムの全バリアントの開発に責任を持つ

あるサイトは最終製品のインテグレーションを行う

開発プロセス

プロダクトラインの定義スコーピング、共通性・変動性の識別、フィーチャのサブシステムへの割り振り（本活動は定期的に行い見直す）

サブシステムの仕様化サブシステムはprovided/required インタフェースとして定義する（仕様は全体の変更管理委員会が管理）

サブシステムの設計各サブシステムをより細粒度のコンポーネントに分割

（各サブシステムは同様のインタフェースを持つ）

サブシステムの実装とテスト各コンポーネントの実装とテスト

製品のインスタンス化サブシステムを用いた製品の実現

Ｔｒｅｗより

9



テスト

4つのレベルのテスト

個々のコンポーネント簡単なアプリケーションを作ってテスト

必要な機能は既存コンポーネントを使うかスタブを作成

パッケージ中の整合性公開インタフェースについてテスト

強い依存性がある場合は既存のパッケージを、そうでなければスタブを利用

パッケージ間の整合性各プロダクトで行う

安定した版とのインテグレーションは製品毎に決定

製品従来と同じテスト

Ommeringより



典型的なプロセス

先取り型 (proactive)：

様々なバリエーションに対応

反応型 (reactive)：

バリエーションに順次に対応

抽出型 (extractive)：

既存のバリエーションを統合

10



先取り型

ドメイン分析やスコーピングを行い、プロダクトライン中のバリエーションを識別

すべてのプロダクトをサポートするアーキテクチャを設計

共通性・変動性に対応するソフトウェアを設計

分析

アーキテクチャ

設計プロダクトライン

プロダクト群

Before After Kruegerより



反応型

新たなプロダクトの要求を現状のプロダクトラインに照らして検討

現状のプロダクトラインでサポートできなければ、差分エンジニアリングを行い、それに対応

プロダクトライン

N+1

プロダクトプロダクトライン

N

プロダクト

N+1プロダクトの要求

＋


11



抽出型

既存プロダクトの共通性と変動性を識別それらに対応できるコア資産や環境を整備


プロダクト群既存プロダクト群




組織構造のタイプ

サイズ 30人以下 30人から100人 100人以上

形態

特性簡単でコミュニケーションが容易

組織・管理のオーバーヘッド小

組織変更が小さい

スケーラビリティの問題

階層化や役割の分離

制約なし

・どの組織も資産を追加可能

・組織毎に独立してしまう

資産管理の責任明確化

・資産を技術者に割り当てる

・役割の衝突

役割を複合化

・資産を組織に割り当てる

・変更の迅速性が損なわれる

ビジネスユニット間のコミュニケーションが減尐

目的の衝突の回避

対極的な最適化がやりやすい

開発組織への要求の管理

独自の資産を作る可能性

J.M.Thompson

12



組織の成熟度との関係

単発開発ではなく類似製品の体系的開発

組織横断的に再利用資産を活用する視点

製品群全体の開発を捉える長期的な視野

アドホックな個人依存の開発ではなく、ビジネス目的に向けた合目的な開発スタイル

その実践にはSEIの成熟度レベルで3以上が必要といわれている



参考）ボーイング社での捉え方

活動の視野、目的、管理対象という観点から成熟度レベルとの対応付けを捉える

ビジネス管理

プロダクトライン管理

プロダクト管理

プロジェクト管理

利益

コストサイクルタイム

品質

スケジュール

ビジネスマーケットシェア


組織

プロジェクト

1

2

3

4

5

視野

目的

管理対象

Vuより

13



プロダクトライン開発の現状調査

組織1 組織2 組織3 組織4 組織５

組織の性格

組織の人数 1,000 1,000 10 250 1,000

開発サイト数 8 3 1 3 8

市場指向性市場指向顧客指向顧客指向顧客・市場指向顧客指向

組込みソフトウェア組込みソフトウェア組込みソフトウェア

コア資産を独立開発 No Yes No Yes Yes

製品系列の性格

製品数多い非常に多い中くらい高い高い

性能要求厳しい厳しいゆるい厳しい厳しい

安定性低い高い中くらい高い高い

アーキテクチャコンポーネントフレームワーク

コンポーネント

フレームワークフレームワークフレームワーク

コンポーネント

HP, Bosch, Software Construction Group, MARKET MAKER Software, sb&m のメンバによる調査結果



重要かつ困難なポイント

組織や支援説得力のあるビジネス事例組織構造を明確にするプラットフォームチームの役割を明確にする

プラットフォームとプロダクトのバランスプラットフォームへの要求を決めるプロセス強い顧客の影響の調整

要求工学要求分析と要求のモデル化過度にアーキテクチャ上の課題にのみフォーカスしない

アーキテクチャ明示的な定義、ステークホルダーとの協議、検討プロダクトアーキテクト、プロダクトラインアーキテクト、ドメインアーキテクト、コンポーネントアーキテクト

HP, Bosch, Software Construction Group, MARKET MAKER Software, sb&m のメンバによる調査結果

14



教訓

プロダクトラインビジネスの実践は明確なマネージメントの関与が必要。マネージメントの後援や関与が不十分なために失敗した例は非常に多い。

組織の規模は問題ではない。多くの組織では、小規模な再利用の失敗経験から、再利用はあまりよい印象をもたれていない。そうした文化に対してプロダクトラインを導入するには、極めて積極的な説得と宣伝が必要となる。

プロダクトラインを成功させるには、アーキテクチャへの注力とアーキテクチャに関する能力が必須である。

組織はしばしばプロダクトラインの取り組みを評価しようとする。プロセスの原則は必須である。プロセスはCMMでもXPでもAgileでもかまわないが、それらは定義され守られなければならない。かつてプロセス改善とソフトウェアプロダクトラインの両方を誤って同時に導入しようとしたことがあるが、プロダクトラインの取組みは失敗した。

プロダクトラインの適用を支援するために、より定量的なデータが必要である。プロダクトラインへの移行は投資であり、意思決定者はビジネス上の具体的な数字を欲しがる。

SEIの資料に基づく



どう進めるか

プロダクトラインの先導者戦略的な計画、長期の目標や回収、技術的な知識

変化に備える単一のシステム開発の体制から、資産を共有する体制への変化

具体的な結果を早期に最適の人員を集め短期間に検討

アーキテクチャの確立プロダクトラインアーキテクチャの設計が最優先

見合わせるコストを高くするプロジェクトがプロダクトライン開発に参加しないことへのコスト

プロダクトライン開発の 広がりとインパクト · でペイすると考えられる Jacobson：再利用可能な資産の開発は、再利用を...

Documents

プロダクトライン開発の広がりとインパクト · でペイすると考えられる Jacobson：再利用可能な資産の開発は、再利用を...