PROHIBITEDVALUES規則
利用者が入力できない値の一覧があることを示す規則です。この規則のxml構文やそこに含まれる属性、サブ要素、設定の仕方については、ALLOWEDVALUES規則と同様のため割愛します。
この規則は、前述の2つのALLOWEDVALUES規則、SUGGESTEDVALUES規則と違い、作業項目を入力するときにドロップダウンリストを表示しません。このため、単に禁止リストを定義するために利用するものと理解しておけば問題ないでしょう。ただし、禁止リストが何であるかを利用者に示す手段が用意されていないため、この規則を単独で使用してしまうとかなり使い勝手の悪いものになってしまいます。そのため、運用ルールとして別途ドキュメントなどで提示するか、ALLOWEDVALUES規則などと組み合わせて定義するか、といった方法が必要となります。
DEFAULT規則
新しい作業項目を作成した時にこの要素の値がフィールドに設定されることを示す規則です。この規則のxml構文は次のようになります。
<DEFAULT from="value|field|clock|currentuser" [value="リテラル値"] [field="フィールド参照名"] [for="適用グループ"] [not="除外グループ"] />
from属性は必須属性で、設定元となるソースを指定します。ここに指定できる値は次の表の通りです。
| 設定値 | 説明 |
| value | value属性に設定した値をコピーする |
| field | filed属性に指定したフィールドの値をコピーする |
| clock | 現在時刻をコピーする |
| currentuser | 作業項目を編集中のユーザー名をコピーする |
value属性は、from属性の値にvalueが設定されているときの必須属性となります。ここに文字列を定義しておき、設定元の値を設定します。
field属性は、from属性の値にfieldが設定されているときの必須属性になります。ここに設定元フィールドのrefname属性の値を設定し、フィールドの値を設定できるように設定します。
この規則が適用されているフィールドは、作業項目が保存されるときに必ず初期値が設定されることになります。例えば、最終更新者、最終更新日など設定される値が明確になり、かつ利用者に設定させるまでもない、または利用者に設定させたくないようなフィールドにこの規則を適用しておくと常に正確な値を設定することができるようになります。この例の場合、フィールド定義のフィールド規則として適用しておくことで常に規則を適用させることができますが、状態定義のフィールド規則などで同じフィールドに別の規則を適用してしまっていると、場合によってはこの規則が有効にならない（例えば、EMPTY規則が適用されているなど）ことがあるため、設定には注意が必要です。
COPY規則
新しい作業項目を作成した時や作業項目を変更したときに、他のところにある値をコピーしてくることを示す規則です。この規則のxml構文は次のようになります。
<COPY from="value|field|clock|currentuser" [value="リテラル値"] [field="フィールド参照名"] [for="適用グループ"] [not="除外グループ"] />
初期値指定かコピーかで若干ニュアンスは異なりますが、from属性、value属性、field属性の設定方法はDEFAULT規則と同様のため、解説は割愛します。DEFAULT規則との違いは、DEFAULT規則が規則が適用されている空のフィールドが初めて保存されるときに適用されるのに対して、COPY規則は作業項目が保存される時に常に適用されるという点です。つまりこの規則が適用されている場合、その対象フィールドに利用者が入力したとしてもこの規則によって有効になる値が常にTFSに保存されることになります。初期値指定だけなのか、常に値をコピーしておく必要があるのかを検討して、DEFAULT規則、COPY規則を使い分けてください。
SERVERDEFAULT規則
作業項目が保存されるときに値が設定されることを示す規則です。この規則のxml構文は次のようになります。
<SERVERDEFAULT from="clock|currentuser" [for="適用グループ"] [not="除外グループ"] />
from属性は必須属性です。DEFAULT規則やCOPY規則と似ていますが、SERVERDEFAULT規則のfrom属性には、clockまたはcurrentuserのみ設定可能です。この規則は、一見するとDEFAULT規則と同じように思いますが、利用者からの見た目としてDEFAULT規則は編集可能であるのに対して、SERVERDEFAULT規則は読み取り専用となります。この規則もDEFAULT規則同様1回だけ適用させる規則なので用途はかなり限定されますが、見た目との兼ね合いによってDEFAULT規則との使い分けを行ってください。
MATCH規則
フィールドのtypeがStringのときに、その文字列のパターンが決められていることを示す規則です。この規則のxml構文は次のようになります。
<MATCH pattern="" [for="適用グループ"] [not="除外グループ"] />
pattern属性は必須属性です。ここには、"A", “N", “X"および記号からなる文字列のパターンを指定します。ここで、"A"は英文字、"N"は数字、"X"は英数字を表します。例えば、pattern属性に「AN.N.NNNNN.N」と指定されていたとすると「v3.5.30729.1」などが有効な値として認識されます。正規表現などを利用して厳密に設定できるわけではないので、用途は限られることを前提にしなければいけませんが、数値のみの入力にさせたい、文字数を固定したいなどの時に利用することができます。
まとめ
ここまでさまざまなフィールドの規則とフィールドの規則を適用できる場所を見てきました。しかし、ちょっと複雑な印象を受けたのではないでしょうか？使いこなせれば確かに作業項目をより使いやすいものにできることは間違いありません。しかし、同時に使い方を少しでも誤ればとたんにとても使いにくいものに変えてしまう可能性もあります。もし、フィールドの規則が複雑だな、難しいなと感じたのであれば、まずは後者の危険が高いということをぜひ認識してください。フィールドの規則の話を始める前にも述べましたが、フィールドの規則は適用する前にその必要性を今一度検討してみてください。あまり過度な制約は使い勝手を落としてしまい、長い時間をかけて検討した作業項目が使われないという事態を招いてしまう可能性があります。
しかし、よく検討し、実際に自分が使う立場であることを考え、どうしたら便利かをきちんと考えていれば、フィールドの規則はさまざまな人たちにとって強力な武器になることもまた間違いではありません。本稿の内容をもとにより使いやすい作業項目を作成する一助になれば幸いです。
次回は作成してきた作業項目をもとにスケジュール管理をしていく術としてProject Server 2007と連携する方法についてみていく予定です。どうぞお楽しみに。
