ソフトウェアプロダクトラインを阻むもの
島敏博氏のブログにプロダクトラインに関する話題が載っていた。いくつもの類似ソフトウェアを継続的に同時開発していく場合、その共通部と可変部に注目して可変部分を分離し、共通部分の比率を徐々に高めていくことで、高い品質と生産性を目指すというものだ。全く新しい複数の開発をこれから始めるという非現実的な状況ではなく、既に大量のソフトウェア資産を持つ組織が、その開発の壁（品質、生産性、拡張性等）にぶつかった時にプロダクトラインを導入する際には極めて現実的な形だろうと思う。
こんな図面を見せられると、プロダクトラインを知らない人は「開発のあり方として当たり前のこと」とネガティブな評価をしがちだけど、方法論を含めて上手く導入出来ている開発組織はあまり多くないようだ。開発部門間の壁、目前に迫った納期、プライドの高い開発者、似て非なる大量の既存コード等々、プロダクトラインの導入を阻害する要因は多々有るし、また、その実施形態も様々なのでどのような取り組み方がベストなのか一概には決められない。
例えば、単なる#ifdefでソースコードを切り分けるやり方も確かに一つの方法としては有り得るのだけど、（経験した人なら分かるように）#ifdefが増えるにつれてソースの可読性や品質は急激に悪化してしまうことが多い。だからこそ、プロダクトラインにおいては、目指すべき方向性とその実施形態としての手法を分けて考えることは出来ないと理解している。
事実、先月行われたIBM Innovate 2010では、UMLのクラス図上でプロダクトラインを示すという考え方が島氏の講演で紹介されていた。この図面を使えば、例えば「共通部はこの範囲、ここが機種A向けの可変部」という構成が明らかになるので、結果として「動作検証を行わなければならない範囲」「変更時に影響が及ぶ範囲」が一目瞭然になり、その効果は計り知れない。（単に#ifdefを使う方法では不可能な「見える化」だ）
実際問題として、プロダクトラインを開発に取り入れても直ぐに効果が表れるものではないので、長期的な取り組みが不可欠になる。だが、長期的な利益より目先の利益、長期的な貢献よりも短期的な成果が求められることが多い組織では少々難しいかも知れない。「急ぎの対応」「至急の案件」「緊急対応」と場当たり的な対応を繰り返す開発にこそ、短期間での対応が可能となる仕組み作りが不可欠のはずだが、長期的な視点に基づく地道な取り組みを軽視しがちなのは残念なことだと思う。
これらの取り組みを続けて、毎年毎年共通部を増やし可変部を少なく局所化する取り組みを絶え間なく続けることが、プロダクトライン開発の取り組みとなります。
島ぶくろ プロダクトライン開発の効果が見えるのは
（中略）
本質的に、なかなか短期間で効果を見せることができないのがプロダクトライン開発なので、しばらくはがまんが必要です。上司があまりに短期の効果ばかり要求しているところではなかなかうまくゆかないかもしれません。
関連
