XDDP実践ガイド：変更要求から設計・影響分析までの4ステップ

『３つの成果物』により、モレ・ミス・ムダを防止します

『XDDP』の特徴は、3つの成果物（USDM・トレーサビリティマトリクス、変更設計書）による、ミス・モレ・ムダの防止です。この3つの成果物を完成させるまでは、絶対に実装をしません。完全なるフロントローディングを行うことにより、手戻りによるムダを排除することで、「派生開発」の問題を未然に防ぐのです。

USDMで仕様のモレを防ぎます

『USDM』は要求と仕様を形式化するツールです。｢派生開発｣における「変更要求仕様」や「追加機能要求仕様」を『USDM』で記述することにより、要求仕様の抜け漏れや矛盾などの問題を見つけやすくなります。

トレーサビリティマトリクス(TM）で変更のモレを防ぎます

『トレーサビリティマトリクス』(TM）は、『USDM』で定義した仕様に対する、コードの対応箇所を示した対応表です。この『トレーサビリティマトリクス』により、変更仕様に対する影響範囲を把握することができ、変更箇所のヌケモレを防ぐことができます。

｢変更設計書｣で、各変更をきちんと設計します

『変更設計書』は、変更箇所に対してどのような変更をするのかを設計し、明文化したものです。これを有識者との間できちんとレビューすることにより、 対応のミスを防ぐことができます。

Why / What：変更内容の調査と仕様化を行います

『XDDP』では、まず最初に「変更要求」に対する具体的な変更内容をとらえて、「変更要求仕様」として定義します。変更内容をとらえる方法としては、既存の機能仕様書などの資産から変更すべき内容を探し出す方法の他に、ソースコードから探し出す「スペックアウト」があります。｢スペックアウト｣とは理解したことと、拾い出した箇所、変更すべき項目を抽出して資料として残すことです。ここでとらえた変更内容を「要求」「仕様」に振り分けてUSDMに記述することで『変更要求仕様』として定義します。

ソースコードからも「スペックアウト」して仕様をとらえます

既存資産の要求仕様書や設計書が整備されていて、「変更要求」が明らかであれば変更内容をとらえるのは容易です。しかし、それらがメンテナンスされておらず、ソースコードと乖離している場合もあります。そのような時にはソースコードを元に「スペックアウト」し、変更内容を探し出します。とはいえ、大量のソースコードに対して、やみくもに｢スペックアウト｣すると、いくら時間があっても足りません。｢スペックアウト｣は、変更箇所にあたりをつけてから実施します。

｢スペックアウト｣で、ソースコードを理解しながら「図面化」し、理解した箇所をチェックして進めていきます。図面化は構造と振る舞いに着目し、開発対象の特徴に合わせて構造図などの最適な図面を選択します。下図は構造図の実施例です。

とらえた仕様は『USDM』でモレなく正確に仕様化します

｢スペックアウト｣で抽出したものも含めて、ここまででとらえた変更内容を元に、「変更要求仕様書」を『USDM』を使って作成します。『USDM』を作成する上で重要な点は｢要求｣と｢仕様｣を分けて書くことです。そうすることで、｢要求｣と｢仕様｣の関係が明確になり、仕様 のヌケモレや認識違いを防ぐことができます。その他、Before/Afterで記述する、変更の範囲・要求の理由を記述する、等のポイントがあります（詳細は「要求の定義と仕様化」をご覧ください）。

また、『USDM』で作成した「変更要求仕様書」は設計者に対する「作業指示」としても使えます。『USDM』では、仕様のモレや誤解を防ぐために、仕様を具体的に、検証可能なレベルで記載します。そうすることで、設計者に対して「厳密な変更の指示」が可能になります。「変更要求仕様書」が適切に作成されており、仕様通り変更作業を行えば、どんなスキルレベルの設計者であっても同じ結果になるはずです。

Where：変更仕様に対する変更箇所を特定します

トレーサビリティマトリクスとは『USDM』で定義した仕様に対し、変更点がどのモジュールに存在するかを示します。そのため、変更に対する影響範囲を確認することができます。

トレーサビリティマトリクスでは、USDMで作成した変更要求仕様に対して、列方向に影響範囲を確認する対象を配置し、影響がある箇所を特定します。 一般的には、影響範囲を確認するのはコードになり、列方向にファイル名を記載し、該当する変更箇所に「○」を付けたり、変更する関数名を記載したりします。

トレーサビリティマトリクスを作成することで、前のプロセスで作成した「変更要求仕様書」と、この後に作成する「変更設計書」とをつなぐ役割を果たします。

• 変更するのは本当にその関数だけで良いのか、他にも変更箇所がないか
• 変更することで、他の関数への影響がないか
• 別の変更仕様で、同じ関数が変更されないか

といったことを具体的に確認します。

トレーサビリティマトリクスを使って変更に対する影響箇所を調べていくと、凝集度の低いモジュールや、結合度が高いモジュール構造が見つかる場合があります。このような箇所は変更の確認が難しいだけでなく、変更による二次障害が発生しやすくなります。その際には、「保守性の向上」を変更要求として『USDM』に追加します。

このように、トレーサビリティマトリクスは既存のモジュールに対する影響度を確認できるだけでなく、副次的に保守性の悪いモジュール構造を見つける事もできます。 この後は、トレーサビリティマトリクスで特定した箇所をどのように変更するかを決定します。

How：どのように変更するかを決定します

変更箇所の特定ができたら、それぞれの変更箇所について、どのように変更するかを決定し、変更設計書を作成します。ソースコードではなく「文章」で記述することにより、変更方法の正しさをレビューできると共に、変更方法を確実に残すことができます。変更内容の詳細度は、実際に変更作業を行う担当者のスキルに応じて臨機応変に決定します。

変更内容を記述する中で、関数の引数や戻り値の変更に気づくことがあります。このような変更は他の関数へ影響を与えるので、『トレーサビリティマトリクス(TM)』に戻って影響範囲を確認をすることが必要です。

変更要求仕様書と変更設計書を作成し、レビューを実施することで変更内容が確定した後は、ソースコードを一斉に変更します。

XDDPによる｢派生開発｣に関する記事を見る

他のソリューションを見る

最新コラム