利用できるフィールドの規則
さて、では作業項目定義のフィールドの規則の中身を確認していきましょう。具体的な個別の項目を確認する前にまず、ほとんどのフィールドの規則に持たせることができる共通の属性を確認し、その後に個別の項目を確認していくことにします。
フィールドの規則の共通属性とは
例えば、次の構文を見てください。
<REQUIRED [for="適用グループ"] [not="除外グループ"] />
これは、フィールドが必須入力であることを示す規則をxml構文で示したものです。ここにfor属性およびnot属性が省略可能属性として定義されています。このfor属性とnot属性はほとんどのフィールドの規則に適用することができる属性で、フィールドの規則が適用されるグループ（for属性）と規則が適用されないグループ（not属性）を指定するために用意されています。例えば、プロジェクトマネージャが更新権限を持っていて、それ以外のユーザーは確認のみというような項目は割と見受けられると思います。これは、プロジェクトマネージャのグループがManagerだったとすると次のリスト4のように定義することができます。
<FIELD name="計画値" refname="Jp.CodeZine.WIT04.Actual" type="Integer"> <READONLY not="[Project]\Manager" /> </FIELD>
この例では、チームプロジェクトに定義されているManagerグループを規則の除外グループとして設定しています。ここで「[Project]」というキーワードは作業項目が属しているチームプロジェクトを示すキーワードです。他にTFS全体に定義されていることを示す「[GLOBAL]」というキーワードもあります。また、for属性もnot属性もそれぞれ1グループのみ指定可能であるため、規則を適用するのか除外するのか、どのようなグループに対してそれを行うのかはよく検討しておく必要があります。また、チームプロジェクトのグループ名を利用する場合は、そのグループが定義済みでないと設定がうまく反映されなくなるため、合わせて注意が必要です。
作業項目定義を検討する場合、TFSのプロセステンプレートの検討の一環として検討することもあると思います。プロセステンプレートはチームプロジェクトのひな型になる定義情報ですので、作業項目定義に必要なグループ名をあらかじめ登録しておくことも可能です。この場合は、チームプロジェクトのグループ情報を定義しているファイルが、プロセステンプレートのルートフォルダ内にある「Groups and Permissions」フォルダ内の「GroupsandPermissions.xml」ファイルとして用意されているため、このファイルを編集することで、必要なグループをあらかじめ定義しておくことが可能です。この方法については本稿の範疇を超えるため解説しませんが、興味がある場合は、同ファイルおよびMSDNライブラリの「GSSスキーマ」をご覧ください。
ここからはいよいよフィールドの規則として利用可能な一覧と簡単な用途について確認していきます。
REQUIRED規則
フィールドが必須入力であることを示す規則です。この規則のxml構文は次のようになります。角カッコで囲んだ属性は省略可能であることを表します（以下、すべて同様）。
<REQUIRED [for="適用グループ"] [not="除外グループ"] />
この規則を適用されたフィールドが未入力の場合、作業項目を保存することができません。作業項目の運用を考えた場合に必ず入力しておいてほしい項目に適用しておくといいでしょう。この規則を常に適用する、ある状態の時のみ適用するなど、この規則は先に示した適用場所のどの場所で利用しても効果を発揮できます。
READONLY規則
フィールドが読み取り専用であることを示す規則です。この規則のxml構文は次のようになります。
<READONLY [for="適用グループ"] [not="除外グループ"] />
この規則が適用されているフィールドは編集することができなくなります。一見すると編集できないフィールドの存在意義には疑問が残ります。しかし、前述のfor属性、not属性と組み合わせて使うとあるグループだけ適用する、除外するということができるため、マネージャグループは編集可、それ以外は編集不可という設定が可能です。また、状態定義のフィールド規則として適用すれば、ある状態の時だけ編集できないようにするといったことも可能です。例えば、計画段階では予定値の入力を許可するが、一度その作業が開始した後（状態が遷移した後）は編集不可にするといった利用方法になるでしょう。
EMPTY規則
フィールドの値がクリアされることを示す規則です。この規則のxml構文は次のようになります。
<EMPTY [for="適用グループ"] [not="除外グループ"] />
この規則は主に状態遷移定義のフィールド規則で使用される規則です。フィールド定義や状態定義のフィールド規則として適用してしまうとREADONLY規則とほとんど同様の効果をもたらしてしまいます。READONLYと異なるのは、状態遷移定義の中でこの規則を利用した場合、対象フィールドの値がクリアされる点です。作業項目には通常、状態ごとにその状態にした利用者、およびその日時を記録するフィールドが用意されています。このフィールドを対象の状態になるときに一度クリアする（状態遷移のフィールド規則として適用する）という用途が大多数になります。for属性、not属性と組み合わせることでこれ以外の用途も考えていくことは可能ですが、適用される範囲、運用方法がややこしくなるため、あまりお奨めはしません。
FROZEN規則
作業項目が保存された後、フィールドの値を変更不可にすることを示す規則です。この規則のxml構文は次のようになります。
<FROZEN [for="適用グループ"] [not="除外グループ"] />
この規則を利用した場合、一度フィールドの値を入力して保存した後は以降の変更が不可になります。例えば、作業項目を新規作成して、計画値を入力して保存します。その後、その値を変更できないようにしたい場合に適用しておきます。この規則では例えばnot属性を利用して、マネージャグループであればいつでも変更できるようにしておくということも可能です。また、作業項目に「再計画」という状態を用意しておいて、その状態に遷移するときにフィールドに対してEMPTY規則を適用しておくと、再度変更ができる状態に戻すことも可能です。FROZEN規則を利用する場合は、このように再編集可能にするルートを検討しておくことも重要な要素となります。
