FiveVai AI Lab
← 実演一覧に戻る

Backlog Watch

BacklogのタスクをAIが仕分け、朝に一覧を届け、夕方には未反応の担当者へ直接連絡する。

Backlog全課題の目視チェック → 1日2回の自動スキャン＋優先10件の自動通知
任せるAI難易度 2/5Google Apps Script (V8) / Backlog REST API / Slack Bot API / Google Sheets

このPoCから得た実装知

  1. 1「期限間近かつ停滞」を最上位カテゴリ（RED）に分けたことで、チャンネル通知の情報密度が上がった
  2. 216時の追加チェックは朝の通知一覧と同じ課題を再確認するだけでよく、Backlog APIコールを最小化できる
  3. 3Backlog /issues は projectIdOrKey を受け付けない。/projects で projectKey→projectId を変換してから検索するしかない
  4. 4GASのタイムゾーンが UTC になっていると、10時/16時のトリガーが意図しない時刻に動く。appsscript.json で Asia/Tokyo を明示する必要がある
  5. 5週次レポートでは担当者ごとの対応率（moved/alertCount）と平均スコアを前週比で並べると改善状況が見えやすい

判断材料

AI 権限レベル
任せるAI
想定対象部門
プロジェクト管理PMODXコンサルティング
扱うデータ
Backlogタスクコメント履歴Slack
人間の承認
不要（閲覧・通知のみ）
失敗時の止め方
通知の送信のみ。Backlogデータの書き換えは行わない。Slackユーザーが見つからない場合はログに記録して次の課題へ進む
導入難易度
2 / 5
初期導入期間
初回セットアップは1日以内。スクリプトプロパティ6項目の設定とトリガー作成のみ
必要な社内担当
Backlog管理者（APIキー発行）Slack管理者（Botインストール・スコープ付与）
連携対象 SaaS
BacklogSlackGoogle SheetsGoogle Calendar（祝日判定）
最小構成
BacklogのAPIキーとSlack Bot Tokenを設定するだけで、複数プロジェクトのウォッチが開始できる
横展開先
タスク管理進捗ウォッチ担当者へのリマインド週次レポート

このPoCが向いている会社

以下に1つでも当てはまる会社では、効果が大きい。

  • Backlogを複数プロジェクトで使っているが、誰がどの課題を止めているか朝会前に把握しきれていない
  • 期限切れ課題の発見が遅れ、対応が後手に回ることがある
  • PMが全プロジェクトのタスクを目視で確認する時間を毎日使っている
  • 担当者が課題に返答しないまま数日経つことが頻繁に起きている
  • 週次でプロジェクト別・担当者別の停滞状況を可視化したいが、集計が手作業になっている

経営インパクト

Before

Backlogの全課題を人が目視で確認し、期限切れ・停滞をPMが個別に追いかけていた

After

毎朝9時にプロジェクト別の上位10件が自動投稿され、未反応の担当者には16時にDMが届く。週次レポートで担当者別・プロジェクト別の傾向が把握できる

減ったリスク
期限超過の見落とし、担当者への追いかけ漏れ、週次集計の手作業ミスを低減
横展開できる型
Backlog API でのコメント最終更新の取得、10時→16時の二段通知ロジック、担当者メールを起点としたSlack DM送信のパターンは他の通知系PoCに転用できる

このデータがあれば、これができる

最小構成 ─ まずここから
INPUT DATA
  • ▸BacklogのAPIキー
  • ▸Slack Bot Token
  • ▸監視するプロジェクトキーのリスト
YOU CAN DO
  • ▸期限3日以内の課題一覧（Slackチャンネル投稿）
  • ▸担当者コメントが3日以上ない課題の通知
  • ▸未反応担当者への16時DM
発展構成 ─ ここまでつなぐと強い
INPUT DATA
  • ▸Googleスプレッドシートのconfigシート（プロジェクト設定を動的変更）
  • ▸notify_logシート（過去の通知ログ）
YOU CAN DO
  • ▸緊急度スコア（0〜10）付きの優先10件通知
  • ▸RED/DUE/STALEの3カテゴリ分類
  • ▸週次アナリティクス（担当者別・プロジェクト別の対応率・平均スコア・前週比）
  • ▸analytics_summaryシートへの自動集計書き込み

Pain — どんな痛みがあったか

PM・プロジェクトリーダーの痛み
  • 複数プロジェクトの課題を毎朝手動で確認している
  • 誰の課題が止まっているか把握するのに時間がかかる
  • 担当者に声をかけてから対応されるまで数日かかることがある
経営者・部門責任者の痛み
  • 週次で停滞状況を把握したいが、集計が属人化している
  • どのプロジェクトで課題が滞留しているか、数字で見られない

Intent — なぜ作ったか

BacklogのタスクウォッチをGASだけで完結させる。期限間近・停滞・その両方という3段階の分類で優先順位を付け、朝のチャンネル通知と夕方のDMという二段構えにした。課題の更新はBotではなく担当者が行う。通知を出すだけに徹したことで、Backlogのデータを書き換えるリスクをゼロにした。

Approach / Rationale / Lessons / 改善ログ の続きを読む

Magic Link で 60 秒。クレカ不要・退会即時。

最初の1週間でやること

  • BacklogのAPIキーを発行する
  • Slack Botを作成してワークスペースにインストールし、必要なスコープを付与する
  • GASにスクリプトプロパティ（BACKLOG_BASE_URL・BACKLOG_API_KEY・SLACK_BOT_TOKEN・LOG_SPREADSHEET_IDなど）を設定する
  • setupTriggersを実行して9時・16時・週次のトリガーを自動作成する
  • runMorningを手動実行してSlack投稿とログ記録を確認する

やらないこと

  • Backlogの課題データを自動で書き換えない（通知だけに徹する）
  • 全課題を通知しない（プロジェクト別上位10件に絞る）
  • 休日に通知しない（土日祝はGoogle カレンダーで自動スキップ）
このPoCの位置づけ

自律型通知Botの実装事例

Backlogを毎朝スキャンして止まっている課題を炙り出し、夕方には担当者へ直接届ける。人は通知を受けて動くだけでいい。

導入前チェックリスト

商談前に、自社側でこの 3 点を確認しておくと検討がスムーズに進む。

  • Backlogのプロジェクトは何件ありますか？

    スプレッドシートのconfigシートで監視対象プロジェクトを追加・変更できる

  • Slackの対応チャンネルは整備されていますか？

    プロジェクトごとにSlackチャンネルをマッピングする必要がある

  • 担当者のBacklogメールアドレスとSlackメールアドレスは一致していますか？

    16時DM送信にメールアドレス一致が必須。不一致の場合はログにエラーが記録される