システム開発をする際には仕様や構成の変更をきちんと管理することが重要です。
特に要件、分析、設計、実装、テストの間のトレーサビリティをいかに維持管理
するかが品質を大きく左右します。とは言っても、開発初期段階から変更管理を
きちんと行うのもなかなか難しいのが現実です。新しい機能を実現しようとする
際には採用している技術の制限によって設計を変えないといけないこともありま
す。そうした試行錯誤的な段階から変更管理をきちんとやっておくことが理想で
すが、実現可能性を探求している段階では開発者の心理として変更ログをこまめ
に残すというのはどうしても優先度の低い作業となりがちです。
一方で顧客からの要求による変更であったり、リリース後の要求ないしは瑕疵に
よる変更である場合には変更管理をきちんと行うというのは納得してもらいやす
いです。
そうなると同じ変更作業でも、それをきちんと管理する場合としない場合とが出
てきてしまうことになります。その変更のトリガーが利用技術によるものなのか
それとも顧客からの要求によるものなのかが明確であれば良いですが、それらが
混在した結果としての変更である場合も多々あります。また変更が生じた時期に
ついても製品の場合であれば明確な出荷日がありますが、受託開発の場合には境
界線を引きづらくなってきます。「この日以降はきちんと変更ログを残しましょ
う」と言っても、なかなか切り替えができずに結局抜け落ちが出てしまうという
こともよく起ることです。
そうなってくると、思い切ってシステム開発のほどんどの工程を「変更管理」と
見なしてしまう方がスッキリするかも知れません。ものすごく乱暴かも知れませ
んが、プロトタイプを作成した後は全てメンテナンスフェーズと見なして仕様・
設計変更とリファクタリングを変更管理プロセスの枠内で遂行するというもので
す。この考え方では製品出荷や初期リリースといったものは変更管理におけるマ
イルストーンの一つに過ぎなくなります。
最初から「全部メンテフェーズなんだよ」という言い方をすれば、実現可能性を
検討している際の変更ログの記録も納得してやってもらえそうな気がします。要
は気の持ち方の問題なのですが、要件や仕様の変更が頻繁であり、規模もそれほ
ど大きくない短納期のシステム構築においてはこうした考え方がフィットするケ
ースもあるのかなぁと思ったりします。
