フィーチャーモデルについての議論

Susumu Yamazaki (ZACKY) @zacky1972

フィーチャー図に関して，2つの話をします．まず1つめの話．フィーチャー図って，マーケティング担当者から開発者まで，さまざま人が関わるので，おのずとその人の立場によってフィーチャー図の役割が変わってきます．

Susumu Yamazaki (ZACKY) @zacky1972

開発者の視点では，ソースコードの ifdef などからリバースした，実際に資産中に存在する可変性を見える化する役割を，フィーチャー図に求めるかもしれません．そういう立場だと，フィーチャー図を人手で書くことの意味はなく，リバースエンジニアリングツールによって書かれるべきでしょう．

Susumu Yamazaki (ZACKY) @zacky1972

しかし，マーケティング担当者の視点だと，フィーチャー図は別の意味合いを持ちます．言ってみればスコーピングの結果である「製品や資産がどうあるべきか」を示す航海図の役割です．この役割は，いくらリバースエンジニアリングをしても果たせないでしょう．

Susumu Yamazaki (ZACKY) @zacky1972

フィーチャー図には，この2つ(もしくはそれ以上)の立場をつなぐ重要な役割があります．しかし，システムが大規模化した今，フィーチャー図ではスケーラビリティという点で課題があるのは事実です．リバース技術も進んだので，もしかするとより適切な他の表現方法があり得ると研究者は考えています．

Susumu Yamazaki (ZACKY) @zacky1972

もう1つの話は，Yさんが某企業の方と議論していたときの話．その某企業の方が悩んでいたのは，フィーチャー図をかくときに階層化をどのようにすればいいのかということ．ある2つのフィーチャーがあったときに，何となくそれらに関連性がある気がするが，抽象的な上位フィーチャーを考えるのが面倒．

Susumu Yamazaki (ZACKY) @zacky1972

フィーチャーの数は膨大なので，そういう1つ1つの抽象化に関わっていたのでは，いくら時間があっても足りない．そういうような悩みだったと記憶しています．

Susumu Yamazaki (ZACKY) @zacky1972

そこから発展して，フィーチャーをツリー構造にまとめ上げるのが難しいので悩んでいるという話でした．

Susumu Yamazaki (ZACKY) @zacky1972

そこで Y さんが言ったのは，それなら上位のフィーチャーが何か，ルートに来るフィーチャーが何か，そんなことを考えるのをやめればいいじゃないかと．そんなことを悩まなくても，可変性を表現する手段はあるし，現実的にプロダクトラインを構築することはできる．

Susumu Yamazaki (ZACKY) @zacky1972

この言葉は僕の中でちょっと目から鱗でした．

Susumu Yamazaki (ZACKY) @zacky1972

無の状態からフィーチャーモデルを作った Kang 先生には敬意を払っていますし，今現在でもフィーチャーモデルは可変性を表す最も有力な手段であることには変わりはない．でも，完璧な手法ではないし，いつか乗り越えるか弱点を補わねばならない．研究者としてそう思いました．

Susumu Yamazaki (ZACKY) @zacky1972

同時に，Yさんのような幾多の困難を乗り越えてきた企業の技術者にとっては，目標は製品を効率よく出荷することであって，1つの方法論を追求することではない．道具の限界を見極めて柔軟に使い分けることが技術者にとって重要であることに気づかされました．

T.Fujikura - うふふのふ @tfujikura

@zacky1972 私のフィーチャモデルのイメージは論理式の塊です。抽象的な上位フィーチャはバリエーションポイントになるのなら必須、そうでなければ任意でクラスタリングでもして作れば良いかと思っています。図はクラス図と同じで必要に応じて生成する。

T.Fujikura - うふふのふ @tfujikura

@zacky1972 たとえば、ifdefのリバースで出てくるモデルとマーケット屋さんが作るモデルを比較するのは形式の世界でおこなって、違いが明確になったら違いの意味はそれぞれの世界で解釈するのはどうでしょうか。論理式だけで絶対的な意味はないかも、相対的に解釈するって感じかな

it’s me yoshi @YoshiWoods

@zacky1972 それはツリーにするかどうかではなく、何が共通かをみつけること。それをサボると何がコアかを見誤ります。

@PescadoDeAbril

OVMは feasible decision を見える化するもんではなかろうかと…。フィーチャ図とは少し用途が違うと思います。逆にアーキテクチャ一歩前まで抽象度が下がっているフィーチャ図はぐっちゃぐちゃでdecisionが見えにくいので，OVMと併用するのも一考の余地ありそ。

Susumu Yamazaki (ZACKY) @zacky1972

たぶん，この問題はリバースしたときに起こるんだな．ソースコードにはなんだかわからないけど製品によって違いがある．この状態だと，製品に違いがあると言うことはわかっても，それが何に由来するかはわからない．

Susumu Yamazaki (ZACKY) @zacky1972

次の段階は，その違いが何に由来しているかが認識できている状態．多くの場合，由来は機能の有無だったり，非機能要件などに関わるパラメーターだったり．つまりフィーチャーです．

@PescadoDeAbril

@zacky1972 共通性に限らず，可変性も名前がつけにくいのがいっぱいあります。特に，リバースでas isのフィーチャ図を作っているときなんか。コード書いた人に聞いたら「AがBになってCという状態でDになっちゃったからEするための可変性」とか。どうやって名前にするんだw

Susumu Yamazaki (ZACKY) @zacky1972

僕はこの2つの違いを製品指向とフィーチャー指向と呼びました(その話を岐阜で取り入れようと思っています)．何10年前にフィーチャー指向を言い出した人たちは，フィーチャー指向の方が資産の変更量が少ないことを「発見」したのではないかと思っています．Yさんのセミナーでその追体験をしたので

Susumu Yamazaki (ZACKY) @zacky1972

その次の段階は，由来(＝フィーチャー)はわかったんだけど，それらにはどうも構造があるようだ，という認識．その構造は，基本的には木構造に近い形で現れ，上位には能力やサービス，環境などが，下位には技術的なことが来るということを「発見」したのが，かの Kang 先生ではないかと．

Susumu Yamazaki (ZACKY) @zacky1972

問題は，開発現場でリバースしたときに，実の多くのフィーチャーについてこのような分析が現実的に行えない，ということだと思います．

@PescadoDeAbril

@zacky1972 「フィーチャ」じゃなくて「プロダクトライン」の話だけど，ビジネス面（製品面）でのプロダクトラインと技術面でのプロダクトラインは違うって書いてた人は数年前にいました。たしか，（昔の）PFEの論文だったと思うけど，SPLCだったかもしんない。

Susumu Yamazaki (ZACKY) @zacky1972

もちろん @YoshiWoods さんがいうように，そうだとしても「共通性は何か」＝「フィーチャーの構造がどうなっているか」を追求することには大きな意味があります．が，それができなかったとしても，PL 化する手段はあるよ，といいたい．

@kentaroy

共通性が50%は無いと、PLは失敗する。共通性の定義すら出来ない組織は、PLの前にやることがたくさんある。FEFレベルの飛び級は危険。

T.Fujikura - うふふのふ @tfujikura

@zacky1972 現場のifdefをリバースすると結構依存関係が汚くなってますが、それをいったん論理式で表して、論理的に等価な論理式に簡略化してifdefで再度表現すればフィーチャのリファクタリングになると思いますがどうですか、マーケのモデルを実装するにも使えるかも知れません