TOP
＞
プロジェクト管理
＞ はじめに
チーム開発ここまできた、個人からチームの生産性向上へ
第２回：Visual Studio 2005の変更管理の有効性
著者：
日本ユニシス 井上 浩司
2006/1/10
1
2
3
4
次のページ
はじめに
ソースコードとドキュメントは互いに依存しています。ゆえに、すべてのソースコードとドキュメントはプロジェクトメンバー間で共有されていなければなりませんし、内容の変更も管理し、さらに関連まで持たせておかなければなりません。そうしておかないと、ドキュメントとソースコードの内容が一致せず、あとで保守する人（注）が苦労してしまいます。
※注：
開発と保守は別のチームになることが多いです。
また、ビジネスの変化が早い昨今、システムの短期開発が求められています。それにともない、開発の現場ではフェーズ分割された並行開発が多くなっています。その並行開発において、ソースコードはフェーズにまたがってきちんと変更履歴を管理しておかないといけません。そうしておかないと、何度も同じバグを発生させてしまいます。
というわけで本連載「チーム開発ここまできた、個人からチームの生産性向上へ」の第2回の今回は、チーム開発の肝とでもいうべきVisual Studio 2005 Team Foundation Server（以下、VS2005 TFS）の変更管理機能の管理コスト、品質向上、時間の短縮の面での有効性について考察していきます。
管理コストの削減
Windows XPなどのアジャイル開発プロセスにおいて、ソースコードの変更管理はそれほど厳密に行う必要はないかもしれません。というのも、最終的にできあがったソースコードが、テストをパスできていればそれでよしとしているからです。ですが、ほとんどのプロジェクトでは何らかの変更管理をしているはずです。
例えば、テストチームで発見されたバグが修正依頼書としてあがってくることがあります。また、税率の計算ロジックの変更や画面の入力項目の追加などの突然の変更要求が変更依頼書としてあがってくることもあります。
そしてプログラマは、依頼書を元にプログラムを修正してテストします。その後、報告書に変更したソースコードの一覧を記入したり、その変更内容や影響度を記述したりします。最後にコードレビューを経て、報告書はWord文書で共有フォルダに、ソースコードはソースコード管理システムにチェックインします。一連の作業は、標準化されてはいますが、慣れるとついついサボりがちになったり、提出するドキュメントが多すぎて記述ミスが多くなったりします。
またテストチームや、クライアントへ出荷するモジュールの管理も面倒でした。Visual SourceSafe（以下、VSS）では、分岐という仕組みを利用すればできますが、あまり知られていないからか使われていません。このため、リポジトリを分岐せずに開発を行ったがために、発生した不具合がどのフェーズのソースコードに潜んでいた問題なのかを切り分けるのが難しくなることがあります。
これらの問題をVS2005 TFSでは、変更セットとブランチ、マージによって解決できます。
1
2
3
4
次のページ
著者プロフィール
日本ユニシス株式会社 井上 浩司
総合技術研究所 所属
オープンミドルウェアMIDMOST for .NETの開発や、MSCSを補完するACABの開発に従事しています。
INDEX
第2回：Visual Studio 2005の変更管理の有効性
はじめに
変更セット
品質の向上
無駄な時間の削減
