　ヘッダファイルやソースファイルを新しく作成するたびに、TFS上のソース管理に登録を行います。また、いったん登録したソースコードをVisual Studioのエディタで編集し始めれば、誰か他の人が編集ロックをかけていない限り、自動的にソースコードが編集可能な状態に移行します。この状態をファイルが“チェックアウト”された状態と呼びます。修正が終わった段階で、ソース管理に編集内容をアップデートします。新規登録の場合も含め、ソース管理上のファイルを更新する操作のことを“チェックイン”と呼びます。チェックインされるまでは、ファイルの修正はあくまでも修正した開発者の開発環境の中だけにとどまり、ソース管理上のファイルは更新されません。チェックインされるまでは、別の開発者の環境で当該のファイルを更新しても、チェックアウトされた時点のファイルの内容に変わりはありません。

図6　ファイルの更新タイミング

　他の開発者が更新したファイルで自分の開発環境のファイルを更新するには、Visual Studioのソリューションエクスプローラーのコンテキストメニューでソリューションやプロジェクトを選択し、コンテキストメニューで［最新バージョンの取得］を選択します。［特定バージョンの取得］を選択すれば、最新のファイルセットだけでなく、過去のバージョンのファイルセットを持ってくることも可能です。

　最後の要件「3．ソースコードの変更と変更理由がひも付いていること」ですが、こちらは、CodePlexのIssue Trackerを例に説明を行います。

　Issue Trackerでは、機能要求や障害情報をはじめとしたさまざまな情報を、ステータスや担当者、プライオリティ、参考情報なども含めて登録・管理できます。TFSでは、一括してこれらの項目のことを“Work Item”と呼びます。CodePlexのIssue Trackerタブのインタフェースを用いて、Work Itemの作成・登録が可能です。また、Visual Studioのメニューの［チーム］―［新しい作業項目］―［Work Item］からも登録が可能です。

図7　新しいWork Itemの作成

　さらに、既に登録済みの項目も、Visual Studioで参照可能です。各項目には誰が、いつ、どんな更新をしたかという履歴情報が自動的に記録されており、それを参照することも可能です。

図8　Work Itemの履歴

　前述のファイルのチェックイン時は、Issue Trackerに登録されているWork Itemに関連付けてソース管理への更新を行えます。ここで関連付けられたWork Itemの機能要求や障害情報に記述されている説明が、“ファイルが更新された理由”になるわけです。

図9　チェックイン時のWork Itemとの関連付け

　以上、Visual Studio 2010を使ったチーム開発について、テーマを絞って解説を行いました。

　振り返れば、筆者が初めてソフトウェア開発のプロセス改善に取り組んだ時、最初に開発組織に導入を試みたことは、“ソースコードの構成管理”でした。

　本稿で書いたように、「開発対象をどう分割するか」という設計が一番重要なのですが、ハードウェアが進化し、IT技術が高度化した現在、チーム開発を支援する強力な開発環境もまた非常に重要な要素です。この2つは、複数人のチームで開発を進める上での両輪となります。

　Visual Studioは、拡張性が高い開発環境です。無償で公開されている「Visual Studio 2010 SDK」を追加でインストールすれば、Visual Studioの拡張機能を容易に開発可能です。拡張機能を作成することにより、人手だと面倒な定型作業を自動化でき、安全かつ効率よく作業を進めることができるようになります。

　プロセス改善というと、分厚いマニュアルを作成し、人手によるチェック作業などを想像する人もいるかもしれませんが、下手なマニュアルを作成して作業工数をかえって増やすよりも、定型作業を自動化することを筆者はおススメします。