デグレードへの根本的な対応

「デグレード」っていやな言葉ですよね？

デグレードとは、バージョンアップ時などに今まで動いていた機能が動かなくなってしまったり、修正したはずの障害が再発してしまったりすることを言いますが、これって実はいろいろなプロジェクトの様々なフェーズで起きてますよね？

例えば、協力会社からソースコードをもらったとき...、ある開発者から他の開発者へソースコードを伝達したとき...、テスト環境へデプロイしたとき...、もちろんお客様へ納品したとき...と。

これらについては、よく「テストが足りないんじゃないの？」と言われます。もちろんテスト不足は、よくある主要課題のひとつで、テスト（テストケースを網羅すること、回帰テスト、リグレッショんテストを行うことなど）を十分に実施せず、それが原因でデグレード！なんてこともあります。また、しっかりしたテストをしても、デプロイのミスや勘違いなどでデグレードなんて目も当てられないことも実はよくありますよね。

これらを予防するには、日々の作業をしっかりとコントロールすることが大切です。作業をコントロールできれば、その成果であるソースコードもコントロールできるようになる...そんな理論で成り立っているのが、ソフトウェア構成・変更管理の分野です。

私が過去にコンサルティングをさせていただいたデグレードに悩みを抱えるいくつかのプロジェクトで、ソフトウェア構成・変更管理を実践することでデグレードの軽減や撲滅が行えていました。対処療法だけでなく、原因療法としてのソフトウェア構成・変更管理に少しでも興味をもって、実践いただくプロジェクトが増えることを切に祈ります（＾＾

そんなソフトウェア構成・変更管理を実践していくにあたってのベストプラクティスを集約したプロセス・フレームワークであり、考え方として統一変更管理（UCM: Unified Change Management）というのがあります。こちらの理論や内容を見ていただくことで、変更管理をやる上でのノウハウを学べるとともに、デグレードについてもそうならないためのエッセンスや、逆にデグレードが起きる原因分子が見えてくると思います。

UCMは、Rational Softwareが提唱し、ツールにて実装もしていますが、今お持ちのツールやそれらを組み合わせて工夫することでもある程度は実現できるものです。

ツールでの実装もデグレードを軽減するための大切なファクターではありますが、まずは、ノウハウを学び、自分のプロジェクトの現状を知り、課題を知ることが大切だと思います。