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

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

このページの内容

お困りですか?

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

コミュニティに質問



robotsnoindex

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


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

以降の情報は、チーム管理対象プロジェクトにのみ適用されます。

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

  • [チーム管理対象プロジェクトをご利用中です] というアイコンに加えて [フィードバックを送信] や [詳細] メニュー項目が表示される場合は、チーム管理対象プロジェクトを利用しています。

  • そうではない場合は、企業管理対象プロジェクトを利用しています。企業管理対象プロジェクトのドキュメントをご確認ください

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. [トランジション] ドロップダウンで、課題の担当者フィールドを更新する列またはステータスを Jira に設定します
  2. [担当者] ドロップダウンで、課題を割り当てる担当者を指定します。

次の選択肢があります。

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

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

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

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

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

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

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

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

Restrict to when an issue is a specific value

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.

以下として値を確認

この機能は、古い構成の 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.

確認するフィールドの種類に応じて、内容を次のように評価できます。

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

    • このフィールドでは、分数は使用できません。

    • このフィールドでは、小数点のみを区切り文字として使用できます。それ以外の記号 (たとえば桁を示すカンマなど) はルール違反となります。

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

    • 値の大きな数字は指数表記で入力できます。たとえば、数値 5000 は「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.

確認するフィールドの種類に応じて、以下の演算子を使用してフィールドの値を比較できます。

  • 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

Restrict to when an issue has been through a status

このルールは、課題がチームのワークフローで 1 つ以上の必須ステージを経由していることを確認するのに役立ちます。ワークフローの自動確認を実施し、課題がプロセスの手順をスキップしないようにします。または、まったく逆に、課題が特定のステータスを通過していないことを確認するようにセットアップすることもできます。

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

  1. [トランジション] ドロップダウンを使用して、前のステータスを確認するトランジションを Jira Software に伝えます

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

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

課題の現在のステータスを含める

既定では、トランジションを許可するかどうかを評価する際、このワークフロー ルールは以前のステータスのみを確認します。現在のステータスも評価したい場合は、[課題の現在のステータスを含める] チェックボックスを選択します。トランジションがステータスをリセットして未変更と表示されてしまう、トランジションのループを防ぐのに役立ちます。これによってワークフローで課題を引き続き進めることができます。トランジションのループの詳細については次をお読みください。

このルールを取り消す

トランジションを許可する前に、課題が特定のステータスを通過していないことを確認するよう、このワークフロー ルールの動作を変更できます。これにより、「却下」ステータスになったバグや機能リクエストがボードに戻されないようにできます。

課題の最新のステータスのみを考慮する

既定では、このワークフロー ルールはプロジェクトでの課題の作成以降の履歴全体を確認します。このオプションを選択すると、ルールは課題の現在のステータスの直前に設定されたステータスのみを評価します。場合によっては、これが現在のステータスと同じ可能性があります。また、直近のステータスが課題の現在のステータスと異なることを評価するため、[ループが設定されたトランジションのステータス更新を無視する] を選択することをお勧めします。

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

一部のプロジェクトはトランジションを使用して、通知や接続されたアプリの自動化やその他のアクションをトリガーします。これらのトランジションは通常、課題のステータスを現在の課題ステータスにリセットします。[課題の最新のステータスのみを考慮する] を選択した場合、最新のステータスが現在のステータスと同じである場合があります。[ループが設定されたトランジションのステータス更新を無視する] オプションを選択することで、現在のステータス異なる課題の直近のステータスを評価します。

品質保証の例

ここでの目的は、作業が完了する前に品質管理を確実に通過させることです。このような場合、ワークフロー ステータスを使用して、顧客へのデプロイ前に品質保証エンジニアがチームの仕事を検討するよう、チームに実行させるようにします。

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

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

作業をプロジェクトで「完了」にする前に、ワークフローのステータスを品質ゲートとして使用できます。ワークフローの最後のトランジションに課題がステータスを経ていることを確認するルールを追加すると、タスクを完了としてマークする前に品質保証エンジニアが確実にレビューを行うようにすることができます。

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

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

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

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

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

これで、作業はどのステータスでも自由に流れることができます。ただし、最新のステータスが「レビュー中」の場合にのみ「完了」にトランジションできます。

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

中断されたステータスの例

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

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

この場合、「設計待ち」と呼ばれるこのような中断のステータスを作成できます。ワークフローは次のようになります。

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

  1. 中断された状態用のステータスを作成し、すべてのステータスが新しいステータスに移行できるようにします。上の例では、中断状態を「設計待ち」と呼びます。

  2. 中断ステータスからメイン ワークフローに戻るトランジションを作成します。上の図では、「タスクの再起動」トランジションと「進行中に戻る」トランジションは、「設計待ち」の中断ステータスからメイン ワークフロー (作業前→進行中→完了) に課題を戻します。

  3. 課題を元の場所に戻すトランジションを許可する課題がステータスを経ていることを確認するルールを追加します。たとえば、「進行中」に課題が中断された場合は次のようにします。

    1. [移行の場合] ドロップダウンで、[処理中に戻る] トランジションを選択します。

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

  4. 課題がワークフローに戻るのを防ぐための課題がステータスを経ていることを確認するルールを追加します。たとえば、「進行中」に課題が中断された場合、「作業前」に戻らないようにすることができます。

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

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

    3. このルールを取り消すオプションを選択します。

これで、メインフローから中断され「設計待ち」に設定されている課題は、次の方法でしか移動できません。

  • 「作業前」から「設計待ち」に移動する課題は、「作業前」に戻ることしかできません。

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

Remind people to update fields

This rule makes sure people capture relevant information when changing a issue's status. When you create the rule on any transition, you can prompt your team to complete empty fields that are relevant to that stage in resolving the issue. The rule removes a burden on your teams to remember to fill in specific fields until they matter. It keeps them focused on the important work of resolving issues.

This rule can prompt your team to update or review up to 40 fields on each transition:

  1. Use the For transition dropdown to choose when to prompt your team.

  2. 更新または確認してほしいフィールドを選択します。

カスタム フィールドを含む、サービス プロジェクトに追加したほとんどのテキスト、数値、ラベル、日付、または時刻フィールドを入力するように要求することができます。カスタム フィールドの詳細をご確認ください

更新するフィールドと理由を示すパーソナライズされたメッセージを含めることができます。

Many teams like to categorize how they resolve an issue when they mark an issue as "done". If you use a field to capture how people resolve issues, you can use this information in reports. This can bring you insights into how your team completes work. You can see if your team is resolving issues because there are too many duplicates, or you might see one type of issue being more successfully completed than others.

For example, you might create a dropdown custom field called "Resolution" in your issue types. This field might have options like "Fixed", "Cancelled", "Abandoned", and so on.

Then, you can set up your issue type's workflow to capture how your team resolves issues when they move the issue into a "Done" status. To do so, add a Remind people to update fields rule to your transition, and choose your "Resolution" field. This rule will prompt your team to add a resolution when they mark a ticket as done.

課題を移動できるユーザーを制限する

This rule helps ensure only the right people can move an issue at a particular point in your team’s process. You can reduce missed steps in your workflow and make sure your team’s work goes through all the people required.

You can restrict who can move an issue to:

  • The issue’s assignee.

  • The issue’s reporter.

  • A user of your choice.

  • People in a specific role.

Multi-discipline teams usually have different people working on a task at different stages in their process. For example, a small feature team may have these steps in their process:

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

The disciplines in the team may be mapped to roles:

  • Designer.

  • Software engineer.

  • Quality assurance.

Learn more about managing project roles.

Using the rule, they can add these restrictions to make sure the right roles move their issues:

  • For issues moving from In design, restrict who can move the issue to the role Designer.

  • For issues moving from In development, restrict who can move the issue to the role Software engineer.

  • For issues moving from In review, restrict who can move the issue to the role Quality assurance.

Validate that people have a specific permission

This rule looks at what permissions someone has before they’re allowed to use a specific transition. This check helps your team ensure only the right people can move an issue at the right time. Use this rule to secure your workflow based on people’s Jira permissions.

A team with a basic workflow might have these statuses in their workflow:

StartTo do → In progress → Done

You can use this rule to validate people have a specific permission by:

  • Only allowing people with the Create issues permission to move an issue from StartTo do. This ensures that only the right people can create work for your team.

  • Only allowing people with the Assign issues permission to move an issue from To doIn progress. This ensures that whoever starts working on an issue can assign it to someone.

  • Only allowing people with the Close issues permission to move an issue from In progressDone. This ensures that people aren’t able to resolve an issue without being allowed to.

課題フィールドを更新

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

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

  1. [トランジション] ドロップダウンで、特定のフィールドを更新する列またはステータスを Jira に設定します。
  2. 自動更新するフィールドを選択します。

テキスト、数値、ラベル、日付、または期間フィールドやカスタム フィールドなど、プロジェクトに追加したすべてのフィールドを更新できます。カスタム フィールドについては、こちらを参照してください

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

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

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

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

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

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

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

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

  • [設計部門の確認中] に移動される課題の [設計部門による確認] フィールドを最新の日付/時間に更新します。
  • [開発中] に移動する課題の [開発への引き継ぎ] フィールドを最新の日付/時間に更新します。
  • [レビュー中] に移動される課題の [QA 担当者への引き継ぎ] フィールドを最新の日付/時間に更新します。

Unknown custom field type

When updating a custom field of a type unknown to the workflow editor, make sure you enter a value that matches the custom field's type. Otherwise, the rule might not work.

You can use these:

  • %%CURRENT_USER%%, which will be replaced with the user who transitioned the issue.
  • %%CURRENT_DATETIME%%, which be replaced with the date and time of the transition.
  • For Select List (cascading) fields, you can either use the value or the id of the option to be selected.

Custom date and time formats

If you’ve set up a custom date and time format and want to configure this rule to update a date and time field, you must enter your desired in the correct format. If this is the case, you’ll see a text field with instructions on how to fill it instead of a date picker field.

For example, you might see a text field that says to enter a date in the “dd/MMMM/yyyy h:mm a” format. One date you could enter would be “15/July/1968 9:30 PM”. To learn more about these formats, check out Java SimpleDateFormat.

To change your date and time formats, you can configure the look and feel of Jira. Learn more about configuring the look and feel of Jira.

最終更新日 2022 年 11 月 5 日

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

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