はじめに
「派生開発」を成功させるプロセス改善の技術と極意の3.2.1より。
『「不完全なものから学ぶ」という行為に切り替えない限り、不毛の連鎖は終わりません。』
仕様書が無い
派生開発の現場では、開発のベースとなるソースコードに対するソースコードが無い場合が多々あります。それは、下記のようなことが発生しているからだと考えます。
新規開発プロジェクト
新規開発時は各モジュールごとに設計書が作成され、最終成果物となるソースコードver0が開発されます。
派生開発プロジェクト1
先の新規開発プロジェクトをベースに、派生開発を行います。その時に作成される設計書は差分部分のみになります。この差分設計書は、新規開発時の設計書をベースに差分されるでしょう。そして、最終成果物となる派生開発のソースコードver1が開発されます。
派生開発プロジェクト2
さらに、派生開発を行います。同様に今回も作成される設計書は差分部分のみになります。そして、最終成果物となる派生開発のソースコードver2が開発されます。
派生開発プロジェクト3
さらに、派生開発を行います。この頃になると、数年が経過しており、新規開発時の設計書へのアクセスが難しくなります。具体的には、新メンバは元の設計書がどこにあるか不明で、ソースコードver2をスペックアウトして差分設計書を作成する人が出てきます。
このように、元の設計書からではなく、ソースコードからスペックアウトして差分設計書を作成し始めると、後に続く派生開発はソースコード全体の思想が不明のまま開発をすることになります。そして、仕様書が無い、という状態になります。
仕様書は見つからないだけ
改めて「仕様書がなくなるプロセス」を見ると、元の仕様書は無いのではなく、見つからないだけだと言えます。そのため、新規開発プロジェクトに近い開発に携わっていたメンバに設計書の所在を質問すると、わりとあっさり見つかります。
仕様書が無い場合は、人に聞きましょう!アクセス方法が属人化している可能性が高いです。
元の仕様書が現状に即していない
ようやく元の仕様書を確認できたとしても、派生開発が長く続くと、現状に即していないということが発生します。そうなった時、「不完全なものから学ぶ」という行為に切り替える必要があります。曲がりなりにも、元々の開発で作成された設計書です。ポイントとなる部分をスペックアウトし、今の派生開発の差分設計書に盛り込むことで、開発環境が改善されます。特に、元の仕様書へのアクセス方法を明記するだけでも効果があります。
おわりに
仕様書がなくなるプロセスを考えました。そして、それは仕様書が無いのではなく、見つからなくなる状態になっていると結論しました。もし、仕様書が無くて困っている方がいらしたら、属人化している可能性があるので、人に聞いてみたら良いと思います。周囲に該当する人物がいない場合は、ソースコードからスペックアウトするしかありませんが。。。