それではベースモデルのドキュメントが存在しない場合、あるいは、全く役に立たないような場合は、このような方法は使えないのかというと、決してそうではありません。むしろ、この方法は、そのようなドキュメントの無い状況にあってこそ、効果を発揮するものと言えます。
実際に、多くの開発組織は、このような状況に置かれていると思われます。しかしながら、「差分開発」の明確な考えや手順を確立できていないのと、新しいことへの挑戦から遠ざかってしまったことから身動きが取れず、いつまでも現状を転換できる機会を持つことが出来ないのでしょう。
（インデックスに戻るときはウィンドウをクローズしてください）
たとえそのようなドキュメントが存在しない組織にあっても、今まで必死になって修正作業をしてきています。もちろん、決して褒められた方法ではないかも知れません。それでも納期の遅れや機能モレなどを伴いながら、何とか修正しているではないですか。そこでは、過去の知識とソースだけで、変更点を認識し、ソースの修正を行っているのです。
ということは、そのような状況にあっても、新しい製品仕様や新しい顧客の「要求」から、“ある程度”の変更点の認識は出来るということで、それを「変更要求仕様書」としてまとめればよいのです。そして、要求の一つひとつについて、具体的な変更方針や変更方法を記述していけばよいのです。この部分は、今までやってきたことに近い行為です。
いいかえれば、有効なドキュメントを持たないベースモデルに基づいて派生モデルを開発する場合、「差分開発」しか方法はないということが出来ます。
（インデックスに戻るときはウィンドウをクローズしてください）
最初はぎこちないかも知れませんが、「要求」を中心に実現方法が文書化されることで、すくなくとも今まで避けることの出来なかった「副作用」や、隠れた影響範囲の問題についてレビューを実施することが出来ます。
最初は、レビューの成果は僅かかも知れませんが、途中で気付いたことを書き込むことはできます。また、テストによって発生したバグの究明の際には、「変更要求仕様」や「変更設計書」に立ち戻って考えることが出来ます。
大事なことは、実際に修正行為を行う前に、このような文書を書くことです。場合によっては、そこには「強い意志」が必要になるかも知れません。特に、長年、直接ソースを弄ってきた人は要注意です。
事前の文書をしっかり書くことに慣れるまでは、決してソースを修正しようとしないことです。そのためには、「変更設計書」に、絶対にソース（の新旧対比）を書かないことです。
一旦、ソースの修正行為に似た行為を持ち込んでしまえば、水を得た魚のように、たちまち以前の姿に戻ってしまいます。そして、一度、このような慣習からの脱出に失敗した人は、「学習効果」のために再度の挑戦は更に困難になります。
「ここで目の前のソースを修正すれば早いのにな」という「声」は、まさに悪魔の囁きと思って下さい。この声は、あなたの取り組みが「受け身」から脱した瞬間から、耳元で囁かれることはなくなります。でも、「受け身」のままであれば、間違いなくこの「声」に誘惑されるのです。そして私のまえで、「そこでソースを修正することの正当性」、あるいは「無問題性」を説いて、哀願するのです。
残念ながら、私に出来ることは、馬を水辺に連れていくことまでであって、飲むかどうかは馬の「意思」次第です。もちろん、その水を飲むことの有用性はいろいろと説明しますが。
（インデックスに戻るときはウィンドウをクローズしてください）
ドキュメントの無い開発組織で、このような取り組みに躊躇する理由の一つに、ドキュメントを書き慣れていないために、「変更要求仕様」や「変更設計書」を書く時間が気になることがあります。
また、具体的な変更点をイメージしながら、もう一歩進んでソースを修正するのを思い止まって、「変更要求仕様」や「変更設計書」を書くことが不合理に思えるかも知れません。
しかしながら、これまでの混乱は、そうやって簡単にソースを修正することに起因しているのです。まさかと思うところに、修正の影響が隠れていたり、今まで問題なく機能していた部分が、今回の修正の結果、動かなくなってしまったり、要求そのものを勘違いしていたり、散々な目にあってきたではないですか。それは、時間が足りなかったからではありません。その派生モデルの開発にたいするプロセスが悪いのです。したがって、プロセスを変えないかぎり、何も変わらないでしょう。
「変更要求仕様」や「変更設計書」を書き、適切なレビューを実施することは、確かにソースの修正に着手する時期を後ろにずらします。しかしながら、隠れた影響や副作用の問題は、事前にチェックされていて減っているはずなのと、一歩下がってバグを追跡できることで、後半の時間が短くて済むはずです。というより、短く出来るのです。
ドキュメントの無い開発組織のリーダーや管理者は、兎に角、一つの保守開発プロジェクトの納期をミートすることに知恵と工夫を傾注することです。「今」のプロジェクトの納期を遅らせている限り、永久に保守開発の「蟻地獄」から抜け出ることはできないでしょう。「差分開発」は、開発に必要なプロセスを省略すること無く最短コースを走る方法です。
（ウインドーを閉じて下さい）