ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(3) ―― 導入方法と効果は開発タイプごとに異なる
2．フィーチャ・モデルと実装構造の分析事例
さて，どのプロジェクトでも共通した悩みの一つが，フィーチャと実装構造の対応付けでした．再利用を考えずに設計したものは，一つのフィーチャが実装構造のさまざまな個所に影響を与えてしまっており，なかなかうまく再利用できずにいました．そこで，通信システムに組み込まれる画像処理に関する製品開発を例に，フィーチャ・モデルと実装構造の対応付けについて，複数の方法で分析してみました．
●ファームウェア改版時の変更個所を限定するために開発手法を導入
例とした製品開発プロジェクトでは，以下のような手順で開発を行っています．
- ハードウェア・プラットフォームを固める．
- 同プラットフォーム上で動作するファームウェアを改版し，機能追加を繰り返す．
この方法により，より早く，より良いサービスを顧客に提供するべく開発しています．しかし現状のファームウェアの改版では，一つの機能を追加しようとするとプログラムのさまざまな個所に修正が入ってしまい，開発スピードの低下や，プログラムが複雑になったことによる設計品質の低下などの問題が起こる恐れがありました．
これらの問題を引き起こさないために，機能を追加することで変更が必要となるプログラム個所を局所化（限定する）ことが重要であると考え，プロダクト・ライン開発手法の導入の検討を行いました．
●2種類のフィーチャ分析を組み合わせて三つのアプローチを実施
ここでの目的は，「ユーザに提供する機能と，それを実現する設計物間の関連性をシンプルにする（機能の追加・変更による設計物への影響度を抑える）」こととし，いくつかの切り口でフィーチャ分析を行いました．
なお，ここでは，プロダクト・ライン開発を用いたフィーチャ分析を，大きく以下の二つとみなして分析を進めました．
- ケーパビリティ・フィーチャ：サービス視点（ユーザ視点）からのフィーチャ分析．顧客要求を実現するための機能が「どのような特徴を持つか」といった切り口で機能を分解する．
- 実装技法フィーチャ：設計構造視点からのフィーチャ分析．顧客要求を実現するためのシステムが「どのような設計部品にて構成されるか」といった切り口で設計構造を分解する．
この2種類のフィーチャ分析を，以下の三つのアプローチによって組み合わせて分析し，両フィーチャ間の関連性を調査・検証しました（図2）．つまり，「ユーザに提供する機能とそれを実現する設計物間の関連性をシンプルにする」ための，再利用に向いた部品化やアーキテクチャを作り出すことができないかを分析することとしました．
- [分析1] 顧客要求をサービス視点で分解し，さらに設計構造視点で分解する
- [分析2] 顧客要求をサービス視点と設計構造視点で個別に分解し，対応する機能と部品を関連付ける
- [分析3] 顧客要求をサービス視点で分解し，最下位機能と1:1に対応する設計部品を定義する
図2 分析1~分析3の違い（模式図）
いずれの分析でも「ケーパビリティ・フィーチャ」（青四角）の分析方法は同じだが，その分析結果であるフィーチャと，実装構造（「実装技法フィーチャ」，赤四角）の関連付けの方法が異なる．
