システム活用法
ウォッチと通知の設計
この記事でわかること
「その話、聞いていません」。プロジェクトでよく聞く言葉です。一方で、通知が多すぎると大事な知らせが埋もれてしまいます。本システムには、システム通知、ウォッチ登録、メール、外部連携（Slack・Teams）と、届け方がいくつかあります。この記事では、これらを上手に組み合わせる方法を紹介します。
届く情報の4つの層
| 層 | 何が届くか | どこに届くか | 誰が設定するか |
|---|---|---|---|
| 1. 自動で届く | 担当タスクの更新・コメント、承認の依頼と結果、チャットやコミュニティでのメンション・返信、招待など | システム通知（「通知」の一覧と、画面右下のポップアップ） | 設定不要 |
| 2. 自分で選ぶ | ウォッチ登録した項目の更新やコメント | システム通知 | 各自（項目の詳細画面のウォッチボタン） |
| 3. メールで届く | 期限が今日・明日、または過ぎた担当タスク（期限リマインダー） | メール（毎朝） | 各自（プロフィールの「メール通知」） |
| 4. チャットツールに届く | 毎朝のまとめ、タスクの起票・更新 | Slack・Teams | 管理員（外部連携の通知先） |
通知の一覧には、受信日時が出ます。既読になった通知は、グレーで表示されます。
立場別：何をウォッチするか
| 立場 | ウォッチのおすすめ | ウォッチしなくてよいもの |
|---|---|---|
| PM | 優先度の高いリスク、判定待ちの変更要求、期限切れの課題、致命的・重大の不具合 | 各チーム内で完結するTODO |
| PMO | 複数チームにまたがる課題、ステータス滞留が気になる項目 | 担当者が順調に進めている項目 |
| チームリーダー | 自チームが主管の課題、他チームからの依頼 | 他チームの内部の作業 |
| 起票者 | 自分が起票した課題・変更要求・不具合 | ― |
| 経営層・利用部門 | （ウォッチより）ニュースや週次の報告で要点を受け取る | 個々の課題やTODO |
通知疲れを防ぐコツ
| コツ | 理由 |
|---|---|
| 終わった項目のウォッチは外す | 完了後の小さな更新まで届き続けるのを防ぐ |
| 「念のため」でウォッチしない | 気になるものは一覧やダッシュボードで見れば足りる |
| 1つの課題に1つの話題 | 話題が混ざると、関係ない人にも通知が届く |
| 全体への連絡はニュースで | 個別の課題のコメントで全体連絡をしない |
| メールは「期限」だけにする | 期限リマインダーは、毎朝1通にまとまる。更新の通知はシステム通知に任せる |
| Slack・Teamsには、まとめを流す | 起票・更新を全部流すと流れてしまう。まず「毎朝のまとめ」だけを選ぶ（記事「Slack・Teamsに通知を流して見落としを減らす」） |
コメントの書き方で通知を「役に立つ」ものに
- 1行目で要点を書く：「【対応完了】再テスト3件すべて合格しました」のように、通知を見ただけで内容が分かるようにします。
- お願いごとは相手と期限を書く：「田中さん、10/15までにご確認をお願いします」。
- ステータス変更と一緒に理由を残す：項目ごとの更新履歴で「何が変わったか」は分かります。コメントでは「なぜ変えたか」を書きます。
承認の通知
変更管理と成果物では、承認を依頼されると、承認者に通知が届きます。順番が自分に回ったときも通知されます。承認・却下の結果は、依頼した人に届きます。承認者は、通知から詳細画面を開き、「承認」欄で操作します。
まとめ
担当の通知は自動で届き、それ以外はウォッチで自分から選ぶ。この設計に、期限のメールと外部連携を加えると、「知るべきことは届き、関係ないことは届かない」状態を作れます。ウォッチは多すぎず、少なすぎず。立場に合わせて選びましょう。