次の方法で共有

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

  • [アーティクル]

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

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

重要

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

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

Note

監査ログを使用して、継承されたプロセスに加えられた変更を確認します。 詳細については、「 アクセス、エクスポート、およびフィルター監査ログを参照してください。

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

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

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

  • ロックされたアイコン システム プロセス —Agile、Basic、Scrum、CMMI— は変更されません。
  • 継承されたアイコン 継承されたプロセス。カスタマイズでき、作成元のシステム プロセスから定義を継承します。 システム プロセスは、Microsoft によって定期的に所有および更新されます。 システム プロセスに対して行われた更新により、継承されたプロセスとその子継承プロセスが自動的に更新されます。 プロセスの更新については、 Azure DevOps Server のリリースノートに記載されています。

Note

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

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

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

管理者コンテキスト、組織の設定、プロジェクトの一覧、および使用するプロセスのスクリーンショット。

プロセス名の制限

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

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

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

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

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

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

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

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

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

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

アジャイル プロセス作業項目階層の概念図。

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

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

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

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

フィールドの種類

カスタマイズのサポート

継承されたフィールド

カスタム フィールド

カスタム コントロール

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

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

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

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

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

Note

継承されたプロセスでは、定義済みのフィールドの候補リスト ( Activity、 Automation Status、 Discipline、 Priority など) を変更することはできません。

構成可能な候補リスト

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

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

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

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

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

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

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

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

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

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

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

フィールド名

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

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

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

Note

プロジェクトを継承したプロセスに移行すると、次の例に従ってアジャイル ツールまたは作業項目が無効な状態になる可能性があります。

  • 必要に応じてフィールドを指定すると、そのフィールドがない作業項目にエラー メッセージが表示されます。 さらに変更を進め、作業項目を保存するには、これらのエラーを解決します。
  • ボードに表示される WIT のワークフロー状態を追加、削除、または非表示にする場合は、プロジェクトで定義されているすべてのチームのボード列の構成を必ず更新してください。 また、チーム領域パス別に作業項目の単一所有権を維持するか、カスタム状態で列を形式化してチーム間で共有することを検討してください。

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

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

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

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

重要

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

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

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

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

ヒント

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

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

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

次の 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 つの列に編成されています。

作業項目フォームの 3 列ページ レイアウトの図。

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

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

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

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

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

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

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

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

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

基本プロセス、作業項目の種類の発行、ワークフロー状態モデル

状態の種類

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

継承されたアイコン 継承された状態

カスタム状態

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

  • Proposed または In Progress State カテゴリに少なくとも 1 つの状態を定義する必要があります

    Note

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

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

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

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

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

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

バックログの種類

カスタマイズのサポート

継承されたバックログ

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

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

  • 継承されたポートフォリオ レベルの削除:
    • 継承されたポートフォリオ レベルを製品から直接削除することはできませんが、いくつかのオプションがあります。
      • ポートフォリオ レベルの名前を変更する: 継承したポートフォリオ レベルの名前をニーズに合わせて変更できます。
      • 継承された WIT: 継承されたポートフォリオ レベルに使用しない WIT が含まれている場合は、無効にすることができます。 このアクションにより、チームはこれらの種類の新しい作業項目を作成できなくなります。
  • バックログ レベルの挿入:
    • 定義済みのバックログの既存のセット内に新しいバックログ レベルを挿入することはできません。 定義済みのバックログ レベルは通常固定されており (エピック、機能、ユーザー ストーリー、タスクなど)、その間にカスタム のバックログ レベルを追加することはできません。
  • バックログ レベルの並べ替え:
    • 残念ながら、バックログ レベルを並べ替えることはできません。 通常、これらは定義済みの階層に従っており、順序の変更はサポートされていません。
  • 複数のバックログ レベルに WIT を追加する:
    • 各 WIT は、1 つのバックログ レベルにのみ属できます。 2 つの異なるバックログ レベルに WIT を同時に追加することはできません。
  • カスタム タスク バックログ レベルの作成:
    • カスタム タスク固有のバックログ レベルを作成することはできませんが、カスタム WIT をイテレーション バックログに追加することはできます。 たとえば、"Enhancement" または "Maintenance" というカスタム WIT を作成し、それをイテレーション バックログに関連付けることができます。
  • バグの管理:
  • バックログからの継承された WIT の追加または削除:
    • 継承された WIT をバックログに直接追加したり、バックログから削除したりすることはできません。 たとえば、製品バックログへの "問題" WIT の追加はサポートされていません。
    • ただし、次のことができます。
      • ポートフォリオ レベルの名前を変更する: 継承されたポートフォリオ レベルに使用しない WIT が含まれている場合は、ニーズに合わせて名前を変更することを検討してください。
      • 継承された WIT: を無効にする:除外する継承された WIT がある場合は、それらを無効にすることができます。 このアクションにより、チームはこれらの種類の新しい作業項目を作成できなくなります。
  • 継承されたポートフォリオ レベルの削除:
    • 継承されたポートフォリオ レベルを製品から削除することはできませんが、次の 2 つのオプションがあります。
      • ポートフォリオ レベルの名前を変更する: より適切な名前を付けます。
      • 継承された WIT を無効にする: チームが特定の継承された WIT を使用できないようにします。
  • バックログ レベルの挿入:
    • 残念ながら、定義済みのバックログの既存のセット内に新しいバックログ レベルを挿入することはできません。 定義済みのバックログ レベル (エピック、機能、ユーザー ストーリー、タスクなど) は固定されたままです。
  • バックログ レベルの並べ替え:
    • バックログ レベルは通常、定義済みの階層に従っており、順序の変更はサポートされていません。 並べ替えはできません。
  • 複数のバックログ レベルに WIT を追加する:
    • 各 WIT (バグ、タスク、ユーザー ストーリーなど) は、1 つのバックログ レベルにのみ属できます。 2 つの異なるバックログ レベルに WIT を同時に追加することはできません。
  • カスタム タスク レベルの作成:
    • カスタム タスク固有のバックログ レベルを作成することはできませんが、カスタム WIT をイテレーション バックログに追加することはできます。 たとえば、"Enhancement" または "Maintenance" という名前のカスタム WIT を作成し、それをイテレーション バックログに関連付けます。
  • バグの管理:

Note

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

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

製品バックログ、クイック追加パネル、バックログ レベルの既定の WIT を表示するスクリーンショット

オブジェクト制限

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