This page is for team-managed プロジェクト
To check whether your project is or team-managed or company-managed, select More actions (•••) next to the project name in either the header or the sidebar. At the bottom of the menu that opens, you’ll be able to view whether your project is team-managed or company-managed.
If you're in a company-managed project, check out these company-managed project articles instead.
More about the difference between company-managed and team-managed projects.
Assign a work item to someone
This rule helps ensure that the right people address the right work items at the right time. It takes the manual work out of assigning a team member after a stage in the workflow is complete.
Jira can change the work item's assignee automatically when you move a work item between columns or change its status:
- Use the For transition dropdown to tell Jira the column or status that updates the work item's assignee field。
- Nominate the person who you want to assign the work item to in the Assign to dropdown.
You can assign work items to:
- 報告者。通常は、課題の作成者。
- The current user, or the person updating the work item's status
- No one, making the work item unassigned
- プロジェクト内の特定のユーザー。
例
幅広い領域にわたるチームでは通常、プロセスのさまざまな段階でタスクを割り当てます。たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。
作業前 → 設計中 → 開発中 → レビュー中 → 完了
You can create rules to assign work items to each discipline across the board:
For work items moving to In design, assign to the team's designer. They then provide implementation details, specifications, and requirements.
For work items moving to In development, assign to the team's feature lead. They then write the code or delegate to other developers in the team.
For work items moving to In review, assign to the team's quality assurance champion. They then provide testing notes or build automated quality tests.
- For work items moving to Done, unassign the work item.
Restrict to when a work item is a specific value
This rule looks at the value of a work item’s field before allowing someone to use a specific transition. This virtual check can help your team better resolve work items by narrowing down the available paths in your workflow based on the information present on the work item. You can use it to enforce best practices for similar work items without having to create a new work type and workflow.
To review the value of a work item’s field before allowing someone to use a specific transition:
[トランジション] ドロップダウンを使用して、フィールドの値を確認するトランジションを Jira Software に伝えます。
[このフィールドに対応] ドロップダウンで、確認する値のフィールドを選択します。
任意で、[以下として値を確認] ドロップダウンを調整して、フィールドの評価方法を変更します (詳細は後述)。
[以下の場合はチェック] ドロップダウンを使用して、Jira Software がフィールドの値を比較する方法を選択します (詳細は後述)。
比較する値を [この値] フィールドに追加します。
[追加] をクリックします。
以下として値を確認
この機能は、古い構成の Jira や、このワークフロー ルールの高度な使い方をサポートするために含まれています。このオプションの初期設定を変更することはお勧めしません。
Jira Software では、フィールドに入力される値をさまざまな方法で評価できます。たとえば、短いテキスト フィールドのテキストとして入力された数字を比較して、ある整数と等しいかどうかを確認するなどの場合に便利に使用できます。
確認するフィールドの種類に応じて、内容を次のように評価できます。
数字 - 小数を含む、-1 兆から 1 兆 (100,000,000,000,000) までの任意の正または負の数。次の点にご注意ください。
このフィールドでは、分数は使用できません。
このフィールドでは、小数点のみを区切り文字として使用できます。それ以外の記号 (たとえば桁を示すカンマなど) はルール違反となります。
Jira は小数点以下 1 桁以降を四捨五入します。たとえば、5.555555 は四捨五入されて 5.6 となります。
値の大きな数字には指数表記を使用できます。たとえば、数値 5000 は「5e3」と入力できます。
選択 - ドロップダウン フィールドやチェックボックス フィールドに構成された利用可能なオプションや、ユーザー フィールドのユーザー ID が含まれます。
タイム スタンプ - 日付と、タイム スタンプ フィールドの場合は時刻が含まれます。日付や時刻を正確に選択するためにカレンダーや時計が表示されるため、管理者が特定の書式を覚えておく必要はありません。
テキスト - 特殊文字や非ラテン文字を含む文字列として評価されます。
以下の場合はチェック
ここで行う選択は、Jira Software に確認しているフィールドの内容をどのように評価する必要があるかを指定します。たとえば、数値フィールドの値が指定した値よりも大きいか小さいかを確認できます。
確認するフィールドの種類に応じて、以下の演算子を使用してフィールドの値を比較できます。
contains - この演算子は、選択フィールドまたはテキスト フィールドの形式で評価する場合に、指定された文字列または選択肢がフィールド内に存在するかどうかを確認します。
doesn’t contain - この演算子は、選択フィールドまたはテキスト フィールドの形式で評価する場合に、指定された文字列または選択肢がフィールドに存在しないことを確認します。
doesn’t equal - この演算子は、評価するフィールドが特定のパターンに正確に一致しないかどうかを確認します。
指定の値に等しい - この演算子は、評価するフィールドが特定のパターンに正確に一致するかどうかを確認します。テキストの場合、評価では大文字と小文字が区別されて正確な書式設定が考慮されます。
is after - この演算子は、日付およびタイム スタンプ フィールドで、指定した値の後に発生したタイム スタンプを時系列で検索します。
is before - この演算子は、日付およびタイム スタンプ フィールドで、指定した値の前に発生したタイム スタンプを時系列で検索します。
is or is after - この演算子は、日付およびタイム スタンプ フィールドで、指定した値と正確に同時またはその後に発生したタイム スタンプを時系列で検索します。
is or is before - この演算子は、日付およびタイム スタンプ フィールドで、指定した値と正確に同時またはその前に発生したタイム スタンプを時系列で検索します。
is greater than - この演算子は、数値フィールドでルールで指定された内容よりも大きな値を検索します。
is greater than or equal to - この演算子は、数値フィールドでルールで指定された内容と正確に等しいかそれより大きな値を検索します。
is less than - この演算子は、数値フィールドでルールで指定された内容よりも小さな値を検索します。
is less than or equal to - この演算子は、数値フィールドでルールで指定された内容と正確に等しいかそれより小さな値を検索します。
Restrict to when a work item has been through a status
This rule helps ensure that work items go through one or more required stages in your team’s workflow. It lets you enforce automated checks in your workflow, and prevents work items from skipping steps in your process. Or, the rule can be set up to do the exact opposite – check that a work item hasn’t been through a particular status.
To check if a work item has been in a status before allowing a specific transition:
[トランジション] ドロップダウンを使用して、前のステータスを確認するトランジションを Jira Software に伝えます。
Select the status you want to check for in the Check that the work item has been through dropdown.
次のオプションを選択することもできます。
Include the work item’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 work item’s current status checkbox. This can help prevent looping transitions, where a transition resets the status and it appears unchanged. It keep work items moving down your workflow. Read more about looped transitions below.
このルールを取り消す
You can change the behavior of this workflow rule to check that a work item 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 work item’s most recent status
By default, this workflow rule checks the entire history of a work item from its creation in the project. Selecting this option forces the rule to only evaluate the status set just prior to the work item’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 work item’s current status.
ループが設定されたトランジションのステータス更新を無視する
Some projects use transitions to trigger notifications, automations in connected apps, or other actions. These transitions usually reset the work item’s status to the current work item status. If you’ve selected to Only consider the work item’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 work item’s current status.
例
品質保証の例
ここでの目的は、作業が完了する前に品質管理を確実に通過させることです。このような場合、ワークフロー ステータスを使用して、顧客へのデプロイ前に品質保証エンジニアがチームの仕事を検討するよう、チームに実行させるようにします。
たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。
やること→開発待ち→レビュー中→完了
You can use a workflow status as a quality gate before allowing work to be completed in your project. Add the Check that a work item 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:
Add a Check that a work item has been through a status rule to the “Any status” transition leading to your “Done” status.
In the Check that the work item has been through dropdown, select the “In review” status.
Select the Include the work item’s current status option.
Select the Only consider the work item’s most recent status option.
[ループが設定されたトランジションのステータス更新を無視する] オプションを選択します。
これで、作業はどのステータスでも自由に流れることができます。ただし、最新のステータスが「レビュー中」の場合にのみ「完了」にトランジションできます。
To add extra assurance, you may also add the Restrict who can move a work item rule to this transition, and restrict it to a “Quality assurance engineer” custom role. This way, only people in your “Quality assurance engineer” role can move the work item to done. Learn more about custom roles.
中断されたステータスの例
ソフトウェア チームは、定期的にプロジェクトに参加しているわけではない同僚と相談する必要がある場合があります。たとえば、フロントエンド タスクでは、ユーザー インターフェイスを構築する際に、設計者からのインプットが必要な場合があります。
This type of input isn’t regularly needed in your workflow, but you want to be able to see and check in on the work items that are waiting for your designer’s input.
この場合、「設計待ち」と呼ばれるこのような中断のステータスを作成できます。ワークフローは次のようになります。
You can use the Check that a work item has been through a status rule to ensure the work item goes back to where it came from before the interruption in your normal workflow:
中断された状態用のステータスを作成し、すべてのステータスが新しいステータスに移行できるようにします。上の例では、中断状態を「設計待ち」と呼びます。
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 work items from our “Awaiting design” interrupted status back into the main workflow (TO DO → IN PROGRESS → DONE).
Add a Check that a work item has been through a status rule to allow the transition that puts the work item back where it came from. For example, if work items were interrupted while they were “In progress”:
[移行の場合] ドロップダウンで、[処理中に戻る] トランジションを選択します。
In the Check that the work item has been through dropdown, select the “In progress” status.
Add a Check that a work item has been through a status rule to prevent the work item moving backward in your workflow. For example, if work items were interrupted while they were “In progress”, you can prevent them from moving back to “To do”:
[移行の場合] ドロップダウンで、[タスクの再起動] トランジションを選択します。
In the Check that the work item has been through dropdown, select the “In progress” status.
このルールを取り消すオプションを選択します。
Now, work items that are interrupted from your main flow and set to “Awaiting design” can only move the following ways:
work items that move from “To do” to “Awaiting design” can only move back to “To do”.
work items that move from “In progress” to “Awaiting design” can only move back to “In progress”.
Restrict who can move a work item
This rule helps ensure only the right people can move a work item 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 a work item to:
The work item’s assignee.
The work item’s reporter.
自分が選択したユーザー
特定のロールを持つユーザー
- 特定のグループに所属するユーザー
- 特定の権限を持つユーザー
例
通常、幅広い領域にわたるチームには、プロセスのさまざまなステージでタスクに取り組んでいるユーザーがいます。たとえば、小規模なチームでは、次のようなステップを踏んでプロセスを進める場合があります。
作業前 → 設計中 → 開発中 → レビュー中 → 完了
チームの領域は次のようなロールにマッピングされます。
デザイナー
ソフトウェア エンジニア
品質保証
プロジェクト ロールの管理に関する詳細についてご確認ください。
Using the rule, they can add these restrictions to make sure the right roles move their work items:
For work items moving from In design, restrict who can move the work item to the role Designer.
For work items moving from In development, restrict who can move the work item to the role Software engineer.
For work items moving from In review, restrict who can move the work item to the role Quality assurance.
ユーザーが特定の権限を持っていることを確認する
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 a work item at the right time. Use this rule to secure your workflow based on people’s Jira permissions.
例
基本的なワークフローを使用するチームでは、ワークフローに以下のステータスがあります。
開始 → 作業前 → 進行中 → 完了
このルールを使用すると、ユーザーが特定の権限を持っていることを次の方法で確認できます。
Only allowing people with the Create work items permission to move a work item from Start → To do. This ensures that only the right people can create work for your team.
Only allowing people with the Assign work items permission to move a work item from To do → In progress. This ensures that whoever starts working on a work item can assign it to someone.
Only allowing people with the Close work items permission to move a work item from In progress → Done. This ensures that people aren’t able to resolve a work item without being allowed to.
あるフィールドの値を別のフィールドにコピーする
Just like the Update a work item field rule, this one also helps ensure your work is updated in the right places at the right time by reducing data entry errors. The key difference is that this rule updates a field based on another field.
フィールドの値は次の場所からコピーできます。
within the work item itself, which copies a field from a work item to another field on the same work item.
the parent work item, which copies from the work item’s parent to itself. This option only works if the work item is the child of another work item e.g. copying a work item from an epic (parent) to a story (child), or from a story (parent) to a subtask (child).
このルールがスキップされる場合
The information you configure this rule with may not apply to all work types that share the workflow. So we’ll skip this rule when:
it’s on a work item that doesn’t have both your selected fields (in Copy from this field and To this field).
it’s configured to copy from the parent work item and the work item doesn’t have a parent.
このルールがスキップされたからといって、何か間違ったことをしたわけでも、バグがあるということでもないため心配は無用です。そのまま作業を続けても問題ありません。ルールがスキップされても、どのフィールドもコピーも更新もされないだけです。
フィールドのコピー方法
次の 3 通りの方法でフィールドを別のフィールドにコピーできます。
追加: フィールドの値がコピー先フィールドの値に追加されます。
先頭に追加: フィールドの値がコピー先フィールドの値の先頭に追加されます。
置換: フィールドの値でコピー先フィールドの値が置換されます。
コピーに対応しているフィールド タイプとそのコピー方法のリストは次のとおりです。
フィールド タイプ | 指定可能なコピー先 | コピーのタイプ |
---|---|---|
テキスト | テキスト 要約 説明 | 追加 |
日付 | 日付 | REPLACE |
ラベル | ラベル | 追加 |
数値 | 数値 | REPLACE |
チェックボックス | チェックボックス | REPLACE |
1 つを選択 | コピー元とコピー先のタイプが同じ (例: コピー元がグループピッカーの場合はコピー先もグループ ピッカー) | REPLACE |
複数選択 | 同じタイプを複数選択 (例: バージョン ピッカー → バージョン ピッカー) | REPLACE |
ユーザー ピッカー (単一ユーザー) | ユーザー ピッカー (単一ユーザー) | REPLACE |
ユーザー ピッカー (複数ユーザー) | 追加 | |
ユーザー ピッカー (複数ユーザー) | ユーザー ピッカー (複数ユーザー) | REPLACE |
担当者 | 担当者 報告者 ユーザー ピッカー (単一ユーザー) ユーザー ピッカー (複数ユーザー) | REPLACE |
添付ファイル | 添付ファイル | 追加 |
Update a work item field
This rule helps ensure that work items capture the right information at the right time. You can reduce data entry errors and increase consistency.
Jira can update certain fields for you automatically when you move work items between columns or change their status:
- [For issues moving to (次に For transition ドロップダウンを使用して、特定のフィールドを更新する列またはステータスを Jira に設定します。
- 自動更新するフィールドを選択します。
テキスト、数値、ラベル、日付、または期間フィールドやカスタム フィールドなど、プロジェクトに追加したすべてのフィールドを更新できます。カスタム フィールドについては、こちらを参照してください。
挙動には次の違いがあります。
ルールを使用してテキスト フィールドを更新すると、 Jira は目的のテキストをフィールド内の既存のテキストに追加します。フィールド内の既存のテキストの置き換えは行いません。
期間または日付フィールドを更新すると、Jira はボード上のカードの移動時の日付とタイムスタンプ (またはこのいずれか) でフィールド内のすべての要素を置き換えます。静的な時間または日付を指定することはできません。
例
幅広い領域にわたるチームでは通常、プロセスのさまざまな段階でタスクを割り当てます。たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。
作業前 → 設計中 → 開発中 → レビュー中 → 完了
For traceability and reporting, teams might add custom date fields to their work types to track hand-off dates:
- 設計部門による確認
- 開発への引き継ぎ
- QA 担当者への引き継ぎ
They can create simple rules that update these hand-off date fields to the current date of when someone moves the work item to a certain column or status:
- For work items moving to In design, update the Picked up by design field to the current date/time.
- For work items moving to In development, update the Handed to development field to the current date/time.
- For work items moving to In review, update the Handed to QA champion field to current date/time.
不明なカスタム フィールド タイプ
不明なタイプのカスタム フィールドをワークフロー エディターに更新するときは、必ずカスタム フィールドのタイプと一致する値をご入力ください。そうしないとルールが機能しない場合があります。
次を使用できます。
- %%CURRENT_USER%%, which will be replaced with the user who transitioned the work item.
- %%CURRENT_DATETIME%%、トランジションの日時に置き換えられます。
- [選択リスト (カスケード)] フィールドには、選択するオプションの値または ID を使用できます。
カスタムの日時形式
カスタムの日時形式をセットアップして、日時のフィールドを更新するようにこのルールを設定する場合は、正しい形式で入力する必要があります。その場合は、日付ピッカー フィールドの代わりに、入力方法の説明が記載されたテキスト フィールドが表示されます。
たとえば、「dd/MMMM/yyyy h:mm a」という形式で日付を入力するように指示するテキスト フィールドが表示される場合があります。入力できる日付の 1 つは、「15/July/1968 9:30 PM」です。こうした形式の詳細は「Java SimpleDateFormat」をご参照ください。
Jira のルック アンド フィールを設定して、日時の形式を変更できます。Jira のルック アンド フィールの設定に関する詳細をご確認ください。