Product Line Enginering Blog

　ソフトウエアプロダクトライン開発に於ける変更管理について紹介する。それはチャレンジングな課題であり、多くの場合プロダクトラインの成功に関わること（製品群の構成よりも）。　ソフトウェアプロダクトラインは、まるで生物のように継続的に変化し続ける。ソフトウェアプロダクトライン開発について聞きかじった人の多くは、それは慣れ親しんだ通常のソフトウェア開発よりずっと複雑になると信じている。しかし驚くなかれソフトウェアプロダクトライン開発の多くの側面は従来方式の開発に似通っている。主な違いは同時に配慮するべき製品の数。そしてこれは疑いも無しに複雑性と課題をもたらすことになる。

Sources of Change

　変更要求やプロダクトラインへの変更には非常に多くの異なるソースがある。1つのソースは製品から出た不具合。欠陥はすぐに削除する必要があるが、ビジネス上で欠陥の影響をこうむる製品群へのインパクトを見積もることはとても重要な課題。出荷済みや開発中の製品など。ここでは迅速であることがキーであり、即座に（そして正確に）インパクトを見積もることでのみ、適正な判断・決定をすることができる（いつ、どのようにして、プロダクトラインのどの製品群の欠陥を直ぐに修正するか、後回しにするか、しないなど）。

変更の2番目のソースは、新製品のアイデア。多くの場合、マーケティング、製品管理、あるいは顧客からアイデアはもたらされる（GPS受信機と携帯電話でナビゲーションアプリケーションをサポートするといったような）。そしてアイデアが必要とする新しい機能がプロダクトラインへ統合される必要がある。（この例ならハードウェアの変更とドライバソフトウェアの一部など）　しかし多くの場合、製品のアイデアは単に既存の機能と要件の新しい組み合わせを求めるのみ（ビジネス電話にMP3プレーヤーとFMラジオアプリケーションなど）

技術的トレンド（携帯電話のタッチ画面操作のような）は、この点で異なっている：プロダクトラインに新しい技術トレンドを取り込むことを考えるには多くの時間を割くべき。なぜならそれがもたらす変更は非常に大きなインパクトをプロダクトライン内の既存フィーチャ、要件、そしてソリューションスペース上の様々な要素（資産）に与えることになるので。それゆえ1つの技術トレンドは、プロダクトラインの既存の情報へ多大な変更をもたらすこととなる。

Change Management Challenges

　プロダクトラインの変更管理の主要な課題は？それは明らかに変更のインパクトが単一の製品開発に比べて高いということ。変更が市場に出荷された製品や開発中のものにまで影響を与えるので。変更を伴う一つの問題が多くの製品に影響するということ。しかしながら、その逆のケースもある。一つの修正が影響を受ける全ての製品の修正となる。いずれにせよ変更によるインパクトは増加するので、より注意深い扱いが求められる。多くの資産にインパクトを及ぼす一つの変更だけでなく、一般には各共有されている資産ごとへの多くの変更要求もある。なぜなら単一製品に比較してより多くの利害関係者が関わることになるので。そしてインコンパチな（両立できない）変更要求なども多く含まれる。それらが変更管理プロセスで正しく扱われないと、変更要求の確認に追われ、実装やテストなどの作業どころではなくなってしまう。

しかしながら問題や欠陥の数は、単一製品の資産を開発することに比べて同等、あるいはいずれ減少することとなる。理由はシンプル。問題の数はコード行数におよそ比例するので。共有されるコードはそうでない単一製品用のコード（バリエーション）に比べて多くなるが、その増加は一般に穏やかな傾向となるので。そして共有されるコードはより良くテストされるし、堅牢でもある（より多く運用されることで問題を出し尽くすなど）。結果、プロダクトライン開発の効果を得ることが出来る。問題がより少ない良いコード。あるケースでは、プロダクトラインのやり方で部品をマージして共有することで、製品間に関わる問題を全体の１０％に削減している。

変更の速度を管理しコントロールすることは興味深い課題。あるプロジェクトが共通資産への新機能や修正を出来るだけ早くに必要としても、他のプロジェクトは頻繁に変更されない安定性を望むことになる。なぜなら共有される資産への変更には、再テスト・再リリースが全ての製品に伴われるので。このような利害関係は避けようが無く、妥協して（歩み寄って）解決されなければならない。とにかくはプロセスや採用される技法により、できるだけこのような課題を緩和できるようにすること。また利害関係者が増えるということも、さらに複雑な要因となる。ある意味 SPL の取組みによる成果を得るためは（失敗しないために）、上手な意思疎通と協調が必要。

要は意思疎通と情報交換のインフラ作りが大切ということ。プロダクトライン開発では全ての利害関係者がプロダクトラインの全ての関連情報（要件、テスト結果、変更要求、バリアント定義、フィーチャモデルなど）に、バージョン管理される共有コードと同様に簡単にアクセスできなければならない。それには中央集権で統一された情報管理が求められる。そして殆どの要件管理・変更管理・テストツールは、自身でプロダクトライン開発を支援するようにできていない。それゆえ要件管理や変更管理のための専用ツールと、バライアビリティやバリアント情報を維持管理するためのソフトウエアプロダクトラインツールが必要となる。

このデータベースの情報は継続的に変更され続ける。そして多くの場合十分な情報が無かったりする。またアーキテクチャ図や顧客リクエストや各種情報などの補完的なドキュメントへの参照もあったりする。そしてこれら全ての情報は、プロジェクトマネージャやアーキテクトなど異なる利害関係者に異なった見え方で提供する必要がある。例えばある製品開発の開発者は、それに関わる要件と機能についてのみ知りたいだけで、全プロダクトラインの全機能を知りたいのではない。プロダクトラインマネージャなら異なる製品バリアントの比較や、共有フィーチャの特定グループに対する変更要求に関する状態などに興味を持つことになる。

プロダクトラインの情報モデルからそれぞれの観点の情報が得られることで、関係者ごとのタスクが単一製品開発に比較しても追加の負荷がなく、高度に実施できるようにされるべき。

プロダクトラインに関わる変更を阻害する対処されるべき顕著な違いがあることは明らかであるが、製品固有の課題や変更要求は通常の単一製品開発のものと同様に扱える。

Getting it right

　SPL における変更管理に銀の弾丸は無いが、プロダクトラインの変更プロセスをどのように行うかの幾つかのアイデアを、その役割や組織上の構成の点から紹介する。

SPLに特有の変更管理の複雑さに対応するためには、組織上の一定の要求、変更に対する市場や顧客の要望、その他多くを打ち合わせるための、適正な基盤・インフラをお膳立てすることが必要となる。しかしながら基本は実績の多くある従来からのアプローチと殆ど同じ。例を用いて変更管理の役割とプロセスを説明する。共通のコア資産を提供するプラットフォームがあり、それらを使用する複数の製品開発プロジェクトがあると仮定。これら異なる全てのプロジェクトやプラットフォーム開発の管理は、プロダクトライン・マネジメント・オフィス（Product Line Management Office）によってコントロールされる。このオフィスに必須の役割はプロダクトラインマネージャで、プラットフォームとプロジェクトをコーディネイトして調和させ、プロジェクト間のレポートや査定などもプロダクトラインのタスクとして取り計らう。そして基本的には全ての意思決定のトップとなる。他の重要な役割にプロダクトライン品質マネージャがあり、全ての開発資産・成果物の品質を管理・メンテナンスすることの責任を持つ。これはソフトウエアプロダクトライン開発で特別の役割ではないが、通常よりも重要（重責）となる。またドメインのエキスパートはプロブレムドメイン（問題空間）と具体的なソリューションドメイン（解決空間）へのマッピングに必要となる知識を提供する。

この筋書きでは変更要求は一つの変更管理委員会によって取り扱われる。この委員会は全プロジェクトとプラットフォームに対する意思決定をまかなう。なぜ、それが重要となるか？もし変更要求が先にプロジェクト内で対処されてから、プロダクトラインに重要であるという考えから変更管理委員会にフォワードされるとすると、a)少なくとも他のプロジェクトが課題を認知するまでに遅延が生じる、b) 多くの関連トピックの可能性が変更管理委員会に全く知らされなくなってしまう。このような管理体制では上手く行かない。プロダクトライン変更管理委員会は、単なる一製品のみの問題はそのプロジェクトに即座に一任しながらも、複数製品やコア資産にインパクトをもたらす全ての変更を管理しなければならない。

変更管理委員会が得られる情報のフィルターとなりながら、アーキテクチャレビュー委員会が、アーキテクチャが常に安定して活用できることを受け持つ。一般には製品の進化によりコア資産も進化されるので、この業務は継続的に必要となる。そしてアーキテクチャのガイドラインやパターンの詳細記述もアーキテクチャレビュー委員会の活動となる。基本的に、ソリューションスペース（解決空間）の実装を管理することになる。

そしてプロダクトライン管理委員会はプロダクトラインマネージャとプロジェクトマネージャで構成される。それはプロダクトラインに影響する戦略的決断（プロダクトラインのスコープ・範囲の定義、プロダクトライン組織構造の決定、製品開発の優先付け）など上位レベルの意思決定を担う。また製品スポンサーもプロダクトライン管理委員会に関与することができる（この場合は上述の役割は負わないが）。製品スポンサーはユーザや顧客を代表することになる（なのでプロダクトマネージャの役割ともいえる）。いくつかの決定にはドメインの熟練者も関与することになる。しかしながらプロダクトライン管理委員会はコンセプトのレベルでプロジェクトをコーディネイトして調整することが目的なので、通常はマネージャやスポンサーのみで担われる。

ドメインの熟練者は変更管理委員会に関与して、ドメイン内の変更の一貫性を保ち、異なって来る変更要求をまとめて再利用の最大化、重複の排除に努めることになる。可能なら、製品スポンサーも変更管理委員会に関わるべき。製品ラインの戦略に変更の悪影響が出ないように確認をするため。アーキテクチャレビュー委員会には、テクニカルなアーキテクトや場合によってドメインのエキスパートが関与する。そして、それ以外の開発者は（幸か不幸か）、これら委員会に関わることはない。

これら各委員会はいつもあるわけではないので、その間を取り持つような作業者も必要となる。プロダクトライン管理委員会の一部として、プロダクトライン・タスクフォース（特別委員会）は、日々の業務を担う。そして深刻な課題が浮上したなら、タスクフォースは個々の委員会に通告する。このタスクフォースは、ドメインの熟練者、テクニカルなアーキテクト、場合によってはビジネス上のエキスパートや個々の製品の熟練者などで構成される。このタスクフォースは新機能を認識して評価し、変更管理委員会にそれらを提案する。ドメインのモデルを詳細に定義することに加え、関わる技術的トレンドも特定する。そしてアーキテクチャにも関わる。しかしながら最も重要なタスクは、ソフトウエアプロダクトライン開発で各プロジェクトが恩恵を受けるようにすること。

Is Your Change Management Fit for Product line Development?

　たとえ素晴らしいアーキテクチャがあり、またpure::variants のような優れたプロダクトライン支援ツールを有していても、変更に対する安定した仕組みを取れないなら全ては泡と化す。ソフトウエアプロダクトラインで変更管理の取り組みに重要な特性・要素とは？

(1)変更要求から影響を受ける製品群にトレースできること

　もし変更管理が単に変更があることを通告するだけで、その変更要求が関与する既存製品群が記録されないなら、プロダクトライン開発にはあわない。単一製品のみ影響を受けるか全製品がその対象となるのかのどちらかのみ。しかしながら製品のサブセットも影響を受けることがある。影響を受けるサブセットを知ることで、その対処や意思疎通に関わる工数を軽減できる（特にテスト）。この情報無しでは、全ての問題が例えそれが単一製品のみに関わるものであっても、全ての製品にわたって問題が通達されることになってしまう。

(2) コア資産からそれを用いる製品にトレースできること

　ある修正を目的にした変更要求によってコア資産を変更するならば、それによって影響を受ける製品群を特定できなければならない。さもなければ非常に多くの製品のテストをする羽目になり、工数が掛かって製品リリースが遅延してしまう。あるいはその資産を使っていない製品の顧客にまでリコールをするような事態に陥りかねない。ビジネスへの悪影響は計り知れない。

(3) 変更要求から関係するコア資産にトレースできること

　多くの場合、変更から既存製品にトレースできることだけでは不十分。変更管理に問題を登録した後に新製品を構成しビルドするとしたら。コア資産のどれが問題の影響を受けるかを特定できて、それらを使用する各製品にトレースすることが出来るなら（上述 ２）、新製品開発にも影響するかもしれない問題を特定できる。

（２）、（３）は両立できれば（１）はそれほどの課題ではなくなる。製品群の一覧は殆ど自動で生成できるようになるので。

これらはプロダクトライン開発の取り組みに必須と言ったものにはなってないが、無くては完全な失敗となる。特にプロダクトライン開発の初期段階で成功して、多くの変更要求と共に派生製品が多く生み出されるようになると、正しい変更管理が無ければ当初の成功は直ちに裏目となってしまう。なので備えることが賢明。

A Sample Change Management Process for Product Line Development

　広範に異なる製品ドメイン、プロダクトラインに対する取組みのバライアティ、などから単純に全てにフィットする変更管理のプロセスは無い。しかしながら、以下に説明するサンプルプロセスは大抵のプロダクトラインに適用できる。そして多くのケースでプロセスは十分簡易化できることを、コアとなるプロセスの紹介の後説明する。

筋書きとして、プロダクトライン内で多くの製品が並行して開発されメンテナンスされていることを前提とする。製品はユーザの観点でわかるフィーチャや機能性でもって定義され、共有されるコア資産と幾つかの製品特有の資産で構築される。顧客・ユーザは特定製品の欠陥をレポートし、多くの場合影響を受ける機能を挙げる。同様に機能の追加、変更、削除などの変更要求は、多くの場合製品顧客・ユーザに関わるが、他にもプロダクトライン・マネジメント委員会などから特定製品にのみ関わらない要求も来る。問題（issue）への対処・取り組みのワークフローや状態は、一般的な問題（issue）をトラッキングするためのツールのそれと同様（“New”, “Assigned”, “Fixed”, “Verified” などの状態、そして問題（issue）間の単純な依存関係）。例えば バグ管理ツールであるBugzilla のようなシンプルな問題（issue）トラッキング（追跡）ツール。

ここで用語として”問題（issue）”とは、欠陥、要処理事項（アクションアイテム）、変更要求などを意味する。

一製品の欠陥に対して一つの問題を提起するだけの単一システムの取組みはプロダクトラインのシナリオとはならないことは明白。共有されるコア資産の欠陥は複数製品に影響するので。ただ単一製品のみではなく全ての影響をこうむる製品へ問題をリンクさせることは良いことではあるが制約もある。問題が全製品で修正され動作することを検証されるまでクローズできないこと。もし修正の検証作業がグループからなる製品群に対して分かれて実施される場合、幾つかの製品では修正が正しいことが検証され、他の製品にはその情報が行き渡らないなど。これは問題（issue）トラッキング（追跡）ツールでは記録して管理することが複雑で困難。なぜなら”部分的に検証済み” といったような中間状態、検証済みの製品リストなどが問題（issue）内に記録される必要があるので。そして検証済みの製品のリリースも、全ての製品で検証が確認されるまで問題（issue）を正式にクローズできない。



このような場合、一つの問題（issue）を関連するタイプに振り分ける方法がある。WorkIssue は、問題（issue）解決の進捗を記録するために用いる。ProductIssues は、個々の製品に関して問題（issue）の状態を記録するために用いる。すなわち各ProductIssue は一つの製品にリンクされる。ProductIssue の目的は主に、製品の問題（issue）への検証と、その製品への問題（issue）解決策の適正さを、トレースすること。そして大事なのが、MasterIssue を用いてWorkIssue と 全てのProductIssues を一つにまとめること。なぜなら問題（issue）は、WorkIssue と 関連した全てのProductIssues の両方がクローズされて始めて完全にクローズできることになるので。MasterIssueはその為に使用され、全ての問題（issue）への正しい解決が記録される。


変更管理のアクティビティ図 問題（issue）の登録・更新
上のアクティビティ図では、最初の問題（issue）が登録されてからの手続きを示している。問題（issue）に対する初期確認から得られる情報に基づいて関連の問題（issue）が定義される。当初の問題（issue）はWorkIssueになる。シンプルに事を進めるために、MasterIssueはProductIssues がある場合のみに定義されるようにする。（すなわち、問題（issue）の影響をこうむる複数の製品がある場合）。そしてWorkIssueへの変更がある場合はいつでも同じプロセスが実施される。

このアプローチでは様々なゴールをサポートする。共有される資産への問題（issue）修正と、それを製品群に反映させることを適正にモニタできること。（これは一製品のみが関わるならシンプル。単一製品開発と変わらないので）　そして品質に対する妥協無しの迅速さが求められるような各製品ごとに、同じ問題（issue）でも異なる状態を持たせられる。

もちろん、このようなワークフローを実施するには変更・修正のインパクトを評価できる適切なツールのサポートが欠かせない。そして状態の変更への対処を自動化できることも必要（不要なマニュアル作業を削除する工夫）。ここで pure::variants は、製品間にまたがる問題（issue）の状態を視覚化し評価するための優れた表示機能を持つ .

Final Remarks

　以上は、当然ながら開発チーム（プロダクトライン）ごとで固有の変更管理の課題に対して完全な解となるわけではないが、配慮するべきことへの何らかのヒントになると思う。場合によってはワークフローの単純化も可能。例えば全製品の同時リリースを実施しているなら、各関連製品ごとで別々の状態に対処する必要は無くなる。

変更管理の課題は、プロダクトラインの学術研究や文献には余り紹介されていないように思う。そして、より多くの実践者や研究者の考え、経験を知り理解したいと思っている。是非とも考え・知識・概念などを知らせて欲しい。

leave a comment

このブログのオリジナルはこちらから Moving targets – Change Management for Software Product Lines

The Product Forest

　殆どの製品が個々に独立して開発されている。しかしながら幾分の共有する機能がある。これら製品の問題領域（problem domain ）は非常に似通っています。例えば、それら製品の全てがエアコンの制御をする（異なった方式で）。この場合、Product Forest 型と呼ぶことができるでしょう。UIのウィジットや算術処理などの基本ライブラリを共有することは再利用の基本系として存在するが、共有するアプリケーションロジックは無い状態。このパターンは、同一ドメインの異なった顧客に複数のプロジェクトを個別に、かつ同時に進行させる場合に良く見受けられる。下図のように、 (P0 ～ P3) の製品が時間とともに登場し、変更やバグフィックスなどにより、(P0’-P1’’’)のように進化する様子がわかります。

　Product Forest 型の他の例は、早期リリース時のMicrosoft Office。それに含まれるアプリケーションであるExcel, Word, PowerPoint など基本コンセプトを共有し、関連製品としてセットで販売されました。しかし、それらは全く異なったコードをベースにしていました。アプリケーションが同じように振舞うのに、それらは統一されなかったという経験をお持ちでしょう。このようなすれ違いを感じる振る舞いこそ、Product Forest 型で出くわす問題なのです。時間の経過とともに、製品間の一貫した振る舞いはより難しくなる。そしてサポートとメンテナンス費用が次第に増大する。（個々の製品で個別の対処と知識が求められるので）　そして同じ会社ということで同一感を求めて購入した顧客の満足度を下げることになる。

The Product Bush

　Product Bush型では、製品間の結び付きがより強くなります。そこでは製品が共有する原型があり、それを複製して個々の製品が開発される。新製品は基本的に既存製品のコピーに対して開発（というより微調整）され、新規のあるいは変更された要件が満たされます。

　このパターンで何が問題か？Product forest 型では、時として共有は全くありませんでしたが、新製品のための適切な原種を選択するだけで（低コスト、少ない時間で新製品へ発展させられる）、とても良いプランであるかに思えます。コピーを取る事にコストは殆どかかりません。必要なツールもコピーだけなので無料です。そのためクローンに要する部分は、安く上がるのですから。

　しかしながら初期段階では良く見えても、後からしっぺ返しを喰らうことになります。例えばP0の顧客が旧製品であるP0と新しい P1の統合したものを希望した場合。もしも個々に進化・発展を遂げてきたシステムのコードをマージした経験があるならば、この事の重大さを想像することは容易です。多くの場合、必要な機能のコンビネーションを改めて実装するほうが安く上がるでしょう。もしProduct bush 型が長期にわたって発展していて、バグ対応が多くの製品に反映されている場合、これは悪夢となるでしょう。数百・数千に枝分かれしている Product bush 型を見たことがあります。もしその枝分かれの様子を描写すれば、ペンの使い方を学んでいる子供が描くようなランダムな絵になるでしょう。そのようなものを正しく理解し、メンテナンスすることはできません。

　でも必ずしも、どのような場合でも Product bush 型が問題であるとも言えません。長期に亘るメンテナンスの必要が無く、同時並行して開発される製品が無い（一つの開発が終わってから次の製品開発をするような場合）、あるいは新製品が必ず旧製品機能のスーパーセットを持っている。このような場合であれば、Product bush 型で上手く運用できるでしょう。

　このProduct bush 型シナリオが進捗中で、でもなぜ bush （やぶ、茂みなどの意味）型なのかと気になられたら、紙に製品間の関係を描いて見ると良いでしょう。。

The Product Gang

　次のレベルの製品間の血縁関係は、Product Gang 型です。再利用資産の構成と誂えで製品群が構築されます。　再利用の意味する所は、新製品に対して再利用資産を組合せ、新製品に必要となる部分を開発するという状態。再利用資産（ここでは“Platform” PF）に対する変更は、アプリの開発者が新しいバージョンのＰＦを取り入れないと、製品には反映されない。Ｐroduct gang 型における製品群は、より多くの資産を共有し、それらはプラットフォームの資産に由来すると言えます。それ故、製品はプラットフォームのインスタンスであり、ここでは製品という代わりに製品バリアント(PV0-PV3)と呼ぶことにします。バリアントとバージョンの違いに関しては、私の別のポストで紹介しています。　this post.

　高度に構成可能なアプリケーションフレームワーク、再利用コンポーネント上に構築される製品群、どのようなものでも。基本的に多くの再利用を意図した開発アプローチは、これに属するでしょう。　”かなり良いと思うけど、何か問題でも？”　はい、確かに上記2つより再利用に関して良さそうですが、本当のソフトウエアプロダクトラインに対して何か足りません。まさしく現実世界のギャングのごとく、全メンバー間には強固な関係が存在しています。しかしながら、シークレットも存在する。誰も自身のことを他のメンバー（ギャング）に明らかにしない。そしてこのアプローチの根本的な課題は、ギャングのメンバーに対する情報が殆ど、あるいは全く無く、共通資産に対する変更の影響を見積もることは困難で、またその調整も非常に厄介です。例えばコンポーネント内のインターフェイス方式を変更する必要がある場合、他のアプリケーションからコールされることが無いことを確認できると良いのですが、ギャングのメンバーは個々に活動（進化）しているので（別の離れたブランチで、あるいは異なったバージョン管理ツールのリポジトリで）、そのようなことを確認することは容易ではありません。そして一般に、product gang のメンバーに提供される再利用部品の用法に関する十分な情報が無い場合、非常に控えめな想定しか出来ないでしょう。多かれ少なかれ全メンバーが現存のやり方で利用しているかもしれないことを想定しなければなりません。そして変更された場合には、それを用いる全メンバーで正しく動くことを検証出来るといいのですが、そのためには変更をリリースする前に少なくとも幾分のギャングメンバーでテストをする必要があります（あるいは他の手段によって取り得る全てのケースを確認すること）　しかしながら、わずかに異なる個々の製品に対するビルド処理、他のプロジェクトのリポジトリにアクセスできないこと、あるいは現実的に時間上の制約から、たいていの場合は不可能です。そして製品個々のソリューションを優先することで再利用はやがて低減されることになる。（それらソリューションは局所的であるために、、）

The Product Family

　そして最後のパターンは、おおよその最終目標となるソフトウエアプロダクトライン開発であり、これは Product Family 型と言えます。前に見た Product gang 型との主な違いは、開発組織全体で製品ファミリー(PV0-PV3) に対する認識が得られることです。そして Product Family 型のアプローチでは、製品ファミリーの資産が進化する中で、全ての関連製品に対する継続的な配慮もされ得ます。どの時点でも共有資産に変更があった場合、（その時点で関連する）ファミリーの全てのメンバーがそれに関わることになります。これはもちろん技術的なプロセスのみならず、資産や製品（バリアント）の個々の担当者間における検討、優先順位付け、変更の却下なども関わってきます。

　再利用コア資産とそれからなる製品との間の双方向なリンクこそが、ソフトウエアプロダクトラインでの再利用と従来型の再利用アプローチとの根本的な違いです。もちろんこれは、ただで得られるわけではありません。大規模なファミリーを抱えておられるのなら、このことはご想像できるかと思いますが、、、

From here we go

　すでに紹介してきた全てのパターンには、それぞれのユースケースがあります。常に問題と言うことではありません。しかしながらプロダクトラインということであれば、それは Product family 型しかありません。そして要は、どのように他のパターンからProduct family 型へ移行できるかです。これには基本的に2つのシナリオがあり、そのひとつは “Separate Product Merger” と私は呼んでいますが、それは個別の製品群（多くの場合全く個別に開発される）がスタートポイントとなります。既存製品間で共通の問題空間（problem space）を有しているが、解決空間（solution spaces）は全く依存関係が無いか、少なくともある程度の逸脱があり、解決空間（solution spaces）のマージには多くの努力が必要となります。しかしながら、なにはともあれ１つか２つ程度の製品の解決空間（solution spaces）の資産を新しいプロダクトラインのベースとして用いることを考えることです。例えば2つのベスト製品を選択、その一つは最もシンプルな製品、そしてもう一つは最も複雑な製品を。

　Product bush 型、Product gang 型では、再利用は既に行われています。それゆえ、私はもう一つのシナリオを単純に、”再利用の改善（Reuse Improvement）”と呼んでいます。なぜなら問題空間（problem space）も解決空間（solution）の資産も、多くの既存資産に密接で、それらを新しいプロダクトラインに用いることが出来るからです。多くの場合、この再利用改善シナリオでのゴールは、殆ど不変な全既存製品が新しいプロダクトラインの資産で生成できることです。シンプルで直ぐにかかれるアプローチは、解決空間（solution space）のバリエーション（コードレベルで比較して得られる情報　これに関しては後日詳しく述べるつもりです）から始め、そして問題空間（problem space）のバリエーションへと繋げることです。別のアプローチは問題空間（problem space）から始めて解決空間（solution space）へと進むことで、これはソフトウエアプロダクトライン開発を開発の全く始めの段階で開始するのと同様の手段です。この場合、問題空間（problem space）のバリエーションを解決空間（solution space）に存在するバリエーションにマップすることは容易ではないので、問題空間（problem space）と解決空間（solution space）のマップは幾分複雑な作業となります。しかしながら、多かれ少なかれこのアプローチは、“Separate Product Merger” のシナリオでも必須な作業です。

　バリエーションポイントを解析し、そして問題空間（problem space）と解決空間（solution space）をドキュメント化することは、容易な作業ではないので、今後改めてご紹介する予定です。

このブログのオリジナルはこちらから Knowing where you are: Product Relation Patterns

一言で言えば、フィーチャモデルはプロダクトラインのコモナリティとバライアビリティを保存（記録）するシンプルで、階層的なモデル。問題空間（problem space ）上の各関連した特性がモデル上の一つのフィーチャとなる。ひとつのフィーチャ（feature）はここで、利害関係者に関連性がある一システムの一特性である。利害関係者の興味次第で、フィーチャは一要件、一テクニカルファンクション、ファンクショングループ、非ファンクショナル（品質）特性となる。悪いニュースは、フィーチャモデルはコモナリティとバライアビリティを記述・描写するための抽象概念であるということ。各プロダクトラインを個別に決定するのに、フィーチャーが明確にされる必要がある。しかしながら一般にはフィーチャは実際の実装コンセプトからは、ある意味切り離されて定義されている（すなわち解決空間 solution spaceから）。　例を挙げると、自動車の色が一フィーチャなら、それは立派な名前を持つことになるが(“dark marine blue”　とか) 、しかしその色の特定メーカに対する注文番号はここでは言及されません（それは解決空間 solution space）。ソフトウエアでも同じ。一フィーチャが一関数にマップしていようが、何十ものコンポーネントに展開されていようが、ここでは関係なし。もし利害関係者が関連する一つの特性とみなし、それがバライアビリティに相当するならば、それは単一のフィーチャである。

フィーチャモデルは、フィーチャの集まりでノードを形成するツリー構造です。フィーチャのバライアビリティは、グループからなるフィーチャー群とそれらへの弧で表される。最近の殆どのフィーチャモデリングの試みでは、4つのタイプの異なるフィーチャグループを利用可能としています。“mandatory（必須）”, “optional（選択自由）”, “alternative（どれか一つ）”、“or（少なくとも１つ）”　各フィーチャは複数のフィーチャグループを子として持つことが出来る。バリアント （variant） にどのフィーチャを加えるかを指定するとき、以下のルールが適応される。もし一つの親フィーチャが一バリアントに含まれるなら、

　・全ての mandatory な子フィーチャ群は必ず含められること (”n from n”),
　・いくつかの optional なフィーチャを含めることが出来る (”m from n, 0 <= m <= n”),
　・唯一のフィーチャが、 alternative なフィーチャグループから選択されなければならない (”1 from n”),
　・少なくとも１つのフィーチャが、 or なフィーチャグループから選択されなければならない (”m from n, m>=1″).

明らかなのは、“optional” や “alternative”　などこれらの用語（表現）は、上限、下限数の指定によって表現されてグループのカーディナリティ（その種類の絶対数）のコンセプトにマップされる。そして、これら４つは最も一般的に用いられています。これら用語のコンセプトは、正確な定義を読まなくても一般的に正しく理解されています。（“or” のフィーチャーグループは、“alternative”と混同されがちですが）

たいていのアプローチは追加のコンストレインツ（制約）も指定できる。フィーチャ間の相互排除（素敵なシャツと、ピンクのシャツは対立する）や、求められる関係（素敵なシャツは、白色シャツか黒色シャツのいずれかを要する）。これらコンストレインツはツリーの階層を横断（さらに複数のフィーチャモデルを用いている場合はモデル間さえも）する。アプローチとツールによって、このようなコンストレインツを表現する言語は、その表現力と複雑さから、これを専用目的とするものから、一般に利用可能なXPath や OCL まで選択肢がある。しかしながらそのようなコンストレインツは控えめにするべきでしょう。コンストレインツが多くなるに従い、モデル内のコネクションを視覚化し理解することは人間には困難になってきます。

いくつかのアプローチではfeature cardinality（フィーチャのカーディナリティ）と呼ばれるコンセプトをサポートしています。そして多重のルールをフィーチャモデル上のサブツリー（下位木）に持たせることが出来ます。例えばシステムに対して複数のセンサーの設定が可能な場合、各センサーごとのフィーチャーのサブツリーを個々に作るより、センサーと一つ記載して例えば１～３のカーディナリティ数を与えて、最小１から最大３つのセンサーのサブツリーを選択させる。feature cardinality（フィーチャのカーディナリティ）とそれに関連する課題については、今後のブログで特別に紹介することにします。それまでは、以下の Read On にリンクを紹介した Kryzstof Czarnecki さんの資料を読まれることをお勧めします。

残念ながら標準的なフィーチャモデルに対するグラフィカル表記は、まだありません。多くの異なる表記が存在しています。しかしながら文字通りである、FODA(Feature-Oriented Domain Analysis) メソッドのグラフィカル表記の拡張形式が最も一般に使用されています。ただこれは標準テキストツールとグラフ・ライブラリーからなり、ただ難しいだけなので、もっとシンプルなものを選り好んでいます。

上述したフィーチャーに対して非常に抽象的な定義をすると、ほぼ全てがフィーチャーとなり得ます。そしておおよそこれは正解でしょう。　そしてフィーチャは何か、それからどのフィーチャをフィーチャモデルに選択するかを、どのようにして見分けるか。

ここで最も重要な作業は、そのフィーチャモデルの利害関係者を明確にすることです。誰のためにフィーチャモデルを作るのか？　プロダクトラインから生み出される製品のエンドユーザにフィーチャが定義されることがあるなら、それらフィーチャは顧客に対してわかり易くなければなりません。良い例は、自動車メーカーのウエブサイトで今日提供される自動車の構成ツールです。またフィーチャモデルの構造は、エンドユーザの考えに沿っているべきでしょう。

簡単に聞こえますが、実際は完璧に行うことは非常にハードです（正直無理でしょう）。多くの場合、ユーザのタイプによりシステムの構成の異なるアプローチがあります（”特別な小さなフィーチャを探す” VS　”自動車のエンジンタイプ、サイズ、色などといった一般的な決定・判断をする”）。一般にフィーチャモデルは自由にナビゲーションできるのに（決まった順番でフィーチャを選択することは必要ない）、判断・決定はモデルの根幹によってしまう傾向があることもより一般的で、それはユーザをそれへ（あるいはツリーのパートへ）深く導いてしまうことになる。

それでもし、異なる言語の利害関係者が存在したら？各利害関係グループごとに複数のフィーチャモデルを作りましょうか？あるいは、最も重要なグループのみに作るのか？かさねて、明解な答えはありません。小さくてシンプルな依存関係がよりよいでしょう。多くのプロダクトラインアプリケーションにとっては、一つのフィーチャモデルが良い選択となります。しかしながら、プロダクトラインの部品群が個別のプロダクトラインを形成するなら、複数のフィーチャモデルはもはや必然となるでしょう。

コンフィギャブルなミドルウエア上で走るアプリを考えた場合、ミドルウエアのバライアビリティはアプリケーション開発者が用いる言語に取り込まれる必要があり、同じフィーチャモデルをそのミドルウエアを用いる全てのアプリで使うべき。明らかに、このケースではアプリケーションドメインのバライアビリティと、ミドルウエアドメインのバライアビリティのマッピングが必要です。このマッピングを作ることは、アプリケーション・プロダクトライン・エンジニアの役割です。ミドルウエアが、唯一の特定コンフィグレーションに使用される場合は、マッピングは全く無いかもしれません。それ以外は、それらは全く複雑となる。例えば、アプリケーション層にセキュアとノンセキュアなアプリ動作の選択がある場合、あるミドルウエアのフィーチャ（例えば暗号化サポート、SSLプロトコルをサポートしした認証によるデータ確認）は、セキュアなアプリ動作のフィーチャを選択する時には有効にされる必要があります。携帯電話で走るアプリなら、そのような認証管理アプリが無いために、そうでないかもしれませんが。

考慮すべき他の側面は、フィーチャの粒度。もしフィーチャが粗い粒度のバライアビリティのみを表現するなら、有効な構成による個々のインスタンスは恐らくシステムの詳細を十分に表現できないでしょう。細かすぎる粒度では、多くの管理されるフィーチャが増大、そして複雑性。ここで再び、背景は何か？：自動製品構成には、製品ロードマップのプランと検討よりも、高度な詳細化が求められる。そして後から詳細を追加するほうが、削除するより容易。

経験では良いフィーチャモデルを取る簡単な方法は、とにかく一つ作ることから始めて、そしてそれを用いてプロダクトラインの既知/想定できる製品バリアントを記述すること。たいていの場合、全くの瞬時にいくつかの決定は非常に賢くないことが判る。時に選択されたフィーチャがバライアビリティを十分に表現しない（詳細のレベル）。あるいは、ツリー構造が間違っていた。例えば、あるオプションAはフィーチャBの子供として用意されていた。しかしAの親フィーチャであるBが、Aを選択されたときに選択されないなど。

しかしながらこれらの間違いは、次への糧になります。多くの場合、問題なのはフィーチャそのものよりは構造である。

フィーチャとフィーチャモデルについて、まだまだあります。今後このブログで書くことにしますので、お楽しみに。

しかし、一つ言い残しがあります。プロダクトラインのバライアビリティを表現するには、フィーチャモデルは非常に重要なエレメントであると考えています。しかしながら、フィーチャモデルのみでは十分ではないケースがあり、フィーチャモデルが取るべき手段ではないケースもあります。もしバライアビリティがどちらかというと合成的なタイプだと、多数の基本エレメントがあり、それらはフォーマルなルールで組み合わされる（家を建てる時のレンガをイメージ）。これらのルールでは無制限のブロックの使用が可能です。この場合、フィーチャモデルではこれらを効率的に表現できないでしょう。しかしながらレンガの取り得るプロパティなら（色、材質など）、フィーチャモデルは可能なバライアビリティを上手く表現できるでしょう。

そして全く数え切れないくらい、フィーチャモデルのみを取るべきケースもある。

このブログのオリジナルはこちらから 　Feature Models and Features - What’s this?
（文中で紹介されている、”Read On にリンクを紹介した Kryzstof Czarnecki さんの資料を読まれることをお勧めします”　へのリンクもこちらからご確認ください）

一資産の一バージョン（A version of an asset ）は、あるタイミングで記録されたその資産の状態・内容。一資産に対する2つのバージョンは、同一あるいは異なる資産内容を取る。従って複数のバージョンは、異なる時間・タイミングにおける同一資産となる。多くの場合複数のバージョンは、ラベルや番号で識別される。時として、リビジョン（部品が変更された場合に作られる）とバージョン（ラベル・指定されたリビジョン）の間で相違がある。

一ベースライン（A baseline ）は、一連の資産群からなるバージョンのある断片・スナップショット（指定された）。

一バリエーション（A variation ）は、単純に複数の資産間の相違。

一バリエーションポイント（A variation point ）は、一資産の異なるバリアントを指し示す判断・選択肢のこと。一つのバリエーションポイントは、複数の選択可能なインスタンスから構成される（バリエーションポイント上の有効となるバリエーション）。バリエーションポイントには、通常インスタンスへの選択が行われるバインディングタイムがある。バインディングタイムの例は、コンパイル時、インストール時、ランタイムなど。

バリアントの導出（variant derivation ）とは、可能な資産群から資産を組合わせて、定義されインスタント化されるバリエーションポイント群を包含させるアクションのこと。複数のバインディングタイムをとるバリエーションポイント群があれば、バリアントの導出は各バインディングタイムごと段階を追って起こる。その導出の結果は、提供されている資産の組合せである。導出は、多くの技術的手段でもって行われる。最も単純な（そして基本的にお勧めできない）方法は、資産群をコピーして（手動で）部分修正すること。例えばコンフィグレーションのパラメータなど。そのような導出の結果は、コンフィグレーション（a configuration）とも呼ばれる。
プロダクトラインエンジニアリングではバリアントの導出は中心的部分となる。理由は、プロダクトラインの資産への変更（バグフィックス）後は、たいていの場合、その資産を持つ全ての製品（バリアント）を再生成する必要がある。そしてこの工程を最小限にするために、自動導出をサポートするツールが用いられる。

もし資産 X’ が資産 X を基にしていて、同じXから派生した他のバリアントの資産と顧客等の観点で異なる特性を持つならば、その X’ は、バリアント（variant）を象徴することになります。これらの違いにより、同じ資産 X から派生する他の資産群との区別ができます。例えば色を塗り分けて青と赤のボール（色以外の点は全く同じ）を作る機械であれば、青ボールと赤ボールの２つのバリアントを生成できる。このとき、赤、青で塗り分けられるボールの数は問題ではありません。

ここでバリアントという用語の定義には、バリアントを導出した時期は含まないことを留意してください。バリアントは、時間に依存しません。

重要なのは、異なる資産間の僅かな相違全てが個々のバリアントを作るのでは無く、製品の利害関係者（顧客など）から見えるバリエーションが個々のバリアントを形成するということ。例えば、最初にシャツを一枚買い、翌週同じブランド・同色・同じ縫製・同じサイズの二枚目を買った場合、これらはもしかすると洗濯ラベルに多少の違いがあれども、それはたいした問題ではなく、それらを同じものとして扱えるでしょう（ボロボロになるまでは）。しかし自分用と友達用に違ったサイズを購入したなら、それらはバリアントです（相対するバリエーションは服のサイズ）。ソフトウエアシステムで考えると、たいていの場合、一資産に対するバグフィックスは新しいバージョンを作りますが、それによって新しいバリアントが出来るわけではない。バグフィックスによって、顧客の観点で望んだり要求される資産の特性が変わるわけではないので。

最後になりますが重要なのは、バライアビリティ（variability ）はバリエーションポイントで資産群から得られるバリエーションを表現します。多くの場合、全てのバリアント群をリストすることはその数が多すぎて不可能です。フィーチャモデルやコンフィグレーションルールなどのバライアビリティモデルなら、システムのバライアビリティを表現し得えます。

次のブログではフィーチャモデル、さらにフィーチャとは何か？といった事を紹介いたします。

このブログのオリジナルはこちらから Versions, Variants and all the rest - Basic definitions