作業項目定義の内容を理解する
作業項目の定義情報を編集し始める前に、この構造の中身を理解しておきましょう。説明する内容にはこんがらがってしまうポイントも多いですが、ここでしっかりとポイントをつかんでしまえば、この後がかなりスムーズになります。
作業項目定義の全体像
はじめに、作業項目定義の全体像を確認しておきましょう。先ほど「デスクトップ」に保存しておいた「MyTask.xml」ファイルをInternet Explorerで開いてください。先頭の要素が<WITD>から始まるかなり大量の定義が含まれているファイルが開いたはずです。量が多いので全部を1から見ていこうとすると大変ですが、大きくは図4に示すように3つのブロックから成り立っています。
ワークフロー定義は、その中でさらに2つのブロックに分かれていて、都合4つのブロックと考えることができます。4つのブロックのルートとなる要素名、その概要を次の表に示します。
| ルート要素名 | 概要説明 |
| FIELDS | 作業項目内で利用するフィールドというものを定義するためのブロックです |
| STATES(WORKFLOW要素内) | 作業の進捗に合わせた作業の状態を定義するためのブロックです |
| TRANSITION(WORKFLOW要素内) | 作業項目の状態の移り変わり（状態遷移）を定義するためのブロックです |
| FORM | 作業項目をVSなどで開いた際の見た目を定義するためのブロックです |
全体としてこの4つがあることを認識し、その後でこの後に説明するそれぞれのブロックの中身を確認していくと理解がスムーズになるはずです。
作業項目のフィールド定義（<FIELDS>要素）
作業項目定義に含まれるフィールドとは、利用者が作業項目を使って入力するデータや、TFSが内部で管理しているデータなどを保存しておく変数のようなものです。作業項目定義をプログラミングにおける「クラス」と捉えると作業項目のフィールドは、クラスに含まれるフィールドのようなものとイメージすると分かりやすいかもしれません。
さて、定義の仕方ですが、基本的には以下の書式で定義します。
<FIELD name="サンプルの名前" refname="JP.CodeZine.WIT01.Name" type="String" reportable="dimension" />
それぞれについて、説明をしておきましょう。<FIELD>要素は、作業項目にフィールド定義を追加するための要素宣言です。<FIELD>要素に含まれている属性の概要は次のとおりです。
| 属性名 | 概要 |
| name | 作業項目クエリで絞り込み条件に利用したり、作業項目クエリの検索結果列名に利用したりするフィールドを識別する名前です。利用者が目で見て判断するために利用されます。 |
| refname | フィールド定義の情報をTFS内で一意に識別するためのフィールド参照名という名前です。既存のフィールド参照名やサードパーティ製品などの拡張とぶつからないようにするための名前付けの推奨規約があります。 |
| type | フィールドに入力される型を識別するための設定情報です。さまざまな種類を設定することができます。 |
| reportable | 作業項目としてこのフィールドに入力された情報をデータウェアハウスでどのように利用するかを指定するための設定情報です。いくつかの種類が用意されています。 |
少し補足しておきましょう。name属性はフィールドの名前を人が分かるような内容で設定していきます。このため、大体は日本語が使われることが多いように思います。また、作業項目を検索する条件を作成するときには、絞り込み条件項目としてこの値を利用します。実際に、作業項目クエリを作成している画面（図5）を見てみると、上側がクエリ編集エリアで、ここのフィールド列に表示されている値は、<FIELD>要素のname属性の内容が利用されています。また、このクエリを使った結果として表示されるクエリ結果一覧のそれぞれの列名も同じく、name属性の内容を利用しています。
refname属性は日本語訳ではフィールド参照名と呼ばれる属性です。フィールド定義の情報をTFS自身がTFS内で一意に識別できるように設定していきます。name属性は人が目で見て分かりやすいようにつけますが、それだと重複が発生してしまう恐れがあるため、別にrefname属性という一種のIDを用いて、一意に識別できるようになっています。作業項目内やプロセステンプレート、チームプロジェクト内ではなく、TFS全体で一意にする点に気をつけなければいけません。そのため、refname属性の名前付けには“名前空間名を付ける"という推奨命名規則があります。既存の<FIELD>要素を確認してみると『System.XXXX』や『Microsoft.VSTS.Common』などが利用されていることが確認できます。なお、これらの既存の名前空間名は予約語扱いのため、自分で作る<FIELD>要素に設定することはできません。また、refname属性は一度作業項目定義をTFSに登録してしまうと変更することができなくなりますので注意して設定する必要があります。
type属性はフィールドに格納可能な値を決めるために設定します。設定可能なフィールドの種類は次の表に示すものがあります。
| 種類 | 内容 |
| String | 255文字以内の文字列 |
| Integer | 32ビット符号付き整数値 |
| Double | 浮動小数点値 |
| DateTime | 日時 |
| PlainText | Stringよりも長い複数行に渡るテキスト |
| HTML | 基本的にPlainTextと同様だが、HTML構文を利用できる |
| History | 作業項目が保存されたときの履歴情報や複数ユーザー間でのディスカッション情報 |
| TreePath | 作業項目の区分パスまたはイテレーションパスとの関連付け |
HistoryとTreePathは少し特殊なもので、基本的には、作業項目定義内にHistoryが1つ、TreePathが最大2つあれば問題ないと思います。既存の作業項目定義をカスタマイズする場合には、これらは既に含まれているのではじめはあまり気にしない方が良いでしょう。これら以外のTypeは直感的に分かりやすく、自分で追加のフィールドを作成する場合によく利用するものなので、しっかり把握しておいてください。
TFSには、作業の区切りを示すための機能として「区分」と「イテレーション」というものが用意されています。言葉の通りに考えると区分は作業区分を指しますので、要件定義、ユーザーインターフェイス設計、開発、テストなどのどれに該当する作業なのかを示します。イテレーションは反復開発をする際のどの位置付けかを指しますので、例えば方向づけ、推敲、作成、移行などが該当します。こう説明してしまうとUPやXP以外では使えないのかと思ってしまいがちです。しかし、これらは単純に時間軸と作業カテゴリをマトリックスで示すためにあるものという程度に解釈してしまえば（もちろんこの限りではない解釈も可能ですが）、柔軟に使いこなしていくことができるはずです。
reportable属性はフィールドに格納される値をTFSのデータウェアハウスでどのように利用するかを設定します。これまでの3つの属性はすべて必須属性でしたが、このreportable属性は任意です。設定しない場合は、フィールドの値をデータウェアハウスで利用することはできません。ただし、一度設定すると後から変更することはできないので注意して設定する必要があります。利用可能な値は、次表の通りです。
| 種類 | 対応する型 | 概要 |
| dimension | String, Integer, Double, DateTime | フィールドの値は、データウェアハウスのデータベースとOLAPキューブに対して、ディメンション属性としてエクスポートされます。キューブ上では、レポートのフィルタとして利用することができます。 |
| detail | String, Integer, Double, DateTime | フィールドの値は、データウェアハウスのデータベースに対してはエクスポートされますが、OLAPキューブに対してはエクスポートされません。 |
| measure | Integer, Double | フィールドの値は、データウェアハウスのデータベースとOLAPキューブに対して、メジャーグループとしてエクスポートされます。キューブ上では、レポートに表示される数値として利用することができます。 |
type属性とreportable属性の組み合わせは、TFSでレポート機能を利用する上では非常に重要な組み合わせです。また、refname属性もTFS上で一意にしなければいけないなど、何かと制約が多くなっています。カスタマイズの際にはいろいろと試してみることも必要ですが、そのときに、不必要なデータがTFS上にたまっていってしまうため、必ずテスト環境を構築して作業することをお奨めします。
Microsoft SQL Server Analysis ServicesなどでOLAPデータベースを扱うときにはメジャーとディメンションという2つの基本概念のもとに多次元構造に構築されたキューブというものが利用されます。キューブを利用する場合、大抵は何らかのデータの分析を行います。ここで分析の切り口となるのがディメンションです。例えば、日付の場合、年単位、月単位、日単位などレベルを変えて集計を行うためにディメンションを利用します。そしてこのときに集計される元ネタとなる値がメジャーです。売上や受注、作業時間数などのデータが該当します。メジャーには売上と受注など関連を持って設定されているものがあり、これら関連を持つメジャーのコレクションがメジャーグループとなります。
