ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(2) ―― 狙いを定めて投資を回収，ガイドライン策定は必須

●まずは心理的障壁を取り除く

　プロダクト開発とソフトウェア・プロダクト・ライン導入スケジュールの関係を図1に示します．

図1　活動スケジュール

　開発プロジェクトのほとんどのメンバは，ソフトウェア・プロダクト・ラインに関する知識を持ち合わせていませんでしたので，まずはプロダクト・ライン開発に関する技術セミナを開催して基礎知識を獲得させました．技術セミナでは社内のソフトウェア・プロダクト・ラインのスペシャリスト，および大学でソフトウェア・プロダクト・ラインを研究している先生方を講師に招き，「ソフトウェア・プロダクト・ラインとは何か」の理解はもちろんのこと，「ソフトウェア・プロダクト・ラインの効果」についての理解を深めてもらい，メンバの導入に対する心理的障壁を取り除くことに腐心しました．

●ガイドラインを定めて統一性を確保する

　次に，ソフトウェア・プロダクト・ライン開発での最初のプロセスとなるフィーチャ分析を行うためのフィーチャ図作成ガイドラインを作成しました．なぜならば，多くのメンバが同時にフィーチャ図を描く場合，一般に知られている作成ルールだけではフィーチャ図の統一性が保たれないからです．

　ガイドラインがない状態でフィーチャ図を作成した場合，フィーチャの上下関係が整理されていないため，開発メンバがフィーチャ図を理解する時間と手間がかかりました．今回作成したフィーチャ図作成ガイドラインでは，Kang氏が提唱するプロダクト・ライン開発手法「Feature-Oriented Reuse Method（FORM）」^（1）の4階層モデル（能力層，動作環境層，ドメイン技術層，実装技法層）などを導入しました．また，記述ルールなどを整理することで，開発メンバが作図しやすく，理解しやすいフィーチャ図の作成ガイドラインが出来上がりました．それと同時に，外から見えるサービスや動作に近いフィーチャだけでなく，より実装に近い部分のフィーチャまで，上から下までのフィーチャがつながった形でとらえることができ，今まで以上に設計資産の関係が明確になりました．

　今回作成したフィーチャ図を図2に示します．

図2　タスク間通信機能でのフィーチャ図（抜粋）

　また，コア資産開発に必要な設計ガイドラインも作成しました．このガイドラインには，コーディング作法や資産の構成管理方法，共通機能と可変機能の分離方法などを記載しており，コア資産を開発するドメイン・エンジニアリング・チームが設計するうえでよりどころとなるものです．

　これらのガイドラインは，十分に時間をかけて事前準備することができなかったものの，利用しながら軽微な間違いや不備を取り除き，最終的には開発で得たノウハウをフィードバックし，内容の充実を図りました．

●流用されてこなかった機能をコア資産に選定

　活動の順序として，まずは装置Aの開発と並行してフィーチャ抽出・分析を行い，2000以上のフィーチャを抽出しました．そのうち，コア資産として開発できるフィーチャは数多くありましたが，今回は初適用であったことと，装置Bで投資を回収したかったことから，コア資産対象を以下の条件で絞り込みました．

• 開発人員が少なくて済む機能：ソフトウェア・プロダクト・ライン説明会の開催などにより，メンバへの知識の浸透を図ったが，コア資産開発ができるほどのスキルの高いメンバは少数であったため，その少数精鋭メンバで開発できる規模の機能を対象とする．
• 実績として流用率が低い機能：装置Aで開発した機能を装置Bに使用する場合，通常の流用開発では流用率が低くなってしまう機能を上手にコア資産化できれば，コア資産化による効果がすぐに現れる．すなわち，装置Bで投資を回収できることとなる．

　上記条件に合致する機能の絞り込みを行った結果，タスク間通信機能をコア資産化することに決めました．タスク間通信機能とは，複数のプロセッサ・コアに配置されている各タスク（スレッド）間の通信における論理レイヤを終端する機能です（一部物理レイヤの制御も含まれている）．

　装置Aと装置Bではプロセッサ数/プロセッサのコア数やタスクの配置が異なるので，通常の流用開発では装置Bで作り直すコードが多くなることが分かっていました．そこで，この違いを隠ぺいする仕組みを入れたコア資産を作ることができれば投資効果が高いと考えて，開発に取りかかりました．