ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(3) ―― 導入方法と効果は開発タイプごとに異なる
●[分析3] 顧客要求をサービス視点で分解し，最下位機能と1:1に対応する設計部品を定義する
ここでは，下記の手順で分析を進めました（図5）．
- ケーパビリティ・フィーチャ：顧客要求をサービス視点で分解し，複数の下位機能を抽出する．サービス視点で分解できなくなるまで，これを続ける．
- 実装技法フィーチャ：最下位機能と1：1に対応する設計部品を実装技法フィーチャ上に定義し，これを設計構造視点の最下位レイヤの設計部品とする．
- 最下位機能と同義となる設計部品をボトムアップで組み上げてシステム構造を決定する．なお，組み上げの際に不足する設計部品（サービス視点からは見えない設計部品）があれば追加定義する．
図5 最下位機能と1:1に対応する設計部品を抽出して組み上げたフィーチャ図
この分析方法のメリットは，機能追加時に影響がある設計部品を限定できるため，再利用性が高くなることです．デメリットは，最下位機能と最下位の設計部品を1：1に対応させたことで，設計部品同士で共通化設計ができず，各設計部品の冗長性が増えてしまうことです．
●調査・検証で見えてきたこと
今回，三つの分析を行った結果，それぞれの方法に表1のようなメリットとデメリットが見えてきました．
表1 今回の手法のメリットとデメリット
[分析1]の方法は各機能が影響を与える設計部品の特定が容易である一方，設計部品間の整合性が低くシステムの全体像を定義しづらくなってしまいました．[分析2]の方法は，設計構造上は最適な構造となるものの，機能追加時に複数の設計部品に影響が出てしまい，開発物の量が増加してしまいました．[分析3]の方法はボトムアップで組み上げるため，設計構造上は最適となりづらくなるものの，機能追加時の設計部品への影響は限定できました．
今回の分析結果では，[分析3]の方法が本プロジェクトの目的にかなっていることが分かり，試験的に一部のソフトウェア構造を変更してみたところ，効果が期待できそうなことが見えてきました．一方で，フィーチャや部品化の粒度に課題があり，今後，最適な設計のパターンなどを見出していく必要があります．また，冗長性に伴う性能面での改善にも取り組んでいく予定です．
＊ ＊ ＊
今回は，開発タイプ別にプロダクト・ライン開発手法を適用した事例を紹介しました．通信機器やネットワーク・システムでは繰り返し再利用されるものが多いので，少しでもQCDを改善するためのコア資産化への取り組みやアーキテクチャ改善の取り組みは，欠かすことのできない活動となっています．
次回は，プロダクト・ライン開発手法で成功するかぎとなる点などを紹介する予定です．
うちば・まこと
つくだ・のりあき
富士通九州ネットワークテクノロジーズ（株）
