配車は、現場が動いている限り必ず変わります。
到着遅れ、前便の遅延、バース変更、車両差し替え、荷主都合、急なキャンセルなど、予定通りに進まないこと自体は珍しくありません。
問題は、変更そのものではなく、変更後の情報だけが残り、変更前の内容や理由を確認できなくなることです。
電話、口頭、LINE、メールで配車情報が上書きされると、荷待ち、再配、付帯作業、請求確認の場面で説明に時間がかかります。
配車変更の履歴は、後から確認する人によって見たい内容が変わります。
配車担当は変更の理由と差し替え内容を見たい一方で、ドライバーは最新の指示だけ確認できれば十分なこともあります。
車両変更、時刻変更、バース変更、キャンセルの理由と通知状況を確認します。
最新の到着予定、受付状況、バース、荷役状態を確認します。
行き先、時刻、受付場所、注意事項など、今必要な情報を表示します。
再配、待機、付帯作業、例外請求につながる変更履歴を確認します。
権限の切り方は、問い合わせ管理の権限・ログの考え方にも近いです（権限・ログ設計）。 履歴を残すだけでなく、誰にどこまで見せるかをあらかじめ決めます。
配車情報が上書きされる原因は、1つのレコードに最新情報も変更理由も入れてしまうことです。
設計上は、現在値と変更ログを分けて管理します。
| 区分 | 主な項目 | 見る人 | 設計上のポイント |
|---|---|---|---|
| 現在値 | 車番、到着予定、バース、荷姿、ステータス | 現場受付、倉庫、ドライバー | 最新の指示をすぐ確認できるようにする。 |
| 履歴 | 変更日時、変更者、変更前後、理由、通知先 | 配車担当、管理者、請求担当 | 変更の差分と理由をあとから確認できるようにする。 |
現場が見るのは基本的に現在値です。
管理側では履歴を確認できるようにして、現場入力を増やしすぎず、必要なときだけ変更理由や差分を見られる形にします。
現在値は、現場で今日の作業を判断するための項目です。
細かくしすぎると入力が重くなるため、まずは現場が受け入れ判断に使う項目を優先します。
履歴で重要なのは、変更後の値だけでなく、変更前との差分です。
1行の履歴を見れば、何が変わり、誰が変更し、なぜ変更したのかが分かる状態にします。
変更理由を自由記述だけにすると、後から集計しにくくなります。
まずは選択式で大分類を用意し、必要に応じて補足を書く形が使いやすいです。
この理由分類は、荷待ちの区切り記録や、付帯料金の例外とも相性が良いです。 配車変更の理由と荷待ちの発生理由をつなげて見ることで、改善すべき箇所を判断しやすくなります。
ドライバー向け画面では、履歴を細かく見せるよりも、最新の指示を間違いなく確認できることを優先します。
変更があった場合も、変更前後の詳細ではなく、現在の行き先、時刻、受付場所、注意事項を分かりやすく表示します。
荷主：東都食品 / 納品 / パレット12枚
到着予定 11:00 / 受付後 B-1 バースへ移動してください。
入場時に受付番号 A-1025 を伝えてください。待機場所は第2ヤードです。
配車変更の通知では、変更があったことだけを知らせても十分ではありません。
誰が何をすればよいのかまで分かる文面にします。
時刻、車両、バース、キャンセルなどの変更内容を登録します。
前便押し、荷主都合、交通事情などの理由を選択します。
変更前と変更後をログとして保存します。
現場、ドライバー、荷主など必要な相手へ通知します。
通知確認、荷待ち、請求確認候補を管理側で確認します。
配車変更が多い現場では、現在値と履歴を分けることが基本です。
現場やドライバーには最新の配車情報を見せ、管理側では変更日時、変更者、変更前後、理由、通知先を確認できるようにします。
現場やドライバーには、最新の時刻・バース・受付情報を分かりやすく表示します。
いつ、誰が、何を、なぜ変えたかを変更ログとして保存します。
前便押し、荷主都合、交通事情などを選択式にして、あとから集計できるようにします。
株式会社インテンスで作る場合も、現場入力を増やしすぎず、必要な履歴を確認できる構成を基本にします。 配車変更の履歴を、荷待ち改善（区切り）や請求連携（例外）までつなげると、現場対応と管理側の確認を同じ情報で扱いやすくなります。