研究会の活動テーマ
「XDDP」や「USDM」はもちろんですが、その他に派生開発にまつわるいろいろなテーマで研究活動を行います。現在、候補として想定されている研究テーマとそのテーマの背景や目指すところを以下に説明します。ただし、これらの研究テーマのすべてが、今すぐに取り組まれるわけではありません。研究会に参加する会員の人数や会員の立場、経験内容によっては取り組むことができません。また、個々の研究会をリードする人が確保されなければ研究も進みません。
現在、以下のようなテーマを想定しています。
いうまでもなくこれらの研究会の活動が盛んになるためには、なによりも多くの会員の参加が必要です。
このHPをご覧の皆さん、本会が主催する各種の研究会に参加して一緒に派生開発を成功させる方法を手に入れましょう。研究会の運営では、定期的に集まって議論する場も設けますが、遠方の方の負担を軽減するためにもMLを活用します。そして、成果としてはできるだけ「論文」の形にまとめるようにします。なおここでまとめられた論文は、原則として本会のHPで公開します。
この研究会に参加するためには会員（正会員・賛助会員）に限りますので、多くの方の入会をお待ちしています。
研究会活動成果はこちら
各研究会のテーマ詳細
T1：障害の克服方法
「XDDP」は派生開発アプローチ全般のプロセスを対象範囲としているため、「XDDP」で提案している一部のプロセスだけを採用してもうまくいきません。そのため、これまで慣れてきたプロセスを変えることに対する抵抗が生じます。
多くの場合、新しい方法が持ち込まれるとき、現行のプロセスに対して「追加」する形で取り組まれるのはこのためです。もちろん、これでは負荷が増えるだけですので成功する可能性は低くなります。また、これまで慣れ親しんできた（もちろん成功していない）方法や考え方で適当にアレンジしてしまうことも起きており、いろんなところに変化に対する抵抗が見られます。
これとは別に、CMMIに取り組んだ組織では、何らかの形で組織の標準プロセス（開発アプローチ）を持っています。困ったことに、これらの標準プロセスのほとんどは新規開発のアプローチになっており、「XDDP」のアプローチとは大きく異なります。またこれらの組織では、組織標準はこれを遵守するものであり、承認された標準プロセスを変えてはいけないという認識（もちろん間違った認識）になっているため、これと異なるプロセスを採用しようとすることには大きな障壁があります。「XDDP」を普及させて派生開発の問題を解消するには、こうした障壁を克服する必要があります。
この研究会では、いろいろな障壁がなぜ生じるのか、それぞれの障壁が生まれる原因を明らかにし、それらの障壁を克服する方法を考え、実際の現場で実践し、その効果を確認します。
この研究会では、
- 現場で派生開発プロジェクトをリードできる立場の人や開発チームのメンバー
- 組織標準の作成に関わっている人
の方の参加を期待しています。
T2：「USDM」の入門
「USDM」による要求の仕様化の方法については『要求を仕様化する技術、表現する技術』に詳しく書かれているのですが、派生開発の現場で混乱に巻き込まれている技術者の皆さんは、総じてこのような本を読む時間を確保できない状態に陥っていると思われます。そのため、第一段階のステップとして、「これだけ」を会得して取り組めば今まで起きていた大きな混乱（のいくつか）は回避できるでしょう、というものを提供できないかと考えています。そのような方法では適用できる範囲が限られるかも知れませんが、それでも現状の混乱の中から一人でも多く技術者の皆さんが次のステップに進むことができれば、現場の混乱した状況は改善に動き出すと考えています。またこのような「手法」というものは、取り組んだだけの効果を感じることができれば、時間が失われるという問題も緩和することもあり、さらに次の段階を目指す勇気も湧いてきます。そこで現場の目線から「USDM」を見直して、「USDM」の本質を崩すことなく、習得のステップを提供したいと考えています。
T3：「XDDP」の入門
「XDDP」による派正開発の方法についても『派正開発を成功させるプロセス改善の技術と極意』に詳しく書かれているのですが、「XDDP」に取り組むには今回の追加機能の要求や変更の要求をうまくまとめる技術（「USDM」がその部分を提供）が必要ですし、その前に求められている納期や作業の制約の中でゴールに到達するための合理的なプロセスを設計する技術（「PFD」がこの部分を提供）も必要になります。しかしながら、このような「XDDPトライアングル（PFD、USDM、XDDP）」をある程度のレベルに達するには、それまで身につけてきた習慣との戦いにもなり時間がかかります。現実には、その間に顧客や上司からの無理な要求が出されてしまい、気がついた時には元のやり方に戻っていた、ということにもなってしまいます。「USDM」や「PFD」を全く抜きして「XDDP」をうまく回そうというのは、おそらく無理があると思われるのですが、たとえば「一人プロジェクト」であれば、そこで求められるようなプロセスは一般には複雑にはならないでしょうから、｢PFD」と「定義書」の標準を「推奨標準」として提供できる可能性もあります。変更要求仕様書もいくつかパターンを提供することもできるでしょう。実際、２人以上のメンバーで対応するプロジェクトであっても、基本的なプロセスのほとんどは「一人プロジェクト」をうまく回す中に出てきます。このテーマの場合、研究活動を通じて獲得したものを、本会のHPなどを通じて広く案内することができるのと同時に、この研究を推進したメンバー（研究員）が「入門」の指導者（初期の指導者）として活動することも可能になると考えています。
T4：「XDDP」とテストプロセスとの接続
「XDDP」はテストプロセスについては特に提案していません。それは「XDDP」の提案者自身がテストの専門家ではないことに起因しています。その他に、「XDDP」が勧める「３点セット」の成果物といくつかの「補助成果物」によって、ソースコードをテスト工程に引き渡す前に多くのバグが発見されていて、いわゆる第３者によるテストでのKLOCあたりのバグ発生率を「１」以下に抑えることができていたことも、特にテストプロセスに言及していない理由です。
しかしながら、今日ではソフトウェアの規模が大きくなり、いろいろな理由で変更にともなう影響範囲も広がっています。変更に対する影響の要因も多様になっている可能性もありますので、「３点セット」の構成や「補助成果物」にも何らかの工夫が必要になっている可能性があります。
この研究会では「XDDP」と効果的なテスト方法を繋ぐ方法、あるいは「XDDP」に適したテストケースの作り方などを探求したいと考えています。
T5：影響箇所の気付き
派生開発で重要なことは、変更に伴って思わぬところに影響がでることをどうやって未然に防ぐかということです。言い換えれば、派生開発は本来求められている変更作業を的確に行うことと、それによる「影響」を抑えることの戦いでもあります。「XDDP」では｢TM」が一つの対応策となっていますが、「TM」が有効に働く範囲は限られています。また「補助成果物」という形でも提案していますが、その構成や内容には必ずしも明確なものを示していません。そこで提案しているのはいくつかの場面では効果はあったものの、それほどな万能なものではないと思われたからです。
さらに、「XDDP」の成果は、その多くが組み込みシステムの世界で取り組まれてきたものです。組み込みシステム以外の世界で「XDDP」を適用した場合には「補助成果物」の構成も変わってくるはずです。
変更にともなう影響箇所に気付く方法が、再利用性が高い状態で提案できれば、多くの派生開発の現場で効果を発揮するはずです。同時に、この方法はテスト工数を削減する効果にも繋がります。
T6：Agile開発との連携
一般にAgile開発は新規開発のイメージで取り組まれています。しかしながら、現実には既存のソフトウェアシステムに新しい機能を追加する方法として「Agile」な開発技法が使われていることが少なくありません。本当の意味での新規開発の機会が少ないことが、そのような選択になっているものと思われますが、ベースのソフトウェアシステムの状況によっては、今回の新しい機能の追加を受け入れるための変更で混乱する危険性が高いと思われます。確かに規模によっては、そしてアーキテクチャの混乱が無ければ、新規開発のイメージで一連の機能を分割しながら追加構築することは可能です。しかしながら、規律もなく長期に亘って機能の追加を繰り返してきたことでベースのソースコードが劣化していることが考えられます。またその期間の中で開発に携わるメンバーも交替してきたでしょうし、ベースのアーキテクチャの設計が最初から不安定であったりすると、新規開発のプロセスを延長した考え方での機能追加では混乱が起きてしまいます。派生開発に於いては、「機能追加」のプロセスを「Agile」な開発技法で対応し、追加機能の受け入れを含む「変更」のプロセス全体を「XDDP」で対応するというところに「Agile」な開発技法と「XDDP」の出会いがあると考えています。もともと「XDDP」自身が、今回の要求に対して必要最小限の規律を求めただけの「機敏な」開発アプローチですので、一般の「Agile」な開発技法との組み合わせは可能と考えています。「Agile」な開発技法そのものはいろいろな方法があり、それぞれ特徴があります。それぞれの「Agile」な開発技法と「XDDP」をどのように繋げば効果的になるのかといった研究が考えられます。
T7：ハードの派生開発への適用
組み込みシステムの世界に於けるH/Wの開発も、多くは派生開発の特徴を備えています。特にCADなどの設計ツールを活用するようになってから、機能単位でモジュールの再利用が行われ、そこに新しい機能モジュールを組み込む形で新しい製品を設計しているものと思われます。
また、PLDなどのFPGAが普及していく中で、今までチップメーカーにオーダーしなければならなかったのが、手元で作れるようになりました。本来は、これによって「試作」のサイクルを短くするのが狙いだったはずですが、逆にS/Wの領域で起きていた派生開発の混乱がH/Wの世界に広がり、結果的に試作がそれぞれのメーカーの開発現場で繰り返されることになりました。いやむしろ今までよりも安易に試作に頼るようになった可能性もあり、製品の競争力という面からは障害になっていると思われます。
この事態を打開するための方策としては、H/WエンジニアにS/Wエンジニアリングの根本的な技術の習得が必要なのですが、現実に製品開発のサイクルが回っていて、混乱している中では「XDDP」などの派生開発の仕組みも合わせて取り入れる必要があると考えています。
また、派生開発のH/W設計に「XDDP」を活用することで、変更要求仕様や「TM」がS/Wの変更と一体化できるというメリットがあると考えています。
H/Wの設計技術者で、現状の開発／設計方法を打開しなければと考えている人や、S/W開発との融合を考えているエンジニアや組織のマネージャーの皆さんの参加をお待ちします。
T8：大規模システムへの効果的対応
「XDDP」は基本的には規模に関係なく適用できるはずです。しかしながら、派生開発のベースとなるソースコードの規模が大きくなることで、一般的には１回のプロジェクトでの変更量（変更箇所）も多くなるでしょうし、関係するモジュール（ソースファイル）も多くなるでしょう。変更量（変更箇所）の多さは、変更要求仕様の構成やまとめ方に何らかの対応が必要になるでしょう。そして、モジュールの多さはTMの構成に工夫が必要になります。これに対応するチームの数も増えるでしょう。そうなると適切なツールが必要になるのかもしれません。
逆に、チーム構成を工夫することで、それぞれのチームが扱う変更量をコントロールすることで、変更規模が大きいことを表面化させない方法も考えられます。
ここでは、こうした大規模システムの領域にいくつかの指針を示したいと思っています。
T9：ビジネス領域での「XDDP」の活用
「XDDP」は、組み込みシステムを中心とした派生開発の中で取り組まれています。それは「XDDP」そのものが組み込みシステムの世界の中で考案されたもので、そこで活用されてきたこと。一方、ビジネス領域には従来から「保守開発」という考え方があり、そこで発生する変更要求も「是正」「予防」「適応」「完全化」といったものがほとんどで「保守開発」で特に問題は生じなかったことなどが考えられます。
しかしながら、ビジネス領域のソフトウェアも、Webの世界と協調するようになったことや、経営上の視点からビジネス要求を捉えてそれをシステムに反映するようになったことで、これまでの「保守」の概念では対応しにくくなっていると考えられます。
2008年に「保守開発」に、機能追加を含む新しい要求を満たすための修正として「改良保守」という考えを取り入れたのは、ビジネス領域の「変更」の様子が変化していることを表しています。つまり、「XDDP」が扱う世界に近づいたということです。
T10：「USDM」とユースケースの連携
要件開発技法の一つにユースケースを使う方法があります。アクターやロールを適切に設定することで、比較的容易にユースケースを引き出すことができることから広がっているものと思われます。
もともと、UMLが「RUP」のような重いイテレーションを前提としたプロセスと繋がったのは、ユースケースに引き続いて引き出された「シナリオ」のまま設計プロセスに入ったことに原因があります。つまり「要求」と「仕様」の概念がなかったことが混乱の原因です。
ユースケースは、その捉え方によっては「USDM」の上位要求に該当します。そこで、ユースケースと「USDM」を繋ぐことで、ユーススケーによる素早い要求の引き出しと、「USDM」による効果的な仕様化の両方のメリットをまとめることができると考えています。
このために、ユースケースをどのような粒度で扱えばよいのか、「USDM」に繋がるようなユースケースの粒度や表現の仕方と、その後の設計プロセスや成果物とのスムースな繋がりを模索したいと考えています。
T11：上位の要件開発技法と「USDM」の連携
ユースケースを使った方法とは別に、いわゆるビジネスゴールから要求（アクティビティ）を探しだす方法もあります。「I*」や「CAOS」「E3VAUE」「AGORA」などは、こちらに分類されます。直面しているビジネスの課題に対応するにはどのようなシステム要求、すなわちアクションが有効なのかが分からない状態、同業他社もまだこの事態に対応できていない段階で問題解決のためのアクション（振る舞い）を引き出す技法でもあります。
しかしながらこれらの技法で引き出されたアクションや振る舞いは一般に抽象度が高く、このままでは具体的に何をすれば良いのか見えないことが多く、この状態で設計に取り掛かかっても設計プロセスの中で仕様の抽出を繰り返さなければならなくなります。
「USDM」はこのような方法で引き出されたシステム要求を上位要求ととらえ、要求の階層化や、要求の中に含まれる動詞を丁寧に表現する方法で仕様の抽出を進めることができるはずです。
ここでの課題は、こうしたビジネス要求の開発技法と「USDM」を効果的に繋ぐ方法を編み出すことで、設計プロセスの中で仕様を引き出すことから脱却し、総合的にQCDの大幅な改善を図ることにあります。
T12：ソフトウェア品質要求の定義
近年、ソフトウェアの品質要求に関する研究が進んでいて、たとえばISO/IEC25030として標準化の動きにも繋がっています。機能要求と違って品質要求は再利用性が高く、それぞれの組織が提供する製品やシステムに対して、品質要求が継続的に適用できるという性質を持っていますので、PDCAのサイクルを回しながら品質要求や仕様の表現を洗練していくことができます。一般に品質要求は機能に付随するもの、作り方に付随するもの、その他の制約に分類され、それぞれ機能性、信頼性、保守性といった「品質特性」の形に分類されています。問題はこれらの品質要求も最終的に「仕様」のレベルに展開されなければプログラムコードになりません。品質要求の難しさの一つは、それをどのように表現するかというところにあります。たとえば機能要求であれば、「～のボタンが押されたときは、～のデータを集めてきて～の変換をして～上に表示する」というように、「ボタン」などをキーにして「機能」を主語にして記述することができます。もちろん、実際には作業者はこの表現を「（～ボタン～～上に表示する）ように作る」と要求すなわちRequireとして読み替えます。パフォーマンスのような品質要求の場合は、これと同じように表現できますが、「保守性」のような作り方に関する品質要求の場合は、機能を主語にした形では表現できません。この部分が、いわゆる機能仕様書と要求仕様書の違いにも繋がっています。ソフトウェアの品質要求に関する研究の機運が盛り上がっている機会に、それぞれの品質特性を「USDM」の表記法を使って効果的に表現する方法に取り組んでみたいと思います。
T13：「USDM」のリスク管理への応用
要求を仕様化するということは、実現したいことを実行可能なレベルに具体化することであり、それによって設計が可能になりソースコードに展開されます。逆にいうと、要求を適切に仕様化できなければ、設計プロセスで改めて仕様化（具体化）する必要が生じます。その場合は、要求仕様書にその具体化されたレベルで記述されない可能性もあります。「USDM」では、要求に「理由」をセットし、さらに動詞を見せるように表現を工夫することで仕様の抽出を誘導します。つまりこの要求を満たすために具体的な処理（対処）内容を導き出すわけです。「リスク管理」も同じ問題が発生します。「リスク」とは実現して欲しくないことであり、裏返すと「○○のリスクを回避して欲しい」という要求として捉えることができます。もちろん、そのようなリスクが生じる背景や理由もあります。そして何よりも大事なことは、「リスク」は回避したいことであって、どのような行動（対応）を取ることでこのリスクに対応するかという具体的な行動を導き出さないと意味がありません。言い換えると、リスク管理のポイントは、リスクを発症させないための適切な軽減措置を引き出せるかどうかにかかっています。そのためには、リスクをいかにして見付けてくるかという問題と、見付けたリスクをどのように表現するかという問題をクリアする必要があります。この「リスク」と「要因」を適切に表現することで「軽減措置」を引き出すという構造が、「要求」と「理由」から「仕様」を引き出すという「USDＭ」の構造に類似しており、ここから新しいリスク管理の方法を提案できると考えています。
T14：SPLと「XDDP」の連携
SPLすなわちSoftware Product Lineも広い意味では派生開発の中に含まれます。一般の派生開発と異なる点としては、たとえば今回の機能追加は予め想定されていて、ベースのソースコードに追加される機能のソースコードを受け入れる方法も考えられており、簡単に接続できるということでしょうか。ただし、それは事前に準備されたロードマップに沿って対応できる状況にあることが条件になります。
このロードマップから外れたとき、あるいはロードマップは用意されていいたが、事前に設計されていたシステムのアーキテクチャが必ずしも適切に対応しきれていないときは、想定以上の改修作業が必要になることもあります。
10年間のロードマップも、これに沿って製品開発ができるのは、兵器開発のような独占的な地位にある企業か、その分野の先頭を走る企業に限られます。先頭を走れていない企業のロードマップは、先頭を走る企業が世に出してくる製品を見て自らのロードマップでは競争に勝てないことを知り、そこで手直しする事が生じます。その結果、事前に想定していなかったような改修が必要になるのです。
SPLを、部品の再利用に重点を置くという考え方もありますが、その場合でもベースのソースコードに組み込まれている機能に影響を与えないようにするのは容易ではありません。
T15：「USDM」の支援ツール
「USDM」による要求の仕様化技法の基本的な考え方は、「要求に含まれる動詞およびその目的語に仕様がある」という単純明快なものです。しかしながら振る舞いを表現する上位要求にはすべての動詞が表現されているわけではありません。そして、これを下位層に展開するときも、上位層に含まれる（一部は見えている）「動詞」を漏れなく引き出せることが保証されているわけではありません。
しかしながら、下位要求に展開する際に、上位要求の振る舞いの特徴とそこに見えているいくつかの動詞から、上位要求に隠れている動詞を連想させるような問い掛けをすることは可能であろうと考えています。また経験則を取り入れることでその問い掛けの確度を向上させることも出来るはずです。
こうしたツールは、派生開発の世界では「変更要求仕様」には直接的な効果は期待できませんが、「追加機能要求仕様」の領域には大きな貢献が期待できます。追加機能の要求仕様の問題をこのツールで軽減することで、担当者は変更要求仕様により多くの工数を投入することができます。
もちろん、変更要求仕様においても何らかのツール化が必要になるでしょうが、まずは追加機能要求仕様書から対応していくことを想定しています。
ここでの課題は、単に「USDM」の記述をExcelから解放するだけのツールから、さらに進んで下位要求の引き出しや仕様グループの設定を支援するようなツールも考えて行きたいと思っています。
T16：「XDDP」の支援ツール
「XDDP」の変更プロセスの中で行われる個々のプロセスには、従来から行われている、いわゆる見付け次第にソースコードを変更するやり方の中でも行われてきました。「XDDP」では、それらのプロセスの実施方法を変更し、見付け次第にソースコードを変更するのではなく、見付けた箇所を変更要求仕様書や変更設計書に書き出すことを求めています。
しかしながら、ソースコードから該当箇所を探したり、変更方法を考えるプロセスはほとんど同じであるために、「XDDP」に対する理解が不十分な状態だと昔のやり方に戻ってしまう危険があります。
「XDDP」による派生開発アプローチ全般、特に変更プロセスをツールでカバーすることによって、プロセスの実施順序を規制することができるので「XDDP」のアプローチを崩すことなく作業を進行させる効果が期待できます。
T17：「PFD」の支援ツール
一般に派生開発の要求は納期や規模、開発の形など多様です。この状況の中で派生開発を成功に導くには、今回のプロジェクトで求められているいろいろな要求（納期を含む）を満たすようなプロセスの設計、すなわち開発アプローチの設計が重要になります。
特に、派生開発では納期が短かったり、ベースのソースコードに対する理解が限定的だったりしますので、そのような状況にマッチしたプロセスを自在に設計することが成功への鍵となります。
「PFD」は、こうした要求に応えるためのプロセスの設計ツールです。現在、既にこのツールは用意されていますが、このＰＦＤの支援ツールを他のツールと繋ぐことで、計画の立案からいわゆる進捗管理をカバーすることも可能なるでしょう。
T18：USDMと形式言語との接合における曖昧表現の克服
要求仕様の問題は２つのパターンに大別できます。１つは「仕様モレ」で、もう一つは「曖昧表現」です。USDMは２種類の階層（要求-要求／要求-仕様）で「仕様モレ」は根本的に防止できますが、要求や仕様の個々の表現の曖昧さによって、読み手に正しく伝わらないという問題はUSDMでは解決できません。
これに対して２つの対応策があると考えています。
① 要求や仕様の表現に「文書表現」の技術を取り入れる。
② フォーマルメソッド（形式言語）に繋ぐことでUSDMの表現の曖昧性を排除する。
という方法です。前者は、別の団体の活動に委ねるとして、ここでは後者の方法でAFFORDDとしての持ち味を活かせるのではないかと考えています。
確かに、近年「形式言語」は大きな話題となっていますが、そこでの取り組みに２つの特徴があると考えています。１つは、日本語の要求仕様の記述を省いて（一部形式言語の不足を補う記述あり）最初から形式言語で記述するというものです。ただ、この場合、実現に向けての工数は節約できるでしょうがレビューに参加できない人がでるという問題が残ります。もう一つの方法は、日本語での要求仕様と並記する方法です。AFFORDDとしては後者の方法で、形式言語との接続を模索する方法があると考えています。
- 形式言語と接続するためにUSDMでどのように表現するか？
- 接続する範囲の見極めを含めて形式言語に展開しやすいUSDMの表現とは？
- 形式言語と対応させることで、日本語表現の曖昧さを解消する方法は？
そしてもう一つの問題は、形式言語による開発方法の研究発表では、一般に新規に開発する場面が中心であり、派生開発の場面での事例はほとんど見当たりません。AFFORDDとしては、将来、派生開発での問題にも踏み込む必要があると考えています。
T19：派生開発におけるスペックアウトの仕方
派生開発の場面においては、ソースコードを読んで変更箇所を探したり、影響しそうな箇所を特定して対応したりすることがしばしば求められます。事前に、ベースのソースコードに対応した精度の高い機能仕様書や設計書が作られていれば、それらの文書からある程度の範囲で変更箇所や影響箇所の特定が可能になりますが、それらの文書は、通常は派生開発の場面での検索の視点に合わせて作られていませんので、変更要求によっては十分に役目を果たさないことがあります。それを補う方法としてソースコードを読んで理解する技術が必要になります。
そして、理解の状況を確認するために適切に表現されることが重要になります。
XDDPでは、ソースコードを読んで理解しながら変更箇所や影響箇所を特定する方法として「スペックアウト」と呼んでいます。一般には、ソースコードから関数の呼出しの様子を表す「構造図（SC）」を書いたり、「クラス図」や「アクティビティ図」などを書いたりしながら探索しますが、変更要求の内容によっては、そのような表現だけでは十分ではありません。例えば、データ構造の変更やその中の要素を変更するような場合は、構造図やクラス図では役に立ちません。
このように変更の内容によっていろいろな表現方法を使いながらスペックアウトすることが必要になります。つまり、変更内容とスペックアウトの仕方には何らかの対応性があるということで、その対応性や表現の方法、さらにはスペックアウト時の注意点などについて掘り下げてみませんか。
T20：「XDDP」とモデル駆動開発の融合
近年、モデル駆動開発が多くの開発現場で行われるようになりました。しかしながら、モデル駆動開発では派生開発に対処する方法は示されていません。そのためその後に発生する仕様変更や機能追加に対して、従来方法と同じように、モデルの該当箇所を探し、見つけながら変更している可能性が大きいです。ソースコードはツールによって生成されるとしても、これでは従来方法と同じように思い込みや勘違いによるバグが混入してしまいます。
仕様変更や仕様追加の範囲がどこまで及ぶのか、どの部分を変更し、どこの部分に機能追加すればよいのか、せっかくモデル駆動で開発したのですから、まずはモデルの段階で把握する必要があります。このとき、変更要求を正確に分析して変更仕様をモデルにつなげるためには、XDDPのプロセスが有効になります。モデル駆動開発の場合は、モデルレベルで変更部分や追加部分が把握できれば、ソフトウェアの静的構造と動的構造(振る舞い)の視点からプログラム処理とデータ構造の変更や追加に対処することができると考えています。
一方、現実問題として、従来方法で開発されたソフトウェアシステムが多く存在しています。ここから離れられないまま繰り返される派生開発の中で構造の劣化も進んでおり、結果的に悪循環を繰り返しています。この状況を緩和しない限りモデル駆動開発の導入が進みません。
XDDPでは、派生開発の中で範囲を限定しながらアーキテクチャを改善することを勧めています。そこでXDDPの長所を活かしながら、変更や機能追加に対してモデル駆動開発の手法を適用範囲を制限して導入することで、ソフトウェア構造を改善していくアプローチがモデル駆動開発の展開に有効と考えています。
さらにモデル駆動開発の最終目標であるモデルシミュレーションやコーディングの自動化について実現可能性を検討し、派生開発の効率アップにつなげることを目指します。
この研究を促進させるために、モデル駆動開発を開発現場で実践していて、今後XDDPを導入しょうと考えている方、または、個々にXDDP、モデル駆動開発を開発現場に導入していて両者を融合させたいと考えている方の参加を求めます。
T21：「PFD」によるプロセス設計
派生開発プロジェクトは納期や変更規模が多様です。また、プロジェクトは開発途中で変化します。この様な状況に適切に対応するには、成功する（させる）ためのプロセスを設計することが重要です。
PFDは単純な成果物とプロセスを繋いだダイアグラムであり、直感的に読むことができ、派生開発のプロセス設計ツールとしては扱いやすいものです。しかし、今回の要求を実現するための合理的なプロセスを「設計する」となると、単にダイアグラムを書けばよいだけではすみません。
要求を実現するという目的に対してどのようなプロセスが有効で、どのような成果物と繋ぐことがより最善のプロセスなのかということを成果物の定義書とプロセスの定義書を含めて考える必要があります。PFDでプロセスを設計し表現する目的は、このような事態に遭遇した時に、プロセスや成果物を組み替えて別の方法（ルート）を考えだすことにあります。
この研究会では、先ず、PFD（と定義書）でプロセスを設計し表現でき、さらにそこから事態の変化を受けてプロセスを組み替えることができるようになることを目指します。そして、プロジェクトの見積りや進捗管理、「代案」の考案の仕方など、様々なPFDの効果的活用の検討へと広げてゆくことを考えています。
T22：失敗事例
XDDP（派生開発）を組織において取り込む場合に、「導入の失敗」と「定着の失敗」があります。一般的にも新しいツールや技法を導入する際には、同様の事が考えられます。当研究会では、実際にあった失敗事例を元に、その失敗事例が発生しないようにするには、どうしたら良いかを研究します。
失敗事例を分析し、XDDP（派生開発）の本質を探ります。本質とは、100％ XDDPを使いこなせることがベストではあるが、ベストになるには時間も知識も技術が必要です。例えば、当初はせいぜい60％しかXDDPを使いこなせないとして、失敗を許容可能なレベルに抑える為には、どの知識・技術を優先的に取り入れれば良いか、この辺りを失敗事例から探ります。
ぜひ、完璧にXDDPを取り込まれていない組織の皆さん、一緒に悩み、旨い酒を飲みませんか。