作業追跡エクスペリエンスをカスタマイズする

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

プロジェクトを計画して追跡するときは、チームの追跡要件に合わせて機能を構成するか、エクスペリエンスをカスタマイズすることを検討してください。 すべてのチームに影響を与えるプロジェクトをカスタマイズする方法は、使用するプロセス モデルによって異なります。

この記事では、使用可能なカスタマイズの概要と、3 つのプロセス モデル間でのカスタマイズの違いについて説明します。 ビジネス上の意思決定をサポートするためのカスタマイズに関する具体的なガイダンスについては、「 Azure Boards の構成とカスタマイズ」を参照してください。 詳細については、「 Azure Boards とは と 作業項目についてを参照してください。

カスタマイズ レベルについて

作業の追跡は、次のレベルでカスタマイズできます。

カスタマイズのスコープと影響

各カスタマイズ レベルのスコープを理解することは、情報に基づいた意思決定を行うのに役立ちます。

プロジェクト レベルの共有リソース

各プロジェクトは、プロジェクト内のすべてのチームをサポートする多くの共有リソースを提供します。 これらの機能は、Web ポータルのユーザー インターフェイスまたは管理者コンテキストを使用して構成します。

コア共有リソース

次の共有リソースは、プロジェクトの作業追跡の基礎を形成します。

• エリア パス: 機能領域またはチームの責任別に作業項目を整理する
• イテレーション パス: 計画と追跡のためのスプリントとリリースを定義する
• 共有クエリ: すべてのチーム メンバーがアクセスできる再利用可能なクエリを作成する
• 作業項目タグ: 分類とフィルター処理のメタデータを追加する
• セキュリティ グループ: プロジェクト全体のアクセス許可を管理する

詳細については、次の記事をご覧ください。

• 領域と反復パスについて
• 区分パスの設定
• イテレーション パスの選択リストを変更する
• クエリの作成と編集
• 作業項目にタグを追加する

共有リソースのベスト プラクティス

• エリア パスを早期に計画する: チームの所有権と製品組織を反映するようにエリア パス構造を設計する
• イテレーションの周期を確立する: 一貫したスプリント長とリリース スケジュールを設定する
• フォルダー構造の作成: フォルダー内の共有クエリを整理して見つけやすくする
• わかりやすいタグを使用する: 一貫性のあるメタデータのタグ付け規則を確立する
• アクセス許可を定期的に確認する: すべてのチーム メンバーに適切なアクセス レベルを確保する

ユーザー 選択ウィンドウと ID フィールド

ユーザー選択機能では、Azure DevOps 全体の ID フィールドがサポートされています。

• [割り当て先] フィールド とその他 の [ID] フィールドでは、ユーザー選択機能が使用されます。
• アクティブ化: 作業項目フォーム内で [ 割り当て済み ] フィールドを選択すると、ユーザー選択ウィンドウが自動的にアクティブ化されます。
• ユーザーの選択: ユーザーを選択するには、名前の入力を開始し、一致するものが見つかるまで検索します。
• 最近選択した項目: 以前に選択したユーザーが一覧に自動的に表示され、すばやくアクセスできます。
• ディレクトリ統合: Microsoft Entra ID または Active Directory を使用する組織の場合、ユーザー 選択ウィンドウでは、ディレクトリに追加されたすべてのユーザーとグループを検索できます (特定のプロジェクトに追加されたユーザーとグループのみではありません)。
• スコープの制限: 選択に使用できる ID のスコープをプロジェクト固有のユーザーに制限するには、 Project-Scoped Users グループを使用します。
• カスタム制限: カスタム ルールでは、作業項目内の ID フィールドで使用できる値をさらに制限できます。

ID フィールドの構成

ID フィールドは、いくつかの方法で構成できます。

• プロジェクト スコープ ユーザー: ID の選択をプロジェクト メンバーのみに制限する
• カスタム ルール: フィールド値を制限するビジネス ルールを実装する
• グループベースの制限: Azure AD グループを使用して使用可能な ID を制御する
• フィールド レベルのアクセス許可: ID フィールドを変更できるユーザーを設定する

詳細については、次の記事をご覧ください。

• Active Directory/Microsoft Entra ユーザーまたはグループを組み込みのセキュリティ グループに追加。

プロジェクトでは、作業の追跡に使用できる作業項目の種類 (WIT) を定義し、アジャイル ツールを構成します。 ユーザー ストーリー、タスク、バグ、および情報のキャプチャに使用されるデータ フィールドを指定します。 カスタマイズされたオブジェクトは、プロジェクト内のチーム間で共有されます。

プロセス モデルの比較

次の表は、サポートされている 3 つのプロセス モデルの違いをまとめたものです。 主な作業追跡オブジェクトの定義については、 Agile 用語集を参照してください。 カスタマイズに関する記事へのリンクについては、「azure Boards 設定の Quick リファレンス インデックスを参照してください。

プロセス モデルの選択ガイダンス

組織のニーズに基づいてプロセス モデルを選択します。

継承プロセス モデル (推奨)

• 最適: 直感的な Web ベースのカスタマイズが必要な Teams
• 利点:WYSIWYG編集、自動更新、簡単なメンテナンス
• 用途: 複雑さを最小限に抑えて中程度のカスタマイズが必要な場合

ホストされた XML プロセス モデル

• 最適: 複雑なプロセス要件を持つ組織
• 利点: 完全なプロセス テンプレート制御、広範なカスタマイズ
• 用途: 高度なプロセスのカスタマイズが必要だが、クラウド ホスティングが必要な場合

オンプレミスの XML プロセス モデル

• 最適な用途:完全なコントロールが要求されるオンプレミスのデプロイメント
• 利点: 完全なカスタマイズの柔軟性、エンタープライズ統合
• 使用するタイミング: 最大制御が必要で、オンプレミスインフラストラクチャを実行する

注:

1. プロセスによって、作業の追跡に使用される構成要素が決定されます。 プロセス テンプレートは、作業やその他の機能領域を追跡するための構成要素と初期構成を提供する、相互依存に関連する XML 定義ファイルのセットを指定します。
2. ホスト型 XML カスタマイズでは、プロセス更新によるグローバル リストの追加と更新がサポートされます (各リストの最大サイズに制限があります)。 詳細については、「 Work 追跡オブジェクトの制限」を参照してください。
3. 継承されたプロセス モデルでは、プロセス テンプレートのカスタマイズで使用できる次の機能のカスタマイズはサポートされていません。 代わりに、Web ポータル内でプロジェクトごとにこれらの領域をカスタマイズします。
   • 区分パスとイテレーション パス
   • 作業項目クエリ
   • セキュリティ グループとアクセス許可
   • バージョン管理やビルドなどの機能領域へのアクセス許可とアクセス
   または、 REST API を使用できます。
   または、 REST API Azure DevOps CLI コマンド ツール を使用。
4. REST API を使用して、プロセス テンプレート インポートおよびエクスポートします。

テスト エクスペリエンスをカスタマイズする

いくつかの作業項目の種類は、Web ポータル Test ページとテスト マネージャー クライアント内のテスト エクスペリエンスをサポートします。

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

継承されたプロセスの場合は、他の作業項目の種類と同様に、次の作業項目の種類をカスタマイズできます。

• テスト計画: テストスイートを整理および管理する
• テスト スイート: グループ関連のテスト ケース
• テスト ケース: 個々のテスト シナリオを定義する

オンプレミスの XML カスタマイズ

オンプレミスの XML プロセスでは、次のようなテスト関連のすべての作業項目の種類をカスタマイズできます。

• テスト計画: 高度なテスト組織
• テスト スイート: テスト ケースのグループ化
• テスト ケース: 個々のテスト定義
• 共有ステップ: 再利用可能なテスト 手順
• 共有パラメーター: パラメーター化されたテスト データ

作業項目のリレーションシップをテストする

次の例は、テスト作業項目の種類間でサポートされているリンク関係を示しています。

カスタマイズ シナリオをテストする

一般的なテスト エクスペリエンスのカスタマイズは次のとおりです。

• カスタム テスト フィールド: 組織固有のテスト メタデータを追加する
• テスト ワークフローの状態: カスタム テストの実行状態を定義する
• テスト結果の追跡: テスト結果レポートをカスタマイズする
• 統合フィールド: 要件と欠陥を含むテストを接続する

あまり一般的ではないカスタマイズ

次のカスタマイズは、ホストされた XML またはオンプレミスの XML プロセス モデルを使用する場合にのみ実行できます。 プロセス構成に対して行われたカスタマイズは、プロジェクト内のすべてのチームに適用されます。

バックログとボードの制限 (ホステッド XML、オンプレミス XML)

表示の読み込み時間を許容可能なパラメーターに制限するために、タスク ボードは最大 1,000 個の作業項目に制限されます。 詳細については、 Process 構成 XML 要素リファレンスを参照してください。

workItemCountLimit 要素の属性の値を指定することで、この値を最大 1500 まで増やすことができます。 詳細については、 Process 構成 XML 要素リファレンスを参照してください。

<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="800" >
    . . .
</TaskBacklog>

ボード制限のパフォーマンスに関する考慮事項

ボードの制限をカスタマイズする場合は、次の点を考慮してください。

• 読み込み時間への影響: 制限を大きくすると、ページの読み込み時間が長くなる可能性があります
• ユーザー エクスペリエンス: 機能とパフォーマンスのバランスを取る
• ブラウザーの制限事項: 一部のブラウザーでは、大きなデータセットの処理方法が異なります
• ネットワーク帯域幅: 接続が遅いチーム メンバーを検討する

フィールドの割り当てを変更する (ホステッド XML、オンプレミス XML)

能力、バーンダウン チャート、予測、速度の計算でシステムが使用する作業項目フィールドを変更できます。 既定の割り当てのいずれかに対して行った変更は、その値の情報を定義およびキャプチャするために使用される WIT に加えられた変更に対応する必要があります。

たとえば、refnameに割り当てられているtype="Activity"を変更する場合は、アクティビティ情報をキャプチャするタスク カテゴリに割り当てられている WIT 定義に同じフィールドを含める必要があります。 詳細については、 Process 構成 XML 要素リファレンスを参照してください。

フィールドの割り当てを使用するツール

割り当てるフィールドは、次のツールで使用されます。

フィールド割り当てのベスト プラクティス

• 整合性を維持する: フィールドの割り当てが作業項目の種類の定義と一致していることを確認する
• 変更のテスト: フィールドの再割り当て後にツールが正しく動作することを検証する
• ドキュメントのカスタマイズ: フィールドの割り当ての変更を後で参照するために記録する
• 影響を考慮する: 変更が既存のデータとレポートにどのように影響するかを理解する

作業追跡ツールへのアクセスを管理する

アクセス許可の設定を使用して、特定の機能へのアクセスを管理します。 チームにユーザー アカウントを追加すると、共同作成者グループに自動的に追加されます。 その後、コード、作業の追跡、ビルド、テストに貢献するために必要なほとんどの機能にアクセスできます。 ただし、共同作成者グループでは、ユーザーが共有クエリを作成したり、領域または反復パスを追加したりすることはできません。 これらのアクセス許可を個別に付与する必要があります。

既定のアクセス許可構造

アクセス許可システムは、次の原則に基づいて動作します。

• 既定のアクセス: 新しいチーム メンバーが 自動的に共同作成者 グループに参加する
• コア アクセス許可: 共同作成者 グループは、開発作業に必要なほとんどの機能にアクセスできます
• 追加のアクセス許可: 一部の機能では、個別のアクセス許可付与が必要です
• 管理アクセス: プロジェクト管理者はアクセス許可を完全に制御できます

共同作成者グループの制限事項

共同作成者グループは、ユーザーが次のことを自動的に許可しません。

• 共有クエリを作成する: 追加のクエリアクセス許可が必要
• 領域または反復パスを追加する: プロジェクト レベルの管理アクセス許可が必要
• セキュリティ設定の変更: 管理アクセスが必要
• チーム設定の構成: チーム管理者の役割が必要

アクセス許可管理のアプローチ

アクセス許可を効果的に管理するには:

1. 既定値から始める: 組み込みのグループを基礎として使用する
2. 特定のアクセス許可を付与する: 特定のニーズに対するアクセス許可を追加する
3. セキュリティ グループの使用: Azure AD グループを活用して管理を容易にする
4. 定期的なレビュー: 権限の適切性を定期的に監査する
5. ドキュメントの決定: アクセス許可付与と根拠の記録を保持する

一般的な既定のアクセス許可とアクセスの割り当ての簡単な概要については、「 Permissions and accessを参照してください。

アクセス許可の管理が初めての場合は、 アクセス許可とセキュリティ グループの概要、およびアクセス許可の継承に関するセクションを参照してください。

特定のアクセス許可領域

特定の機能へのアクセスを管理するには、次の記事を参照してください。

その他のカスタマイズ オプション

組み込みのカスタマイズ機能以外に、Azure DevOps 機能を拡張するための次の追加オプションを検討してください。

Marketplace 拡張機能

• ソリューションを参照する: Marketplace 拡張機能 を確認して、目的に合ったツールがあるかどうかを確認する
• 一般的なカテゴリ: 作業の追跡、レポート、プロジェクト管理で拡張機能を探す
• コミュニティへの貢献: Azure DevOps コミュニティによって開発されたソリューションの恩恵を受ける

カスタム開発オプション

• 拡張機能の構築: 特定の組織のニーズに合 わせて独自の拡張機能を開発 する
• 統合ツール: REST API を使用してカスタム統合を作成する
• サービス フック: サービス フック が自動化のニーズを満たすかどうかを判断する

コミュニティエンゲージメント

• 機能要求: 開発者コミュニティ ページに機能要求を追加する
• ユーザー フィードバック: 製品チームとエクスペリエンスと提案を共有する
• ベスト プラクティス: 他の組織のカスタマイズ アプローチから学習する

カスタマイズ戦略の計画

カスタマイズを実装する前に、次のことを検討してください。

1. ビジネス要件: 達成する内容を明確に定義する
2. 影響評価: 変更が既存のワークフローにどのように影響するかを理解する
3. メンテナンスのオーバーヘッド: カスタマイズを維持するための長期的なコストを考慮する
4. 代替ソリューション: 既存の機能がニーズを満たしているかどうかを評価する
5. 移行パス: 今後の更新と移行を計画する

次のステップ

関連記事

• 作業項目フィールドのインデックス
• witAdmin コマンド ライン ツール
• プロセス テンプレートを管理する
• プロセス テンプレートの概要
• 作業の追跡、処理、およびプロジェクトの制限
• Azure Boards 設定のクイック リファレンス インデックス