自動化ルールの最適化に関するベスト プラクティス
次のベスト プラクティス ガイドラインによって自動化ルールを最適化することで、より円滑に実行できて管理しやすくなります。
管理性
ルールを作成する前に計画を立てる
自動化ルールを事前に計画すると、どのようなルールが必要になってどこで条件を使用してルールを組み合わせればよいかを認識しやすくなります。
チームの作業プロセスと発生させたいアクションから始めて、そのアクションをトリガーするイベントにさかのぼります。たとえば、課題に対する顧客のすべてのフィードバック コメントにメールを送信するか、優先度の高い課題に関するメールのみに返信するかといったことです。
ビジネスと業務プロセスに合わせた自動化計画
自動化ルールはビジネスと業務プロセスの効率向上に役立つように設計されています。自動化ルールと、ビジネスと業務プロセスは適合するようにしてください。自動化ルールの確認は、ビジネスと業務プロセスの確認と同時に行います。
使用制限内にとどめる
ルールに条件を追加する
条件を使用して、アクションが希望どおりのタイミングで行われるようにします。アクションが成功したルールのみが使用量にカウントされるので、これは月次の上限を最大限に活用するのに役立ちます。たとえば、Jira Automation では、課題ステータスのフィルターを追加して、特定のステータス ("作業前"、"進行中" など) でのみ実行することを検討してください。
ルールのスコープを確認する
ルールは、実行させたい Jira プロジェクトまたは Confluence スペースでのみ実行するようにします。たとえば、グローバル ルールがある場合は、そのルールをすべての Jira プロジェクト/Confluence に適用する必要があるかどうかを検討します。必要がない場合は、代わりにマルチ プロジェクト ルールまたはマルチ スペース ルールに変更します。
これにより、無駄なルール実行を最小限に抑え、月次の上限を最大限に活用できます。
ルールを無効にする
ルールを監視し、実行量が多すぎるルールや不要なルールを特定し、それらを無効にして、無駄なルール実行を防ぎます。
パフォーマンス
ルールのスコープを制限する
グローバル ルールはできるだけ使用しないでください。ルールを複数のプロジェクトまたはスペースに適用する必要があるかどうかや、単一のスコープのルールで十分かどうかを検討します。変更すると、一致しないルールがあるプロジェクトがフィルターによってイベントから排除されるため、ルールの効率性が向上します。その結果、実行キューに並ぶルールの数が減少します。
ルールの結合
ルールは単独でも十分機能しますが、組み合わせて使うこともできます。複数の現在のルールに対して同じルールを使えるのでしょうか。たとえば、現在のルールで分岐するルールがあり、その下で条件とアクションを実行するとします。
適切なトリガーを選択する
Some triggers are more specific than others, so if your situation requires a specific trigger, avoid using a more general one. For example, in Jira automation, Field Value Changed is far more economical than Issue Updated. This is because an issue update can encompass many things, while a field value being changed is a more specific kind of update.
ルール チェーンで可能な限り早く比較条件を使う
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).
たとえば、ルールの早い段階で条件によって issue type = Bug
バグかどうかを確認した場合はルールからバグ以外のすべてを早期に排除できるため、ルールがはるかに効率的になります。
ルールの始めにこれらの条件をチェーン化して、対応が不要なすべての課題をできる限り早く除外することが理想です。
処理量の多いチェックをルール チェーンの下位に移動する
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.
The Advanced compare condition, and those involving query languages like the JQL and CQL conditions, require more processing. Try to avoid these if possible, or push them to the back of the chain.
For example, checking if type = Done
(a JQL condition) requires more processing than comparing {{issue.status.name}}
equals Done (an Advanced compare condition).
ブランチの使用は控えめにする
ブランチは、絶対に必要な際にのみルールに追加してください。これは、ブランチによってルールに新しいプロセスが生成されるためです。ルールを組み合わせる場合は便利ですが、目的を果たさない場合はパフォーマンスに悪影響を及ぼしかねません。
この内容はお役に立ちましたか?