連載：Team Foundation Server 2010入門 第9回　Team Foundation Server 2010レポートを使ってみよう WINGSプロジェクト　りばてぃ（監修：山田 祥寛） 2011/04/26
Page1 Page2 Page3

●「バグ」カテゴリのSSRSレポート

　「バグ」カテゴリのSSRSレポートは、バグ作業項目の［状態］フィールドに基づいてデータが生成される。一例として「バグの状態」レポート（図5）を見てみよう。

図5　「バグの状態」レポート

　図3の「テスト計画の準備」レポートと同じような表示で、こちらはバグ作業項目の［状態］フィールドの値ごとに集計された結果が表示されている。最終的には、すべてが「終了」となってバグ0ということになる。

　次は「再アクティブ化」レポート（図6）だ。

図6　「再アクティブ化」レポート

　こちらは、いったんは「終了」状態になったが、その後、何らかの理由により［状態］が「再度アクティブ」に変更された率が表示されている。「解決したはずなのに解決していなかった」という舞い戻りの割合が分かる内容となっている。

　バグ作業項目はさまざまなシーンで作成できるが、いずれの場合も基本的には利用者によって作成される。つまり、テスト・ケース作業項目と違って「何かのツールに依存している」といったことがあまりない作業項目であり、比較的自由に利用できる。逆に自由度が高いため、「どんなときにバグ作業項目を作成するべきか」はあらかじめルール決めが必要だろう。

　あとは、日々の利用の中でバグを作成する（＝「アクティブ化」する）、バグを修正する（＝「解決」する）、修正されていることを確認する（＝「終了」する）、直っていなければ再度処理する（＝「再アクティブ化」する）といった作業を行っていけば、おのずと3種類のSSRSレポートが意味あるものとして表示されるようになるはずだ。

　なお、各レポートの詳細はそれぞれ、下記のリンク先に掲載されているので参照していただきたい。

• MSDNライブラリ：バグの傾向レポート
• MSDNライブラリ：バグの状態レポート
• MSDNライブラリ：再アクティブ化レポート

●「ビルド」カテゴリのSSRSレポート

　「ビルド」カテゴリのSSRSレポートは、チーム・ビルドの動作内容に基づいてデータが生成される。一例を確認してみると、「ビルドの概要」レポートは図7のような内容を、「一定期間内のビルド成功」レポートは図8のような内容を確認できる。

図7　「ビルドの概要」レポート

図8　「一定期間内のビルド成功」レポート

　図7の場合は、指定したチーム・プロジェクト上で行われたチーム・ビルドの結果を表形式で確認できる。履歴も含めて表示されるのが表形式なので、ぱっと見では少々分かりにくいだろう。

　図8のレポートは、「ビルド定義ごとにその日の最後に行われたチーム・ビルドの結果が、どういうステータスになったのか」を日ごとに表示している。「毎日ビルドが成功していっているかどうか」を確認できるので、単純なコンパイル程度の設定しかしていなくても見る価値が出てくるだろう。

　いくつか触れてきたとおり、これらのレポートはチーム・ビルドが行ったビルド結果の各種データに基づいて生成されるため、チーム・ビルドを利用していない場合はいずれのレポートも参照できない。また、どのレポートも基本的にはビルドと同時にテスト（特に単体テスト）が実施され、同時にコード・カバレッジが取得されることを想定しているため、開発中のシステムに単体テストが用意されていない場合はSSRSレポートの価値がかなり低いものとなってしまう。

　特に「ビルド品質指標」レポートに関しては、チーム・ビルドと同時にテストを行うように設定していない場合には参照してもあまり意味がないだろう。これは、このレポートがコード・チャーン、テスト成功／失敗数、カバレッジ率、バグ数を一括して参照してビルド対象の品質状況を確認するために用意されているためだ。図9は単体テストなしの状態で「ビルド品質指標」レポートを表示したものだが、参照しても有意義な情報が得られないことがよく分かる。

図9　意味のない「ビルド品質指標」レポートの表示例

　なお、各レポートの詳細はそれぞれ、下記のリンク先に掲載されているので参照していただきたい。

• MSDNライブラリ：ビルドの概要レポート
• MSDNライブラリ：ビルド品質指標レポート
• MSDNライブラリ：一定期間内のビルド成功レポート

●「プロジェクト管理」カテゴリのSSRSレポート

　「プロジェクト管理」カテゴリのSSRSレポートは、少々データを得るのが難しい。このカテゴリに含まれているSSRSレポートの種類によって若干異なる部分はあるが、基本的には上記で取り上げてきたすべての機能のデータを総合的に利用した形でSSRSレポートが生成される。つまり、ソース管理、チーム・ビルド、作業項目、テスト・マネージャをすべて利用していないと正しい内容を参照できないというわけだ。

　まずは「ストーリーの概要」レポート（図10）を見てみよう。

図10　「ストーリーの概要」レポート

　「ストーリーの概要」レポートでは、ユーザー・ストーリー作業項目ごとの進ちょく時間、テスト・ケース作業項目、テスト結果の状況を一覧で確認できる。

　次は「ストーリーの進行状況」レポート（図11）だ。

図11　「ストーリーの進行状況」レポート

　「ストーリーの進行状況」レポートは、「ストーリーの概要」レポートからテストの状況を除いたものとほとんど変わらない。このため、図10を参照している限りはあまりこちらを参照することはないだろう。

　一例で示した「ストーリーの概要」レポート、「ストーリーの進行状況」レポート、さらに「すべてのイテレーションの状態」レポートの3つに関しては、ユーザー・ストーリー作業項目を含むすべての作業項目が利用されていて、かつTFS 2010のすべての機能からのデータがそろっているという2つの条件を満たして、初めて正しい結果を得ることが可能だ。

　「必要条件の概要」レポートと「必要条件の進行状況」レポートは、「ユーザー・ストーリー作業項目」の部分を必要条件作業項目に置き換えて、先ほどのレポートと同様の条件となる。「必要条件の概要」と「必要条件の進行状況」のレポート・イメージはそれぞれ、［ストーリーの概要］レポートおよび［ストーリーの進行状況］レポートと酷似している。

　これら4つのレポートは、MSF for AgileまたはMSF for CMMIの思想に従って、TFS 2010を的確に使用して初めて得られるレポートのため、自分たちの理想に合わない部分を許容しながらの運用が不可能ならば参照する価値がない可能性もある。逆にこれらのSSRSレポートを得られれば、マイクロソフトの意図するとおりにほぼ完ぺきにTFS 2010を使いこなしているともいえるだろう。

　次は、「計画していなかった作業」レポートを見てみよう（図12）。

図12　「計画していなかった作業」レポート

　これは、ある時点で追加された作業の量を確認するためのレポートだ。「ある程度の範囲の作業量であれば許容量として見るが、一定以上を超えると過剰な負荷となるため、計画の変更などを行う」といったことを実施するために参照する。

　「バーンダウンと書き込みレート（＝バーンダウンとバーン・レート）」／「計画していなかった作業」／「残存作業」レポートの3つに関しては、タスク作業項目を利用して、「ダッシュボード」カテゴリSSRSのレポートを見られるような運用がされていれば参照することが可能だ。

　なお、各レポートの詳細はそれぞれ、下記のリンク先に掲載されているので参照していただきたい。

• MSDNライブラリ：ストーリーの概要レポート
• MSDNライブラリ：ストーリーの進行状況レポート
• MSDNライブラリ：すべてのイテレーションの状態レポート
• MSDNライブラリ：バーンダウンと書き込みレートレポート
• MSDNライブラリ：計画していなかった作業（英語ページ）
• MSDNライブラリ：残存作業レポート

　以上でSSRSレポートについて一通り紹介した。

　さて次のページでは、Excelのピボット（テーブルとグラフ）を活用したExcelレポートについて説明する。

INDEX
	［連載］Team Fourndaiton Server 2010入門
	第9回　Team Foundation Server 2010レポートを使ってみよう
	1．Team Foundation Serverに容易された2種類のレポート
	2．Reporting Servicesによるレポート（SSRSレポート）
	3．Excelピボットによるレポート（Excelレポート）

「連載：Team Foundation Server 2010入門」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）