最近のソフトウェア開発では新規開発の機会はほとんどなく、多くは現行のソースコードを変更したり、新しい機能だけをコーディングして追加したり、別の製品やシステムで稼働しているソースコードを一部切り出して移植・流用したりして使い続けています。その背景には、プログラム言語の寿命が長くなったことや、製品のリリース間隔が短くなっていること、ソフトウェアの規模が大きくなって新規に開発するリスクが高くなったことなどがあります。もともと「保守開発」という領域があるのですが、今日行われている開発の状況は「保守開発」の領域を超えるケースが増えています。たとえば、かつての「携帯電話」が「ケータイ」に変遷する状況や、多様な機能が追加されてきたデジカメの状況などは「保守」では説明しにくいのです。実際、組み込みシステムの世界では「保守開発」という言葉を耳にすることはなく「派生開発」という呼び方が広く使われています。もちろん、出荷後のバグだけを訂正してリリースすることもありますが、ほとんどが新規機能の追加を伴います。エンタープライズの世界でも新しいビジネス要求の実現や規格の変更などに伴って大きな機能追加が頻繁に行われています。

派生開発にはいくつかの特徴があります。たとえば１ヶ月とか３ヶ月というような「短納期」で完成が求められたりします。この納期が短いということが、必要なプロセスや成果物を省く圧力になっています。またそこにある機能仕様書や各段階の設計書などの公式文書が、必ずしも適切な状態になく、これまでの派生開発の中できちんと更新されていないことが多く、どうしてもソースコードに依存することになります。その結果、「部分理解」すなわち全体を理解できていない状態で変更作業が強いられることによる「思い込み」と「勘違い」の問題に見舞われます。思い込みや勘違いは、その時点では担当者は正しいという認識ですので、第３者によるレビューなどの手段を持ち込まないかぎり、事前に発見することは難しくなります。それにもかかわらず、いきなりソースコードを変更されてしまうと、第３者の目を取り入れる機会を失い、結局テスト工程で多くのバグとなって発見されることになります。中にはテストをすり抜けるものも出てくるでしょう。

派生開発の問題は、多くの現場で行われている開発プロセスが、このような派生開発の要求にマッチしないために起きているのです。その中で多くのバグに見舞われ、繰り返される手戻り作業によってソフトウェア技術者の疲弊を招いているのです。このような状況に対処するには派生開発の要求にマッチした開発プロセス（開発アプローチ）が必要です。「XDDP（eXtreme Derivative Development Process）」はこうした時代的背景の中で提案されたものです。

派生開発推進協議会  初代代表　清水 吉男