次世代プロジェクトで利用可能なワークフロー ルール

次世代プロジェクトでワークフロー ルールを追加または削除する

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

robotsnoindex

descriptionここでは、チーム管理対象プロジェクト ワークフローに追加できるルールについて詳述します。この参照によって、作業プロセスを合理化して反復的なアクションを自動化できます。

このヘルプ ページの内容について

The following information only applies to team-managed projects.

どのタイプのプロジェクトの情報を参照すべきかを確認するには、プロジェクトの左側のサイドバーの下部をご覧ください。

This page describes each of the workflow rules you can add to your team-managed projects and gives an example of why you might want to use one. Learn how to add a rule to your team-managed project's workflow.

課題を誰かに割り当てる

このルールを設定すると、適切なユーザーが、適切なタイミングで適切な課題に取り組むようにすることができます。これにより、ワークフローで 1 つのステージが完了した後に手作業でチーム メンバーを割り当てる必要がなくなります。  

Jira では、課題の列間での移動またはステータスの変更時に、課題の担当者を自動的に変更できます。

  1. Use the For transition dropdown to tell Jira the column or status that updates the issue's assignee field.
  2. [担当者] ドロップダウンで、課題を割り当てる担当者を指定します。

次の選択肢があります。

  • 報告者。通常は、課題の作成者。
  • 現在のユーザーまたは課題のステータスの更新者。
  • なし。したがって課題は割り当てられません。
  • プロジェクト内の特定のユーザー。

幅広い領域にわたるチームでは通常、プロセスのさまざまな段階でタスクを割り当てます。たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。

作業前 → 設計中 → 開発中 → レビュー中 → 完了

ユーザーはボードの各領域に対して、課題を割り当てるためのルールを作成することができます。

  • 設計中列に移動する課題は、チームの設計者に割り当てます。設計者は、実装の詳細、仕様、および要件を指定します。

  • 開発中列に移動する課題は、チームの機能開発リードに割り当てます。リードはコードを記述したり、チーム内の他の開発者に作業を任せます。

  • レビュー中に移動する課題は、チームの品質保証担当者に割り当てます。品質保証担当者はテスト記録を作成したり、自動品質テストをビルドしたりします。

  • 完了列に移動する課題では、割り当てを解除します。

Check an issue's field

This rule looks at the value of an issue’s field before allowing someone to use a specific transition. This virtual check can help your team better resolve issues by narrowing down the available paths in your workflow based on the information present on the issue. You can use it to enforce best practices for similar issues without having to create a new issue type and workflow.

To review the value of an issue’s field before allowing someone to use a specific transition:

  1. Use the For transition dropdown to tell Jira Software the transition that checks for the field’s value.

  2. Select the field whose value you want to check in the For this field dropdown.

  3. Optionally, adjust the Review its value as dropdown to change how you want to evaluate the field (see below for details).

  4. Use the Check if it dropdown to select how Jira Software should compare the field’s value (see below for details).

  5. Add the value you want to compare against to the This value field.

  6. Click Add.

Review its value as

この機能は、古い構成の Jira や、このワークフロー ルールの高度な使い方をサポートするために含まれています。このオプションの初期設定を変更することはお勧めしません。

Jira Software allows you to evaluate the value entered in a field in a number of different ways. This can be useful when comparing numerals entered as text in a short text field to see if they are equal to an integer, for example.

Depending on the type of field you’re checking, you can evaluate its contents as:

  • a number - any positive or negative number, including decimal values, between -1 trillion and 1 trillion (100000000000000). Keep in mind:

    • The field will not accept a number expressed as a fraction.

    • The field only accepts one separator–the decimal. Other notation (for example, commas to denote places) will break the rule.

    • Jira は小数点以下 3 桁以降を四捨五入します。たとえば、5.555555 は四捨五入されて 5.6 となります。 

    • You may enter large numbers using scientific notation. For example, the number 5000 can be entered as 5e3.

  • a selection - including the available options configured in the field for dropdown and checkbox fields, or user IDs in people fields.

  • a time stamp - including a date and, for time stamp fields, a time. We provide a calendar and clock to accurately select the date and time, so you don’t need to know specific formatting.

  • text - evaluated as a string, including special and non-Latin characters.

以下の場合はチェック

The selection you make here tells Jira Software how they should evaluate the contents of the field you’re checking. For example, you can check if the value of a number field is greater than or less than a desired value.

Depending on the type of field you’re checking, you can compare the field’s value with these operators:

  • contains - for evaluating fields as either a selection or text, this operator looks to see if the desired string or selection is present in the field

  • doesn’t contain - for evaluating fields as either a selection or text, this operator looks to see that the desired string or selection is absent from the field

  • doesn’t equal - this operator looks to see if the field being evaluated doesn’t exactly match a specific pattern

  • equals - this operator looks to see if the field being evaluated does exactly match a specific pattern. For text, the evaluation is case sensitive and considers exact formatting.

  • is after - for date and time stamp fields, this operator looks for time stamps that occur after the desired value chronologically

  • is before - for date and time stamp fields, this operator looks for time stamps that occur before the desired value chronologically

  • is or is after - for date and time stamp fields, this operator looks for time stamps that occur at exactly the same time or after the desired value chronologically

  • is or is before - for date and time stamp fields, this operator looks for time stamps that occur at exactly the same time or before the desired value chronologically

  • is greater than - for number fields, this operator looks for values that are larger than what’s specified in the rule

  • is greater than or equal to - for number fields, this operator looks for values that are either exactly equal to or larger than what’s specified in the rule

  • is less than - for number fields, this operator looks for values that are smaller than what’s specified in the rule

  • is less than or equal to - for number fields, this operator looks for values that are either exactly equal to or smaller than what’s specified in the rule

Check that an issue has been through a status

This rule helps ensure that issues go through one or more required stages in your team’s workflow. It lets you enforce automated checks in your workflow, and prevents issues from skipping steps in your process. Or, the rule can be set up to do the exact opposite – check that an issue hasn’t been through a particular status.

特定のトランジションを許可する前に、課題が特定のステータスにあったことを確認するには、次の手順を実行します。

  1. Use the For transition dropdown to tell Jira Software the transition that check previous statuses.

  2. [課題が次のステータスを経ていることを確認する] ドロップダウンで、確認したいステータスを選択します。

次のオプションを選択することもできます。

Include the issue’s current status

By default, this workflow rule only looks at prior statuses when evaluating whether to allow a transition. If you want to also evaluate the current status, select the Include the issue’s current status checkbox. This can help prevent looping transitions, where a transition resets the status and it appears unchanged. It keep issues moving down your workflow. Read more about looped transitions below.

このルールを取り消す

You can change the behavior of this workflow rule to check that an issue hasn’t been through a particular status before allowing the transition. This can enforce that bugs or feature requests that have been in a “rejected” status don’t make their way back onto your board.

Only consider the issue’s most recent status

By default, this workflow rule checks the entire history of an issue from its creation in the project. Selecting this option forces the rule to only evaluate the status set just prior to the issue’s current status. In some cases, this may be the same as the current status. We recommend also selecting the Ignore status updates from looped transitions option to ensure the rule evaluates the most recent different status from the issue’s current status.

ループが設定されたトランジションのステータス更新を無視する

Some projects use transitions to trigger notifications, automations in connected apps, or other actions. These transitions usually reset the issue’s status to the current issue status. If you’ve selected to Only consider the issue’s most recent status, the most recent status may be the same as the current status. Selecting the Ignore status updates from looped transitions option forces the rule to evaluate the most recent status that’s different from the issue’s current status.

Quality assurance example

The aim here is make sure that work goes through quality control before its complete. In this case, you can use your workflow statuses to help your team enforce that a quality assurance engineer has looked at your team’s work before deploying it to your customers.

たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。

やること開発待ちレビュー中完了

You can use a workflow status as a quality gate before allowing work to be completed in your project. Add the Check that an issue has been through a status rule to the final transition in your workflow, and you can ensure that work has been reviewed properly by your quality assurance engineer before marking the task as complete:

  1. [リクエストがステータスを経ていることを確認する] ルールを、"完了" ステータスにつながる "すべてのステータス" トランジションに追加します。

  2. [リクエストが次のステータスを経ていることを確認する] ドロップダウンで、"レビュー中" ステータスを選択します。

  3. [このリクエストの現在のステータスを含める] オプションを選択します。

  4. [リクエストの最新のステータスのみを考慮する] オプションを選択します

  5. [ループが設定されたトランジションのステータス更新を無視する] オプションを選択します。

Now, work can freely flow between any status. But, the transition to “Done” is only allowed if the most recent status was “In review”.

保証を追加するには、この移行に課題を移動できるユーザーを制限するルールを追加し、それを「品質保証エンジニア」のカスタム ロールに制限することもできます。この方法では、「品質保証エンジニア」のロールを持つ人だけが課題を完了に移動することができます。カスタム ロールの詳細をご確認ください

Interrupted status example

ソフトウェア チームは、定期的にプロジェクトに参加しているわけではない同僚と相談する必要がある場合があります。たとえば、フロントエンド タスクでは、ユーザー インターフェイスを構築する際に、設計者からのインプットが必要な場合があります。

この種類のインプットはワークフローで定期的に必要ではありませんが、設計者のインプットを待っている課題を表示して確認できるようにする必要があります。

In this case, you can create a status for this kind of interruption called “Awaiting design”. Your workflow may look like this:

[課題がステータスを通過していることを確認する] ルールを使用すると、課題は通常のワークフローで中断される前の元の場所に確実に戻ることができます。

  1. Create a status for your interrupted state, and allow any status to transition into your new status. In the example above, the interrupted status is called “Awaiting design”.

  2. Create transitions from the interrupted status back to your main workflow. In the diagram above, the “Restart task” and “Back to in progress” transitions direct issues from our “Awaiting design” interrupted status back into the main workflow (TO DO → IN PROGRESS → DONE).

  3. Add a Check that an issue has been through a status rule to allow the transition that puts the issue back where it came from. For example, if issues were interrupted while they were “In progress”:

    1. In the For transition dropdown, select “Back to in progress” transition.

    2. [課題が次のステータスを経ていることを確認する] ドロップダウンで、「レビュー中」ステータスを選択します。

  4. Add a Check that an issue has been through a status rule to prevent the issue moving backward in your workflow. For example, if issues were interrupted while they were “In progress”, you can prevent them from moving back to “To do”:

    1. [移行の場合] ドロップダウンで、[タスクの再起動] トランジションを選択します。

    2. [課題が次のステータスを経ていることを確認する] ドロップダウンで、「レビュー中」ステータスを選択します。

    3. Select the Reverse this rule option.

Now, issues that are interrupted from your main flow and set to “Awaiting design” can only move the following ways:

  • Issues that move from “To do” to “Awaiting design” can only move back to “To do”.

  • 「レビュー中」から「設計待ち」に移動する課題は、「進行中」に戻ることしかできません。

課題フィールドを更新

このルールを設定すると、課題に適切なタイミングで適切な情報を取り込むようにすることができます。これにより、データの入力エラーを減らし、一貫性を向上させることができます。

Jira では、課題の列間での移動またはステータスの変更時に、課題の担当者を自動的に変更できます。

  1. Use the For transition dropdown to tell Jira the column or status that updates a certain field. 
  2. 自動更新するフィールドを選択します。

You can update any text, number, label, date, or time fields you’ve added to your project, including custom fields. Learn more about custom fields.

挙動には次の違いがあります。

  • ルールを使用してテキスト フィールドを更新すると、 Jira は目的のテキストをフィールド内の既存のテキストに追加します。フィールド内の既存のテキストの置き換えは行いません。

  • 期間または日付フィールドを更新すると、Jira はボード上のカードの移動時の日付とタイムスタンプ (またはこのいずれか) でフィールド内のすべての要素を置き換えます。静的な時間または日付を指定することはできません。

幅広い領域にわたるチームでは通常、プロセスのさまざまな段階でタスクを割り当てます。たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。

作業前 → 設計中 → 開発中 → レビュー中 → 完了

チームではトレーサビリティやレポートのために課題タイプに以下のカスタム日付フィールドを追加して、引き継ぎ日を追跡できます。

  • 設計部門による確認
  • 開発への引き継ぎ
  • QA 担当者への引き継ぎ

チームは簡単なルールを作成することで、課題が特定の列またはステータスに移動された時点で、このような引き継ぎ日付フィールドを最新の日付で更新するように設定できます。

  • [設計部門の確認中] に移動される課題の [設計部門による確認] フィールドを最新の日付/時間に更新します。
  • For issues moving to In development, update the Handed to development field to the current date/time.
  • [レビュー中] に移動される課題の [QA 担当者への引き継ぎ] フィールドを最新の日付/時間に更新します。

最終更新日: 2021 年 10 月 11 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.