No.88: 構成を管理できているか

　ドキュメント等の成果物には、販管理またはバージョン管理といったものが必須です。世の中には多くのバージョン管理システムがあるので、それを利用すればバージョンの違いによる混乱を避けられる可能性は高いでしょう。

　しかし、当然ですがシステムを入れさえすれば問題の発生を防げるというわけではありません。それを適切に運用する必要があります。期限が迫る中、ドタバタと修正を加えたものを、バージョン管理システムに登録し忘れてしまったということが現に起こりえます。

　ところで、”単品”の成果物に対してそのバージョンをしっかり管理していても、複数の成果物の間の依存関係を含めて、いわゆるその”構成”を管理できているかについては注意が必要です。

　例えば、システムの開発プロジェクトにおいて、上位のドキュメントAでシステムの仕様を定義していたとして、そのシステムを構成する2つのサブシステムの仕様をそれぞれ定義するドキュメントB及びドキュメントCがあったとします。

　それぞれのドキュメントのバージョンが管理されているとしても、ドキュメントAとドキュメントB及びCの関係は管理されているでしょうか。

　そのシステムが頻繁に更新される性格のものであると、ドキュメントB及びCに基づいてサブシステムの更新作業を行いながら、同時並行で次のシステム更新のためにドキュメントAに変更の手を入れているかも知れません。

　この様な場合、ドキュメントB及びCの上位ドキュメントはAのどのバージョンかということを明確にする必要があります。ドキュメントBのバージョン1の前提となるのはドキュメントAのバージョン1という様に、です。

　聞けば当たり前のことと思われるでしょうが、私は現場でドキュメントBの前提となるドキュメントAのバージョンが明確になっていない場面に幾度も遭遇しています。実態として明確に識別できていないケースがあるのです。

　これはドキュメントB及びCを作成、更新する立場からの問題ですが、ドキュメントAを作成、更新する立場でも問題は発生します。

　ドキュメントAのバージョン1に基づきドキュメントB及びCが作成されているのと並行して、次回の更新のためにドキュメントAのバージョン2を作成しているとします。ここで、ドキュメントB及びCからのフィードバックでドキュメントAのバージョン1に変更が発生する場合があります。変更を反映したドキュメントAをバージョン1.1としましょう。さて、このバージョン1から1.1で加えられた変更は、バージョン2においてどうすれば良いでしょうか。

　ケース・バイ・ケースで判断しなければなりません。バージョン1から1.1で加えられた変更は、バージョン2にも反映しなければならないものかも知れませんし、バージョン2では無視して良い内容かも知れません。

　シンプルな例で説明しましたが、いずれにしても、そういった変更を含めて全体の構成を管理できているか、その仕組みができているか、ということです。

　プロジェクトのトラブルは、その原因が上流にあればあるほど影響が大きくなりますが、構成管理の不徹底は、プロジェクトの終盤に発生しても大きな影響を及ぼしてしまうものです。構成管理の仕組みができていなかったということに目を向ければ、これも上流に原因があったと言えるのですが。

　あなたの組織、プロジェクトでは、”構成”の管理ができていますか。仕組みがなく、属人的な気配りに依存してしまってはいないでしょうか。

関連提言；No.44: プロセスが確立されているか