1. 発表論文
• タイトル
「Five Years of Product Line Engineering
in a Small Company」
（小規模企業におけるプロダクトライン開発の五年間）
• 著者
– Martin Verlage, Thomas Kiesgen
• 出典
– 27rd International Conference year accept rate
2004 13%
on Software Engineering
2005 14%
（ICSE 2005）
2006 9%
0

2. 選定理由
• ICSE（ソフトウェア工学系最強の学会）だから
→ 高級な学会の論文を調査することで、
自分も高級な着眼点で研究ができそう
• SPLを実際の企業に適用しているから
→ SPLを使うことで、企業がどうなったのかが
非常に興味深い
1

3. 概要
• 目的
→ 開発プロセスをSPLに変更するとどうなるのか、
実際の企業における適用結果から教訓を得るため
• 手法
→ MARKET MAKERがSPLを導入したことによって
変更した部分（開発プロセス・組織）を分析
• 結論
→ SPLを企業に適用することにおける教訓と、
今後の研究へのフィードバックを示した
2

4. SPL導入のきっかけ
• 市場で優位に立ちたかった
• 将来を見据えた開発を行いたかった
• 仲がいいフランホーファー研究所で、
PuLSETMというSPLのアプローチを研究していた
• 企業：SPLのアプローチが好都合
• 研究所：SPLのアプローチの検証に好都合
互いに Win-Win な関係！
3

5. i*PrudocutLineの概要
インターネット技術を利用した製品ファミリーを
開発したい
既存システム（株式市場データとニュースを
管理・分析するためのツールセット）を再利用
5年かけて、
万能再利用資産 i*PrudocutLine を開発
4

6. i*PrudocutLineのインスタンス
– WIP：
株式市場のデータやニュースを提供
– INFO-AGENT：
銀行員が市場データを調べ、顧客に助言
– XML-Market：
データの評価・表示・配信のための
XMLインターフェース
– Publisher：
登録しているユーザだけがアクセスできる
WEBサービス上のデータを抽出 5

7. i*PrudocutLineのINFO-AGENT
6

8. i*PrudocutLineの可変性
• 画面
– 共通：HTML
– 可変：色、フォント、データ項目の位置
• データ構造
– 共通：単一のデータパッケージ
– 可変：なし
• データ品質
– 共通：一定時間経過後の取引データ（安価）←ほとんどコッチ
– 可変：リアルタイムの取引データ（高価）
• 機能性
– 共通：基本的な機能（安価）
– 可変：高度な検索機能、価格データのグラフ（高価） 7

9. 導入初期の意思決定1
• 市場投入までの時間を短縮
– 顧客の要求により、最初の製品はプロジェクトの
開始後12カ月以内にカットオーバー
– ドメインエンジニアリングに時間をかけれなかった
• 新しくチームを編成
– i*PL開発用に新たな人材を採用
– 既存システムを見直す、いい機会になった
• ドメインではなく技術に焦点を当てる
– ドメインエンジニアリングを停止
– スコーピングで要件を識別、参照アーキテクチャを定義
8

10. 導入初期の意思決定2
• ドメインエンジニアリングとアプリケーションエンジニアリング
を分離しない
– 一つのチームが、ドメインエンジニアリングとアプリケーシ
ョンエンジニアリングの両方を行った
– アイディアの分離を回避するため
• 既存システムをカプセル化
– Delphiで書かれた既存システムをJAVAで
カプセル化し統合できるようにする
• 設計様式を単純化
– RMI（Remote Method Invocation）により高いスケーラビ
リティを可能に
– 任意機能はコンポーネントのインスタンス化と設定ファイ
ルでとったりつけたり 9

11. 導入初期の意思決定3
• 意思疎通を効果的に
– 意思決定者は直接開発者に提案
– 営業担当者が中心となって顧客の考えを共有
• 信頼性の高い意思決定を素早く
– 最初にビジョンを立て、意思決定の方向性が合理的だっ
たかを判断
– チームのモチベーションの維持に役立った
• SPLを導入するためのコーチング
– フランホーファー研究所が協力的でサポート
• 投資を最小限に
– 市場投入まで時間がないという圧力が、投資を尐なくした
10

12. SPL導入による開発プロセスの変化1
• スコーピング
– SPL化にあたり新しく導入されたプロセス
– 系図学図表をもとに、共通部分と可変部分を明確化
• アーキテクチャの評価
– 2年後には参照アーキテクチャが複雑になると予測
– フランホーファー研究所のM-Systemで定期的に構造的
品質を評価
• 再利用資産の設計
– SPL化にあたり新しく導入されたプロセス
– 普通の開発ではかからないコストがここではかかるため、
ガイドラインに沿ってきっちりやる必要があった 11

13. SPL導入による開発プロセスの変化2
• 再利用資産の実装と新システムの実装時の単体テスト
– 伝染するので、特に再利用資産のバグは致命的
– Junitのテストフレームワークを使用
• ビルドプロセスの自動化
– コンパイラであるファウラーのCruise Controlが自動でコ
ンポーネントテストを行い、エラーはメールで送られる
• 変更管理と問題管理
– 再利用先で大きなバグに化ける可能性があるため、顧客
からのバグ報告は慎重に分析する必要がある
– 報告された問題は2人の上級スタッフに送られ、変更計画
が立てられる
12

14. SPL導入による組織の構造1
• スコーピングチーム
– プロセスが行われるたびに、経験豊かな人が集められ形
成される
– ビジョンを共有し、開発目標について合意する
• ドメインの専門家
– ドメイン知識があるシニアSEがコンポーネントとフレーム
ワークを開発・保守・機能強化
• アーキテクチャーマネージャー
– 上級従業員がシステム全体の設計をM-Systemで監督・
評価
• コンポーネント開発者
– 経験の浅い開発者がアプリケーションエンジニアリングを
行う 13

15. SPL導入による組織の構造2
• 変更管理マネージャー
– 影響分析に基づき変更要求を評価し変更スケジュールを
決める
• リクエストディスパッチャー
– マイナーでマニアックな問題は変更管理マネージャーで
はなくリクエストディスパッチャーに送られる
– システムに関する深い知識が必要
• 問題追跡者
– 問題を追跡・管理・分析する
– 開発チームとは別に構成される
• 構造マネージャー
– Junitテストと自動ビルドプロセスを監視し、維持し続けさせる
14

16. SPL導入による教訓1
• メンテナンスの労力が60%、カットオーバーまでの
時間が50%削減
• 小さなチームによるSPL開発は組織構造の欠落に
注意する必要がある
• 株式市場のドメインは新機能を頻繁に要求しないた
めSPLに向いている
• 既存システムのカプセル化は非常に有用で、成功し
た1番の要因となった
• シンプルなアーキテクチャーが、保守や変更・拡張
を容易にした 15

17. SPL導入による教訓2
• 可変部分の変更・拡張はコンポーネントレベル（粗
い粒度）がほとんど
• 緊急時で再利用資産をうまく利用できない場合があ
った
• ビジョンが定まっていないので、SPLの最初の顧客
は危険かもしれない
• 再利用資産と製品が乖離しないよう管理する必要
がある
• プロセス定義がしっかりしていると、開発者の能力
やチームの大きさに開発が左右されない 16

18. SPL導入による教訓3
• JUnitを用いたテストを含むビルドの自動化は、より
高い品質のための鍵となる
• 単一のシステム開発に比べ慎重に影響分析をする
必要があり、問題解決に時間がかかる
• 顧客は開発プロセスに興味がないので、労力に応じ
た価格ではなく固定価格方式でプロジェクトを行う必
要がある
17

19. SPL研究に対するフィードバック
• PuLSETMのアプローチは実際の開発現場で貢献した
• 試験用に製品実例の情報を提供した
• 開発者とマネージャーのインタビューから、PuLSETMの小さ
な会社向けのバージョンが定義された
• 既存システムをコンポーネント化するリバースエンジニアリン
グのアプローチは想定どおりには行かず、もっと研究の余地
がある
• 企業目標とアーキテクチャー要素を関連付けることが重要
• SPLにおいて静的なコード分析ではクラス関係を検地するこ
とができないため、ランタイム情報に基づいた動的分析が必
要となる
18

20. まとめ
実際の企業にSPLAを適用させた
SPLのために開発プロセスと組織が変更された
SPLを企業に適用することにおける教訓と、
今後の研究へのフィードバックを示した
19

21. 私見
• 長所
– SPLを実際の企業に適用している
– 現状を研究にフィードバックしている
• 短所（要望）
– 大規模企業にもSPLを導入して、今回の結
果と比較して欲しい
20