現在、多くの開発現場で行なわれている派生モデルの開発作業には、幾つかの問題を抱えているようです。その主な原因は、
１）開発期間が短い
２）新規開発と同じ手順を踏んでいる
ことが挙げられます。
そして、そのために
３）要求に対する変更個所がわからなくなったり
４）変更に伴う影響範囲が検討されない
ということが起き、変更にともなって発生する「バグ」に振り回されるのです。
（インデックスに戻るときはウィンドウをクローズしてください）
保守開発は、一般に新規開発と違って、開発期間は短く設定されます。顧客にとっては、「今の製品と、◇◇と□□が違うだけ」という形で「要求」が発生するため、新規開発のような感覚で開発期間を確保できることは有りえません。したがって、短い開発期間で開発できる方法を持っていなければ、市場の要請に応えることは出来なくなります。
また、「□□」が変わることで、△△も変わることになるかも知れませんが、それには顧客は気づいていません。このことも、後になって開発期間を遅らせる要因となります。
何れにしても、短い開発期間に対応できて、それでいて品質の高いものが開発できる開発方法を持たなければ、これからは「出番」はなくなります。“あと二ヶ月もらえれば・・・”と言っても始まりません。
（インデックスに戻るときはウィンドウをクローズしてください）
このように開発期間が短く、顧客から出される要求が「変更点」だけという状況にもかかわらず、開発現場では、しばしば新規開発と同じ手順を踏もうとする光景を見ることが有ります。
つまり、新しいモデル（製品）のための、外部仕様書や内部仕様書、或いはモジュール仕様書など１式を用意しようとします。そのような場合、実際のソースの修正作業は、ここで作られたモジュール仕様書とは別に、「頭の中で考えられた」ように修正されることになるのですが、実際にはモジュール仕様書を全部更新している時間はなく、内部仕様書を修正する程度で時間切れとなり、ソースは「考えて」修正することになります。
そこでは、一体、ベースモデルと今回の新モデルとの違いは何処か、ということについてまとめられたドキュメントはなく、担当者が顧客から出された「要求」を頼りに、あるいは新しい製品仕様書から「変化点」を探り当てて、該当するソースの個所を探し、修正するという作業が行われます。
その結果、「ソースを修正する」という作業の中に、
●ベースとの変化点を考え
●それに該当するプログラムの個所を探し
●どのように修正すればいいのかを考え
●副作用や影響範囲について考え
●問題がなさそうだと分かれば、当初の「案」でソースを修正する
という複雑な行為が含まれています。
このような幾つかの性質の異なる行為を混ぜてしまうと、それぞれの行為の品質が下がってしまうことは言うまでもありません。
（インデックスに戻るときはウィンドウをクローズしてください）
そこには、「要求」が正確に把握されていないのと、その要求ごとに、
一体、この要求を実現するために、
何処を
どのように
修正したのかを示したドキュメントがありません。
つまり、現状は「担当者」の能力に全面的に依存しているのです。担当者が「要求」を影響範囲まで上手く判断して、適切に修正することが求められているのです。そこでは、周囲の誰もレビューなどを通じて手伝ってあげることは出来ません。担当者一人が間違わないように修正するしかないのです。
残念ながら、それでも修正モレや修正ミスが発生し、バグとなって姿を現わします。もちろん担当者は“細心の”注意を払ったのでしょうが、そこには越えることの出来ない「分かる」の問題が関わっています。担当者が、これで“大丈夫”と思っていても、実際には「バグ」となって現れてくるのです。それは、やはり「分からなかった」範囲があったことの証明なのです。
そしてこれは“ひとり”では解決しません。その人とは違った「分かるの範囲」を持った人が参加しない限り、この種のバグは減ることは有りませんし、何年もその「部分」を担当していても、バグの発生状況は変わらないところをみると、単なる「経験年数」は、この種のバグを減らすのには、あまり寄与していないように思われます。
（インデックスに戻るときはウィンドウをクローズしてください）
このあと、「バグ」を究明する作業に入ることになりますが、そこで新たな問題が発生します。それは、ある要求を実現するため目的で、プログラムの何処を修正したのか分からなくなっていることです。
それでも、最初の頃はある程度分かっていても、バグを追いかけ、それを修正していくうちに、「要求」と「修正個所」が分からなくなっていきます。
正常に機能していた「ベースモデル」に対して、「機能Ａ」を追加するために修正を加えた結果の「生成モデル」が予定通りに機能しないとすれば、「機能Ａ」にまつわる修正行為が間違っていることになります。もちろん、修正個所そのものが間違っているケースもあれば、修正しなければならない個所に気づかなかったケースもありますが、何れも、今回の「機能Ａ」の実現の為の修正行為の間違いに変りはありません。
したがって、保守開発の場合、「要求」に対して修正した個所が明確にされていることが重要なのです。バグの追跡も、そこに戻ることによって、「原因」を見付けやすくなります。
（インデックスに戻るときはウィンドウをクローズしてください）
もう一つ、現状の保守開発作業に秘める問題としては、新しい要求に対する「変更点」が整理されていないため、間接的な影響や副作用に気付くのが遅れてしまいます。
たとえば「ＣＰＵのクロックが２０ｍｚから３３ｍｚに変わる」という要求から、「ソフトタイマの繰り返し値が５０から３５に変わる」というのは、比較的容易に気付くでしょうが、通信プログラムの物理層の処理のなかで行っている、プログラム内での「１０μｓのディレイ」処理には気付かないかも知れません。
実際に、一つの「要求」が、いろいろなところに影響を与えるもので、バグの殆どはそのような目立たない個所に潜んでいます。もちろん担当者は気付いていませんので、修正作業に伴うテストでは、そのような個所が試されることはありません。当然、バグは総合テストか運用に入ってから発症することになります。
新規開発では全般に亙って注意して設計しているため、この種の問題は余り発生しません。それに対して保守開発では、最初から「変更要求」に焦点が絞られていて、周辺に注意を促す仕掛けが用意されない限り、システム全般に注意の網が拡げられることはありません。また、この問題は、担当者が「漏れないように注意」するというだけでは解決しません。隠れている問題を“あぶり出す”仕組みがなければ実現しません。
（ウインドーを閉じて下さい）