作業項目フィールドの追加および修正とレポート作成
作業項目フィールドは、作業項目の種類のデータの追跡、クエリのフィルター条件の定義、およびレポートのデザインに使用します。 レポートに表示するフィールド (システム フィールドは除く) はすべて、そのフィールドによって追跡される作業項目の種類に対応する定義ファイルの中で定義する必要があります。 システム フィールドは、作業項目の種類ごとに自動的に定義されます。 ただし、データを入力できるようにする場合は、作業項目フォームに含める必要があります。
レポート機能をサポートするには、フィールドの追加または既存のフィールドの属性の変更を実行します。 フィールドを追加または修正するときは、体系的な名前付け規則を適用して、データが SQL Server Analysis Services キューブの各フォルダーに論理的にグループ化されるようにしてください。
このトピックの内容
ベスト プラクティス
既存フィールドを使用する
チーム プロジェクト コレクションに対して定義されているフィールドを一覧表示する
レポート可能フィールドの属性
フィールドの reportable 属性を変更する
フィールドを追加してレポートを作成できるようにする
レポート可能フィールドの属性値に対する変更内容を確認する
レポート用参照名を割り当てるときのベスト プラクティス
MSF プロセス テンプレートで定義されているレポート可能フィールド
ベスト プラクティス
フィールドを追加または修正する前に、次のベスト プラクティスを確認してください。
お客様のチーム プロジェクトが含まれているチーム プロジェクト コレクションの中で既に定義されているフィールドを使用できるかどうかを確認します。 既存フィールドを使用すると、プロジェクト間レポートを作成できます。
Visual Studio Team Foundation Server 内の別のプロジェクト コレクションの中で既に定義されているフィールドを使用できるかどうかを確認します。既存フィールドを使用すると、プロジェクト間レポートを作成できます。
各プロジェクト コレクション内で定義できるフィールドは最大 1,024 個です。また、Team Foundation Server の各プロジェクト コレクション内で定義できる一意のレポート可能フィールドの合計数は、最大 1,024 個です。 結合されたフィールドは、1 個のレポート可能フィールドとして数えます。
プロセス テンプレート、チーム プロジェクト、またはプロジェクト コレクションでフィールドを追加または修正する際の、標準手順と確認プロセスを策定します。
レポート対象フィールドに名前を付ける際、体系的な名前付け規則を適用します。 Team Foundation Server のすべてのチーム プロジェクト コレクションにわたって体系的な方法で参照名を設定した場合、ウェアハウスおよびキューブ スキーマにおける一貫性と使い勝手が向上します。また、ウェアハウス内でのスキーマ競合を回避できます。 詳細については、「データ ウェアハウスで発生しているスキーマ競合の解消」を参照してください。
1 つの作業項目フィールドに最大 4 種類のラベル属性を割り当てられます。
注意
Microsoft Solutions Framework のプロセス テンプレートで定義されているフィールドには、レポート用表示名またはレポート用参照名は割り当てられていません。 参照名属性および名前属性が既定で使用されます。
name. 作業項目クエリのドロップダウン メニューに表示されるフィールドの表示名。 表示名は、チーム プロジェクト内で定義されているすべてのフィールドにわたって一意である必要があります。 また、表示名が作業項目フォーム上のフィールドに割り当てられいる表示名と異なる場合があります。 詳細については、「Control XML 要素のリファレンス」を参照してください。
refname. 当該フィールドと、チーム プロジェクト コレクションで定義されている他のすべてのフィールドを区別する目的で設定される一意の名前。 refname に割り当てられた値は、変更できません。
フィールドの表示名および参照名に関する要件と制約事項については、「作業項目トラッキング オブジェクトの名前付け規則」を参照してください。
reportingname. 省略可能な属性。 レポート内のフィールドを識別する目的で使用される名前。 値を明示的に設定しなかった場合は、name 属性の値が使用されます。
reportingrefname. 省略可能な属性。 当該レポート可能フィールドを、各チーム プロジェクト コレクションで定義されている他のすべてのレポート可能フィールドと区別する目的で設定される一意の名前。 値を明示的に設定しなかった場合は、refname 属性の値が使用されます。 推奨される名前付け規則については、後の「レポート用参照名を割り当てるときのベスト プラクティス」を参照してください。
注意
レポート用参照名は、ピボットテーブル レポートおよび Analysis Services キューブにのみ表示されます。
既存フィールドを使用する
ある既存フィールドが、追跡してレポート対象にする情報と合致している場合は、その既存フィールドを使用する必要があります。 既存フィールドを使用するには、次の手順を実行します。
使用するフィールドを特定します。 witadmin listfields コマンドを使用して、各プロジェクト コレクションに対して定義されているフィールドとその属性を表示します。 詳細については、このトピックの「チーム プロジェクト コレクションに対して定義されているフィールドを一覧表示する」を参照してください。
そのフィールドがレポート可能かどうか、および、reportable 属性の値がレポート作成ニーズに合っているかどうかを確認します。
そのフィールドがレポート可能でない場合は、witadmin changefield コマンドを使用して、そのフィールドが使用されているプロジェクト コレクションの reportable 属性の値を変更します。 詳細については、このトピックの「フィールドの reportable 属性を変更する」を参照してください。
プロジェクト コレクションでそのフィールドが定義されていない場合は、データ追跡に使用する作業項目の種類に対応する XML 定義ファイルにそのフィールドを追加します。 詳細については、このトピックの「フィールドを追加してレポートを作成できるようにする」を参照してください。
チーム プロジェクト コレクションに対して定義されているフィールドを一覧表示する
witadmin listfields コマンドを使用して、フィールドとその属性を一覧表示できます。 あるプロジェクト コレクションで定義されている指定フィールドまたはすべてのフィールドを一覧表示できます。 witadmin listfields コマンドの構文は次のとおりです。
witadmin listfields /collection:CollectionURL /n:RefName
詳細については、「作業項目フィールドの一覧表示とフィールドに割り当てられている属性の表示」を参照してください。
レポート可能フィールドの属性
レポート可能フィールドとは、reportable 属性の値が Detail、Dimension、または Measure であるフィールドのことです。 次の各属性により、作業項目フィールドがデータ ウェアハウスのデータベースでエクスポートおよび処理される方法が決まります。
reportingtype. あるフィールドをレポートに含めるには、reportable 属性に対して次のいずれかの値を割り当てる必要があります。
Detail を割り当てると、フィールドはリレーショナル ウェアハウス データベースにはエクスポートされますが、キューブにはエクスポートされません。 次の例に示すように、Detail はデータ型が Integer、Double、String、または DateTime のフィールドに対してのみ使用します。
<FIELD refname="MyCorp.Summary" name="Summary" type="String" reportable="detail">Dimension を割り当てると、フィールドはリレーショナル ウェアハウス データベースとキューブの両方にエクスポートされます。 次の例に示すように、Dimension はデータ型が Integer、Double、String、または DateTime であるフィールドに対してのみ使用します。 この値は、レポートをフィルター処理するためのフィールド (例: 有効値のリストが格納されているフィールド) を含める際に便利です。
<FIELD refname="MyCorp.Category" name="Category" type="String" reportable="dimension">Measure に設定した場合、キューブ内の事前計算値を処理できます。 Measure 型は、Integer フィールドと Double フィールドに対してのみ使用します。
reportingtype の値に Measure を割り当てるときは、formula 属性に sum を割り当てる必要があります。次に例を示します。
<FIELD refname="MyCorp.Cost" name="Cost" type="Integer" reportable="measure" formula="sum">
reportingrefname. reportable として指定されたフィールドに、別の参照名を割り当てることができます。 値を指定しなかった場合は、refname 属性に割り当てられた値が使用されます。
この属性を使用して、レポートに含まれているフィールドを結合または分岐することができます。 別々の参照名が設定されており、かつ、別々のプロジェクト コレクションで定義されている 2 つのフィールドを結合するには、両フィールドに同じ reportingrefname を設定します。 同じ参照名が設定されているが別々のプロジェクト コレクションで定義されている 2 つのフィールドを分岐するには、各フィールドに別々の reportingrefname を設定します。
ウェアハウスのフィールド数を最小化できる場合やレポート可能フィールドの上限を 1,024 個に維持できる場合は常に、フィールドを結合する必要があります。 結合フィールドを使用して、グループ間レポートを作成することができます。
reportingname. レポートにデータを表示するために使用されるフィールドに、別のラベルを割り当てることができます。 値を設定しなかった場合は、name 属性に設定した表示名が使用されます。 reportingname に割り当てられた値は、キューブ内に表示されます。 reportingrefname に割り当てられた値は表示されません。
重要
レポート対象フィールドに名前を付ける際、ベスト プラクティスに従ってください。それにより、フィールドはグループ化されてピボットテーブル レポートに表示されます。 詳細については、「レポート用参照名を割り当てるときのベスト プラクティス」を参照してください。
作業項目フィールドの reportable 属性を変更する
既存フィールドをレポート可能として設定するには、プロジェクト コレクションに対して定義されているそのフィールドの属性値を変更します。 既存フィールドは、1 つ以上の作業項目の種類の定義の中で定義されています。 また、データ ウェアハウス内でのフィールドの処理方法を決めるすべての属性を変更できます。
フィールドの属性の割り当てを変更するには、次の手順を実行します。
フィールドへの属性の割り当てを変更するには、witadmin changefield コマンドを使用します。 チーム プロジェクト コレクションに対してこのコマンドを実行します。 このコマンドの構文は次のとおりです。
witadmin changefield /collection:CollectionURL /n:RefName [/name:NewName] [/syncnamechanges:true | false] [/reportingname:ReportingName] [/reportingrefname:ReportingRefName] [/reportingtype:Type] [/reportingformula:Formula] [/noprompt]既存フィールドを reportable として設定するには、reportingtype を変更します。 たとえば、AW.Common.TeamPriority フィールドを、レポートをフィルター処理する目的で使用できるようにするには、reportingtype に Dimension を割り当てます。
witadmin changefield /collection:http://AdventureWorksServer:8080/AWTeam/Collection1 /n:AW.Common.TeamPriority /reportingtype:dimension詳細については、「作業項目フィールドの管理 [witadmin]」を参照してください。
(任意) プロジェクト コレクションが複数個ある場合、各プロジェクト コレクションで定義されている作業項目フィールドに対して同じ変更を行わなければならないことがあります。 データ ウェアハウス データベースにデータをエクスポートして処理する際にスキーマ競合を回避するには、すべてのプロジェクト コレクションにわたって次の各属性に同じ値を割り当てる必要があります。
フィールドの種類 (既存フィールドの場合、このフィールドの値は変更できません)。
レポートの種類。
レポート名。
詳細については、「データ ウェアハウスで発生しているスキーマ競合の解消」を参照してください。
レポートに使用する作業項目フィールドに対する変更が完了したら、データ ウェアハウス データベースを処理する必要があります。 ProcessWarehouse Web サービスおよび ProcessAnalysis Web サービスを利用できます。これらの Web サービスは、WarehouseControlWebService を介して利用します。
この手順の目的は、フィールドの属性値を変更した場合にレポート使用者に対してエラーが表示されないようにすることです。 詳細については、「Team Foundation Server で使用するデータ ウェアハウスおよび Analysis Services キューブの手動処理」を参照してください。
詳細については、「作業項目フィールドの管理 [witadmin]」を参照してください。
フィールドを追加してレポートを作成できるようにする
作業項目の種類の定義にフィールドを追加できます。 フィールドを追加する際、そのフィールドによってレポートを作成できるようになるすべての作業項目の種類に対して、同じフィールド要素定義を追加します。 プロジェクト間レポートを作成できるようにするには、レポート対象のすべてのチーム プロジェクト内の作業項目の種類にフィールドを追加します。
詳細については、次のトピックを参照してください。
レポート可能フィールドの属性値に対する変更内容を確認する
レポート可能フィールドの属性値に対する変更内容を調べるには、データ ウェアハウスをオンデマンドで処理してレポートの内容を検査し、変更内容が反映されているかどうかを調べます。 スケジュールに基づいてウェアハウス アダプター ジョブが実行されるまで待ってもかまいません。 既定では、リレーショナル データベースに対する処理は数分ごとに実行されます。 キューブに対する処理は、既定で 2 時間ごとに実行されます。
注意
WarehouseControlWebService の詳細については、「Team Foundation Server で使用するデータ ウェアハウスおよび Analysis Services キューブの手動処理」を参照してください。
ProcessWarehouse WarehouseControlWebService を使用して、リレーショナル データ ウェアハウスをオンデマンドで処理します。
ProcessAnalysisDatabase WarehouseControlWebService を使用して、キューブをオンデマンドで処理します。
レポートが更新されていることを確認します。 ダッシュボードまたはレポート マネージャーでレポートを表示します。 詳細については、「ダッシュボード (アジャイル)」または「レポート (アジャイル)」を参照してください。
レポート用参照名を割り当てるときのベスト プラクティス
フィールドにレポート用参照名を割り当てると、ピボットテーブル内およびキューブ内でフィールドを簡単に探すことができます。 そのとき、体系的な名前付け規則を適用すると、フィールドを論理的にグループ化できます。 フィールドが使いやすい方法でグループ化されていない場合は、フィールドのレポート用参照名を変更できます。
体系的な名前付け規則を適用することは、ますます重要になっています。これは、各プロジェクト コレクションで定義されている各チーム プロジェクトのレポート可能データは、すべて 1 つのリレーショナル データ ウェアハウスに書き込まれるためです。 データ ウェアハウスに書き込まれたデータは、処理されてキューブに書き込まれます。 作業項目フィールドは、プロジェクト コレクションごとに別々に管理されているので、プロジェクト コレクションごとに別々の名前が設定される可能性があります。その場合、レポート作成時にフィールドが適切に整理されません。
reportable 属性の値が dimension に設定されている作業項目フィールドは、キューブ内のディメンションの属性に対応しています。 ディメンションの属性は、プロセス テンプレートまたは作業項目の種類の定義の中で設定されているレポート用参照名に基づいて、各フォルダーに分類されます。 次の種類のマッピングが行われます。
"System" というプレフィックスが付いているフィールドは組み込みフィールドであり、"作業項目" ディメンションの直下に配置され、"Work Item" というプレフィックスが付いています。
その他のフィールドは、参照名内のプレフィックスに対応するフォルダーの下に配置されています。 たとえば、"Microsoft.VSTS.Common" というプレフィックスが付いているフィールドは、Microsoft.VSTS.Common フォルダーの下に配置されています。
次の図に示すとおり、同じプレフィックスを持つフィールドのプレフィックス グループごとに、フォルダーが追加されます。
.png "OLAP データ キューブのフォルダー構造")
次の表に、参照名が "System" で始まり、ピボットテーブル レポート内で "Work Item" というプレフィックスが付くフィールドを示します。 これらのフィールドは、"作業項目" ディメンションの直下に配置されています。 その他のフィールドは、参照名内のプレフィックスに対応するフォルダーの下に配置されています。
注意
SQL Server Analysis Services の Enterprise バージョンを使用していない配置では、そのバージョンの変換機能を利用できません。 これらの配置では、フィールドはキューブ内の完全な参照名によって識別されます。"." は "_" に置換されます (例: System_Id"、"System_Title")。
ピボットテーブル レポート内およびキューブ内での名前 |
参照名 |
データ型 |
|---|---|---|
Work Item.Area Path |
System.AreaPath |
TreeType |
Work Item.Assigned To |
System.AssignedTo |
String |
Work Item.Changed By |
System.ChangedBy |
String |
Work Item.Changed Date |
System.ChangedDate |
DateTime |
Work Item.Created By |
System.Created By |
String |
Work Item.Created Date |
System.CreatedDate |
DateTime |
Work Item.ID |
System.Id |
Integer |
Work Item.Iteration Path |
System.IterationPath |
TreeType |
Work Item.Previous State |
System.PreviousState |
String |
Work Item.Reason |
System.Reason |
String |
Work Item.Rev |
System.Rev |
Integer |
Work Item.State |
System.State |
String |
Work Item.Title |
System.Title |
String |
Work Item.Work Item Type |
System.WorkItemType |
String |
次の表に、"作業項目" ディメンションの下の Microsoft.VSTS.Common フォルダーに配置されている、ピボットテーブル レポートに表示されるフィールドを示します。 これらのフィールドには、"Microsoft.VSTS.Common" で始まる参照名が設定されています。
ピボットテーブル レポート内およびキューブ内での名前 |
参照名 |
データ型 |
|---|---|---|
Work Item.Activated By |
Microsoft.VSTS.Common.ActivatedBy |
String |
Work Item.Activated Date |
Microsoft.VSTS.Common.ActivatedDate |
DateTime |
Work Item.Closed By |
Microsoft.VSTS.Common.ClosedBy |
String |
Work Item.Closed Date |
Microsoft.VSTS.Common.ClosedDate |
DateTime |
Work Item.Created By |
Microsoft.VSTS.Common.CreatedBy |
String |
Work Item.Created Date |
Microsoft.VSTS.Common.CreatedDate |
DateTime |
Work Item.Resolved By |
Microsoft.VSTS.Common.ResolvedBy |
String |
Work Item.Resolved Date |
Microsoft.VSTS.Common.ResolvedDate |
DateTime |
Work Item.Resolved Reason |
Microsoft.VSTS.Common.ResolvedReason |
String |
Work Item.Priority |
Microsoft.VSTS.Common.Priority |
Integer |
Work Item.Severity |
Microsoft.VSTS.Common.Severity |
String |
Work Item.Stack Rank |
Microsoft.VSTS.Common.StackRank |
Double |
MSF プロセス テンプレートで定義されているレポート可能フィールド
次の表に、MSF (Microsoft Solutions Framework) プロセス テンプレートで定義されているフィールド、および既定の設定値を示します。 これらのフィールドは、MSF プロセス テンプレートのバージョン 5.0 で作成されたチーム プロジェクトに対してのみ表示されます。 レポート可能として設定されているフィールドのみを示します。
詳細フィールド
ディメンション フィールド
メジャー フィールド
MSF プロセス テンプレートで定義されているフィールドの一覧については、「システム フィールドおよび MSF のプロセス テンプレートで定義済みのフィールドの使用」を参照してください。 チーム プロジェクトをアップグレードした場合、これらのフィールドの一部を使用するには、事前に特別な作業が必要になることがあります。 詳細については、「アップグレードされたチーム プロジェクトの更新と新機能の利用」を参照してください。
詳細フィールド
フィールド名 |
説明 |
参照名 |
データ型 |
オートメーションの状態 |
テスト ケースの状態。 次の値を指定できます。
|
Microsoft.VSTS.TCM.AutomationStatus |
String |
ディメンション フィールド
フィールド名 |
説明 |
参照名 |
データ型 |
ID |
作業項目に割り当てられる一意の識別子。 作業項目 ID は、チーム プロジェクト コレクションで定義されたすべてのチーム プロジェクトおよび作業項目で一意です。 |
System.Id |
Integer |
タイトル |
作業項目の内容をまとめた簡単な説明。ユーザーはこの説明を参考にして、作業項目をリスト内の他の作業項目と区別できます。 |
System.Title |
String |
チーム プロジェクト |
この作業項目が属するチーム プロジェクト。 |
System.TeamProject |
String |
作業項目の種類 |
作業項目の種類の名前です。 |
System.WorkItemType |
String |
区分 |
作業項目を製品機能区分またはチーム区分に分類します。 この区分は、プロジェクト階層で有効なノードである必要があります。 |
System.AreaPath |
TreePath |
イテレーション |
名前付きスプリントまたは期間を基準にして作業項目を分類します。 このイテレーションは、プロジェクト階層で有効なノードである必要があります。 |
System.IterationPath |
TreePath |
変更者 |
最近作業項目を変更したチーム メンバーの名前。 |
System.ChangedBy |
String |
アクティビティ |
タスクを実行するために必要なアクティビティの種類。 |
Microsoft.VSTS.Common.Activity |
String |
バージョン |
作業項目の履歴のリビジョンに割り当てられている番号。 |
System.Rev |
Integer |
期限 |
タスクの完了が予想される期限。 |
Microsoft.VSTS.Scheduling.DueDate |
DateTime |
完了日 |
スケジュールに示されているタスクの完了予定日時。 |
Microsoft.VSTS.Scheduling.FinishDate |
DateTime |
開始日 |
スケジュールに示されているタスクの開始予定日時。 |
Microsoft.VSTS.Scheduling.StartDate |
DateTime |
発見されたビルド |
バグが発見された製品ビルド番号 (リビジョンとも呼ばれます)。 |
Microsoft.VSTS.Build.FoundIn |
String |
統合ビルド |
コードを取り込む製品ビルド番号またはバグを修正する製品ビルド番号。 |
Microsoft.VSTS.Build.IntegrationBuild |
String |
担当者 |
現在、作業項目を所有しているチーム メンバーの名前。 |
System.AssignedTo |
String |
理由 |
作業項目が現在の状態になっている理由。 値は、作業項目の状態と種類ごとに異なります。 テスト ケースおよび共有ステップでは、このフィールドは追跡されません。 |
System.Reason |
String |
状態 |
作業項目の現在の状態。 有効値は、作業項目の種類ごとに異なります。 |
System.State |
String |
アクティブ化した人 |
作業項目をアクティブ化または再アクティブ化したチーム メンバーの名前。 |
Microsoft.VSTS.Common.ActivatedBy |
String |
アクティブ化された日 |
作業項目がアクティブ化または再アクティブ化された日時。 |
Microsoft.VSTS.Common.ActivatedDate |
DateTime |
終了者 |
作業項目を終了したチーム メンバーの名前。 |
Microsoft.VSTS.Common.ClosedBy |
String |
終了日 |
作業項目が終了した日時。 |
Microsoft.VSTS.Common.ClosedDate |
DateTime |
作成者 |
作業項目を作成したチーム メンバーの名前。 |
Microsoft.VSTS.Common.CreatedBy |
String |
作成日 |
作業項目が作成された日時。 |
Microsoft.VSTS.Common.CreatedDate |
DateTime |
解決者 |
バグまたはユーザー ストーリーを解決したチーム メンバーの名前。 |
Microsoft.VSTS.Common.ResolvedBy |
String |
解決日 |
バグまたはユーザー ストーリーが解決された日時。 |
Microsoft.VSTS.Common.ResolvedDate |
DateTime |
解決理由 |
バグが解決された理由 (例: バグが修正された)。 |
Microsoft.VSTS.Common.ResolvedReason |
String |
優先順位 |
業務に関連付けた場合のバグ、懸案事項、タスク、またはテスト ケースの主観的な評価。 次の値を指定できます。
|
Microsoft.VSTS.Common.Priority |
Integer |
順位 |
同じ種類の他の作業項目と比較した場合のユーザー ストーリー、タスク、懸案事項、またはバグの主観的な評価。 小さい数値が割り当てられている項目は、大きい数値を割り当てられている項目よりも前に修正する必要があります。 |
Microsoft.VSTS.Common.Rank |
Double |
ストーリー ポイント |
ユーザー ストーリーのサイズを把握する主観的な測定単位。 ユーザー ストーリーに割り当てるポイントが大きいほど、実装に必要な作業量が多いということです。 |
Microsoft.VSTS.StoryPoints |
Double |
リスク |
ユーザー ストーリーを完了させることを主観的に評価した場合の相対的な不確実性。 次の値を指定できます。
|
Microsoft.VSTS.Common.Risk |
String |
重大度 |
プロジェクトにおけるバグの影響の主観的な評価。 次の値を指定できます。
|
Microsoft.VSTS.Common.Severity |
String |
期限 |
懸案事項の解消が予想される期限。 このフィールドは、懸案事項の作業項目にのみ適用されます。 |
Microsoft.VSTS.Scheduling.DueDate |
DateTime |
メジャー フィールド
フィールド名 |
説明 |
参照名 |
データ型 |
最初の見積もり |
タスクを完了するために必要な時間数。 |
Microsoft.VSTS.Scheduling.OriginalEstimate |
Double |
残り |
タスクを完了させるまでの残りの時間数。 |
Microsoft.VSTS.Scheduling.RemainingWork |
Double |
完了済み |
タスクの完了にかかった時間数。 |
Microsoft.VSTS.Scheduling.CompletedWork |
Double |
参照
参照
概念
Visual Studio ALM のレポートの作成、カスタマイズ、および管理
その他の技術情報
Team Foundation Server で使用するデータ ウェアハウスおよび Analysis Services キューブの手動処理