自動化ルールの最適化に関するベスト プラクティス

次のベスト プラクティス ガイドラインによって自動化ルールを最適化することで、より円滑に実行できて管理しやすくなります。

管理性

ルールを作成する前に計画を立てる

自動化ルールを事前に計画すると、どのようなルールが必要になってどこで条件を使用してルールを組み合わせればよいかを認識しやすくなります。

チームの作業プロセスと発生させたいアクションから始めて、そのアクションをトリガーするイベントにさかのぼります。たとえば、課題に対する顧客のすべてのフィードバック コメントにメールを送信するか、優先度の高い課題に関するメールのみに返信するかといったことです。

ビジネスと業務プロセスに合わせた自動化計画

自動化ルールはビジネスと業務プロセスの効率向上に役立つように設計されています。自動化ルールと、ビジネスと業務プロセスは適合するようにしてください。自動化ルールの確認は、ビジネスと業務プロセスの確認と同時に行います。

パフォーマンス

ルールのスコープを制限する

グローバル ルールはできるだけ使用しないでください。ルールを複数のプロジェクトまたはスペースに適用する必要があるかどうかや、単一のスコープのルールで十分かどうかを検討します。変更すると、一致しないルールがあるプロジェクトがフィルターによってイベントから排除されるため、ルールの効率性が向上します。その結果、実行キューに並ぶルールの数が減少します。

ルールの結合

ルールは単独でも十分機能しますが、組み合わせて使うこともできます。複数の現在のルールに対して同じルールを使えるのでしょうか。たとえば、現在のルールで分岐するルールがあり、その下で条件とアクションを実行するとします。

適切なトリガーを選択する

一部のトリガーは他のトリガーよりも具体的です。特定のトリガーが必要な場合は、一般的なトリガーは使用しないでください。たとえば、Jira の自動化では、フィールド値の変更更新された課題よりもはるかに無駄がありません。なぜなら、課題の更新にはさまざまなものが含まれる可能性があるのに対して、変更されるフィールド値はより具体的な更新であるためです。

ルール チェーンで可能な限り早く比較条件を使う

You want to use conditions that compare one value with another early in your rule, to eliminate possible issues or pages as early. Examples of compare conditions include the User condition, Advanced compare condition, or Issue fields condition (Jira only).

たとえば、ルールの早い段階で条件によって課題タイプ = バグかどうかを確認した場合はルールからバグ以外のすべてを早期に排除できるため、ルールがはるかに効率的になります。

ルールの始めにこれらの条件をチェーン化して、対応が不要なすべての課題をできる限り早く除外することが理想です。 

処理量の多いチェックをルール チェーンの下位に移動する

Conditions that check singular fields, such as the Issue fields condition (Jira only) or User condition, are the simplest to run so these should be earlier in your rule chain.

詳細な比較JQLCQL などのクエリ言語を含む条件には、より多くの処理が必要です。できるだけ使用を避けるか、チェーンの後半で使用するようにしてください。

For example, checking if type = Done (a JQL condition) requires more processing than comparing {{issue.status.name}} equals Done (an Advanced compare condition).

ブランチの使用は控えめにする

ブランチは、絶対に必要な際にのみルールに追加してください。これは、ブランチによってルールに新しいプロセスが生成されるためです。ルールを組み合わせる場合は便利ですが、目的を果たさない場合はパフォーマンスに悪影響を及ぼしかねません。

その他のヘルプ