連載 次世代開発基盤技術“Software Factories”詳解 第2回 開発手法「ソフトウェア・プロダクトライン」とは？ マイクロソフト株式会社　萩原 正義 2005/04/16

Page1 Page2

Back Issue

1 ソフトウェア工業化を目指して

　従来の開発プロセスの多くは、長期的視点と短期的視点が明確に分離できていない。あるいは、ソフトウェア・システムの各構成部分における要求や技術の変化に対して、その変化のスピードの違いをまとまりとして管理していない。

　図1はソフトウェア・システムを構成する複数のサブシステム（アーキテクチャやドメインの単位）*1における変化のスピードの違いを管理する2種類の方法を図示している。

*1 UML 2.0では、サブシステムとコンポーネントの違いは漠然としていて、サブシステムはコンポーネントの特殊なモデルである。また、コンポーネント自体は物理的な成果物ではなく、論理的な設計段階での構成体で、クラス概念を継承する。

　

図1　複数のサブシステムにおける変化のスピードの違いを管理する2種類の方法

○はコンポーネントを表し、□はサブシステムを表している。図中の2つのソフトウェア・システムには、それぞれ3つのサブシステムがあり、個別のサブシステムの中には2つずつコンポーネントが含まれている。左側のソフトウェア・システムでは、各サブシステム内に変化のスピードが異なるコンポーネントが混在している（例えば左上のサブシステムでは、「速い変化1」と「遅い変化2」が混在している）。一方、右側のソフトウェア・システムでは、変化のスピードが同程度のコンポーネントでサブシステムを構成している（例えば、右上のサブシステムでは、「速い変化1」と「速い変化2」でまとめられている）。当然、左側ではサブシステムの保守が困難になるので、右側の管理方法に移行すべきである。なお、この図はn階層モデルに類似しているが、UI層、ロジック層、データ層をサブシステムとして表現しているのではない。

　変化を管理するために理想的な方法は、変化のスピードがほぼ同程度のコンポーネントでサブシステムを構成し、それらのサブシステムの単位で全体のアーキテクチャを構築することである（図1の右側のソフトウェア・システム）。長期にわたり安定した基盤となるアーキテクチャを構築したうえで（＝長期的視点）、要求の変化に柔軟かつ俊敏に対応する短期的プロジェクトを遂行できれば（＝短期的視点）、アーキテクチャが有効に機能する大規模システム、特に企業システムでの開発ライフサイクルを成功に導ける。そのためには、長期と短期で視点を分離した開発プロセス、開発チーム、ドメイン*2の分割やサブシステム化を考慮しなければならない。

*2 ドメインにはシステム利用者の課題や要求の種類で分割される問題領域と、そのソフトウェア上の実現方法の種類で分割される解決領域がある。また、特定業務向けの垂直と汎用性の高い水平がある。ドメインは業務担当者、システム開発者の知識、経験に基づき分割される。

　前回の「Software Factoriesの理念」では、Software Factoriesの開発手法が、そのような長期的視点と短期的視点の違いを明確に分離して、それぞれに厳格に対応するものであることを簡単に紹介した。このような開発手法の考え方は「ソフトウェア・プロダクトライン」もしくは「プロダクトライン・アーキテクチャ」と呼ばれるが、今回はこのソフトウェア・プロダクトラインについて掘り下げ、より詳しく解説する。

◆開発手法「ソフトウェア・プロダクトライン」

　ソフトウェア・プロダクトラインあるいはプロダクトライン・アーキテクチャとは、長期間に複数の開発プロジェクトで共通利用するアーキテクチャやコンポーネントの基盤を構築し、その基盤を再利用した個々の開発プロジェクトを一種のプロダクト生産として見る考え方である。従って、生産されるプロダクトはプロダクトラインの下でソフトウェア・ファミリーを構成する。例えば、機能に複数のバリエーションがある携帯電話のような組み込み系装置、開発プロジェクトごとに選択的機能を持つWebアプリケーションやポータル・サイトなど、さまざまなバリエーションを持つプロダクトがソフトウェア・ファミリーとなる。

　長期間の複数の開発プロジェクトで、必要とされるソフトウェア要求と要求の変更頻度を予見できれば、長期間にわたってアーキテクチャやコンポーネントの基盤を再利用できるので、ソフトウェア・プロダクトラインは非常に有効な開発手法となる。ただし、一般的には長期にわたる要求の予見は不可能であるため、予見外の要求変更に対してソフトウェア・プロダクトラインを維持するためのコストを考慮したうえで、アーキテクチャやコンポーネントの基盤を構築する必要がある。

　そこで以下では、次の3点からソフトウェア・プロダクトラインの特徴や、維持コストを考慮したうえで、有効に活用するためのポイントを説明する。

1. 開発プロセス
2. 開発チーム体制とチーム・メンバーの役割
3. 開発責任の分担

　それでは、それぞれの項目について詳しく見ていくことにしよう。

1. 開発プロセス

　ソフトウェア・プロダクトラインの開発手法は、開発プロセスを長期的視点と短期的視点に分離するのが特徴である。その特徴を明確にするために、ほかの開発プロセス（UP:Unified Process）と比較してみよう。

　UPの開発プロセスでは、アーキテクチャの確立はプロジェクト初期の段階で行う。具体的には、プロジェクトの開発プロセスは方向付け、推敲（すいこう）、作成、移行という4つのフェイズで構成され、推敲フェイズでアーキテクチャを固め、プロジェクトの後半では大きなアーキテクチャの変更がないという前提でプロジェクト失敗のリスクを減らす（図2）。

図2　UPのアーキテクチャの確立

方向付け、推敲、作成、移行の4フェイズのうち推敲フェイズでアーキテクチャを確立する。アーキテクチャの確立は1回のプロジェクトの開発要求に基づいて決定するため、長期的視点による確立が難しい。現実的には、アーキテクチャは1回のプロジェクトで確立されるのではなく、複数回のプロジェクトの予算を使ってインクリメンタルに確立されることが多い。実際にアーキテクチャの確立だけでプロジェクトの予算化を行うのは困難であり、またインクリメンタルなアーキテクチャの保守が必要となるからである。

　UPのアーキテクチャの確立は、プロジェクトの非機能要求（例えば、パフォーマンスや信頼性など）に従って行われる。

　UPではプロジェクトの要求定義であるユースケースを中心に、長期間利用できるアーキテクチャの確立を考えるが、ソフトウェア・プロダクトラインではユースケースと、長期の複数プロジェクトにまたがる要求であるフィーチャ*3とを分離し、フィーチャに基づきアーキテクチャを確立する。

*3 ユースケースとフィーチャの厳密な違いについては、次回で説明する。

　ソフトウェア・プロダクトラインでは、アーキテクチャを構築するための開発プロセス（＝プロダクトライン開発）と、そのアーキテクチャが提供するフレームワークやコンポーネントを利用したプロジェクトの開発プロセス（＝プロダクト生産）を分離する（図3）。この「プロダクトライン開発」と「プロダクト生産」という2つの開発プロセスについては、それぞれ後に詳しく説明する。

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

ソフトウェア・プロダクトラインは、アーキテクチャの構築という長期的視野を重視し、長期的に継続される複数回のソフトウェア開発向けに適用される。左側のプロダクトライン開発がアーキテクチャを構築し、右側のプロダクト生産がそのアーキテクチャを再利用し、提供されるフィーチャを選択して、1回ずつのプロジェクト開発を行う。

　短期的視点と長期的視点の要求を分離することで開発プロセスでのアーキテクチャ確立の強制を明確化する。また、アーキテクチャ構築の開発プロセス（＝プロダクトライン開発）をプロジェクトの開発プロセス（＝プロダクト生産）から独立させることで、それぞれの開発プロセスで（ウォーターフォールなどの）フォーマルな開発方法論とアジャイルな開発方法論の組み合わせや、品質管理の方法が選択可能になる。

2. 開発チーム体制とチーム・メンバーの役割

　最近はEoD（Ease of Development）で示されるように、フレームワークや開発ツールの支援により、開発すべきコード量の削減、コード入力支援、技術の複雑さの隠ぺいなどが図られている。これらにより目覚しい生産性向上の効果を生んでいる。しかし、EoDの支援のおかげで、属性やアノテーション（＝コード部分に付加的要素を加える機能）の宣言、設定ファイルだけでトランザクション要求やセキュリティ構成定義が実現できたとしても、機能を適正に利用する背景知識や経験がなくては正しい開発はできない。また開発すべきコード量だけを見れば開発に掛かるコストは減少したかのような印象を与えるが、もともと開発コード量だけでコストを評価するのは誤りである。従って、EoDの目指す方向性は間違いとはいえないが、複雑化する技術進歩への対応法としては限界があり、根本的なソフトウェア開発の複雑さの改善とはならない。それではどうすべきか？

　プロダクトライン開発とプロダクト生産を分離することで、それぞれの開発プロセスを遂行する開発チーム体制やチーム・メンバーの役割を専門化することが可能である。

　ソフトウェア・プロダクトラインでは、アーキテクトや要求定義にかかわるビジネス・アナリスト、モデラー（＝ソフトウェア設計者）の上級レベルの開発チーム（以降、上級開発チーム）と一般レベルの開発チーム（以降、一般開発チーム）を分離することで、ソフトウェア開発の複雑さを低減させる。ここで、上級開発チームと一般開発チームは開発プロセスの上流と下流の分類とは異なり、両チームともに上流、下流のすべての開発プロセスを経験する。

　上級開発チームが、プロジェクト成功の根幹となる適正なドメイン・スコープの決定と要求定義によるアーキテクチャの確立、フレームワークやコンポーネントの調達や開発に従事し、その成果物を一般開発チームに提供してプロジェクトの開発を遂行する。一般開発チームに必要とされるスキルは、例えば、トランザクションやセキュリティの詳細を省いた、「プロパティ設定」「ウィザード（Wizard）」「カスタマイズを支援するモデル言語（DSL：Domain Specific Language）の利用」「簡単なカスタム・コーディング」だけにとどめる。

　すなわち、ソフトウェア・プロダクトラインでは、EoDを開発プロセスと開発チーム体制により実現するのである。

3. 開発責任の分担

　ソフトウェア・プロダクトラインでの開発プロセスと開発チーム体制は、別の見方をすれば、「開発の範囲と責任の分担」に多様性を与える。

　例えば、アーキテクチャを構築するプロダクトライン開発の遂行はA社が行い、プロジェクト生産の遂行はB社が行う、というようにソフトウェア開発を分担できる。例えば、A社はシステムインテグレータ（SIer）で、B社はシステムを利用するユーザー企業というケースも考えられる。あるいは、A社は特定ビジネス分野に特化したフレームワーク開発ソフトウェア会社で、B社はシステムインテグレータというケースや、A社は日本のソフトウェアハウスで、B社はオフショアの開発会社というケースもあり得るだろう。

　すなわち、これらの例で示したようなオフショア開発を含めた開発体制に関する新しいビジネス・モデルを提供するのも、ソフトウェア・プロダクトラインの特徴である。なお、当然ながらA社とB社の間の「開発責任の分担」に関する契約関係、資産の受け渡し、要求変更の手続きなどの細かな取り決めは必要である。

　また、A社とB社という2社間だけでなく、ソフトウェア・プロダクトラインで開発される特定ドメインの成果物、資産を1つの単位として、複数のソフトウェア・プロダクトラインを連鎖させるビジネス・モデルも作成可能である。

　この場合、1つのソフトウェア・プロダクトラインの単位が、Software Factories（＝複数のまとまり）における“Factory”（＝単体）となる。そして、連鎖の全体がソフトウェア開発のサプライチェーン（＝プロダクト供給の流れ）を構成する。

　本稿で“Software Factories”と複数形を用いているのは、理念としてFactoryのサプライチェーンを想定しているからである。この種の産業モデルはほかの製造業やそのほかの業種で産業の成熟化とともに発生したモデルであり、ソフトウェアの工業化を目指すための動きとなる。

　それでは、次に「プロダクトライン開発」と「プロダクト生産」の開発プロセスの詳細を見ていこう。

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第2回 開発手法「ソフトウェア・プロダクトライン」とは？
	1．開発手法「ソフトウェア・プロダクトライン」
	2．「プロダクトライン開発」と「プロダクト生産」の開発プロセス

　

「次世代開発基盤技術“Software Factories”詳解」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）