QUALIこの記事の要点SUMMARY
- 早すぎる通知は「まだ大丈夫」で流され、その体験が次の通知の効きも下げる
- 決め方の基準は時間ではなく「気づいてから終わらせるまでに要る時間」
- 温度で期限が動く材料では、通知の時刻も動く。固定の「◯分前」は暑い日に間に合わなくなる
- 切れたあとの通知は別物として要る。切れる前の通知の再送ではない
期限が近づいたら知らせる。仕組みとしては単純です。ところが「何分前に出すか」を決める段になると、これが簡単ではないことに気づきます。残り時間そのものの決まり方は「可使時間（ポットライフ）とは？」、気温をどれだけ細かく見るかは「気温は何分ごとに取れば足りるのか」にあります。
早すぎれば「まだ大丈夫」で流されます。遅すぎれば、気づいたときには手が打てません。しかも温度で期限が動く材料では、「何分前」という指定そのものが動きます。
早すぎる通知が起こすこと
通知が効かなくなる原因の多くは、遅すぎることではなく早すぎることです。
2時間前に通知が来て、実際にはまだ十分に余裕がある。現場は「あとでやる」と判断します。この判断は、その時点では正しい。問題は、その体験が次の通知の受け取り方を変えることです。「この通知は早めに来るものだ」と学習すると、本当に急ぐべき通知も同じ扱いになります。
通知の効き目は回数ではなく、「来たら対応が要る」という信頼で決まります。一度その信頼が落ちると、間隔を短くしても戻りません。
基準は時間ではなく「終わらせるのに要る時間」
「30分前」「1時間前」という決め方は、実は根拠がありません。決めるべきは、気づいてから終わらせるまでに何分要るかです。
| 要素 | 例 | 見積もり方 |
|---|---|---|
| 気づくまで | 手が離せない作業中なら5〜15分 | 現場の作業の切れ目の間隔 |
| 移動 | 保管場所まで2〜5分 | 実測する |
| 片付け・使い切り | 残りを使い切る／回収する時間 | 材料と量による。ここが一番大きい |
| 記録 | スキャンや記入で1分 | 仕組みがあれば短い |
これを足したものが最小の余裕です。足りない時間で通知しても、通知が届いた時点で手遅れになります。逆に、この合計より大幅に早い通知は、上で書いた「流される通知」になります。
材料や工程ごとに要る時間は違うので、全部を同じ「◯分前」でそろえる根拠はありません。使い切るのに30分かかる材料と、5分で片付く材料を同じ扱いにする必要はない、ということです。
温度で期限が動くと、通知の時刻も動く
ここが見落とされやすい点です。気温で期限を補正している場合、「期限の30分前」という指定は、絶対時刻としては動きます。
朝の時点で「明日15時が期限」と計算されていれば、通知は14時30分の予定です。ところが昼に気温が上がって期限が13時40分に前倒しになれば、通知も13時10分に動かなければなりません。通知の予定時刻を最初に決めて固定してしまうと、暑い日に間に合わなくなります。
設計としての含意
「通知は期限の◯分前」という決め方をするなら、期限が動くたびに通知の予定時刻も計算し直す必要があります。逆に「開封から◯時間後に通知」という決め方は、期限が動いても通知は動かないので、暑い日にずれます。動く期限を扱うなら、通知は期限から逆算する形でなければ噛み合いません。
切れたあとの通知は、別物として要る
切れる前の通知だけを用意して終わりにすると、見逃した人には何も届きません。
期限前の通知は「準備してください」という予告です。切れたあとの通知は「もう使わないでください」という別の意味を持ちます。前者を見逃した人にこそ後者が要るので、前者の再送では役目が違います。
そして切れたあとの通知は、気づかれるまで繰り返す必要があります。1回だけ送って、その瞬間に画面を見ていなければ届きません。ただし繰り返す先は「対応できる人」でなければ意味がないので、誰に送るかは切れる前と変えたほうが実務的です。
よくある誤解
- 「早めに知らせたほうが親切」：早すぎる通知は流され、通知全体の信頼を下げます
- 「回数を増やせば気づく」：回数ではなく「来たら対応が要る」という信頼で効き目が決まります
- 「全材料を同じ◯分前で統一すべき」：片付けに要る時間が違うなら、そろえる根拠がありません
- 「切れたら赤くすれば十分」：画面を見ていない人には届きません。切れたあとの通知は別に要ります
まとめ
- 通知が効かなくなる主因は、遅すぎることより早すぎること
- 決めるべきは「◯分前」ではなく、気づいてから終わらせるまでに要る時間
- 温度で期限が動くなら、通知の時刻も期限から逆算して動かす
- 切れたあとの通知は予告の再送ではなく、別の役目として用意する
- 繰り返すなら、送る先は対応できる人にする
この分野を扱うなら ― QUALIKEEP でできること
QUALIKEEP は通知の基盤ではありません。社内チャットへの配信、メールの一斉送信、パトランプの制御などは行いません。通知は機能の一部で、本体は「現物をスキャンした瞬間の判定」のほうです。この記事で書いたとおり、通知は流されるものなので、それだけに頼る設計にはしていません。
| 領域 | QUALIKEEP が担える範囲 | 対象外（他の仕組みで扱う領域） |
|---|---|---|
| 期限前の通知 | 何分前に出すかを設定できる | —— |
| 期限切れの通知 | 切れた側も別に通知する | —— |
| 使用前の判定 | スキャン時に警告 | —— |
| 通知の基盤そのもの | （該当なし） | 社内チャット連携・メール配信・パトランプの制御はいずれも対象外 |
| 通知ワークフローの設計 | （該当なし） | 承認フローや条件分岐の組み立ては行いません |
| 見落としが起きないこと | 保証しません | 通知は気づきを助けるだけです。そもそもスキャンしない運用は止められません |
最後の行は重要です。スキャンされなければ、判定も通知も始まりません。仕組みで防げるのは「気づかずに使った」であって、「知っていて使った」ではありません。
期限そのものが動く材料を扱っているなら、まず動き方を確かめておくと設計しやすくなります。
気温別の早見表をつくる →ご注意
本記事は通知の設計についての一般的な考え方を整理したものです。実際に必要な猶予時間は、現場の作業内容・人員・材料の量によって異なります。自社の作業を実測したうえで決めてください。