
大分の運送・製造業が11月の年末繁忙期前に決める協力会社への配車依頼|電話とFAXで回している傭車の手配と運賃精算を、実績データとして残す範囲
11月から年末にかけて、自社車両だけでは荷物が捌けなくなります。そこで協力会社に配車を依頼するわけですが、その手配はたいてい電話で始まります。「明日の朝、4トン1台お願いできますか」と聞いて、口頭で了解をもらい、あとから運行指示をFAXで流す。この流れ自体は速くて確実で、繁忙期の現場では合理的です。
問題は、繁忙期が終わったあとに何も残らないことです。12月に何台傭車したのか、どの協力会社に何回頼んだのか、1台あたりいくら払ったのか。これを月末に集計しようとすると、送信済みFAXの控えとホワイトボードの書き込みと配車担当の記憶を突き合わせる作業になります。そして請求書が届いてから「この日、この便は頼んだのか」を確かめるところで止まります。
電話とFAXをやめる話ではありません
先に立場をはっきりさせておきます。繁忙期の傭車手配で、電話をやめるのは現実的ではありません。急な増便や当日の車両故障に対応できるのは電話だけで、システムに入力してから返事を待つ運用に置き換えると、かえって手配が遅れます。FAXも同じで、協力会社側の受け取り手段を自社の都合で変えることはできません。
決めるべきなのは、電話とFAXを残したまま、どこまでを実績データとして別に残すかです。手配の速さは触らず、記録の側だけを足す。この分け方をしないと、「システムを入れたら現場が電話に戻った」という結果になります。似た構図は業務システムが定着せず現場がExcelに戻る4つの理由にも書いています。
残す範囲を決めるとき、次の4つを別々に扱うと整理しやすくなります。
| 記録の種類 | 発生する場面 | 繁忙期に残せる範囲 |
|---|---|---|
| 依頼の事実 | 電話で了解を得た直後の場面 | 依頼日・協力会社・車格・区間だけ残す場合 |
| 運行指示の内容 | FAXを送る場面 | 送信済みPDFを案件に紐付けて置く場合 |
| 実績の確定 | 運行が終わった場面 | 完了・キャンセル・車格変更を後から直す場合 |
| 支払金額 | 請求書が届く場面 | 依頼1件ごとの単価と付帯料金を持つ場合 |
手順1:依頼1件を数える単位を決めます
最初に決めるのは、何を1件と数えるかです。ここが揃っていないと、あとで何を集計しても数が合いません。
運送の現場では、1日1台を1件と数える会社と、1運行(積地から卸地まで)を1件と数える会社があります。前者は日当・車建ての契約に馴染み、後者は距離制や個建ての契約に馴染みます。両方の契約が混在している場合は、車建ては日単位、距離制は運行単位と決めて、依頼データに「数え方」の列を1つ持たせてください。
そのうえで、依頼1件に持たせる項目を書き出します。繁忙期に配車担当が入力し続けられる量に絞ることが前提です。
- 依頼日と運行日(当日依頼があるため別に持ちます)
- 協力会社コード(社名の表記ゆれを避けるため、必ずコードで持ちます)
- 車格(2t・4t・10t・トレーラなど、自社の呼び方で固定します)
- 積地・卸地(自社の拠点コードと、取引先コードで持ちます)
- 元請の案件番号(自社の受注データと結び付けるための鍵です)
- 契約形態(車建て・距離制・時間制)
協力会社名を毎回手で打つと、「〇〇運輸」「〇〇運輸(株)」「〇〇運送」が別会社として集計されます。取引先マスタの重複が集計を壊す話は取引先別の売上を出したら合計が合わないで詳しく書きました。
手順2:電話の直後に30秒で入る入力の場を作ります
依頼データを残せるかどうかは、入力画面の項目数でほぼ決まります。繁忙期の配車担当は片手で受話器を持っています。この状態で入るのは、選択肢を押すだけの入力です。
現実的な設計は、依頼の瞬間は6項目だけ入れて、残りは後で足すという二段構えです。電話中に入れるのは運行日・協力会社・車格・積地・卸地・案件番号まで。ドライバー名・車番・実際の到着時刻は、運行指示のFAXを送るときか、翌朝の朝礼のタイミングで追記します。
この設計を開発会社に伝えるときは、画面の話ではなく状況の話で渡すと通じます。
【傭車依頼の入力画面について、開発側へ渡す前提】
■ 誰が入力するか
配車担当2名。11月〜12月は1日20〜40件の依頼を電話で受ける。
■ どういう状態で入力するか
- 片手で受話器を持ったまま入力する
- 相手の返事を待つ数秒の間に入力を終えたい
- 事務所のPCとタブレットの両方から入る
■ 電話中に入れる項目(必須6つ)
運行日 / 協力会社 / 車格 / 積地 / 卸地 / 元請案件番号
→ 協力会社と車格と拠点は、すべて選択式。手入力させない
→ 協力会社は「よく使う順」で上位10社が最初に出ること
■ あとから足す項目(任意)
ドライバー名 / 車番 / 到着時刻 / 特記事項(横持ち・待機の有無)
■ 満たしてほしいこと
- 必須6項目だけで保存できること(未入力の任意項目で止めない)
- 同じ協力会社に同じ運行日で複数台頼むとき、台数を指定して
1件ずつのレコードに展開できること
- 依頼後のキャンセルは削除せず、状態を「キャンセル」に変えて残すこと
最後の1行が重要です。キャンセルを削除で処理すると、「12月に何件手配して何件流れたか」が翌年に分からなくなります。
手順3:運賃の単価をどこに置くかを決めます
依頼のデータが残り始めると、次に効いてくるのが金額です。ここでよくあるのは、依頼データに単価を持たせず、請求書が来てから金額を入れる運用です。これだと請求書のチェックができません。手元に「いくらのはずか」がないからです。
単価の持ち方は、契約の実態に合わせて3通りに分かれます。
| 単価の持ち方 | 向いている場合 | 繁忙期に起きること |
|---|---|---|
| 協力会社×区間×車格の表で持つ場合 | 決まった区間を反復して頼む場合 | 表にない区間の依頼で単価が空欄になる場合 |
| 依頼のたびに都度入力する場合 | スポットの依頼が多い場合 | 電話中に金額まで決まらず未入力が残る場合 |
| 表を基準にして依頼ごとに上書きする場合 | 基本は定型で、繁忙期だけ上乗せする場合 | 上書きの理由が残らず、翌年の交渉根拠が消える場合 |
多くの会社に合うのは3つめですが、上書きしたときに理由コードを1つ選ばせる設計にしてください。「繁忙期割増」「復路空車」「指定時間厳守」といった選択肢を5個ほど用意しておくと、翌年の単価交渉で「どういうときに割増を払っていたか」を数字で出せます。
なお、燃料費や高速代の上昇分を運賃に反映する交渉については、国土交通省が標準的な運賃・標準運送約款として告示や関連資料を公開しています。自社の単価表を作り直すときの基準として確認できます。制度や告示の内容は改定されることがあるため、最新の内容は同省のページや大分運輸支局の窓口でご確認ください。
手順4:請求書との突き合わせ方を先に決めます
年末の傭車が終わり、1月に協力会社から請求書が届きます。ここで「1件ずつ照合するのか、月合計だけ見るのか」を先に決めておきます。決めていないと、実務では月合計を見て終わりになります。
現実的な線引きは、金額の差が出やすいところだけ1件ずつ照合するというものです。具体的には次の3つです。
- 単価を上書きした依頼(理由コードが付いているもの)
- 待機料・横持ち料などの付帯料金が乗った依頼
- キャンセルまたは車格変更があった依頼
これ以外の定型の依頼は、件数と単価の積が合っていれば良しとします。全件照合を目指すと、経理が1月に2日間潰れます。
突き合わせの作業をシステムに寄せるなら、協力会社からの請求データをCSVで受け取れるかを先に聞いてください。紙とFAXしか出せない協力会社が半分以上なら、その分は手入力が残ります。請求データを受け取る側の整理は入金消込が毎月2日かかると考え方が共通しています。
照合の要件を整理するときは、次のような形で条件を書き出しておくと、開発側と経理の認識が揃います。
【傭車の支払照合について、開発側へ渡す条件】
■ 突き合わせの鍵
自社の依頼番号 / 運行日 / 協力会社コード / 車格
※ 協力会社の請求書に自社の依頼番号が載らない場合が多いため、
「運行日+協力会社+車格」の3点で候補を出す設計にすること
■ 自動で一致とみなす条件
- 上記3点が一致し、金額差が0円の場合
- 定型区間(単価表に載っている区間)であること
■ 人が確認する条件(一覧に出す)
- 金額差がある場合(差額と、単価上書きの理由コードを並べて表示)
- 付帯料金(待機・横持ち・附帯作業)が乗っている場合
- 依頼データにない請求行がある場合(口頭だけで手配された便の可能性)
- 依頼データにあるのに請求されていない場合
■ 出したい帳票
- 協力会社別・月別の傭車件数と支払額
- 車格別の平均単価(前年同月と比較できること)
- 単価上書きの理由コード別の集計
つまずきやすいのは、口頭だけで走った便です
実際に運用を始めると、必ず「依頼データに存在しない請求行」が出てきます。夜間や休日に配車担当が携帯で直接頼んだ便、現場判断で車格を上げた便、翌日に持ち越して別会社に振り替えた便。これらは入力が飛びます。
対策は、入力を強制することではありません。請求照合の画面から、その場で依頼レコードを後付けで作れるようにすることです。「請求書にあるが依頼データにない」行を一覧に出し、そこから1クリックで依頼レコードを起こす。運行日・協力会社・金額は請求データから埋まっているので、車格と区間を選ぶだけで済みます。
もう1つのつまずきは、繁忙期の入力を協力会社側に求めてしまうことです。協力会社に専用の画面を配って入力してもらう構想は、平常時なら通りますが、11月から12月にかけて新しい入力を頼むと断られます。協力会社への展開は、自社側の記録が1シーズン回ってからにしてください。
なお、傭車は下請取引にあたる場面があり、発注時の書面交付や支払期日の数え方に決まりがあります。この点は1月施行の取適法に、いまの発注書と支払データで答えられますかで扱いました。依頼データを残す設計は、この記録要件とも重なります。
相談先としてのえらびの道
えらびの道は、業務システムをオーダーメイドで開発しています。卸売の受発注・請求、出張販売の管理、介護のシフト管理、ECサイトなどを作ってきました。傭車の手配のように、電話とFAXという速い手段を残したまま記録だけを足す設計は、既製のパッケージでは合わせにくい部分です。片手で入力できる画面の作り方、単価表と上書きの持ち方、請求データとの照合ルールを、御社の契約形態に合わせて組み立てるところからお手伝いできます。
データが1シーズン貯まったあとは、協力会社別・車格別の単価推移をレポートとして自動で出す、繁忙期の傭車必要台数を過去の受注データから見積もる、といった段階に進めます。最初から全部を作らず、まず依頼データを残す部分だけを小さく作って動かし、実際の繁忙期を1回通してから広げる進め方をとっています。
傭車の依頼記録と運賃精算まで、えらびの道でお手伝いできること
合同会社えらびの道は、中小企業向けのシステム受託開発と、データ活用・DX支援を行っています。卸売の受発注・請求、介護のシフト管理、出張販売の管理、EC・決済といった、現場が毎日回している業務を実際に作ってきました。この記事に書いた「手配の速さは触らず、記録の側だけを足す」という考え方も、そうした現場での実装から出てきたものです。
傭車の手配記録についても、御社の運用に合わせた形でお手伝いできます。協力会社コードと車格の呼び方を自社の言い方のまま固定する、電話の直後に選択肢を押すだけで依頼が1件残る入力の場を作る、運行が終わったあとに完了・キャンセル・車格変更を直せるようにする、届いた請求書と依頼データを突き合わせる。どこまでを繁忙期に残すかは、配車担当の手が空く範囲を見ながら一緒に決めます。
進め方としては、全部を一度に置き換えることはしません。止まると困る1業務、この場合であれば依頼の事実を残すところから動かして、運賃精算や支払明細の照合は様子を見ながら移していきます。11月の繁忙期に入ってから作り込むのは無理があるので、対象を絞る判断が要ります。
まずは現状をお聞かせください。オンラインで30分、費用はかかりません。打ち合わせから開発まで同じ人間が担当しますので、現場の話がそのまま設計に届きます。
よくある質問
傭車の手配をシステム化すると、電話での依頼はできなくなりますか?
電話は残したまま運用できます。電話で了解を得た直後に、運行日・協力会社・車格・積地・卸地・案件番号の6項目だけを選択式で入力する設計にすれば、依頼の速さは変わりません。ドライバー名や到着時刻は後から追記する形にします。
協力会社にも入力してもらう必要がありますか?
繁忙期の導入では不要です。まず自社の配車担当が入力する範囲だけで1シーズン回し、記録が貯まってから協力会社への展開を検討することをおすすめします。年末の忙しい時期に新しい入力作業を協力会社へ求めると、断られて運用が止まりやすくなります。
傭車の依頼データを残すと、具体的に何が分かるようになりますか?
協力会社別の依頼件数と支払額、車格別の平均単価、単価を上乗せした理由の内訳が月次で出せるようになります。翌年の単価交渉で「どの区間にいくら払ってきたか」を数字で示せますし、繁忙期に何台足りなかったかを見て、翌年の手配計画を立てられます。
この記事は、生成AIで下書きを作成し、実務経験にもとづいて内容を確認・編集したうえで公開しています。制度・金額・要件は年度や状況によって変わるため、実際のご判断の前に公式の窓口でご確認ください。
あわせて読みたい
資金繰り表が経理担当のExcelと頭の中にしかない|年末の賞与・納税・支払いが重なる前に、販売と購買のデータから3か月先の入出金をどこまで自動で出すか
資金繰り表を経理担当のExcelから外に出すとき、3か月先の入出金のどこまでを販売・購買データから自動で出せるのかを、項目ごとの条件で整理します。年末の賞与・納税・支払いが重なる前に決める判断軸をまとめました。
リベートの金額が期末にならないと分からない|取引先ごとに違う達成条件と支払方法を、下期の条件更新までに販売データから引き当てる手順
取引先ごとに違うリベートの達成条件と支払方法を、契約書の文章から判定できる形に分解し、月次の販売データで仮計算するまでの手順をまとめます。下期の条件更新前に決めておく線引きも書きます。
猛暑で発注が当たらない夏|需要予測を入れる前に、社内の販売データが使える状態か確かめた食品卸の話
猛暑で発注が外れ、廃棄と欠品が同時に出た食品卸の想定ケースです。需要予測を入れる前に、欠品記録・商品コード・販促日・日付の粒度という4か所を整えた流れを時系列で追います。



