【第１回 XDDP（派生開発プロセス）解説 コラム】

世の中の開発プロジェクトのほとんどが、派生開発です。

派生開発は、既存の開発資産に変更や機能追加を行いますが、ミスやモレ、勘違いによって思わぬ不具合が発生し工数が増加してしまうことがあります。

XDDPは派生開発に特化したプロセスで、ミスやモレ、勘違いを防止し、不具合を最小限に食い止めることができます。

本コラムは、XDDP（派生開発プロセス）とは？について、基礎的な内容を数回に分けてわかりやすく解説していきます。

---

派生開発の現状

世の中の開発プロジェクトのほとんどが、派生開発です。すでにある製品に対する仕様変更、機能の追加、あるいは、不具合の対応によるバージョンアップなどは、どれも、派生開発に分類されます。

派生開発の対象になる行数は、既存行数に比べて少ない行数にも関わらず、多くの工数が投入されています。

しかし、多くの工数をかけて、代を重ねるごとに品質が判定するはずなのに、バグが取り切れず、出荷後に不具合がでる、必要な変更がモレていた、もしくは変更した内容が不十分だった、など、手戻りにより工数が増加しているのです。

開発現場ではいったい何が起きているのでしょうか。

---

現場で起きていること（開発スタイル1）

早くコードを直さないと間に合わない、というプレッシャーのもと、変更箇所は「ここだろう」という担当者の思いこみでソースコードを修正した結果……

• 認識違いや仕様モレが発生する
• 手あたり次第にコードを修正することにより、変更と確認を繰り返し、工数が増加する
• 変更すべき範囲が把握できず、変更モレが発生する
• 変更による影響範囲が把握できず、新たなバグが混入してしまう

といったことが多くの現場で見られます。

さらに、既存の仕様を理解するために仕様書やソースコードを調査する際、何も形に残さないまま、何度も読み返して多くの時間を費やしており、時間をかけた割には、理解があやふやになってしまい、ミスにつながっています。

---

現場で起きていること（開発スタイル2）

新規開発のプロセスをそのまま変更プロセスに適用している点も問題です。

変更要求を受け取り、仕様書をひたすら変更していくと、変更すべき箇所が仕様書に埋もれてしまい、変更仕様に矛盾はないか？、変更による影響はないか？、同じ変更が必要な箇所が他にないか？という視点での確認ができなくなります。

また、規模が大きくなり、複数人で作業する場合、お互いの影響まで確認せず、変更要求をそのまま受け取り、変更を行った結果、個々の変更はうまく動いても、複数の変更が組み合わさることでコンフリクト（衝突）が発生し、うまく動かないことがあります。

---

現場で起きていること（見積り）

見積もりがそもそも甘すぎることもあります。既存ソフトに対して、追加・変更するコード行数は微小であることから、過少に見積もりがちです。

また、作業全体を把握せずに、修正作業だけ見積もってしまうことがあります。変更すべき箇所を特定するためには、既存のソースコードを調査しなければなりませんが、その作業が見積もりから抜けていることがあります。

---

現場で起きていること（その他）

変更すべき内容の理解が不十分のまま開発を進めてしまうことも問題です。要求および仕様に対する認識違いによって、開発終盤で仕様モレが発覚し、部署間・担当者間で「言ったはず」「聞いていない」の応酬になるといった話も他人事ではありません。

変更方法の検討が不十分なまま作ってしまうこともあります。変更方法が適切ではないと、いままで出ていたパフォーマンスが出なくなったり、無節操な修正によるクローンコードが発生したり、コードの解析性が低下するといった問題も発生します。

---

派生開発における問題のまとめ

派生開発の問題についてまとめましょう。

• 変更すべき内容の理解が不十分
• 変更箇所の特定が不十分
• 変更方法の検討が不十分
• つまるところ、開発の仕方（プロセス）が不十分
• かつ、見積もり方法が不十分

こういったさまざまな「不十分」が原因で、問題が発生しているのです。
この「不十分」を取り除くのに必要なことは以下の項目になります。

• 早い段階からの根拠に基づいた見積もり
• 仕様変更や機能追加に特化した開発プロセス
• ミスや抜けモレに気づくような仕様化技術

そして、上記を満たす派生開発プロセスがXDDP、すなわちeXtreme Derivative Development Processなのです。

---

---

派生開発プロセス「XDDP」とは

さて、XDDPとは具体的にどのようなものなのでしょうか。
XDDPは、派生開発に特化した、変更、機能追加のプロセスです。
さまざまな制約のなかで、変更する部分だけを理解し、作り手の思い込みや勘違いがあることを前提として、3つの成果物を作成することで、モレ・ミス・ムダを防止します。

3つの成果物の内訳は以下になります。

1. USDMの形式で作成した変更要求仕様書
2. 変更仕様と変更箇所（ソースコードの関数など）を見える化するトレーサビリティ・マトリクス
3. 具体的な変更内容を記述する変更設計書

---

３つの成果物の関係

3つの成果物の関係を詳しく見ていきましょう。

変更要求仕様は、USDMの形式で、変更要求とその背景・理由を明記します。要求と仕様を対応付けることで、その要求に関連して変更しなければならない仕様のモレや、勘違いによるミスを防ぎます。

トレーサビリティマトリクスは、変更要求仕様に対して、既存ソフトのどのモジュールに変更を加えるかを対応付けます。これにより、変更すべき場所の抜けモレ・ミスを防ぐだけでなく、変更による影響箇所に気づくことが期待できます。

変更設計書は、要求の行とモジュールの列の交点に記される関数に対して、どのような変更を行うのかを具体的に記します。これにより、変更の実施内容、手段の誤り・ミスを防ぎます。

---

変更要求仕様書が与える気づき

これはUSDMの形式で変更要求仕様を記述することによる利点ですが、要求を目的語と動詞に着目して記述し、理由も付け加えることで、

• この要求を満たすためには、このような仕様が必要なのではないか？
• この要求の背景に何があるのだろう？本当にこの要求は必要なのか？
• この仕様の要求は何だろうか？この仕様で、何が満たせるのか？

といったことに気づくことができます。

---

トレーサビリティ・マトリクスが与える気づき

変更仕様に対応する既存ソフトのモジュールを明らかにすることで、

• 他にも変更しなければならないモジュールがあるのでは？
• そのモジュールに変更を加えるのは誤りでは？
• そのモジュールに変更を加えると、他の仕様にも影響がでるのでは？
• 複数の変更内容に矛盾はないだろうか？

といったことに気づくことができます。

---

変更設計書が与える気づき

変更方法を具体化することで、

• この変更の仕方で問題ないだろうか？
• 他の変更が重なった場合を考慮しているか？

といったことに気づくことができます。

---

XDDP（派生開発プロセス）を実際に学んでみる

XDDPの技術を実際に学んでみたいという方に、まずは無料でお試しいただけるオンライン学習をご提供しております。

業務が多忙なエンジニアでも、スキマ時間で効率的に実践的な学習が出来るEureka Boxは、エンジニアの現場の声から生まれたツールです。

ソフトウェア開発を改善するための開発技術を“知り・学び”“実践する”
超実践的オンライン学習プラットフォーム
Eureka Box（ユーリカボックス）

---

XDDP（派生開発プロセス）を正しく理解した上で適用し、最大限の効果を得られるようスキルアップしたい方にもEureka Boxでの学習はお勧めで、無料会員登録だけでも以下の特典が受けられます。

---

XDDPは、派生開発に特化した開発プロセスです。
派生開発に最低限必要なプロセスで構成されています。
XDDPの基本の3点セットは、変更要求仕様書、トレーサビリティ・マトリクス、変更設計書です。
この3点セットにより、これまでの「不十分」を取り除きます。
これにより、手戻りゼロが実現できるようになります。

---

関連コラム