CodeZine(コードジン)

特集ページ一覧

TFSの作業項目をプロジェクトに合わせてカスタマイズする(前編)

Visual Studio Team System 徹底活用(1)

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2009/06/18 14:00
目次

作業項目定義の内容を理解する

 作業項目の定義情報を編集し始める前に、この構造の中身を理解しておきましょう。説明する内容にはこんがらがってしまうポイントも多いですが、ここでしっかりとポイントをつかんでしまえば、この後がかなりスムーズになります。

作業項目定義の全体像

 はじめに、作業項目定義の全体像を確認しておきましょう。先ほど「デスクトップ」に保存しておいた「MyTask.xml」ファイルをInternet Explorerで開いてください。先頭の要素が<WITD>から始まるかなり大量の定義が含まれているファイルが開いたはずです。量が多いので全部を1から見ていこうとすると大変ですが、大きくは図4に示すように3つのブロックから成り立っています。

図4:作業項目定義の全体像
図4:作業項目定義の全体像

 ワークフロー定義は、その中でさらに2つのブロックに分かれていて、都合4つのブロックと考えることができます。4つのブロックのルートとなる要素名、その概要を次の表に示します。

4つのブロックのルート要素と概要
ルート要素名 概要説明
FIELDS 作業項目内で利用するフィールドというものを定義するためのブロックです
STATES(WORKFLOW要素内) 作業の進捗に合わせた作業の状態を定義するためのブロックです
TRANSITION(WORKFLOW要素内) 作業項目の状態の移り変わり(状態遷移)を定義するためのブロックです
FORM 作業項目をVSなどで開いた際の見た目を定義するためのブロックです

 全体としてこの4つがあることを認識し、その後でこの後に説明するそれぞれのブロックの中身を確認していくと理解がスムーズになるはずです。

作業項目のフィールド定義(<FIELDS>要素)

 作業項目定義に含まれるフィールドとは、利用者が作業項目を使って入力するデータや、TFSが内部で管理しているデータなどを保存しておく変数のようなものです。作業項目定義をプログラミングにおける「クラス」と捉えると作業項目のフィールドは、クラスに含まれるフィールドのようなものとイメージすると分かりやすいかもしれません。

 さて、定義の仕方ですが、基本的には以下の書式で定義します。

[リスト1]フィールド定義の方法
<FIELD name="サンプルの名前" refname="JP.CodeZine.WIT01.Name" type="String" reportable="dimension" />

 それぞれについて、説明をしておきましょう。<FIELD>要素は、作業項目にフィールド定義を追加するための要素宣言です。<FIELD>要素に含まれている属性の概要は次のとおりです。

属性名 概要
name 作業項目クエリで絞り込み条件に利用したり、作業項目クエリの検索結果列名に利用したりするフィールドを識別する名前です。利用者が目で見て判断するために利用されます。
refname フィールド定義の情報をTFS内で一意に識別するためのフィールド参照名という名前です。既存のフィールド参照名やサードパーティ製品などの拡張とぶつからないようにするための名前付けの推奨規約があります。
type フィールドに入力される型を識別するための設定情報です。さまざまな種類を設定することができます。
reportable 作業項目としてこのフィールドに入力された情報をデータウェアハウスでどのように利用するかを指定するための設定情報です。いくつかの種類が用意されています。

 少し補足しておきましょう。name属性はフィールドの名前を人が分かるような内容で設定していきます。このため、大体は日本語が使われることが多いように思います。また、作業項目を検索する条件を作成するときには、絞り込み条件項目としてこの値を利用します。実際に、作業項目クエリを作成している画面(図5)を見てみると、上側がクエリ編集エリアで、ここのフィールド列に表示されている値は、<FIELD>要素のname属性の内容が利用されています。また、このクエリを使った結果として表示されるクエリ結果一覧のそれぞれの列名も同じく、name属性の内容を利用しています。

図5:作業項目クエリのフィールド
図5:作業項目クエリのフィールド

 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つの基本概念のもとに多次元構造に構築されたキューブというものが利用されます。キューブを利用する場合、大抵は何らかのデータの分析を行います。ここで分析の切り口となるのがディメンションです。例えば、日付の場合、年単位、月単位、日単位などレベルを変えて集計を行うためにディメンションを利用します。そしてこのときに集計される元ネタとなる値がメジャーです。売上や受注、作業時間数などのデータが該当します。メジャーには売上と受注など関連を持って設定されているものがあり、これら関連を持つメジャーのコレクションがメジャーグループとなります。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:Visual Studio Team System 徹底活用

著者プロフィール

  • 山田 祥寛(ヤマダ ヨシヒロ)

    静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for ASP/ASP.NET。執筆コミュニティ「WINGSプロジェクト」代表。 主な著書に「入門シリーズ(サーバサイドAjax/XM...

  • WINGSプロジェクト りばてぃ(リバティ)

    <WINGSプロジェクトについて> 有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5