案件の遅延を見張るPMダッシュボード
プロジェクトの遅延やブロッカーをAIが自動で見張り、毎日の進捗とバーンダウンをSlackに届けるPM自動化システム。
拡大表示（別タブで原寸を開く）Claude Code CLI / Backlog・Slack (MCP) / launchd
案内役のデジコと、約3分のノベルゲームで要点をつかめます（読むのは苦手という方に）。
このPoCから得た実装知
- 1AIはチケットを勝手に変えない。検出・通知・提案に徒し、最終判断は人が下す
- 2同一課題への連続アラートは24時間空け、通知をノイズにしない
- 3タスクワーカーの成果物は『ドラフト』。AIが作って人が確定する
判断材料
- AI 権限レベル
- 承認して動くAI
- 想定対象部門
- PM開発
このPoCが向いている会社
以下に1つでも当てはまる会社では、効果が大きい。
- 複数の案件・プロジェクトが並行し、PMが進捗を手で追っている
- 遅延やブロッカーに気づくのが遅れ、対応が後手に回る
- 毎日の進捗共有や週次レビューの準備に時間がかかっている
- AIに任せたいが、チケットを勝手に変えられるのは怖い
経営インパクト
PMがBacklogを手で巡回し、遅延・ブロッカーの検知と進捗共有に追われていた
AIが定時に巡回して遅延・ブロッカーをSlackに通知し、日次レポートと週次バーンダウンを自動配信。PMは判断に集中できる
- 削減時間
- 毎日の巡回・進捗まとめ・週次サマリ作成 → 自動
- 減ったリスク
- 遅延・ブロッカーの見落とし、対応の遅れを低減
- 判断の改善
- バーンダウンとリスク評価で、週次の意思決定が早くなる
このデータがあれば、これができる
- ▸Backlogの課題（期限・状態・担当）
- ▸過期課題・ブロッカー・遅延の検出
- ▸Slackへの巡回通知
- ▸毎朝の日次進捗レポート
- ▸通知先のSlackチャンネル
- ▸タスクのAI実行可能性
Pain：どんな痛みがあったか
プロジェクトが複数走ると、PMはBacklogを毎日見て回り、遅延・ブロッカー・未対応を拾い、進捗をまとめてSlackに共有する。これだけで一日が削られる。気づくのが遅れると対応が後手になり、週次レビューの準備にも時間がかかる。AIに任せたいが、チケットを勝手に書き換えられるのは怖い。
Intent：なぜ作ったか
PMの「見張りと共有」をAIに肩代わりさせ、PMは判断と調整に集中する。ただしAIにチケットの変更や決定は任せず、検出・通知・提案に徒する。
最初の1週間でやること
- 監視したいプロジェクト（Backlog）を1つ決める
- 通知先のSlackチャンネルを用意する
- まず巡回（遅延・ブロッカー検出）と日次レポートだけ動かす
- 1週間運用して通知の頻度・粒度を調整する
やらないこと
- AIにチケットの変更や担当アサインをさせない
- 通知を出しすぎない（連続アラートは間隔を空ける）
- AIの成果物をそのまま確定しない（ドラフト→人が確認）
- いきなり全エージェントを動かさない
費用対効果の考え方
- PMの巡回・進捗まとめ・週次準備の工数
- 遅延・ブロッカーの見落としによる手戻り
- 週次意思決定の遅れ
- 複数案件を1人で見る負荷
承認して動くAIの代表事例 — チケットは変えず、見張りと気づきを任せるPMエージェント
AIにチケットは触らせない。遅延とブロッカーの見張りと、毎日の進捗共有だけを任せる。
導入前チェックリスト
商談前に、自社側でこの 5 点を確認しておくと検討がスムーズに進む。
対象となるデータは、自社のどこにあるか
この PoC が扱うデータ: Backlog課題 / Slack通知
そのデータの更新頻度はどれくらいか（毎日 / 週次 / 不定期）
人間の承認が必要な操作は何か
この PoC は「人が確認してから実行」を前提に設計している
想定どおり動かないとき、止める方法はあるか
この PoC の止め方: Backlogのステータス変更・担当者アサインはせず提案のみ。エージェントを止めれば通知が止まるだけでチケットには影響しない。アカウント操作・権限変更は禁止
社内の担当者は誰か（運用・データ・承認の窓口）
想定担当: PM・進行管理 / Backlog・Slackの管理者