このヘルプ ページの内容について
以降の情報は、チーム管理対象プロジェクトにのみ適用されます。
どのタイプのプロジェクトの情報を参照すべきかを確認するには、プロジェクトの左側のサイドバーの下部をご覧ください。
[チーム管理対象プロジェクトをご利用中です] というアイコンに加えて [フィードバックを送信] や [詳細] メニュー項目が表示される場合は、チーム管理対象プロジェクトを利用しています。
そうではない場合は、企業管理対象プロジェクトを利用しています。企業管理対象プロジェクトのドキュメントをご確認ください。
課題を誰かに割り当てる
このルールを設定すると、適切なユーザーが、適切なタイミングで適切な課題に取り組むようにすることができます。これにより、ワークフローで 1 つのステージが完了した後に手作業でチーム メンバーを割り当てる必要がなくなります。
Jira では、課題の列間での移動またはステータスの変更時に、課題の担当者を自動的に変更できます。
- [移行の場合] ドロップダウンを使用して課題の担当者フィールドを更新する列またはステータスを Jira に設定します。。
- [担当者] ドロップダウンで、課題を割り当てる担当者を指定します。
次の選択肢があります。
- 報告者。通常は、課題の作成者。
- 現在のユーザーまたは課題のステータスの更新者。
- なし。したがって課題は割り当てられません。
- プロジェクト内の特定のユーザー。
例
幅広い領域にわたるチームでは通常、プロセスのさまざまな段階でタスクを割り当てます。たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。
作業前 → 設計中 → 開発中 → レビュー中 → 完了
ユーザーはボードの各領域に対して、課題を割り当てるためのルールを作成することができます。
設計中列に移動する課題は、チームの設計者に割り当てます。設計者は、実装の詳細、仕様、および要件を指定します。
開発中列に移動する課題は、チームの機能開発リードに割り当てます。リードはコードを記述したり、チーム内の他の開発者に作業を任せます。
レビュー中に移動する課題は、チームの品質保証担当者に割り当てます。品質保証担当者はテスト記録を作成したり、自動品質テストをビルドしたりします。
- 完了列に移動する課題では、割り当てを解除します。
課題が特定の値になっている場合に制限する
このルールでは、特定のトランジションの使用をユーザーに許可する前に、課題のフィールドの値を確認します。この仮想チェックによって、ワークフローで利用できるパスを、課題で提示される情報に基づいて絞り込むことで、チームが課題を解決しやすくなります。この機能を使用することで、新しい課題タイプやワークフローを作成することなく、類似した課題のベスト プラクティスを適用できます。
特定のトランジションの使用をユーザーに許可する前に課題のフィールドの値を確認するには、次の手順に従います。
[トランジション] ドロップダウンを使用して、フィールドの値を確認するトランジションを 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 - この演算子は、数値フィールドでルールで指定された内容と正確に等しいかそれより小さな値を検索します。
課題がステータスを経ている場合に制限する
このルールは、課題がチームのワークフローで 1 つ以上の必須ステージを経由していることを確認するのに役立ちます。ワークフローの自動確認を実施し、課題がプロセスの手順をスキップしないようにします。または、まったく逆に、課題が特定のステータスを通過していないことを確認するようにセットアップすることもできます。
特定のトランジションを許可する前に、課題が特定のステータスにあったことを確認するには、次の手順を実行します。
[トランジション] ドロップダウンを使用して、前のステータスを確認するトランジションを Jira Software に伝えます。
[課題が次のステータスを経ていることを確認する] ドロップダウンで、確認したいステータスを選択します。
次のオプションを選択することもできます。
課題の現在のステータスを含める
既定では、トランジションを許可するかどうかを評価する際、このワークフロー ルールは以前のステータスのみを確認します。現在のステータスも評価したい場合は、[課題の現在のステータスを含める] チェックボックスを選択します。トランジションがステータスをリセットして未変更と表示されてしまう、トランジションのループを防ぐのに役立ちます。これによってワークフローで課題を引き続き進めることができます。トランジションのループの詳細については次をお読みください。
このルールを取り消す
トランジションを許可する前に、課題が特定のステータスを通過していないことを確認するよう、このワークフロー ルールの動作を変更できます。これにより、「却下」ステータスになったバグや機能リクエストがボードに戻されないようにできます。
課題の最新のステータスのみを考慮する
既定では、このワークフロー ルールはプロジェクトでの課題の作成以降の履歴全体を確認します。このオプションを選択すると、ルールは課題の現在のステータスの直前に設定されたステータスのみを評価します。場合によっては、これが現在のステータスと同じ可能性があります。また、直近のステータスが課題の現在のステータスと異なることを評価するため、[ループが設定されたトランジションのステータス更新を無視する] を選択することをお勧めします。
ループが設定されたトランジションのステータス更新を無視する
一部のプロジェクトはトランジションを使用して、通知や接続されたアプリの自動化やその他のアクションをトリガーします。これらのトランジションは通常、課題のステータスを現在の課題ステータスにリセットします。[課題の最新のステータスのみを考慮する] を選択した場合、最新のステータスが現在のステータスと同じである場合があります。[ループが設定されたトランジションのステータス更新を無視する] オプションを選択することで、現在のステータスと異なる課題の直近のステータスを評価します。
例
品質保証の例
ここでの目的は、作業が完了する前に品質管理を確実に通過させることです。このような場合、ワークフロー ステータスを使用して、顧客へのデプロイ前に品質保証エンジニアがチームの仕事を検討するよう、チームに実行させるようにします。
たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。
やること→開発待ち→レビュー中→完了
作業をプロジェクトで「完了」にする前に、ワークフローのステータスを品質ゲートとして使用できます。ワークフローの最後のトランジションに課題がステータスを経ていることを確認するルールを追加すると、タスクを完了としてマークする前に品質保証エンジニアが確実にレビューを行うようにすることができます。
[リクエストがステータスを経ていることを確認する] ルールを、"完了" ステータスにつながる "すべてのステータス" トランジションに追加します。
[リクエストが次のステータスを経ていることを確認する] ドロップダウンで、"レビュー中" ステータスを選択します。
[このリクエストの現在のステータスを含める] オプションを選択します。
[リクエストの最新のステータスのみを考慮する] オプションを選択します。
[ループが設定されたトランジションのステータス更新を無視する] オプションを選択します。
これで、作業はどのステータスでも自由に流れることができます。ただし、最新のステータスが「レビュー中」の場合にのみ「完了」にトランジションできます。
保証を追加するには、この移行に課題を移動できるユーザーを制限するルールを追加し、それを「品質保証エンジニア」のカスタム ロールに制限することもできます。この方法では、「品質保証エンジニア」のロールを持つ人だけが課題を完了に移動することができます。カスタム ロールの詳細をご確認ください。
中断されたステータスの例
ソフトウェア チームは、定期的にプロジェクトに参加しているわけではない同僚と相談する必要がある場合があります。たとえば、フロントエンド タスクでは、ユーザー インターフェイスを構築する際に、設計者からのインプットが必要な場合があります。
この種類のインプットはワークフローで定期的に必要ではありませんが、設計者のインプットを待っている課題を表示して確認できるようにする必要があります。
この場合、「設計待ち」と呼ばれるこのような中断のステータスを作成できます。ワークフローは次のようになります。
[課題がステータスを通過していることを確認する] ルールを使用すると、課題は通常のワークフローで中断される前の元の場所に確実に戻ることができます。
中断された状態用のステータスを作成し、すべてのステータスが新しいステータスに移行できるようにします。上の例では、中断状態を「設計待ち」と呼びます。
中断ステータスからメイン ワークフローに戻るトランジションを作成します。上の図では、「タスクの再起動」トランジションと「進行中に戻る」トランジションは、「設計待ち」の中断ステータスからメイン ワークフロー (作業前→進行中→完了) に課題を戻します。
課題を元の場所に戻すトランジションを許可する課題がステータスを経ていることを確認するルールを追加します。たとえば、「進行中」に課題が中断された場合は次のようにします。
[移行の場合] ドロップダウンで、[処理中に戻る] トランジションを選択します。
[課題が次のステータスを経ていることを確認する] ドロップダウンで、「レビュー中」ステータスを選択します。
課題がワークフローに戻るのを防ぐための課題がステータスを経ていることを確認するルールを追加します。たとえば、「進行中」に課題が中断された場合、「作業前」に戻らないようにすることができます。
[移行の場合] ドロップダウンで、[タスクの再起動] トランジションを選択します。
[課題が次のステータスを経ていることを確認する] ドロップダウンで、「レビュー中」ステータスを選択します。
このルールを取り消すオプションを選択します。
これで、メインフローから中断され「設計待ち」に設定されている課題は、次の方法でしか移動できません。
「作業前」から「設計待ち」に移動する課題は、「作業前」に戻ることしかできません。
「レビュー中」から「設計待ち」に移動する課題は、「進行中」に戻ることしかできません。
課題を移動できるユーザーを制限する
このルールによって、チームのプロセスにおける特定の時点で適切なユーザーのみが課題を移動できるようになります。ワークフローで見逃すステップを減らして、作業にかかわるすべてのユーザーが確実にチームの作業に取り組めるようにします。
課題を移動できるユーザーを次のように制限できます。
課題の担当者
課題の報告者
自分が選択したユーザー
特定のロールを持つユーザー
例
通常、幅広い領域にわたるチームには、プロセスのさまざまなステージでタスクに取り組んでいるユーザーがいます。たとえば、小規模なチームでは、次のようなステップを踏んでプロセスを進める場合があります。
作業前 → 設計中 → 開発中 → レビュー中 → 完了
チームの領域は次のようなロールにマッピングされます。
デザイナー
ソフトウェア エンジニア
品質保証
プロジェクト ロールの管理に関する詳細についてご確認ください。
ルールを使用して次のような制限を追加することで、適切なロールが課題を移動できるようにします。
「設計中」から移行する課題では、課題を移動できるユーザーをデザイナーのロールに制限する。
「開発中」から移行する課題では、課題を移動できるユーザーをソフトウェア エンジニアのロールに制限する。
「レビュー中」から移動する課題では、課題を移動できるユーザーを品質保証のロールに制限する。
ユーザーが特定の権限を持っていることを確認する
このルールでは、特定のトランジションの使用をユーザーに許可する前に、ユーザーが持つ権限を確認します。この確認は、チームにとって適切なユーザーだけが適切なタイミングで課題を移動できるようにするのに役立ちます。このルールを使用すると、ユーザーの Jira 権限に基づいてワークフローを保護できます。
例
基本的なワークフローを使用するチームでは、ワークフローに以下のステータスがあります。
開始 → 作業前 → 進行中 → 完了
このルールを使用すると、ユーザーが特定の権限を持っていることを次の方法で確認できます。
課題の作成権限を持つユーザーのみが「開始」から「作業前」に課題を移動できるようにする。これによって、適切なユーザーのみがチームの作業を作成できるようになります。
課題の割り当て権限を持つユーザーのみが「作業前」から「進行中」に課題を移動できるようにする。これによって、課題の作業を開始したユーザーがその課題を別のユーザーに割り当てることができるようになります。
課題のクローズ権限を持つユーザーのみが「進行中」から「完了」に課題を移動できるようにする。これによって、ユーザーは許可なしで課題を解決することができなくなります。
課題フィールドを更新
このルールを設定すると、課題に適切なタイミングで適切な情報を取り込むようにすることができます。これにより、データの入力エラーを減らし、一貫性を向上させることができます。
Jira では、課題の列間での移動またはステータスの変更時に、課題の担当者を自動的に変更できます。
- [For issues moving to (次に For transition ドロップダウンを使用して、特定のフィールドを更新する列またはステータスを Jira に設定します。
- 自動更新するフィールドを選択します。
テキスト、数値、ラベル、日付、または期間フィールドやカスタム フィールドなど、プロジェクトに追加したすべてのフィールドを更新できます。カスタム フィールドについては、こちらを参照してください。
挙動には次の違いがあります。
ルールを使用してテキスト フィールドを更新すると、 Jira は目的のテキストをフィールド内の既存のテキストに追加します。フィールド内の既存のテキストの置き換えは行いません。
期間または日付フィールドを更新すると、Jira はボード上のカードの移動時の日付とタイムスタンプ (またはこのいずれか) でフィールド内のすべての要素を置き換えます。静的な時間または日付を指定することはできません。
例
幅広い領域にわたるチームでは通常、プロセスのさまざまな段階でタスクを割り当てます。たとえば、小規模な機能チームでは、ボードに次のような列が配置されている場合があります。
作業前 → 設計中 → 開発中 → レビュー中 → 完了
チームではトレーサビリティやレポートのために課題タイプに以下のカスタム日付フィールドを追加して、引き継ぎ日を追跡できます。
- 設計部門による確認
- 開発への引き継ぎ
- QA 担当者への引き継ぎ
チームは簡単なルールを作成することで、課題が特定の列またはステータスに移動された時点で、このような引き継ぎ日付フィールドを最新の日付で更新するように設定できます。
- [設計部門の確認中] に移動される課題の [設計部門による確認] フィールドを最新の日付/時間に更新します。
- [開発中] に移動する課題の [開発への引き継ぎ] フィールドを最新の日付/時間に更新します。
- [レビュー中] に移動される課題の [QA 担当者への引き継ぎ] フィールドを最新の日付/時間に更新します。
不明なカスタム フィールド タイプ
不明なタイプのカスタム フィールドをワークフロー エディターに更新するときは、必ずカスタム フィールドのタイプと一致する値をご入力ください。そうしないとルールが機能しない場合があります。
次を使用できます。
- %%CURRENT_USER%%、課題をトランジションしたユーザーに置き換えられます。
- %%CURRENT_DATETIME%%、トランジションの日時に置き換えられます。
- [選択リスト (カスケード)] フィールドには、選択するオプションの値または ID を使用できます。
カスタムの日時形式
カスタムの日時形式をセットアップして、日時のフィールドを更新するようにこのルールを設定する場合は、正しい形式で入力する必要があります。その場合は、日付ピッカー フィールドの代わりに、入力方法の説明が記載されたテキスト フィールドが表示されます。
たとえば、「dd/MMMM/yyyy h:mm a」という形式で日付を入力するように指示するテキスト フィールドが表示される場合があります。入力できる日付の 1 つは、「15/July/1968 9:30 PM」です。こうした形式の詳細は「Java SimpleDateFormat」をご参照ください。
Jira のルック アンド フィールを設定して、日時の形式を変更できます。Jira のルック アンド フィールの設定に関する詳細をご確認ください。