実際に起きる問題から設定

レビュー停滞

事例: コードレビューは1日以内に動いてほしいが、法務承認には5日かかる。

1. Flow Guard 設定 → 検出ポリシー を開く。
2. 進行中ステータスでの滞留は、全体の既定値として 72 時間を維持する。
3. ステータス別の滞留しきい値 に追加する。

レビュー中 = 24
法務確認 = 120

プレビューし、レビュー中は検出され、通常の法務確認がノイズにならないことを確認します。翌週に 想定内のワークフロー という却下が多ければ、その時間を延ばします。

プロジェクト横断の依存関係

事例: 1件の決済ブロッカーが APP、WEB、OPS の作業を止めている。

1. 検出ポリシー → ステータス別ルールと依存関係 を開く。
2. 「この課題が別の課題をブロックする」を意味する Jira リンク種別を設定する。既定は Blocks。
3. 最初はブロック継続を 24 時間にする。
4. プレビューし、優先度の高い検出結果に想定した後続プロジェクトが表示されるか確認する。

Flow Guard は閲覧できるリンクを最大5段までたどり、進行中の後続課題が多いほど、特に別のプロジェクトにまたがるほど上位にします。

リリースリスク

事例: リリースまで7日だが、残課題のうち本当に止まっているものだけを見たい。

1. Jiraバージョンに未リリースのリリース日があることを確認する。
2. リリースに影響 は 168 時間のままにする。
3. 課題単位の期限には 期限が近い 48 時間を使う。
4. 監視対象 のサイトタイムゾーンを確認し、プレビューする。

すでにフロー遅延がある課題にだけリリースシグナルが付きます。リリース週という理由だけで健全な課題を追加しません。

スプリント持ち越し

事例: 未完了の同じ課題が、完了済みスプリントから次へ繰り返し移される。

1. 検出ポリシー を開く。
2. スプリント持ち越しの検出 をオンにする。
3. プレビューし、Jira Softwareから完了スプリント履歴を取得できているか確認する。
4. 滞留・更新停止と合わせて確認する。

翌週は 再発 を見ます。再発が続く場合はワークフローの原因を疑います。

担当者不在の進行中課題

事例: 課題は進行中だが、担当者が空欄。

特別なしきい値は不要です。UNASSIGNED_ACTIVE は組み込みの15点シグナルで、滞留や更新停止も重なると優先順位が上がります。担当者設定は明示的な利用者操作で、Jiraが割り当て可能と確認した候補だけを使います。