「組み込みソフト開発現場でソフトウェア・プロダクトライン・エンジニアリングについて考えてみる（３）」

Dive 3： リアル SPLE ～

成功のツボ

・失敗のドツボ

大公開

　皆さん、当ページにお越しいただきありがとうございます。

　前回までは（Dive1、Dive2）、「なぜ今の組み込みソフト開発現場において、ソフトウェア・プロダクトライン・エンジニアリング（Software Product Line Engineering; SPLE）が有効なのか」について、実践事例を交えて述べさせていただきました。
　今回は、私どもがお客様をご支援する中で得た、
　・ SPLEの取り組みを成功に導くツボ 　・・・ 代表的な3つ
　・ SPLEの取り組みを失敗に導くドツボ ・・・ 3つの局面からひとつずつ
をご紹介していきます。
　既にSPLEに取り組んでいる皆様はもちろん、SPLEに関心を持ち、これから取り組んでみようとされている皆様にとって、ご参考になれば幸いです。

１． SPLEの取り組みを成功に導くツボ

　ここでは、SPLEを実践する上でツボとなることを3つご紹介します。

(1) SPLEに取り組む狙いが明確で、現場において共有されている

　SPLEに限りませんが、取り組むべき理由や目標が明確になっており、かつ、それらがメンバー全員の意識に刻まれていないと、現場での改善活動は成功に辿り着けません（そして、現場での改善の成功を積み重ねないと、組織全体の改善は到底成功し得ません）。

　弊社がご支援した事例では、例えば下記のような狙いを挙げられていました。

例1.既存機能を組織的に再利用することで、

・開発期間を短縮　　　→　“他社との競争に勝つ”

・開発コストを抑える　→　“利益を出す”

例2.品種、グレード、出荷先市場の違いに容易に対応できる拡張性を実現すること。

　　必要な機能のみを選択的に搭載してROMサイズをスリム化すること。

例3.製品の差別化ポイントを実現する機能を中心に、開発資産や設計ノウハウを共有・共通化したい。

(2) 直接的な効果だけでなく、 　　中長期的に生み出される効果もアピールする

　これもSPLEに限りませんが、現場の改善は一種の投資です。よって、現場で改善を進めるためには、上位のマネジメント層や経営層にその効果を理解してもらい、投資することの意思決定をしてもらう必要があります。
　SPLEの場合、以下の２つの視点で効果を訴求することで、理解を得やすいと考えています。
　ひとつは、直接的な効果である“検証済の再利用資産（SPLEではコア資産と呼ぶ）を活用して個別製品を開発することでもたらされる生産性や品質の向上”です。
　そしてもうひとつは、中長期的な視点での効果として、“コア資産を生み出すプロセスを構築できる”ことです。
　一度作ったコア資産で得られる直接的な効果には、限りがあります（生み出せる個別製品の種類の限界。あるいは、時間経過に伴い、新しい状況に合わなくなるという限界）。しかし、コア資産を“一度作った経験から得たノウハウ”に基づいて継続的にコア資産を生み出せるとなれば、“直接的な効果”を将来に渡って享受することができます。

(3) アーキテクチャの統一も行うという意識を持つ

　コア資産は、再利用すべき“ソフトウェア部品”（コンポーネント、モジュール、等）の集合体と考えられがちです。
　確かにSPLEにおいて、個別製品の開発は、コア資産から適切なソフトウェア部品を選択して組み合わせることが主な作業となります。コア資産として蓄積されている検証済のソフトウェア部品を最大限活用して個別の開発量を最低限に抑えることで、生産性や品質の向上を図っているわけです。
　しかし、何の制約なく、どんなソフトウェア部品でも自由に組み合わせられるようにすることは現実的ではありませんし、かつ必要ではありません。なぜなら、製品ロードマップや製品バリエーション表によって、ソフトウェア部品の組み合わせ方は、ある程度決まってくるからです。
　そこで、ソフトウェア部品の使いどころ・使い方に一定のルールを設けます。このルールを実現するものが、SPLEにおけるアーキテクチャです[注1]。従って、あるコア資産群を用いて実現される一連の個別製品（これらがプロダクトラインを形成します）は、ある統一されたアーキテクチャを持つことになります。
　このプロダクトラインで統一されたアーキテクチャ自体も、個別製品で再利用されるべきという意味でコア資産なのです（アーキテクチャ設計ドキュメント、ルールを実装したソースコード、等）。

[注1]プロダクトラインアーキテクチャ、参照アーキテクチャ、等と呼ばれます。また、もちろん、アーキテクチャが実現することは、ソフトウェア部品の組み合わせルールだけではありません。様々な非機能要求等を織り込んで設計する必要があることは、通常のアーキテクチャと同じです。

２． SPLEの取り組みを失敗に導くドツボ

　ここでは、SPLEを実践する際に陥りがちなドツボを、3つの局面から一つずつご紹介します。

２．１． 【導入局面】基本的な問題が解決できていないままにSPLEに取り組む

　顕在化している形は様々ですが、私たちが改善をご支援する開発現場の多くは、次の3タイプの問題を抱えておられます。

　このような問題を解決しないままSPLEに取り組んでも、成功する確率は低くなります。なぜなら、コア資産の構築や活用が、開発者個人の判断やスキルに依存してしまうからです。
　SPLEにおいて、コア資産の構築は、言わば先行投資です。この先行投資はコア資産を活用することで得られる個別製品開発コストの低減（生産性の向上による工数削減、品質向上によるテスト・デバッグ工数削減）によって、回収していくことになります。
　しかし、上記のような問題を解決できていない開発現場では、開発者によって先行投資やその回収に差異が出てしまいかねません。結果として、組織全体で見た場合、適切な先行投資（コア資産の構築）やそれに見合う回収（個別製品開発での活用）が行えていないリスクが大きくなってしまいます。

２．２．

【コア資産の開発局面】スコープを広げすぎて／狭めすぎて、 コア資産が作りにくい

　コア資産を構築する際は、どの個別製品の開発で使うことを想定するか決める必要があります（想定した範囲は“スコープ”と呼ばれます）。
　傾向的には、できるだけ多くの製品で使えるコア資産を作ろうとして、スコープを広く設定してしまいがちです。しかし、広げすぎるとスコープに含まれる個別製品間の共通部分が少なくなり、かえってコア資産を作りにくく（少なく）なってしまいます。
　と言って逆に、狭めすぎると、コア資産を活用して生み出される個別製品が少なくなり、コア資産の構築に要した投資を回収できなくなる恐れが出てきます。
　スコープの決定方法には、様々な提案がされているようですが、実際の運用としては、仮決めのスコープを広げたり狭めたりしてコア資産の候補を抽出し、それらを開発する投資が個別製品の開発で回収できるか否かを見極め、最終的なスコープを決めていくというのが現実的と考えます。
　ある事例では、スコープをとある製品シリーズに仮決めし、コア資産の候補を出しました（出し方の一例は連載第2回：Dive2をご覧ください）。それらの候補をお客様内でレビューしたところ、ある機能群の仕様（特定のメカの制御仕様、操作者の危険を判定する仕様）については、当該製品シリーズ以外の製品とも共通化すべきであるということが判明しました。そこで、当該製品シリーズに加え、共通化すべき機能群についてのみ、他の製品シリーズの製品もスコープに加えました。

２．３． 【個別製品の開発局面】再利用のダークサイドに囚われてしまう

　苦労して折角コア資産を構築したとしても、実際の個別製品の開発で活用してもらえなければ、無駄になってしまいます。ところが、他人が作ったソフトウェアを積極的に再利用して自らが責任を負うソフトウェアを開発することに対して、開発者は心理的な障壁（== ダークサイド）を持ってしまいがちです。例えば、

　このようなダークサイドに囚われないためには、個別製品の開発担当者が、下記のような意識を持つことが必要だと考えています。

★ コア資産を作った人を知ろう！　作った意図を知ろう！
★ コア資産に問題があれば積極的にフィードバックしてあげよう！
★ 改善策や希望があれば提案してあげよう！
　　（コア資産の開発担当者はフィードバックや提案をバイアスなく聞く耳を持とう）

★ 使えるコア資産をみんなで育てようという前向きな意識を持とう！

　SPLEは組織として取り組むべき活動なので、“保守性・再利用性を高める”という意識が全開発担当者に浸透していないと、このようなダークサイドに囚われる可能性が高くなります。

次回の予告

　最後までお読みいただきありがとうございます。
　今回は、SPLEの実践を成功に導くツボと失敗に導くドツボを３つずつご紹介しました。ツボは（ドツボも）、まだまだあります。SPLEを活用して開発現場の改善を図りたいとお考えの皆様は、ぜひ弊社のコンサルタントを活用して、皆様にとって役立つ“ツボ”を得てください。
　さて、次回はいよいよ本連載の最終回です。筆者がSPLEの実践（ご支援）を通じて考えるようになった、組み込みソフトエンジニアの今後の姿（役割）についてお話したいと考えています。次回も、ぜひお楽しみに！

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。