次の方法で共有

プロセスのカスタマイズと継承

Azure DevOps サービス

組織のニーズに合わせて Azure DevOps 作業追跡システムを調整するには、組織の設定を使用して継承されたプロセスをカスタマイズできます。 継承されたプロセスを使用する組織内のすべてのプロジェクトは、そのプロセスに対して行ったカスタマイズを取得します。 その後、各プロジェクト チーム のプロジェクト バックログ、スプリント、ボード を構成できます。

重要

この記事は、Azure DevOps Services の継承プロセス モデルにのみ適用されます。 オンプレミス のプロジェクトをカスタマイズしたり、XML 定義ファイルを更新したりするには、「 ホストされた XML プロセス モデル 」および「 ホスト型 XML プロセスのカスタマイズ」を参照してください。

継承されたプロセスに対していくつかのカスタマイズを行うことができます。 最も重要なものは、カスタム作業項目の種類 (WIT) を作成するか、既存の WIT を変更してユーザー設定フィールドを追加したり、レイアウトを変更したり、ワークフローを変更したりすることです。 継承された要素の一部のオプションはロックされており、カスタマイズできません。

この記事では、継承されたプロセスをカスタマイズする方法の概要について説明します。 カスタマイズできるフィールド、WIT、バックログ レベル、およびその他のオブジェクトの数に関する制限については、「 作業の追跡、プロセス、およびプロジェクトの制限」を参照してください。

Note

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

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

アジャイル、Basic、スクラム、および機能成熟度モデル統合 (CMMI) はロックされ、ユーザーは変更できません。 Microsoft はこれらのシステム プロセスを所有し、定期的に更新します。

継承されたプロセス はシステム プロセスからカスタマイズされ、基になっているシステム プロセスから定義を継承します。 Microsoft がシステム プロセスに対して行う更新は、継承されたプロセスとその子継承プロセスで自動的に更新されます。

組織内のすべてのプロジェクトは、そのすべてのプロセスを共有できます。 1 つのプロジェクトをカスタマイズする代わりに、プロセスをカスタマイズします。

継承されたプロセスを作成したら、それをカスタマイズし、コピーし、それに基づいてプロジェクトを作成し、既存のプロジェクトを変更して使用することができます。 継承されたプロセスに対して行った変更により、そのプロセスを使用する組織内のすべてのプロジェクトが自動的に更新されます。

次の例は、 fabrikamprime 組織内のプロジェクトの一覧と、各プロジェクトが使用するプロセスを示しています。 Fabrikam Fiber プロジェクトのカスタマイズを変更するには、アジャイル システム プロセスを継承するマイ アジャイル プロセスを変更します。 マイ アジャイル プロセスに加えた変更は、そのプロセスを使用するアジャイル バイ デザインプロジェクトにも反映されます。 他のプロジェクトをカスタマイズするには、継承されたプロセスを使用するように変更する必要があります。

プロジェクトと使用するプロセスのスクリーンショット。

既存のプロジェクトのプロセスを変更する

プロジェクトが使用するプロセスを、あるプロセスから別のプロセスに切り替えることができます。 詳細と手順については、次の記事を参照してください。

リストされている記事の一般的なガイダンスに従うことで、CMMI からアジャイル、アジャイルから CMMI への変更など、他の変更を行うことができます。 プロジェクト プロセスを変更する前に、変更するプロセスを理解しておいてください。 詳細については、 プロセスとプロセス テンプレートの概要に関する記事を参照してください。

プロジェクトを別のプロセスに移行すると、一部の既存のツールまたは作業項目が無効になる可能性があります。 たとえば、新しいプロセスで必要なフィールドがない作業項目にエラーが表示される場合があります。 変更を続行して作業項目を保存するには、これらのエラーを解決する必要があります。 プロセスの変更で、ボードに表示される WIT のワークフロー状態を追加、削除、または非表示にする場合は、プロジェクトで定義されているすべてのチームのボード列の構成を必ず更新してください。

継承されたプロセスを変更または名前変更する

継承されたプロセスの変更は簡単ですが、アクティブなプロジェクトに適用する前に変更をテストすることをお勧めします。 プロセスをコピーし、コピーしたプロセスに変更を加えて、既存のプロジェクトに影響を与えないようにし、プロセス変更の悪影響を回避できます。

継承されたプロセスの名前を変更するには 、[組織の設定] でプロセス名の横にある [その他のアクション ] アイコンを選択し、[ 編集] を選択します。

プロセス名

プロセス名には、次の要件があります。

  • 組織内で一意である必要があります
  • 128 文字以下の Unicode 文字を使用する必要があります
  • 次の文字を含めることはできません。 .,;':~\/*|?"&%$!+=()[]{}<>

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

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

継承されたプロセスの [作業項目の種類] ページに表示されるすべての WIT のフィールドを追加したり、ワークフローフォームと 作業項目 フォームを変更したりできます。 カスタム WIT を追加することもできます。

継承されたプロセス WIT に基づいてユーザーが新しい作業項目を作成しないようにするには、[組織の設定] の WIT 名の横にある [その他のアクション] アイコンを選択し、コンテキスト メニューから [無効] を選択します。

作業項目フィールド

このセクションでは、作業項目フィールドについて説明します。

フィールドとフィールド参照

作業項目を使用して、プロジェクトの計画と追跡を行います。 各作業項目の種類は、31 個のシステム フィールドと、作業項目に関する追跡情報を提供するいくつかの種類固有のフィールドに関連付けられています。 フィールドに割り当てる値は作業追跡データ ストアに格納され、クエリを実行して状態と傾向を判断できます。

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

フィールド名

作業項目のフィールド名は、各作業項目フィールドを一意に識別します。 フィールド名が次の要件を満たしていることを確認します。

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

フィールド名と定義は組織全体に適用されます。 組織内に既に存在するフィールド名を持つフィールドや、WIT に追加された別の継承されたプロセスを含むフィールドを追加することはできません。

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

フィールドは、組織内のすべてのプロジェクトとプロセスに対して定義されます。 継承されたプロセスは、システム プロセスで定義されているフィールドを継承し、それらに限られた変更を加えることができます。 継承されたプロセスでユーザー設定フィールドを作成および変更できます。

あるプロセスで WIT に対して定義した任意のユーザー設定フィールドを、別のプロセス用に定義されている任意の WIT に追加できます。 同じプロセス内 で既存のフィールドを別の WIT に追加 することもできます。 たとえば、ユーザー ストーリーまたはバグ WIT に期限を追加できます。

フィールドとコントロールをカスタマイズする

次のリソースでは、継承されたフィールド、ユーザー設定フィールド、またはカスタム コントロールのさまざまなカスタマイズを実装する方法について説明します。

継承されたフィールド

カスタム フィールド

カスタム コントロール

削除されたフィールドを削除または復元する

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

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

制限事項

  • フィールド名またはデータ型を定義した後は変更できません。 ただし、[ レイアウト ] タブから作業項目フォームのフィールドに表示されるラベルを変更できます。クエリでフィールドを選択する場合は、フィールド ラベルではなくフィールド名を使用する必要があります。
  • [状態]、[理由]、[領域パス]、[反復パス] の各フィールドを含むフォームの灰色の領域を変更することはできません。
  • エリア パスと反復パスの選択リストは、プロジェクトごとに構成され、継承されたプロセスを通じてカスタマイズすることはできません。
  • [ 割り当て済み ] や [ 変更者] などのユーザー ID フィールドに関連付けられている選択リストは、 プロジェクトまたはチームに追加されたユーザーに基づいて設定されます。
  • WIT ごとに最大 64 個のフィールドを定義でき、プロセスごとに最大 512 個のフィールドを定義できます。
  • ホスト型 XML およびオンプレミスの XML プロセス モデルでサポートされているグローバル リストをインポートまたは定義することはできません。

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

各 WIT には、 タイトル フィールドの要求や [値領域 ] フィールドの既定値の設定など、いくつかのシステム ルールが定義されています。 システム ルールでは、ワークフローの状態が変化したときに実行するアクションも定義されます。

たとえば、作業項目が変更されるときに、複数のルールで現在のユーザー ID が変更者フィールドにコピーされ、ワークフローの状態が終了または完了に変わる際には閉じた人フィールドにコピーされます。 定義済みのシステムルールは、上書きされるカスタムルールよりも優先されます。

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

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

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

カスタム ルールの定義の詳細については、「 作業項目の種類にルールを追加する (継承プロセス)」を参照してください。

ヒント

ルールを使用して数式を定義することはできません。 ただし、 Power Automate ではニーズに合ったソリューションが見つかる場合があります。 詳細については、 作業およびその他のフィールドのロールアップを参照してください。

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

条件 current user is a member of a group... または current user is not a member of a group...を使用すると、グループまたはセキュリティ グループのメンバーまたはメンバー以外のユーザーに対して、選択したフィールドを要求または構成できます。 たとえば、選択したユーザーまたはグループの [タイトル ] または [状態 ] フィールドを読み取り専用にすることができます。

領域パスに基づいて作業項目の変更を制限する

チーム領域パスごとに作業項目の単一所有権を維持するか、チーム間で共有されるカスタム状態で列を形式化することを検討してください。

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

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

次のリソースでは、継承された WIT とカスタム 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) のワークフローをカスタマイズできます。 継承された状態は、カスタム プロセス (アジャイル、Basic、スクラム、または機能成熟度モデル統合 (CMMI) の作成に使用されるシステム プロセスによって異なります。 詳細については、「 ワークフローの状態、遷移、および理由を参照してください。

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

  • 各状態間の前方および後方遷移。 たとえば、基本的なプロセス の問題 WIT には、 To Do、 Doing、 Done の 3 つの状態が含まれています。
  • 各状態遷移の既定の理由。

継承されたワークフローとカスタム ワークフローは、次の規則に準拠している必要があります。

  • 少なくとも 2 つのワークフロー状態を定義します。
  • 提案中または進行中の状態カテゴリに、少なくとも1つの状態を定義してください。
  • 作業項目の種類ごとに最大 32 個のワークフロー状態を定義します。

Note

カスタム ワークフロー状態を追加する前に、「 バックログとボードのワークフロー状態について 」を参照して、ワークフローの状態がカテゴリにどのようにマップされるかを確認してください。

継承されたワークフロー状態とカスタム ワークフローの状態のカスタマイズについては、次のリソースを参照してください。

継承された状態

カスタム状態

制限事項

  • 継承された状態の名前、色、またはカテゴリを変更することはできませんが、表示したくない場合は非表示にできます。
  • 定義したカスタム状態の名前は変更できません。
  • 既定の状態カテゴリ名を変更またはカスタマイズすることはできません。
  • 完了状態カテゴリに存在できる状態は 1 つだけです。 このカテゴリにカスタム状態を追加すると、そのカテゴリの他の状態が削除または非表示になります。
  • 状態遷移のカスタム 理由を 指定することはできません。 既定の理由 ( [状態トリアージ済みに移動] や [状態トリアージ解除 ] など) を使用します。
  • 作業項目フォームの [状態 ] フィールドと [ 理由 ] フィールドの配置を変更することはできません。

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

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

継承されたポートフォリオバックログとカスタムポートフォリオバックログのカスタマイズの詳細については、次のリソースを参照してください。

継承されたバックログ

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

制限事項

  • 継承されたポートフォリオ レベルを製品から削除することはできません。 レベルの名前を変更するか、WIT を無効にして、チームがこれらの種類の新しい作業項目を作成できないようにすることができます。
  • 定義済みのバックログの既存のセット内に新しいカスタム バックログ レベルを挿入することはできません。 定義済みのバックログ レベルは通常、 エピック、 機能、 ユーザー ストーリー、 タスクなど、固定されています。
  • バックログ レベルを並べ替えることはできません。 通常、これらは定義済みの階層に従っており、順序の変更はサポートされていません。
  • 2 つの異なるバックログ レベルに WIT を追加することはできません。 各 WIT は、1 つのバックログ レベルにのみ属できます。
  • カスタム タスク固有のバックログ レベルを作成することはできませんが、カスタム WIT をイテレーション バックログに追加することはできます。 たとえば、 Enhancement または Maintenance というカスタム WIT を作成し、それをイテレーション バックログに関連付けることができます。
  • バグ WIT は、既定では特定のバックログ レベルに属していません。 各チームは、バグを管理する方法を決定できます。 バックログとボードにバグを表示するか、個別に処理することができます。 詳細については、「 バックログのバグを表示する」を参照してください。

関連コンテンツ

  • Last updated on