毎日誰かが手でやっている"定期連絡"を、仕組みにした話 #WEB自動化 #業務自動化
この記事で紹介するシステムは、私が実際に設計・開発したものです。開発工数12人日。現在も現場で稼働しています。
はじめに
納期変更、キャンセル、先行納入。
取引先や倉庫への変更連絡は、製造業の現場では毎日発生します。そしてその連絡を、今日も誰かが手動でやっています。
「うちはちゃんとできている」と思っているかもしれません。でも少し考えてみてください。
その連絡、送った後に変更が入ったとき、倉庫に伝わっていますか?
担当者が休みの日、誰かが代わりにやっていますか?
何か問題が起きたとき、いつ・何を・誰が指示したか、すぐに調べられますか?
この記事は、そういった「じわじわと積み重なる手作業の問題」を、シンプルな仕組みで解決した話です。
難しい技術の話はしません。発想の話をします。
第1章 その連絡、本当に届いていますか?
毎日夕方に繰り返される作業
ある自動車部品メーカーの業務部門では、毎日、こんな作業が行われていました。
その日と当番となった担当者はファイルサーバーを開き、その日付の変更要望Excelファイルを探します。シートには「延期・キャンセル」「先行納入」など区分ごとに欄があり、その日発生した変更内容が書き込まれています。
内容を確認したら、倉庫の担当者宛にメールを送ります。宛先は1人だけでなく、副担当者、社内の関係者数名にもCC。もし先行納入のSOSに印がついていれば、別途届いている「カンバン納入バーコード」も添付ファイルに加えます。
変更が何もない日でも、「本日の依頼はありません」というメールを送らなければなりません。それがルールだからです。
これが、毎日の業務でした。
問題が起きるのは「送った後」
この作業自体は、慣れてしまえばそれほど時間はかかりません。問題は、送信した後に変更が入ったときです。
変更要望Excelはすでにメールで送信済み。倉庫はその情報をもとに動いています。しかし送信後にキャンセルが追加され、別の担当者がそのExcelに書き込んでいた——。
「連絡した?」「いや、昨日のファイルで送ったからもう変えられない」「でも今日また変わったんだけど……」
こういったやり取りが発生し、最悪の場合、倉庫が古い情報のまま作業を進めてしまいます。クレームが出て初めて、連絡漏れに気づく。そんな経験をお持ちの方も多いのではないでしょうか。
もう一つの問題:属人化
担当者が休みの日は、誰かが代わりにやります。出張中でも連絡が入ります。「あの人がいないと送れない」という状態は、組織として脆弱です。
そして万が一クレームや問い合わせがあったとき、「あの日の変更内容を確認したい」となれば、日付ごとのExcelファイルを1つずつ開いて確認するしかありません。ファイルが何十、何百と積み重なっていく中で、それは決して簡単な作業ではありません。
第2章 なぜこうなるのか——構造的な問題
悪いのは「あなた」ではなく「構造」
ここで大切なことをお伝えしたいと思います。
こういった問題は、担当者が不注意だから起きるのではありません。「Excelファイル+手動メール」という構造そのものに、問題の根があります。
Excelファイルは、書いた後も誰でも書き直せます。「送信済み」という状態をファイル自体が持てないからです。送った後に誰かが追記しても、システムはそれを検知できません。
手動メールは、送る人間に依存します。当番制は「人が仕組みを補っている」状態です。人が変われば、やり方が変わる。担当者がいなければ、止まる。
つまりこの問題の本質は、「確定した情報」と「まだ変わるかもしれない情報」が、同じExcelファイルの中に混在していることにあります。
ここを分離すること——それが解決の鍵です。
第3章 「日付という箱」という発想
Googleカレンダーを思い浮かべてください
みなさんは、Googleカレンダーを使っていますか?
「25日は締日。請求書の発送」「毎月第1月曜は定例会議」——そういった予定を、日付の枠の中に入力する。あの使い方です。
日付という「箱」があって、その箱の中にやることを入れる。とても直感的な操作です。
このシステムの発想は、まさにそれです。
業務はもともと「日付」で動いています。「今日の変更内容を、今日の担当者が入力する」——それだけのことです。Excelの代わりに、カレンダー形式の画面に入力する。それだけで、多くの問題が解決されます。
「箱を閉じる」ことで確定する
Googleカレンダーで予定を入力したとき、その日付が過ぎたら自動的に「過去」になります。誰も昨日の枠に新しい予定は入れません。
このシステムも同じ発想です。
毎日17時になると、システムがその日の内容を自動でメール送信します。そして送信されたデータは変更できなくなります。
「箱が閉じた」状態です。
これにより、「送信済み=確定情報」が誰の目にも明らかになります。送った後に変更があっても、「今日の箱はもう閉じた。翌日以降の箱に入れてください」という運用が自然に成立します。
なぜカレンダーなのか
難しい理由はありません。「日付で動く業務には、日付を軸にした仕組みが一番わかりやすい」——ただそれだけです。
担当者に特別な操作を覚えてもらう必要もありません。カレンダーを見て、日付をクリックして、内容を入力する。それだけです。
「難しいものを使いこなす」のではなく、「使い慣れたものの構造を、業務システムに応用する」。
それがこの発想の核心です。
第4章 仕組みはこう動く
全体の流れ
担当者が画面で入力
↓
カレンダー上に内容が表示される(同じ日付に複数登録可能)
↓
17時になると自動でメール送信
↓
送信済みデータは変更不可(確定)
↓
翌日以降の日付は引き続き入力可能
入力画面のポイント
カレンダー画面では、入力できる日付に制限があります。
土曜・日曜・祝日は入力不可(業務日のみ)
過去の日付は入力不可(確定した日付は変更できない)
一斉休日に設定した日も入力不可

入力する内容は、従来のExcelシートと同じ項目です。品番、数量、受注日、納期、変更タイプ、理由コードなど。SOSの場合は添付ファイルをドラッグ&ドロップで追加できます。


自動送信の仕組み
毎日17時になると、その日に登録されたデータがまとめてExcelファイルに変換され、自動でメール送信されます。
送信先はシステムのアドレス帳で一元管理しています。担当者が変わっても、ここを変更するだけです。
送信する文面も、ケースによって変えられます。
通常時:変更内容をまとめたExcelを添付して送信
データなしの日:「本日の依頼はありません」という文面で自動送信
SOS対応時:別途の文面と添付ファイルで送信
「依頼なし」の日でも、自動でメールが送られます。担当者が何もしなくても、倉庫には毎日連絡が届きます。
変更依頼一覧と検索
登録されたすべての変更依頼は、一覧画面でいつでも確認できます。
期間を指定してExcelにダウンロードすることもできます。「先月1ヶ月間に、どんな変更依頼があったか」を振り返ったり、傾向を分析したりするのに便利です。
第5章 導入後に変わったこと
当番が不要になった
「今日の担当は誰?」という会話がなくなりました。誰でも画面にアクセスして入力できる。17時になれば自動で送信される。それだけです。
担当者が休みの日も、在宅勤務の日も、関係ありません。画面はWebブラウザで開けます。
「送った=確定」が当たり前になった
送信済みデータは変更できない。この一点だけで、「送った後に変更されて倉庫に伝わっていなかった」という問題がなくなりました。
変更があれば翌日以降の日付に入力する。運用のルールが自然と決まります。
クレーム対応が劇的に楽になった
以前は、「あの日の変更内容を確認して」と言われると、日付ごとのExcelファイルを1つずつ開いて探す必要がありました。
今は、システムの変更依頼一覧を開いて、品番や日付で検索するだけです。担当者・理由コード・変更前後の納期、すべてその場で確認できます。
分析ができるようになった
期間を指定してダウンロードしたデータを見ると、「毎月この時期に変更が集中する」「このタイプのキャンセルが多い」といった傾向が見えてきます。
それまでは「なんとなく多い気がする」だったものが、数字で確認できるようになりました。次の対策を考えるための材料が、自然と蓄積されていきます。
第6章 この考え方はどこでも使える
「日付で動く業務」はどこにでもある
このシステムの発想——「日付という箱に情報を入れ、時間になったら自動送信し、送ったら確定」——は、製造業の倉庫連絡に限った話ではありません。
次のような業務に、同じ発想が使えます。
施設・設備の予約連絡:毎日の使用予定を担当部門に通知
シフト・当番の連絡:翌日の配置を関係者に自動送信
定期報告業務:日次・週次の報告を、入力者が変わっても確実に送付
締日処理の連絡:月末の処理状況を関係部署に自動通知
工程変更の連絡:製造スケジュール変更を下流工程に確実に伝達
共通点は何か。「誰かが毎日・定期的に、手動でやっている連絡業務」です。
3つの問いで確かめてください
自社の業務を振り返るとき、次の3つを問いかけてみてください。

3つすべてに「はい」と答えられない業務があれば、「日付という箱」の発想が役に立つかもしれません。
シンプルであることが強さ
「こんなシンプルな仕組みで本当に大丈夫なのか」と思う方もいるかもしれません。
しかし現場では、複雑なシステムよりシンプルで確実に動くものの方が長く使われます。覚えることが少ない。操作に迷わない。担当者が変わっても引き継ぎが簡単。
このシステムの開発工数は、現状分析・設計・開発・テストを合わせて12人日程度でした。大掛かりなシステム投資ではありません。しかし毎日の手作業をなくし、ミスを防ぎ、クレーム対応を楽にする——その効果は、コスト以上のものがあります。工数が少ないのは、ツールとカレンダーテンプレート活用によるものです。いちから仕組みを構築するのではなく、再利用することで工数を削減する、という思想で開発をしています。
おわりに
「毎日の手作業に、慣れすぎていませんか?」
毎日繰り返している業務は、「それが当たり前」になりやすいものです。しかしその当たり前の中に、ミスの温床が潜んでいることがあります。
今回ご紹介した仕組みは、特別な技術や大きな予算が必要なものではありません。「日付という箱」という発想と、その発想を業務に当てはめる視点——それだけです。
あなたの職場で、思い当たる業務はありましたか?
気になった方へ:3つのご案内
📩 まずはメルマガ登録(無料)
この記事で紹介した「設計の考え方」を他の業務に応用した事例や、発注する際のポイントなどを定期的にお届けしています。読むだけでも、自社業務を見直すヒントになります。
👉 メルマガ登録はこちら
📋 困りごとシートを記入する(無料・10分)
「うちの業務にも使えるか確認したい」という方は、まず「困りごとシート」をご記入ください。難しいことは書かなくて大丈夫です。「なんとなく困っている」という感覚をそのまま書いていただくだけで構いません。
記入後、担当者より2営業日以内にご連絡します。
👉 困りごとシートはこちら(困りごとシートへのリンク)
🎙️ 30分の無料ヒアリング
困りごとシートをご記入いただいた方には、30分の無料ヒアリングをご案内しています。
ヒアリングでお伝えできること:
今の業務が自動化できそうかどうかの初期判断
解決のアプローチのイメージ
要望書作成にかかる時間と費用の目安
改善できる可能性のある効果予想
売り込みは一切しません。 「話を聞いてみただけ」で終わっても構いません。まず現状を整理したい、という方も歓迎です。
💼 要望書作成サービス(有料)
無料ヒアリング後、ご希望の方には要望仕様書の作成をお受けしています。
項目 内容 料金 8,000円/時間 上限時間 ヒアリング時に事前明示します 目安 シンプル:2〜3時間 / 標準:3〜4時間 / 複雑:Max5時間 納品物 要望仕様書(スライド形式・PDF) 用途 社内提案・外注発注・当社への開発依頼、いずれでも使えます
要望書は「あなたの資産」です。
当社に開発を依頼しなくても、社内提案資料として、あるいは他の外注業者への発注書として、そのままお使いいただけます。
この記事で紹介したシステムは、実際に稼働している業務システムを元に、社名・担当者名等を一般化して記載しています。
いいなと思ったら応援しよう!
応援ありがとうございます。掲載した内容が、あなたにとって、少しでも助けになれば、幸いです。活動費として使わせていただきます。