XDDPとSPLEについて

it’s me yoshi @YoshiWoods

XDDP と SPLE: 但し、国際会議に出てきた事例では、システム No. 1 を顧客に納品した後、その No. 1 自体をコア資産として扱い、以後の Nos. 2, 3, 4,... の開発の度に再利用しやすいように整備してきた、というのもあるのです。

it’s me yoshi @YoshiWoods

XDDP と SPLE: XDDP が何であるかはかなり具体的に論ずることができますが、SPLE はパラダイムなので方法論／技法としてはバリエーションが多く、XDDP との差異を明確に言明できません。このため、先程からしつこく「基本的には」と断りを入れています。

it’s me yoshi @YoshiWoods

XDDP と SPLE: まとめ１―XDDP と SPLE は基本的に別物だが、後者の定義が人によって異なるため、実際には重なる部分が見られる。

it’s me yoshi @YoshiWoods

XDDP と SPLE: まとめ２―異なりはするが、同じ製品群に対して時期や個別対象を違えて二つを別々に適用することはありうる。

it’s me yoshi @YoshiWoods

XDDP と SPLE: まとめ３―コア資産は進化させる。それは派生と呼べる。但し XDDP を適用することは、皆無でないにしても、典型的ではない。

it’s me yoshi @YoshiWoods

End of XDDP と SPLE. 仕事に戻ります。

あきやま🐯 @akiyama924

@YoshiWoods XDDPとSPLEの解説ありがとうございました。ボトムアップのXDDP、トップダウンのSPLEといった印象を受けました。つまり、最初はSPLEを意識してトップダウン的にスタートするのですが、そのうちにどんどん汚れてきてXDDPでボトムアップ的に整理してと。

it’s me yoshi @YoshiWoods

前半は合ってます。 QT @akiyama924: @YoshiWoods XDDPとSPLEの解説ありがとうございました。ボトムアップのXDDP、トップダウンのSPLEといった印象を受けました。…

it’s me yoshi @YoshiWoods

そうなるとコア資産に基づいて個別製品を派生させる仕組みが仕組みとして機能していないので、SPLE と呼べるかどうか。 QT @akiyama924: …最初はSPLEを意識してトップダウン的にスタートするのですが、そのうちにどんどん汚れてきてXDDPでボトムアップ的に整理してと。

あきやま🐯 @akiyama924

@YoshiWoods 後半、違っていましたか。

あきやま🐯 @akiyama924

@YoshiWoods SPLEで初め、数製品こなしてくると、だんだん、当初のアーキテクチャーが持たなくなってきてSPLEでなくなってきて、そうなるとXDDPで派生開発するしかなくて、これじゃイカンとちゃぶ台をひっくり返して新アーキテクチャーをSPLEでやるぞというイメージです。

あきやま🐯 @akiyama924

ただの企画ですら外すんだから、いわんや群企画をやといった、、、苦い思い出が。ｗｗ

saltheads @saltheads

.@YoshiWoods 効率よく派生機種開発できるようなモデルを作ることもSPLEの目的なので、変更理由やTM並びの頻出パターンを俯瞰していいモデルが導出できそうなところは多いに期待したいです。

it’s me yoshi @YoshiWoods

@akiyama924 実際には、特に予定していた進化（変更）でなく、欠陥修正がヘタに扱われると、仰る様なエントロピー増大を招いてしまうかも知れません。事例としては覚えがありません（大体いいことしか表に出ないし。）

saltheads @saltheads

.@YoshiWoods 私がSPLEの外れた解釈の元凶かもw。単独でもそれぞれ役に立つけど、お互いに組み合わせるともっと役に立ちそうな感覚は十分にあります。いいSPLEにはいいインプットが必要は確か。

あきやま🐯 @akiyama924

@YoshiWoods うわぁ。SPLEって成功事例の方が多いのですか？　あ。でも、仰る通り表に出るのは成功事例ですね。

saltheads @saltheads

.@YoshiWoods コア資産の進化は資産の追加ではなく、凝集度をあげるための責務入れ替えも含まれるので差分開発を越えてしまうことが多い感じがします。

細谷泰夫 @yasuohosotani

@YoshiWoods 固有部同士はときに派生開発的になっているのでXDDP を活用すると良いと思ってます。先日@saltheads さんともそんなお話しをしました。

it’s me yoshi @YoshiWoods

@saltheads 特に可変点の追加は共通部に対してのものでありながら変異体追加には不可欠の作業なので、通常の意味での追加でないにしても、進化には付き物だと思います。ただ、それを XDDP では変更仕様の一部として扱えます。ううむそうすると同対象に同時に適用しない訳でもないか。

it’s me yoshi @YoshiWoods

先ほどの salthead氏への返信と同じですね。 QT @yasuohosotani: @YoshiWoods 固有部同士はときに派生開発的になっているのでXDDP を活用すると良いと思ってます。先日@saltheads さんともそんなお話しをしました。

細谷泰夫 @yasuohosotani

@YoshiWoods @saltheads ＴＬ確認しました。同じですね。こういう議論や@saltheadsさんがその前に言われている変更パターンの話しを@AOOmimiさんも交えてやりたいなと思ってます。

it’s me yoshi @YoshiWoods

@yasuohosotani 再訪ー固有部として使っている資産の中身が不明確な場合に使えますね！ QT: @YoshiWoods 固有部同士はときに派生開発的になっているのでXDDP を活用すると良いと思ってます。先日@saltheads さんともそんなお話しをしました。

it’s me yoshi @YoshiWoods

@yasuohosotani もっというと、派生開発による製品変種追加から SPLE に移行する時、仕様化困難な共通部の一部はブラックボックスのままコア資産として扱い、徐々に取り回しが容易な状態にしていくという手はありますね。ただその場合、XDDP が友好なのでしょうか？

細谷泰夫 @yasuohosotani

@YoshiWoods 派生開発からSPLEに移行する手前に、「変更方法を再利用する」というフェーズがあると思っています。これは先ほど話題に出ていた変更をパターン化するという話しと同じです。XDDPは「変更方法の再利用」に優れていると思ってます

細谷泰夫 @yasuohosotani

@YoshiWoods 「変更方法の再利用」で頻出するパターンは、SPLEの可変性の定義に繋がるはずです。頻出パターンにかかわる構造は、XDDPでホワイトボックス化されるのでそこを足がかりにできると思います。