# 社内フィードバックが「記録は残るが誰も気づかない」で死ぬのを塞ぐ 不具合・要望フォームを作ったのに報告が放置される事故は、**フォームの出来ではなく通知の設計**で起きる。 この指示書は、通知経路の穴を塞ぎ、溜まった未対応を毎日押し出すところまでを型にする。 ## 前提となる失敗（実測） フォームは動いていて、投稿はシートに記録されていた。それでも誰も気づかなかった。原因は3つ。 1. **通知先が実質1本しかなかった**。中継サーバ経由の通知だけが設定され、フォールバック用の webhook は空。中継が落ちている間の投稿は**通知ゼロ**になる。記録は残るので障害として顕在化しない。 2. **未対応を押し出す仕組みが無かった**。初回通知を見逃したら、そこで終わる。 実際に未完了1件が15日放置されていた。 3. **「未対応」の定義を間違えていた**。「対応メモが空のもの」に絞ると、 *メモは書いたが完了していない*案件が全部こぼれる。実測ではまさにその1件だけが残っていた。 ## 型1: 通知は多段フォールバックにし、全滅を検出可能にする ``` (1) 中継/API -> (2) 本人への DM -> (3) チャンネル webhook ``` - **先に成功した1つで止める**（多重通知しない） - 各段の失敗理由を配列に積み、**全滅したときだけ** `via: 'none'` と理由の連結を返す - **通知が全滅しても記録は成功扱い**にする（記録が本体、通知は best-effort）。 ただし全滅の理由は必ず残す。残さないと「静かに壊れている」状態が続く ```js var errors = []; if (config.url && config.secret) { var attempt = postRelay(config, payload); if (attempt.ok) return { ok: true, via: 'relay' }; errors.push('中継: ' + (attempt.error || '送信失敗')); } else errors.push('中継: 未設定'); if (config.botToken && config.dmUserId) { if (postDm(config.botToken, config.dmUserId, content, blobs)) return { ok: true, via: 'dm' }; errors.push('DM: 送信失敗'); } else errors.push('DM: 未設定'); if (config.webhook) { if (postWebhook(config.webhook, content, blobs)) return { ok: true, via: 'webhook' }; errors.push('webhook: 送信失敗'); } else errors.push('webhook: 未設定'); return { ok: true, via: 'none', error: errors.join(' / ') }; ``` **導入完了の条件は「実際に着信を見たこと」**。設定値を入れただけを完了と呼ばない。 疎通テスト関数（1通だけ送る）を必ず用意し、それを叩いて着信を確認する。 ## 型2: DM は webhook では送れない（Bot トークンが要る） Discord の webhook は**生成時に紐づいたチャンネルにしか投稿できない**。宛先を指定する経路が無いので、 個人 DM は Bot API を使う。2ステップ: ```js // 1) DM チャンネルを開く POST https://discord.com/api/v10/users/@me/channels headers: { Authorization: 'Bot ' + token, 'Content-Type': 'application/json' } body: { "recipient_id": "<ユーザーID>" } // -> 200, レスポンスの id が DM チャンネル。type は 1 (DM) // 2) 送る POST https://discord.com/api/v10/channels//messages // 画像なし: { "content": "..." } // 画像あり: multipart/form-data で payload_json + files[0..n] ``` - Bot は**対象ユーザーと同じサーバーに居る**必要がある（居ないと DM チャンネルを開けない） - content は 1900 文字で切る（上限 2000） - `muteHttpExceptions: true` にして**例外を投げない**。通知の失敗で記録を巻き込まない - ユーザーIDの取り方: クライアントのユーザー設定 → 詳細設定 → **開発者モード ON** → アイコンを右クリック →「ユーザーIDをコピー」 ### トークンの置き場所（ここを間違えない） **Bot トークンをクラウド側（サーバレスのプロパティストア等）へ複製するのは既定にしない。** 認証情報のコピーが増え、棚卸しの対象も増える。 - 即時通知は**中継/webhook**（クラウド側）に任せる - DM と毎日プッシュは**本人の端末で動く定期実行**から送る。トークンはその端末のローカルファイルに置いたまま - こうすると「中継が落ちて即時通知が飛ばなくても、翌朝のプッシュが記録を読んで必ず拾う」**二段構え**になる クラウド側から直接 DM したい場合だけ、意識的にトークンを置く。既定にはしない。 ## 型3: 未対応の毎日プッシュ ``` 未対応 = 状態が done / 完了 / 対応済 / 却下 のいずれでもないもの「全部」 ``` **対応メモ（返答）が入っていても除外しない。** 代わりに各行へ `未返答` / `返答済・未完了` を出して区別する。 「返答が無いものだけ」に絞ると、*返事はしたが終わっていない*案件が消えて放置される。 その他の要件: - **0件のときは送らない**。毎日の無意味通知はすぐ無視されるようになり、本番の通知まで死ぬ - **1通にまとめる**（1件1通にしない）。最大15件、超過は「ほか N 件」 - 各行に**経過日数**を出す。日付がパースできない行は `経過不明` として**落とさない** - 末尾に記録シート/DB への**リンクを1本**付ける - 列は必ず**ヘッダー名で引く**。列番号固定は壊れる（実測: `受付ID` 列が後から増えて全部ズレた） ```js var doneStates = { done: true, '完了': true, '対応済': true, '却下': true }; var state = String(row[col['状態']] || '').trim().toLowerCase(); if (doneStates[state]) continue; // メモの有無では切らない var replyState = String(row[col['対応メモ']] || '').trim() ? '返答済・未完了' : '未返答'; ``` 出力例: ``` 🐛 未対応の不具合・要望 3 件 ・[要望/返答済・未完了] 原価を集めるタスク … 経過 15 日 / 送信元: パネル ・[不具合/未返答] 印刷リストのリンクが違う … 経過 2 日 / 送信元: チェックシート / フォーム <記録シートのURL> ``` ### 定期実行 - 日次トリガー/タスクは**1本だけ**にする。設置関数は「同名ハンドラを全削除してから1本作る」形にする （再実行で増殖する事故が多い。サーバレス側はトリガー数に上限があり、溢れると**他の定期処理も止まる**） - 端末側のスケジューラで動かす場合は、ウィンドウを出さない起動方法にして、ログをファイルに残す ## 型4: 社内ルールとして明文化する 個別アプリで直しても次のアプリでまた同じ穴が空く。配布テンプレとルール文書の両方を直す。 - 「**通知先を1つも設定しないまま導入完了にしない**」を明文化する - テンプレには**ドメインや個人IDをハードコードしない**。設定値（`` ``） として外に出す。ハードコードすると他アカウントで配布物が壊れる - 社内グループウェアのリンクは、素の URL だとブラウザ既定の個人アカウントで開いて弾かれることがある。 ドメイン付きの形式に揃える設定を用意する ## チェックリスト - [ ] 通知経路が2つ以上あり、全滅時に理由が残る - [ ] 疎通テストを実行して**実際に着信を見た** - [ ] 未対応の定義が「状態が完了系でないもの全部」になっている - [ ] 0件のとき送らない - [ ] 日次トリガーが1本だけ（再実行で増えない） - [ ] 列をヘッダー名で引いている - [ ] テンプレに固有値がハードコードされていない - [ ] トークンをクラウドへ不要に複製していない ---