お知らせ:メンテナンスのため、来週まで当社のローカルAIモデルを停止しています。その間、エージェントによる新しいモデルの生成はご利用いただけません。スタジオとデモモデルは引き続きブラウザでご利用いただけます。
本文へスキップ
Vector Stream Systems のロゴVector Stream Systems English 今すぐ始める

派生開発・XDDP

派生開発(差分開発)と MBSE:XDDP のトレーサビリティをモデルで

日本のエンジニアリング業務の多くは、既存製品を変更する派生開発です。派生開発のためのプロセス XDDP は、変更の前に「何を、どこで、どう変えるか」を3つの成果物で明らかにします。本記事では、XDDP が重視するトレーサビリティをシステムモデルで保持する方法を説明します。

派生開発(差分開発)とは

派生開発とは、既存の製品やソフトウェアをベースに、機能の追加や変更、不具合の修正を行う開発です。差分開発とも呼ばれます。日本の組込み開発や機械設計では、まったくの新規開発よりも、前の機種や既存製品からの派生開発のほうがはるかに多いのが一般的です。

派生開発には特有の難しさがあります。限られた期間で、他人が書いたコードや図面の一部だけを変更しなければならず、変更していない部分への影響を見落とすと、それが出荷後の不具合として現れます。

XDDP とは

XDDP(eXtreme Derivative Development Process)は、清水吉男氏が提唱した派生開発のためのプロセスです。2010年からは派生開発推進協議会(AFFORDD)が普及を進めています。

XDDP では、ベースのソースコードに手を入れる前に、次の3つの成果物を作ります。

  • 変更要求仕様書。何を変えるのか、その理由と、それを実現するための仕様を明らかにします。
  • トレーサビリティマトリクス。変更の仕様ごとに、どこを変えるのか(ソースコード上の変更箇所)を対応付けます。
  • 変更設計書。変更箇所ごとに、どう変えるのかを記述します。

変更箇所を実装の前にすべて洗い出し、まとめて確認してから手を入れることで、変更漏れや影響範囲の見誤りを防ぎます。

XDDP が解決しようとしている問題

XDDP が対象とする根本的な問題は、仕様書や設計書が古くなり、ソースコードの実態からずれていくことです。派生開発を重ねるたびにドキュメントは更新されずに残り、正しい情報はソースコードと担当者の記憶にしかなくなります。その結果、エンジニアは変更の影響範囲を見誤り、ある修正が別の不具合を生みます。

XDDP はこの状況を前提に、ドキュメント全体を作り直すのではなく、変更する部分を確実に文書化するという割り切りをしています。

ドキュメント中心のトレーサビリティの限界

XDDP の成果物は文書と表です。トレーサビリティマトリクスは表計算ソフトで作られることが多く、変更のたびに人手で作成し、確認します。派生開発の規律として有効ですが、次のような限界もあります。

  • 変更箇所の洗い出しは担当者の調査に依存し、表に書かれていない関係は見えません。
  • 表は変更ごとに作られるため、過去の変更とのつながりを横断して確認しにくくなります。
  • 電源容量、取付寸法、通信インターフェースのような機械や電気との取り合いは、ソースコード中心の表では扱いにくい部分です。

同じトレーサビリティをシステムモデルで持つ

システムモデルでは、要件、部品、機能、インターフェースが要素としてつながっています。XDDP の3つの問いは、モデルの上では次のように対応します。

XDDP の問いXDDP の成果物システムモデルでの対応
何を変えるか変更要求仕様書変更対象の要件と、その変更内容
どこを変えるかトレーサビリティマトリクス要件から部品、機能、インターフェースへのつながり
どう変えるか変更設計書部品や属性の変更として記録されたモデルの差分

要件を起点にモデルのつながりをたどれば、影響を受ける部品とインターフェースが分かります。変更後は、モデルの差分を変更内容として確認し、ベースラインと比較できます。トレーサビリティは表として別に保守するものではなく、モデルの構造そのものになります。

既存製品にモデルがない場合は、まず変更に関係する部分をリバースモデリングでモデル化します。詳しくはリバースモデリングとはを、モデルの範囲を段階的に広げる進め方は既存システムへの MBSE の事後適用をご覧ください。

MBEstudio での派生開発

MBEstudio では、既存の CAD(STEP AP242)、部品表(Onshape BOM CSV)、KiCad ネットリスト、QIF の検査データ、ReqIF による要件、関連ドキュメントから既存システムをモデル化できます。モデルは SysML v2 のテキストで、コンパイラが検証します。要件は形状、質量、電力に対して評価され、値、上限、マージンが示されるため、変更後も要件を満たしているかをモデル上で確認できます。

モデルの差分とベースラインで変更の履歴を追えます。ReqIF で要件を入出力し、識別子を保持するため、IBM DOORS などの要件管理ツールとも往復できます。AI エージェントは不足しているインターフェース、機能、要件を提案し、エンジニアがそれぞれ承認または却下します。なお、MBEstudio は XDDP の文書を自動生成するものではありません。XDDP が重視するトレーサビリティを、検証できるモデルとして保つためのツールです。

対応データはリバースモデリング・派生開発、エージェントについてはエージェント、プランについては料金のページをご覧ください。

よくある質問

XDDP とは何ですか?

清水吉男氏が提唱した派生開発のためのプロセスで、2010年から派生開発推進協議会(AFFORDD)が普及を進めています。ソースコードを変更する前に、変更要求仕様書、トレーサビリティマトリクス、変更設計書の3つの成果物を作ります。

MBSE を導入すると XDDP は不要になりますか?

いいえ。XDDP は変更の進め方の規律で、システムモデルはその情報を保持する手段です。モデルにトレーサビリティを持たせると、影響範囲の確認をモデル上で行えます。

MBEstudio は XDDP の文書を作成できますか?

いいえ。MBEstudio は XDDP の文書を生成しません。要件、部品、インターフェースのつながりをモデルに持ち、モデルの差分とベースラインで変更の履歴を追えるようにします。

リバースモデリング入門ガイド(無料 PDF)
既存設計からシステムモデルを起こす進め方を4ページにまとめました。進め方のご相談も承ります。

資料ダウンロード無料相談