期限のある業務が落ちる。
契約の更新、資格や免許の更新、法定点検、助成金の申請。どれも「うっかり忘れた」で済まない種類のもので、だからこそ一覧表を作り、リマインドを設定する。それでも落ちる。
原因はたいてい、仕組みの4分の1しか作っていないことにある。
先日、期限管理の仕組みを一つ作った。題材は仕事ではなく、乳児の予防接種だった。ワクチンによっては「この日を過ぎると定期接種として公費で受けられない」という失権日が週単位で設定されていて、1日遅れると取り返しがつかない。しかも担当者は、慢性的に余裕のない状態にある。
期限が絶対で、落とすと回復不能で、担当者が疲弊している。業務の性質としては、かなり厳しい部類だ。
そこで作ったものを一般化したら、そのまま社内の期限管理に使える構造になった。この記事はその話をする。
なぜ一覧表とリマインドでは期限が守れないのか?
「締切を計算して通知する」までしか作っていないからだ。実施した事実を回収する工程と、記録のずれを検出する工程が抜けている。
期限管理の自動化と聞くと、多くの人が「締切日にアラートを出すこと」を思い浮かべる。だがそれは4つある工程のうちの2つでしかない。
改めて定義すると、こうなる。
期限管理の自動化とは、「締切を通知すること」ではなく、①締切を計算し ②本人が動ける形で届け ③実施した事実を最小の手数で回収し ④記録同士の食い違いを検出する、という4つを閉じた輪にすることである。
この4段構造——計算・配信・回収・検出——のうち、世の中の「期限管理ツール」の多くは①と②しか実装していない。通知だけの仕組みが3ヶ月で読まれなくなるのは、③と④が無いからだ。
③が無いと、システムは「まだ終わっていない」と思い続ける。終わったものまで通知し続けるので、通知の信頼性が落ちる。読まれなくなる。
④が無いと、Excelの一覧と実際の状態がずれていく。ずれていることに気づけないので、「一覧表はあるのに落ちる」が起きる。
記録の手数は、どこまで下げれば残るのか?
アプリを開かせた時点で残らない。メールへの返信で完結するところまで下げる必要がある。
今回いちばん時間をかけたのは、③の回収だった。
最初、専用の管理画面を作ろうとした。やめた。記録のためにアプリを開かせると続かないからだ。病院から帰ってきて、疲れていて、片手が塞がっている状態でログインを求めるものは使われない。
採用したのは、メールの本文にこういうリンクを置く方法だった。
<a href="mailto:自分@example.com?subject=Re:%20記録&body=済%20RT1">接種した</a>
タップすると、本文が入力済みのメールが開く。ユーザーの操作は「送信」の1回だけ。専用アプリを配らずに、実質的なボタンUIが手に入る。
受け取る側は、毎時の巡回で受信箱を検索し、本文から規則に合う1行を拾う。前後に挨拶文があっても構わない。
済 RT1 実施した
済 RT1 9/13 日付つき
予約 GS1 9/13 予約した
取消 RT1 記録を取り消す
取消 を最初から作ること。押し間違いは必ず起きる。取り消せない記録は、怖くて使われなくなる。
記号は RT1(ロタ1回目)のように短く・意味が推測でき・打ちやすいものを機械的に採番する。連番(1, 2, 3…)にしてはいけない。完了に伴って番号がずれ、事故になる。
通知を減らす機能が、なぜ必要なのか?

毎週機械的に届く通知は読まれなくなるからだ。関係のある時期だけ喋る仕組みを、先に実装する。
配信の設計で、最初に決めたのは「送らない条件」だった。
- 次の予定も期限も45日以上先なら、送信しない
期限管理の仕組みは、放っておくと毎週律儀に届く。そして「まだ先の話」が続くと、人は開かなくなる。開かなくなった頃に本当の期限が来る。
だから通知を減らす機能を作った。これが通知を効かせる条件になる。
同じ理由で、完了した項目は「次にやること」からも期限警告からも即座に消えるようにした。残っているものだけが表示される状態を保たないと、一覧は読まれない。
承認を通すものと、通さないものをどう分けるか?
「実施した」は申告された事実なので承認を通さない。承認を挟むのは、人の判断が要るものだけ。
これは設計上、かなり効いた判断だった。
社内システムを作ると、つい何でも承認フローに載せたくなる。だが「予防接種を受けた」「点検を実施した」は事実の報告であって、誰かが可否を判断するものではない。ここに承認を挟むと、承認待ちが溜まって仕組み全体が止まる。
承認が要るのは「これで完了と判断してよいか」のように、判断が入るものだけだ。事実と判断を分けないと、承認キューが詰まって、結局みんな使わなくなる。
AIに何をさせて、何をさせなかったのか?

させたのは、公的資料の規則をコード化することと、日付の計算。させなかったのは、何をいつ実施すべきかという判断。
ここは明確に線を引いた。
規則の出どころは、自治体が公開している公式資料である。こちらで新しい情報を作っていない。やったのは、公開されている規則を一度だけコードに落とし、起点日から全予定日と失権日を計算させることだけだ。
そして仕組みの冒頭に、こう書いてある。
これは医療判断ではなく、期限を落とさないための道具です。何を実施するかは専門家が決めます。
この線引きを設計に組み込むこと自体が、仕組みを信用できるものにしている。AIが判断まで踏み込むと、その判断の妥当性を誰も検証できなくなる。転記と計算に徹しているから、間違っていれば元資料と突き合わせて確認できる。
企業でAIを導入するときも同じだ。判断させるのか、計算させるのかを最初に決める。混ぜると、後から検証できないものが出来上がる。
特別な技術は要るのか?
要らない。メールとテキストだけで閉じている。
使ったものを並べると、こうなる。
| 要素 | 使ったもの | 代替になるもの |
|---|---|---|
| 規則のコード化 | プログラムのデータ定義 | 表計算+スクリプト |
| 日付計算 | 標準機能のみ | 同上 |
| 配信 | 既存のメールアカウント | 通知アプリ・チャット |
| 回収 | 受信箱の検索+文字列の抽出 | フォーム・チャットのbot |
| ボタン | mailto: リンク |
ディープリンク |
| 定期実行 | 曜日判定つきの常駐処理 | タスクスケジューラ |
新しいツールの導入も、専用アプリの配布も要らない。既にあるメールの上に載せただけである。
そしてこの構成には副次的な利点がある。システムが止まっていても、メールは受信箱に残る。後から拾い直せる。専用DBに閉じ込めると、これができない。
社内の期限業務に、どう置き換わるか?
起点日・失権日・担当者・記録の合図、この4つを差し替えれば、そのまま動く。
対応関係はこうなる。
| 育児の例 | 業務の例 |
|---|---|
| 予防接種の失権日 | 契約更新日・資格や免許の更新・法定点検・助成金の申請期限 |
| 生年月日が起点 | 入社日・契約締結日・設置日が起点 |
| 配偶者に転送 | 担当者と上長の両方に配信 |
済 RT1 の返信 |
完了 A-12 の返信 |
担当が2人いる業務では、両方から記録できることが決定的に重要になる。片方だけが記録できる仕組みは必ず破綻する。今回、配偶者に転送でき、転送先からの返信も同じように記録される設計にしたのはそのためだ。
そして冒頭の問いに戻る。
「Excelの一覧表を作って月1回みんなで確認する」で回らない理由は、③の回収が人力だからだ。
一覧表を更新する担当者が必要で、その人が忙しくなると更新が止まり、止まったことに誰も気づかない。回収の手数を「メールに返信して送信」まで下げると、記録が残るようになる。
まとめ:4段構造のうち、どれが欠けているか
期限を落とす業務があるなら、まずこれを確認してみてほしい。
- 計算 — 締切は自動で出ているか。人が数えていないか
- 配信 — 本人が動ける形で届いているか。届きすぎていないか
- 回収 — 実施した事実は、何タップで記録できるか
- 検出 — 記録と実態のずれに、気づける仕組みがあるか
多くの現場で欠けているのは3だ。そして3が無いから、4も成立しない。
通知を増やす前に、記録の手数を下げる。順番はそちらが先である。
自社の期限業務に③の回収が抜けていないか、まず一つ確認してみてください。抜けていれば、そこが最初に手をつける場所です。
業務ドックでは、業務を1件ずつ診て、どこにAIや自動化が効くかを設計しています。自社のどの業務から手をつけられるかは、無料の業務AI化診断で確かめられます。
業務のAI化、どこから始めるか迷ったら
業務ドックが、御社の業務を1件ずつ診てAI化・標準化の優先順位を設計します。まずは無料相談、または業務AI化の無料診断からどうぞ。


コメント