アラート処理履歴
発火した alert が「誰によって、 いつまでに、 どんな action で」 処理されたかを担当者別に可視化。 pilot 主 KPI 「アラート対応率」 計測の中核基盤。
最終更新: 2026-05-13 / 担当: 伊藤
01解決する課題
alert は発火するだけでは価値ゼロ。 「捌けたか / 漏れたか / 誰の負荷が偏っているか」 を追える状態を作る。
- alert を発火しても、 捌けたか・スルーされたかを後から追えない。
- 担当者間で alert 対応の負荷が不均衡 (例: manager A が 80%, manager B が 20%)、 でも見えない。
- 「未対応のまま 72 時間超え」 のケースを後追いできず、 talent への影響が放置される。
- executive レビュー時に「先月の alert 対応はどうだったか?」 と聞かれて答えられない。
- pilot 主 KPI 「アラート対応率」 を実測する base data がない。
02目的
担当者別の response rate と未対応 alert を可視化することで、 ① 個人負荷の偏り検出、 ② 漏れ alert の救済、 ③ pilot KPI の実測、 を 1 画面で実現する。 manager は毎週 1 回ここを見るだけで、 自身の対応漏れと相対位置がわかる状態を目指す。
03期待される効果
主 KPI 連動
アラート対応率 80% 達成
補助 KPI
担当者別偏り検知
定量効果
未対応 72h 超え 0 件
定性効果
執行レビューの可視化
04HOW (実装方式)
| 運用形態 | 半自動 (alert 発火は自動、 処理 (handled_at 記録) は manager の手動操作 or task 紐付け)。 |
|---|---|
| data source | talent_mgmt.alerts 全件 + handled_at / handled_task_id / handler_user_id 列。 pilot view: talent_mgmt.pilot_alert_response_view で集計。 |
| 集計指標 | handled_within_72h = handled の中で 72h 以内が占める割合 / fired_count = 発火総数 / 担当者別の積分。 |
| UI 配置 | 独立 page (/ops/alert-history/) を維持。 manager 用には担当者別 table + response rate 推移 chart + 未対応 list の 3 ブロック構成。 |
| UI 配置 (補助) | 担当者 KPI page 内に compact summary (response rate 1 数字) を embed。 |
| 関連 worker | tm-sns-alert (alert 生成側)、 collector は不要 (Supabase view で完結)。 |
| 権限 | manager は自分の担当 talent 分のみ。 executive は全件 + 担当者別比較。 |
05現状
設計のみ (Sprint 3 で旧 ops.html に簡易セクションあり)。 commit 5630753 時点では 「処理済み履歴」 セクションが実装されていたが、
ops.html 全体が工事中表示に切り替わったため (25045a7) 現在非表示。 pilot view (pilot_alert_response_view) は Sprint 3 で migration 済 (bb7e5e4)。
- 関連 view (Supabase):
talent_mgmt.pilot_alert_response_view - 関連 schema:
talent_mgmt.alerts.handled_at,handled_task_id - 関連 commit:
5630753(旧 UI 残骸),bb7e5e4(view 作成) - 本番 UI 化: pilot 開始後の Sprint 4 で実装予定
06残す / 残さない の判断材料
pilot 期間中の以下数値で判定。 これは alert モジュール本体の存続条件にも直結する。
- alert 発火数が週 5 件以上ある (発火がゼロなら本 page 自体が不要)。
- 担当者間で response rate に 30% 以上の差が出る (差がなければ可視化価値が低い)。
- 「未対応 72h 超え」 が月 1 件以上発生する (出ないなら救済機能不要)。
- manager / executive が月 4 回以上この page を開く (使用頻度の実測)。
- pilot 振り返りで「対応率を上げる施策」 が議論される (= dashboard が判断起点になっている)。
代替検討
Discord channel #tm-sns-alert の reaction 数で代用可能か? → 個人単位の集計ができないので不可。 本 page の独自価値は 「Supabase に紐付いた永続ログ + 担当者別集計」。