このページでは、チーム管理対象プロジェクトに追加できる各ワークフロー ルールについて説明して、それらの使用例を紹介します。 チーム管理対象プロジェクトのワークフローにルールを追加する方法をご確認ください。。
リクエストを誰かに割り当てる
このルールを設定すると、適切なエージェントが適切なタイミングで適切な課題に取り組むようにすることができます。これにより、ワークフローの 1 つのステージが完了した後に手動でトリアージを行ってエージェントを割り当てる必要がなくなります。
ステータスを変更したときに、Jira Service Management でリクエストの担当者を自動的に変更できます。
[For transition] ドロップダウンを使用して、リクエストの担当者フィールドを更新するトランジションを Jira Service Management に伝えます。
[担当者] ドロップダウンで、リクエストを割り当てる担当者を指定します。
リクエストを次のユーザーに割り当てることができます。
現在のユーザーまたはリクエストのステータスの更新者。
なし。リクエストは割り当てられません
サービス プロジェクトの特定のユーザー
例
サービス チームの特定のメンバーがサービスの特定の分野の専門知識を持っていたり、特定のリクエストの実施を明示的に担当している場合があります。たとえば、サービス エージェントがソフトウェア ツールまたはメッセージ リストへのアクセスの提供を担当し、シニア サービス エージェントが困難なリクエストや影響の大きいリクエストのエスカレート方法の評価を担当する場合があります。
特定のリクエスト タイプを、そのタイプのリクエストを担当しているユーザーに自動的に割り当てるよう、リクエスト ワークフローを設定できます。
上記の例では、次のようになる場合があります。
IT help のリクエスト タイプ設定に移動して、ワークフローを編集します。ワークフローの最初のトランジションを選択 ("Create issue" から "Waiting for support" への "Create issue" トランジション) します。"リクエストを割り当てる" ルールを追加して、これらのリクエストをアクセス担当者に自動的に割り当てます。これで、IT ヘルプ リクエストが作成されると、チケットが IT ヘルプ担当者に自動的に割り当てられ、リクエストの手動トリアージは不要になります。リクエストの各タイプに対してこの手順を繰り返し、サービス チームの適切な専門家に割り当てることで、リクエストのトリアージは不要になります。
リクエストが [エスカレート済み] ステータスに移動すると担当者を変更するようにワークフローを編集します。これらのリクエストをシニア サービス エージェントやマネージャーに自動的に割り当てるようなルールを設定し、困難なリクエストや影響が大きいリクエストの場合にこれらのユーザーに通知できます。サービス エージェントはキューの他のリクエストに引き続き取り組みながら、困難なリクエストが適切に処理されていることを把握できます。
リクエストが特定の値になっている場合に制限する
このルールでは、特定のトランジションの使用をユーザーに許可する前に、リクエストのフィールドの値を確認します。この仮想チェックにより、ワークフローでリクエストが利用できるパスを、リクエストで提示される情報に基づいて絞り込むことで、サービス チームが課題を解決しやすくなります。この機能を使用することで、新しいリクエスト タイプやワークフローを作成することなく、類似したリクエストのベスト プラクティスを適用できます。
特定のトランジションの使用をユーザーに許可する前にリクエストのフィールドの値を確認するには、次の手順を実行します。
[トランジション] ドロップダウンを使用して、フィールドの値を確認するトランジションを Jira Service Management に伝えます。
[このフィールドに対応] ドロップダウンで、確認したい値のフィールドを選択します。
任意で [以下として値を確認] ドロップダウンを調整して、フィールドの評価方法を変更します (詳細は後述)。
[以下の場合はチェック] ドロップダウンを使用して、Jira Service Management でのフィールドの値の比較方法を選択します (詳細は後述)。
比較したい値を [この値] フィールドに追加します。
追加をクリックします。
以下として値を確認
この機能は、古い構成の Jira や、このワークフロー ルールの高度な使い方をサポートするために含まれています。このオプションの初期設定を変更することはお勧めしません。
Jira Service Management では、フィールドに入力される値をさまざまな方法で評価できます。たとえば、短いテキスト フィールドのテキストとして入力された数字を比較して、ある整数と等しいかどうかを確認するなどの場合に便利です。
確認するフィールドの種類に応じて、内容を次のように評価できます。
数字 - 小数を含む、-1 兆から 1 兆 (100000000000000) までの任意の正または負の数。次の点にご注意ください。
このフィールドでは、分数は使用できません。
このフィールドでは、小数点のみを区切り文字として使用できます。それ以外の記号 (たとえば桁を示すカンマなど) はルール違反となります。
Jira は小数点以下 1 桁以降を四捨五入します。たとえば、5.555555 は四捨五入されて 5.6 となります。
値の大きな数字には指数表記を使用できます。たとえば、数値 5000 は「5e3」と入力できます。
選択 - ドロップダウン フィールドやチェックボックス フィールドに構成された利用可能なオプションや、ユーザー フィールドのユーザー ID が含まれます。
タイム スタンプ - 日付と、タイム スタンプ フィールドの場合は時刻が含まれます。日付や時刻を正確に選択するためにカレンダーや時計が表示されるため、管理者が特定の書式を覚えておく必要はありません。
テキスト - 特殊文字や非ラテン文字を含む文字列として評価されます。
以下の場合はチェック
ここで行う選択は、Jira Service Management に対し、確認するフィールドの内容をどのように評価するかを指定します。たとえば、数値フィールドの値が指定した値よりも大きいか小さいかを確認することができます。
確認するフィールドの種類に応じて、以下の演算子を使用してフィールドの値を比較できます。
contains - この演算子は、選択フィールドまたはテキスト フィールドの形式で評価する場合に、指定された文字列または選択肢がフィールド内に存在するかどうかを確認します。
doesn’t contain - この演算子は、選択フィールドまたはテキスト フィールドの形式で評価する場合に、指定された文字列または選択肢がフィールドに存在しないことを確認します。
が次に等しくない - この演算子は、評価するフィールドが特定のパターンに正確に一致しないかどうかを確認します。
が次に等しい - この演算子は、評価するフィールドが特定のパターンに正確に一致するかどうかを確認します。テキスト フィールドの場合、評価では大文字と小文字が区別され、正確な書式設定が考慮されます。
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 - この演算子は数値フィールドで、ルールで指定された内容と正確に等しいかそれより小さな値を検索します。
例
ご利用のサービス プロジェクトで、組織のソフトウェアを使用してユーザーからバグ レポートを収集している場合、課題に対応する必要がある旨をソフトウェア チームに通知する前にバグを確認するための、ベスト プラクティスを適用できます。
この例では、"Verified" というバグ報告リクエスト タイプにチェックボックス フィールドを作成できます。次に、[リクエスト フィールドを確認] を設定することで、バグの解決プロセスを開始する前に、"Verified" フィールドをエージェントが選択したかどうかを確かめることができます。
Jira Service Management の既定のバグ報告ワークフローは以下のようになっています。
課題の作業を開始する前にバグ レポートが確認されるようにするには、次の手順を実行します。
外部サービス プロジェクトで、バグを報告リクエスト タイプを編集します。外部サービス プロジェクトについて詳しく説明します。
チェックボックス フィールドを作成し、"Verification" という名前を付けます。
このフィールドに、"Verified" と "Rejected" の 2 つのオプションを追加します。
[変更を保存] をクリックします。
[ワークフローを編集] を選択します。ワークフロー エディタが表示されます。
[Start work] トランジションを選択します。
ツールバーで [ルール] を選択します。
[リクエスト フィールドを確認] ルールを選択し、[選択] をクリックします。
[このフィールドに対応] ドロップダウンで、新しい "Verification" フィールドを選択します。
[以下として値を確認] ドロップダウンの設定は、既定の [選択] のままにします。
[以下の場合はチェック] ドロップダウンで、演算子 "が次に等しい" を選択します。
[この値] フィールドで "Verified" オプションを選択します。
これでエージェントは、リクエストの "Verified" チェックボックスを選択するまで、"Work in progress" ステータスへのトランジションを表示したり実行したりすることができなくなりました。
このプロセスを [Set as done] トランジションでも繰り返し、"Verification" フィールドで "Rejected" オプションが選択されていることを確認するようにします。これにより、ワークフローには、バグ報告への対応を実行する前に、製品でバグを確認するためのベスト プラクティスが適用されます。
リクエストがステータスを経ている場合に制限する
このルールは、リクエストがチームのワークフローで 1 つ以上の必須ステージを経由していることを確認するのに役立ちます。ワークフローの自動確認を実施し、リクエストがプロセスの手順をスキップしないようにします。または、まったく逆に、リクエストが特定のステータスを通過していないことを確認するようにセットアップすることもできます。
特定のトランジションを許可する前に、課題が特定のステータスにあったことを確認するには、次の手順を実行します。
[トランジション] ドロップダウンを使用して、前のステータスを確認するトランジションを Jira Service Management に伝えます。
[リクエストが次のステータスを経ていることを確認する] ドロップダウンで、確認したいステータスを選択します。
次のオプションを選択することもできます。
リクエストの現在のステータスを含める
既定では、トランジションを許可するかどうかを評価する際、このワークフロー ルールは以前のステータスのみを確認します。現在のステータスも評価したい場合は、[リクエストの現在のステータスを含める] チェックボックスを選択します。トランジションがステータスをリセットして未変更と表示されてしまう、トランジションのループを防ぐのに役立ちます。これによってワークフローで課題を引き続き進めることができます。
このルールを取り消す
トランジションを許可する前に、リクエストが特定のステータスを通過していないことを確認するよう、このワークフロー ルールの動作を変更できます。これにより、"却下" ステータスになった購入リクエストや機能リクエストがキューに戻されないようにできます。
リクエストの最新のステータスのみを考慮する
既定では、このワークフロー ルールはプロジェクトでのリクエストの作成以降の履歴全体を確認します。このオプションを選択すると、ルールはリクエストの現在のステータスの直前に設定されたステータスのみを評価します。場合によっては、これが現在のステータスと同じ可能性があります。また、直近のステータスがリクエストの現在のステータスと異なることを評価するため、[ループが設定されたトランジションのステータス更新を無視する] を選択することをおすすめします。
ループが設定されたトランジションのステータス更新を無視する
一部のプロジェクトはトランジションを使用して、自動化ルールや接続されたアプリのアクションをトリガーします。これらのトランジションは通常、リクエストのステータスを現在のリクエスト ステータスにリセットします。[リクエストの最新のステータスのみを考慮する] を選択した場合、最新のステータスが現在のステータスと同じである場合があります。直近のステータスがリクエストの現在のステータスと異なることを評価するため、[ループが設定されたトランジションのステータス更新を無視する] オプションを選択します。
例
ソフトウェア チームと連携するサービス チームでは、バグやその他の課題の修正が品質保証エンジニアによって検証されるのを待機してから、顧客リクエストをクローズする必要がある場合があります。たとえば、サービス チームはサービス プロジェクトからバグ レポートを収集およびリンクします。その後、サービス チームは開発チームとやり取りし、これらの課題を解決します。この場合、ワークフロー ステータスを使用して、品質保証エンジニアがレビューを行うまで、チームがチケットをクローズしないようにすることができます。
例えば、バグ レポート リクエストで、カスタマー サービス チームのステータスが次のようになる場合があります。
作業前 → 開発待ち →レビュー中 → 完了
カスタマー リクエストをプロジェクトで "完了" に設定する前に、ワークフローのステータスを品質ゲートとして使用できます。ワークフローの最後のトランジションに [リクエストがステータスを経ていることを確認する] ルールを追加すると、タスクを完了としてマークする前に品質保証エンジニアが確実にレビューを行うようにすることができます。
[リクエストがステータスを経ていることを確認する] ルールを、"完了" ステータスにつながる "すべてのステータス" トランジションに追加します。
[リクエストが次のステータスを経ていることを確認する] ドロップダウンで、"レビュー中" ステータスを選択します。
[このリクエストの現在のステータスを含める] オプションを選択します。
[リクエストの最新のステータスのみを考慮する] オプションを選択します。
[ループが設定されたトランジションのステータス更新を無視する] オプションを選択します。
これで、最新のステータスが "レビュー中" の場合にのみ "完了" にトランジションできるようになりました。
Jira Service Management を使用したバグ レポートの収集の詳細をご覧ください。
フィールドを更新するようにユーザーにリマインド
このルールはチーム管理対象プロジェクトでのみ利用できます。
このルールによって、エージェントがリクエストのステータスの変更時に関連情報を把握できるようにします。トランジションのルールを作成すると、その段階でリクエストの解決に関連する空のフィールドを記入するようにエージェントに要求することができます。このルールにより、チームで特定のフィールドに入力する必要性を覚えておくための負荷を軽減することができます。これにより、カスタマーを支援するための重要な作業に注力することができます。
Jira Service Management はチームに各トランジションで最大 40 個のフィールドを更新または確認するように要求することができます。
[For transition] ドロップダウンを使用して、チームにプロンプトを表示するタイミングを Jira Service Management に伝えます。
更新または確認してほしいフィールドを選択します。
カスタム フィールドを含む、サービス プロジェクトに追加したほとんどのテキスト、数値、ラベル、日付、または時刻フィールドを入力するように要求することができます。カスタム フィールドの詳細をご確認ください。
更新するフィールドと理由を示すパーソナライズされたメッセージを含めることができます。
例
ほとんどのサービス チームは、チケットを "完了" とマークする際にリクエストの解決方法を設定します。エージェントがチケットを解決した方法をフィールドで取得している場合、この情報をレポートで使用できます。これによって、サービス チームがカスタマーとどのようなやり取りをしたのかを詳細に確認できます。カスタマーからの連絡がなくなったためにエージェントがチケットをクローズしているかどうかを確認できます。あるいは、あるチャンネルが別のチャンネルよりもリクエストの完了に成功していることがわかります。
たとえば、リクエスト タイプに "解決状況" というカスタム ドロップダウン フィールドを作成します。このフィールドには、"修正済み"、"キャンセル済み"、"中止" などのオプションがあります。
次に、リクエスト タイプのワークフローをセットアップして、エージェントがチケットを [完了] ステータスに移動する際にリクエストの解決方法を取得するようにします。そのためには、[空のフィールドを更新するようにユーザーにリマインド] ルールをトランジションに追加し、[解決状況] フィールドを選択します。Jira Service Management はチケットを完了とマークする際に解決状況を追加するようにチームに要求します。
リクエストを移動できるユーザーを制限する
このルールでは、特定のトランジションを使用してリクエストを移動できるユーザーを強制します。
リクエストを移動できるユーザーを次のように制限できます。
リクエストの担当者。
リクエストの報告者。
自分が選択したユーザー
特定のロールを持つユーザー
- 特定のグループに所属するユーザー
- 特定の権限を持つユーザー
標準準拠や業界標準の作業方法を強制する必要があるサービス チームに便利です。ルールにより、適切な人物がワークフローに沿ってリクエストのレビューと移動を実施できるようにします。
Jira Service Management ではリクエスト タイプのワークフローで任意のトランジションを制限できます。
[For transition] ドロップダウンを使用して、制限したい経路を Jira Service Management に伝えます。
トランジションの使用を許可される個人ユーザーまたはプロジェクト ロールを選択します。最大 20 のユーザーまたはロールを選択できます。
例
一部のサービス チームには、受信したリクエストをトリアージして最適なエージェントに振り分けるマネージャーがいます。彼らはリクエストを誰かに割り当てて作業を依頼する前に、リクエストの有効性を検証したり、プロジェクト内の他の既知のリクエストにリンクさせたりする場合があります。
この場合、マネージャーやチーム リードがリクエストを適切にトリアージする前にリクエストがワークフローを移動することのないよう、ルールを使用できます。この操作を行うには、次の手順を実行します。
ワークフローで "トリアージ" ステータスを作成します。
開始ステータスを変更し、リクエストを "トリアージ" ステータスに移動させます。
リクエストの残りのワークフローへの発信トランジション ("チームに送信") を作成します。
この新しいトランジションに "Restrict who can move a request" ルールを追加して、マネージャーまたはチーム リードに制限します。
Jira Service Management により、新しく作成されたリクエストをプロジェクトの他のメンバーが進められないようにすることができます。
ユーザーが特定の権限を持っていることを確認する
このルールでは、特定のトランジションの使用をユーザーに許可する前に、ユーザーが持つ権限を確認します。この確認は、チームにとって適切なユーザーだけが適切なタイミングでリクエストを移動できるようにするのに役立ちます。このルールを使用すると、ユーザーの Jira 権限に基づいてワークフローを保護できます。
例
基本的なワークフローを使用するチームでは、ワークフローに以下のステータスがあります。
開始 → 作業前 → 進行中 → 完了
このルールを使用すると、ユーザーが特定の権限を持っていることを次の方法で確認できます。
課題の作成権限を持つユーザーのみが「開始」から「作業前」にリクエストを移動できるようにする。これによって、適切なユーザーのみがチームの作業を作成できるようになります。
課題の割り当て権限を持つユーザーのみが「作業前」から「進行中」にリクエストを移動できるようにする。これによって、リクエストの作業を開始したユーザーがそのリクエストを別のユーザーに割り当てることができるようになります。
課題のクローズ権限を持つユーザーのみが「進行中」から「完了」にリクエストを移動できるようにする。これによって、ユーザーは許可なしでリクエストを解決することができなくなります。
あるフィールドの値を別のフィールドにコピーする
[リクエスト フィールドを更新] ルール同様、こちらのルールでもデータ入力ミスが減ることで、適切な場所で適切なタイミングで作業を更新できます。主な違いとしては、このルールでは別のフィールドに基づいてフィールドが更新されます。
フィールドの値は次の場所からコピーできます。
リクエスト自体の中: あるリクエストのフィールドが同じリクエストの別のフィールドにコピーされます。
親リクエスト: リクエストの親からそれ自体にコピーされます。リクエストが別のリクエストの子である場合にのみこのオプションを使用できます (例:エピック (親) からストーリー (子) に、またはストーリー (親) からサブタスク (子) にリクエストをコピーする)。
このルールがスキップされる場合
このルールを設定した情報は、ワークフローを共有するすべてのリクエスト タイプには適用されない場合があります。そのため、次の場合はこのルールがスキップされます。
[Copy from this field (このフィールドからコピー)] と [To this field (このフィールドにコピー)] で選択したフィールドが両方ともないリクエストに対してルールが設定されている。
親リクエストからコピーするように設定されているが、リクエストに親がない。
このルールがスキップされたからといって、何か間違ったことをしたわけでも、バグがあるということでもないため心配は無用です。そのまま作業を続けても問題ありません。ルールがスキップされても、どのフィールドもコピーも更新もされないだけです。
フィールドのコピー方法
次の 3 通りの方法でフィールドを別のフィールドにコピーできます。
追加: フィールドの値がコピー先フィールドの値に追加されます。
先頭に追加: フィールドの値がコピー先フィールドの値の先頭に追加されます。
置換: フィールドの値でコピー先フィールドの値が置換されます。
コピーに対応しているフィールド タイプとそのコピー方法のリストは次のとおりです。
フィールド タイプ | 指定可能なコピー先 | コピーのタイプ |
|---|---|---|
テキスト | テキスト 要約 説明 | 追加 |
日付 | 日付 | REPLACE |
ラベル | ラベル | 追加 |
数値 | 数値 | REPLACE |
チェックボックス | チェックボックス | REPLACE |
1 つを選択 | コピー元とコピー先のタイプが同じ (例: コピー元がグループピッカーの場合はコピー先もグループ ピッカー) | REPLACE |
複数選択 | 同じタイプを複数選択 (例: バージョン ピッカー → バージョン ピッカー) | REPLACE |
ユーザー ピッカー (単一ユーザー) | ユーザー ピッカー (単一ユーザー) | REPLACE |
ユーザー ピッカー (複数ユーザー) | 追加 | |
ユーザー ピッカー (複数ユーザー) | ユーザー ピッカー (複数ユーザー) | REPLACE |
担当者 | 担当者 報告者 ユーザー ピッカー (単一ユーザー) ユーザー ピッカー (複数ユーザー) | REPLACE |
添付ファイル | 添付ファイル | 追加 |
リクエスト フィールドを更新
このルールを設定すると、リクエストに適切なタイミングで適切な情報を取り込むようにすることができます。これにより、データの入力エラーを減らし、一貫性を向上させることができます。サービス プロジェクトの内部フィールドに特に便利です。
Jira Service Management では、課題の列間での移動またはステータスの変更時に、特定のフィールドを自動的に変更できます。
[For transition] ドロップダウンを使用して、特定のフィールドを更新するステータスを Jira Service Management に伝えます。
自動更新するフィールドを選択します。
テキスト、数値、ラベル、日付、または期間フィールドやカスタム フィールドなど、プロジェクトに追加したほとんどのフィールドを更新できます。カスタム フィールドの詳細をご確認ください。
挙動には次の違いがあります。
ルールを使用してテキスト フィールドを更新すると、Jira Service Management は目的のテキストをフィールド内の既存のテキストに追加します。フィールド内の既存のテキストの置き換えは行いません。
時間または日付フィールドを更新すると、Jira Service Management はリクエストのステータス変更時の日付とタイムスタンプ (またはこのいずれか) でフィールド内のすべての要素を置き換えます。静的な時間または日付を指定することはできません。
不明なカスタム フィールド タイプ
不明なタイプのカスタム フィールドをワークフロー エディターに更新するときは、必ずカスタム フィールドのタイプと一致する値をご入力ください。そうしないとルールが機能しない場合があります。
次を使用できます。
- %%CURRENT_USER%%、リクエストをトランジションしたユーザーに置き換えられます。
- %%CURRENT_DATETIME%%、トランジションの日時に置き換えられます。
- [選択リスト (カスケード)] フィールドには、選択するオプションの値または ID を使用できます。
カスタムの日時形式
カスタムの日時形式をセットアップして、日時のフィールドを更新するようにこのルールを設定する場合は、正しい形式で入力する必要があります。その場合は、日付ピッカー フィールドの代わりに、入力方法の説明が記載されたテキスト フィールドが表示されます。
たとえば、「dd/MMMM/yyyy h:mm a」という形式で日付を入力するように指示するテキスト フィールドが表示される場合があります。入力できる日付の 1 つは、「15/July/1968 9:30 PM」です。こうした形式の詳細は「Java SimpleDateFormat」をご参照ください。
Jira のルック アンド フィールを設定して、日時の形式を変更できます。Jira のルック アンド フィールの設定に関する詳細をご確認ください。