プロセスのカスタマイズと継承されたプロセスの概要

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

作業追跡システムをカスタマイズするには、 組織の管理ユーザー インターフェイスを使用して継承されたプロセスをカスタマイズ します。 継承されたプロセスを使用するすべてのプロジェクトは、そのプロセスに対して行われたカスタマイズを取得します。 一方、チームごとにアジャイル ツール (バックログ、スプリント、かんばんボード、タスクボード) を構成します。

重要

オンプレミスのプロジェクトをカスタマイズしたり、XML 定義ファイルを更新してカスタマイズをサポートしたりするには、オンプレミスの XML プロセス モデルを参照してください。 この記事は、Azure DevOps Services と Azure DevOps Server 2019 にのみ適用されます。

カスタマイズできるカスタマイズは多数あります。 主なものは、カスタム作業項目の種類 (WIT) を追加するか、既存の WIT を変更してユーザー設定フィールドを追加したり、レイアウトを変更したり、ワークフローを変更したりすることです。

Note

継承されたプロセスに加えられた変更は、監査ログを通じて確認できます。 詳細については、「 監査ログへのアクセス、エクスポート、フィルター処理」を参照してください。

以下に、継承されたプロセスをカスタマイズするために実行できるタスクのインデックスを示します。 継承された要素の一部のオプションはロックされており、カスタマイズできません。

システムと継承されたプロセス

次の 2 種類のプロセスが表示されます。

  • locked icon システム プロセス —アジャイル、基本、スクラム、CMMI。変更がロックされています。
  • inherited icon 継承されたプロセス。カスタマイズでき、作成元のシステム プロセスから定義を継承します。 システム プロセスは、Microsoft によって定期的に所有および更新されます。 システム プロセスに対して行われた更新により、継承されたプロセスとその子継承プロセスが自動的に更新されます。 プロセスへの更新については、Azure DevOps Server のリリース ノート。

Note

基本プロセスは、Azure DevOps Server 2019 Update 1 以降のバージョンで使用できます。

さらに、すべてのプロセスが共有されます。 つまり、1 つ以上のプロジェクトで 1 つのプロセスを使用できます。 1 つのプロジェクトをカスタマイズする代わりに、プロセスをカスタマイズします。 プロセスに加えられた変更により、そのプロセスを使用するすべてのプロジェクトが自動的に更新されます。 継承されたプロセスを作成したら、それをカスタマイズし、それに基づいてプロジェクトを作成し、コピーを作成し、既存のプロジェクトを変更して使用することができます。

たとえば、次の図に示すように、fabrikam 組織に対して定義されているプロジェクトの一覧が表示されます。 2 番目の列は、各プロジェクトで使用されるプロセスを示しています。 Fabrikam Fiber プロジェクトのカスタマイズを変更するには、MyScrum プロセス (スクラム システム プロセスから継承) を変更する必要があります。 MyScrum プロセスに加えた変更は、そのプロセスを使用する他のプロジェクトも更新します。 一方、アジャイルから継承するプロセスに変更するまで、クエリ テスト プロジェクトをカスタマイズすることはできません。

Screenshot of Admin context, Organization settings, Project list and the process they use.

プロセス名の制限

プロセス名は一意で、128 Unicode 文字以下である必要があります。 また、名前に次の文字 .,;'`:~\/\*|?"&%$!+=()[]{}<>を含めることはできません。

プロセスの名前を変更するには、... プロセスのコンテキスト メニューをクリックし、[編集] を選択します。

プロジェクトの参照プロセスを変更する

プロジェクトが使用するプロセスをあるシステム プロセスから別のシステム プロセスに切り替える場合は、それを行うことができます。 これらの変更を行うには、切り替えるプロセスに基づいて継承されたプロセスを作成する必要があります。 たとえば、次の変更をサポートするための手順が提供されています。

上記の記事で提供されているガイダンスに従って、CMMI からアジャイル、アジャイル、CMMI など、追加の変更を行うこともできます。

この変更を行う前に、変更するプロセスについて理解しておくことをお勧めします。 システム プロセスは、プロセスとプロセス テンプレートについてで まとめられています。

変更を行う際のベスト プラクティス

継承されたプロセスに変更を加えるのは簡単で安全です。 ただし、アクティブなプロジェクトに適用する前に、これらの変更をテストすることが常にベスト プラクティスです。 次の手順 に従うと、プロセスの変更に悪影響を及ぼす可能性があります。

継承されたオブジェクトとカスタム オブジェクト

作成した継承された各プロセスは、システム プロセス (Basic、Agile、Scrum、または CMMI) で定義されている WIT を継承します。 たとえば、アジャイル プロセスでは、バグ、タスク、ユーザー ストーリー、機能、エピック、問題、テスト関連の WIT が提供されます。

Conceptual image of Agile process work item hierarchy.

フィールドを追加し、[作業項目の種類] ページに表示されるすべての継承された WIT のワークフローフォームと作業項目フォームを変更できます。 ユーザーに WIT を作成させたくない場合は、無効にすることができます。 さらに、カスタム WIT を追加することもできます。

フィールドのカスタマイズ

システム プロセスで定義されているフィールドは、継承されたアイコンと共 に表示され、継承されたプロセスで変更を制限できることを示します。

フィールドは、組織内のすべてのプロジェクトとプロセスに対して定義されます。 つまり、あるプロセスで WIT に対して定義したユーザー設定フィールドは、別のプロセス用に定義されている他の WIT に追加できます。

フィールドの種類

カスタマイズのサポート

継承されたフィールド

カスタム フィールド

カスタム コントロール

カスタム フィールドを追加するときは、次の制限に注意してください。

  • WIT ごとに定義できるフィールドは最大 64 個です
  • プロセスごとに定義できるフィールドは最大 512 個です

さらに、プロセス内の別の WIT に既存のフィールドを追加できます。 たとえば、ユーザー ストーリーまたはバグの WIT に期限を追加できます。

カスタマイズできない内容

  • フィールド名またはデータ型を定義した後は変更できません
  • [状態]、[理由]、[領域パス]、[反復パス] フィールドがあるフォームの灰色の領域を変更することはできません。
  • ホスト型 XML およびオンプレミスの XML プロセス モデルでサポートされているグローバル リストをインポートまたは定義することはできません。 詳細については、「グローバル リストの定義」を参照してください。
  • フィールド名またはデータ型を定義した後は変更できません
  • [状態]、[理由]、[領域パス]、[反復パス] フィールドがあるフォームの灰色の領域を変更することはできません。
  • 選択リストに関しては、現在、次の操作を実行することはできません。
    • [アクティビティ] フィールドや [規範] フィールドなど、継承されたフィールドの選択リストを変更する
    • 選択リストの順序を変更し、選択リストをアルファベット順に表示する
  • 継承されたフィールドの説明ヘルプ テキストを変更することはできません
  • ホスト型 XML およびオンプレミスの XML プロセス モデルでサポートされているグローバル リストをインポートまたは定義します。 詳細については、「グローバル リストの定義」を参照してください。

Note

継承されたプロセスでは、アクティビティ、オートメーションの状態、規範、優先順位などの定義済みフィールドの選択リストを変更することはできません。

構成可能な候補リスト

次の候補リストはプロジェクトごとに構成され、継承されたプロセスではカスタマイズできません。

担当者名フィールドに関連付けられた候補リスト (割り当て済み、変更者など) は、プロジェクトまたはチームに追加したユーザーに基づいて管理されます。

フィールドの名前を変更したり、データ型を変更したりすることはできますか?

フィールドの名前変更やデータ型の変更は、サポートされていないアクションです。 ただし、[レイアウト] タブから作業項目フォームのフィールドに表示されるラベルを変更できます。クエリでフィールドを選択する場合は、フィールド ラベルではなくフィールド名を選択する必要があります。

削除されたフィールドを削除または復元できますか?

フィールドを削除し、後で復元することができます。 フィールドを削除すると、履歴値を含め、そのフィールドに関連付けられているすべてのデータが削除されます。 一度削除すると、フィールドを復元してデータを回復するには、Fields - Update REST API を使用する必要があります。

フィールドを削除する代わりに、作業項目フォームのフィールドを非表示または削除することができます。 詳細については、「フィールドの追加と管理」、フィールドの表示、非表示、または削除を参照してください。

フィールドとは何か? フィールド名はどのように使用されるか?

各作業項目の種類は、31 個のシステム フィールドと、種類固有の複数のフィールドに関連付けられています。 作業項目は、プロジェクトの計画と追跡に使います。

各フィールドは、実行する作業に関する情報の追跡をサポートします。 フィールドに割り当てた値は、作業追跡データ ストアに格納され、それを使って、状態と傾向を判断するためのクエリを作成できます。

コア システム プロセス (スクラム、アジャイル、CMMI システム プロセス) に定義されている各フィールドの説明と使用法については、作業項目フィールドのインデックスを参照してください。

フィールド名

作業項目のフィールド名は、各作業項目フィールドを一意に識別します。 フィールド名が次のガイドラインに当てはまることを確認します。

  • フィールド名は、組織内またはプロジェクト コレクション内で一意である必要があります
  • フィールド名は、Unicode 文字で 128 文字以下にする必要があります
  • フィールド名の先頭または末尾をスペースにすること、または 2 つ以上連続するスペースを含めることはできません
  • フィールド名には、少なくとも 1 つの英字が含まれる必要があります
  • フィールド名に次の文字を含めることはできません: .,;'`:~\/\*|?"&%$!+=()[]{}<>。

すべてのフィールドは組織に対して定義されているため、組織に既に存在するか、別の継承されたプロセスで WIT に追加されたのと同じフィールド名を持つユーザー設定フィールドを追加することはできません。

Note

継承されたプロセスを使用するようにプロジェクトを変更すると、1 つ以上のアジャイル ツールまたは作業項目が無効な状態で表示されることがあります。 次に例を示します。

  • フィールドを必須にした場合、そのフィールドが未定義の作業項目にエラー メッセージが表示されます。 追加の変更を行い、作業項目を保存するには、エラーを解決する必要があります。
  • かんばんボードに表示される WIT のワークフロー状態を追加または削除または非表示にする場合は、プロジェクトで定義されているすべてのチームのかんばんボード列の構成を更新する必要があります。

カスタムルールとシステムルール

各 WIT (バグ、タスク、ユーザー ストーリーなど) には、いくつかのシステム ルールが既に定義されています。 タイトル フィールドを必須にしたり、[値領域] フィールドに既定値を設定したりするなど、シンプルなものもあります。 さらに、ワークフローの状態が変化したときに実行するアクションは、多数のシステム ルールによって定義されます。

たとえば、次の条件で現在のユーザー ID をコピーするための規則がいくつか存在します。

  • 作業項目が変更されたら、[変更者] フィールドにユーザー ID をコピーします
  • ワークフローの状態が [終了] または [完了] に変わったら、[終了者] フィールドにユーザー ID をコピーします。

重要

定義済みのシステムルールは、定義したカスタムルールよりも優先され、上書きされます。

カスタム ルールでは、さまざまなビジネス ユース ケースがサポートされるため、フィールドの既定値の設定や必須設定を超えて行うことができます。 ルールを使用すると、フィールドの値をクリアし、値をフィールドにコピーし、異なるフィールドの値間の依存関係に基づいて値を適用できます。

カスタム ルールを使用すると、特定の条件に基づいて多数のアクションを定義できます。 たとえば、次の種類のシナリオをサポートするルールを適用できます。

  • [優先度] に値が定義されている場合は、[リスク] を必須フィールドにします
  • リリースの値に変更が加えられたら、[マイルストーン] の値をクリアします。
  • Reメインing Work の値に変更が加えられた場合は、[完了作業時間] を必須フィールドにします。
  • [承認済み] の値が True の場合は、[承認済み] を必須フィールドにします。
  • ユーザー ストーリーが作成されたら、次のフィールドを必須にします。

ヒント

ルールを使用して数式を定義することはできません。 ただし、Power Automate または TFS アグリゲーター (Web サービス) Marketplace 拡張機能を使用して、ニーズに合ったソリューションを見つけることができます。 作業およびその他のフィールドのロールアップも参照してください。

カスタム ルールの定義の詳細については、「ルールとルールの評価」を参照してください。

選択ユーザー グループの選択フィールドの変更を制限する

次の 2 つの条件のいずれかを使用して、セキュリティ グループのユーザーまたはセキュリティ グループのメンバーではないユーザーに必要な選択フィールドを作成できます。

  • current user is a member of a group...
  • current user is not a member of a group...

たとえば、選択したユーザーまたはグループの [タイトル] または [状態] フィールドを読み取り専用にすることができます。

エリア パスに基づいて作業項目の変更を制限する

エリア パスに対するアクセス許可を設定することで、ユーザーが選択した作業項目を変更できないようにすることができます。 これはルール設定ではなく、アクセス許可の設定です。 詳細については、「子ノードの作成、エリア パスの下の作業項目の変更」を参照してください。

作業項目の種類 (WIT) のカスタマイズ

継承された WIT とカスタム WIT のカスタマイズ オプションを次に示します。

作業項目の種類

カスタマイズのサポート

継承された作業項目の種類

カスタム作業項目の種類

カスタマイズできない内容

  • 継承された WIT をバックログに追加したり、バックログから削除したりすることはできません
  • フォーム レイアウト内で継承されたフィールドの位置を変更することはできません (ただし、フォームの 1 つの領域のフィールドを非表示にして、フォーム内の別の場所に追加することはできます)。
  • 継承されたポートフォリオ レベルを製品から削除することはできません (ただし、名前を変更することはできます)。
  • カスタム WIT の名前を変更することはできません。

作業項目フォームのカスタマイズ

WIT フォームに対して次のカスタマイズを行うことができます。

グループまたはページの種類

カスタマイズのサポート

継承されたグループ

カスタム グループ

継承されたページ

カスタム ページ

レイアウトとサイズ変更

Web フォーム レイアウトは、次の図に示すように 3 つの列に編成されています。

Illustration of 3-column page layout for work item form.

最初の 2 つの列にのみグループとフィールドを追加する場合、レイアウトには 2 列のレイアウトが反映されます。 同様に、グループとフィールドのみを最初の列に追加する場合、レイアウトには 1 列のレイアウトが反映されます。

Web フォームは、使用可能な幅とレイアウト内の列数に応じてサイズが変更されます。 ほとんどの Web ブラウザーでは、ページ内の各列が最大幅で、独自の列内に表示されます。 表示幅が小さくなると、各列は次のように比例してサイズが変更されます。

  • 3 つの列の場合: 50%、25%、25%
  • 2 つの列の場合: 66% と 33%
  • 1 つの列の場合: 100%

表示幅がすべての列に対応できない場合、列は列内で左に積み重ねて表示されます。

ワークフローのカスタマイズ

継承された状態を非表示にするか、カスタム状態を追加することで、任意の作業項目の種類 (WIT) のワークフローをカスタマイズできます。 継承された状態は、カスタム プロセスの作成元として選択したシステム プロセス (アジャイル、基本、スクラム、または CMMI) によって異なります。

各 WIT の各既定のワークフローは、2 つから 4 つの状態の間で定義され、次のワークフロー操作を指定します。

  • 各状態間の前方および後方遷移
  • 各状態遷移の既定の理由

たとえば、基本プロセスである Issue WIT は、次の図に示す 3 つの状態 (To Do、Doing、Done) と遷移によって特徴付けられます。

Basic Process, Issue work item type, workflow state model

状態の種類

サポートされているカスタマイズ

Inherited icon 継承された状態

カスタム状態

ワークフローの状態は、次の規則に準拠している必要があります

  • 提案済みまたは進行中のいずれかの状態カテゴリに少なくとも 1 つの状態を定義する必要があります。

    Note

    ワークフロー状態を追加する前に、ワークフローの状態と状態カテゴリを確認して、ワークフローの状態が状態カテゴリにどのようにマップされるかを確認します。

  • 少なくとも 2 つのワークフロー状態を定義する必要があります
  • 作業項目の種類ごとに最大 32 個のワークフロー状態を定義できます

サポートされていないワークフローのカスタマイズ

  • 継承された状態を変更することはできません (名前、色、またはカテゴリを変更することはできません)、非表示にすることはできます
  • 完了状態カテゴリには、状態を 1 つだけ指定できます。 [完了] カテゴリにカスタム状態を追加すると、その他の状態は削除または非表示になります。
  • カスタム状態の名前を変更することはできません
  • 状態の理由を指定することはできません。代わりに、既定の理由 (状態トリアージドに移動、状態トリアージ解除など) が定義されています
  • フォームの [状態] フィールドと [理由] フィールドの場所を変更することはできません
  • 状態カテゴリ名をカスタマイズすることはできません
  • 継承された状態を変更することはできません (名前、色、またはカテゴリを変更することはできません)、非表示にすることはできます
  • 完了状態カテゴリには、状態を 1 つだけ指定できます。 システムでは、このカテゴリにカスタム状態を追加できません
  • カスタム状態の名前を変更することはできません
  • 状態の順序を変更することはできません。状態は、作業項目フォームのドロップダウン リスト内の状態カテゴリに基づいて自然な順序で一覧表示されます
  • 状態の理由を指定することはできません。代わりに、既定の理由 (状態トリアージドに移動、状態トリアージ解除など) が定義されています
  • フォームの [状態] フィールドと [理由] フィールドの場所を変更することはできません
  • 遷移を制限することはできません。すべての遷移は、任意の状態から別の状態に定義されます。

バックログとボードのカスタマイズ

バックログとボードは、チームの作業を作成および管理するための不可欠なアジャイル ツールです。 システム プロセスから継承された標準のバックログ (製品、イテレーション、ポートフォリオ) は完全にカスタマイズできます。 さらに、合計で 5 個のポートフォリオ バックログにカスタムのポートフォリオ バックログを追加できます。

バックログの種類

カスタマイズのサポート

継承されたバックログ

カスタム ポートフォリオ バックログ

カスタマイズできない内容

  • 製品から継承されたポートフォリオ レベルを削除することはできません (ただし、ポートフォリオ レベルの名前を変更したり、継承した作業項目の種類を無効にしたりできます)
  • 定義済みのバックログの既存のセット内にバックログ レベルを挿入することはできません
  • バックログ レベルを並べ替えることはできません
  • 2 つの異なるバックログ レベルに作業項目の種類を追加することはできません
  • カスタム タスク バックログ レベルを作成することはできませんが、イテレーション バックログにカスタム WIT を追加することはできます。
  • バックログ レベルに バグ WIT を追加することはできません。 代わりに、各チームがバグを管理する方法を決定できます。 詳細については、「バックログとボードにバグを表示する」を参照してください。
  • 継承された WIT をバックログに追加または削除することはできません。たとえば、製品のバックログに問題 WIT を追加することはできません
  • 製品から継承されたポートフォリオ レベルを削除することはできません (ただし、ポートフォリオ レベルの名前を変更したり、継承した作業項目の種類を無効にしたりできます)
  • 定義済みのバックログの既存のセット内にバックログ レベルを挿入することはできません
  • バックログ レベルを並べ替えることはできません
  • 2 つの異なるバックログ レベルに作業項目の種類を追加することはできません
  • カスタム タスク レベルを作成することはできませんが、イテレーション バックログにカスタム作業項目の種類を追加することはできます。
  • バックログ レベルに バグ WIT を追加することはできません。 代わりに、各チームがバグを管理する方法を決定できます。 詳細については、「バックログとボードにバグを表示する」を参照してください。

Note

一部の機能では、Azure DevOps Server 2020.1 更新プログラムのインストールが必要です。 詳しくは、Azure DevOps Server 2020 Update 1 RC1 リリース ノートの Boards に関する説明をご覧ください。

バックログ レベルの既定の WIT を変更すると、その WIT がクイック追加パネルに既定で表示されます。 たとえば、顧客チケットは、製品バックログの次のクイック 追加パネルに既定で表示されます。

Screenshot of Product backlog, Quick Add Panel, Displays Default WIT for a backlog level

オブジェクト制限

カスタマイズできるフィールド、WIT、バックログ レベル、およびその他のオブジェクトの数に設定されている制限の一覧については、「Work Tracking オブジェクトの制限」を参照してください。