XDDPによる｢派生開発｣

｢派生開発｣における失敗やトラブルの原因は、変更仕様のモレやミスによる手戻り、影響範囲の特定が不十分であることによる不具合がほとんどです。それを未然に防ぐのが『XDDPによる派生開発』です。

XDDPは、ソフトウェアの「派生開発」に特化したプロセスです

現在のソフトウェア開発においては、新規開発はほとんどなく、既存コードに機能追加や変更を行う｢派生開発｣が多くなっています。

一般的に、変更や追加は仕様レベルでエンジニアに伝えられることが多く、また、納期も短いことから、変更仕様をそのままコードで実現してしまいます。その結果、変更箇所以外の仕様が漏れたり、変更箇所以外の不具合による手戻りの連続により、工数が増大するとともに、エンジニアも疲弊してしまいます。

これまで、ソフトウェア開発技術は欧米を中心として発展し、新規開発を対象としていましたが、「派生開発」に特化した唯一のプロセスが『XDDP』です。『XDDP』は変更や追加に必要最低限のドキュメントとプロセスが定義されており、｢派生開発｣を効率よく進めることができます。

01

「3つの成果物」により、モレ・ミス・ムダを防止します

02

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

03

変更仕様に対する変更箇所を特定します
（トレーサビリティマトリクス作成）

04

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

05

開発を支援する様々なこと

XDDP導入に「よくある問題」

『XDDP』を導入する際によくある問題として、まず、現状の問題を明らかにせずに『XDDP』に飛びついてしまい、効果が出ないといった問題があります。『XDDP』導入にあたっては、現状のプロセスの問題点を明らかにし、『XDDP』による改善をイメージできるようになってから導入する必要があります。

次に、｢スペックアウト｣が十分できていないまま、あいまいな状態で『USDM』を記述することがあります。このような状態では「変更要求仕様」として不十分であるため、実装でモレや勘違いに気づき、手戻りすることになります 。

また、実際に『XDDP』を実践してみると、｢要求｣や｢仕様｣をどう分割していいかわからず、途方に暮れることがあります。仕方なく、思いついた｢要求｣と｢仕様｣のみを記述し、先に進むことで、仕様のモレに後になって気付くことがあります。

さらに、大規模だからといって端からあきらめてしまい、【トレーサビリティマトリクス】(TM）を省略することがあります。これにより、変更の影響による不具合が後になって見つかるといったことが見受けられます。

『XDDP』は、比較的早い段階ではっきりとした効果が得られる技術です。しかし、誤った適用や正しくない導入により、失敗してしまうケースもあります。それを未然に防ぐためには、経験豊富な専門家に依頼することも、一つの方法と言えます。

コンサルタントが教える成功の秘訣

エグゼクティブコンサルタント 斎藤 賢一

『XDDP』を導入する上で多くの人がつまずくのが、最初の一歩となる『変更要求仕様書（USDM）』のところです。『USDM』では、要求を階層化しグルーピングしていくのですが、どんな粒度や視点で階層化やグルーピングするのか、初心者の方はずいぶん悩まれるようです。

要求の階層化は、「スペックアウト」で正確に仕様を抽出し、その仕様から構成や時系列の視点で要求を定義、整理します。ここで、「スペックアウト」を行うには設計技術が必要となります。この仕様化技術と設計技術のコツさえ掴んでしまえば、後はスムーズに進むのですが、この段階でつまずくと、『XDDP』の導入はうまくいきません。

エクスモーションでは、仕様化技術、および、設計技術をベースに『XDDP』の導入を支援するサービスを行っております。

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

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

最新コラム