イベント「3000万円をかけて作ったシステムが、現場で使えなかった」――今回のイベントは、そんな、配車支援システム導入の失敗事例を起点に議論が深められた。
配車システムを巡る議論は、ともすればAIやアルゴリズムの性能比較に傾きがちだ。しかし、システムの性能以前に、そもそも「何のために導入するのか」「誰にとって使える状態を目指すのか」を決められているだろうか。
LOGISTICS TODAYは4日、オンラインイベント「配車システム『使えない』説は本当か。第2弾」を開催した。
登壇したのは、高末・後藤尚紀氏(事業本部運送グループグループ長)、ナビタイムジャパン・内門智弥氏(ビジネスナビタイム事業部部長)、パスコ・井手修平氏(システム事業部営業統括部長)と栁原那南氏(システム事業部顧客サポート部サポート課)、Hacobu・木地谷健介氏(執行役員Hacobu Solution Studio本部本部長)、オプティマインド・松下健氏(社長)、構造計画研究所・矢野夏子氏(オペレーションズ・リサーチ部部長)、ライナロジクス・岸川智哉氏(営業部部長)、マトリックスフロー・畑本裕之氏(営業部CS部部長)の9人。
第1弾では、経営者、物流管理者、配車担当者で目指すゴールが異なることや、熟練者の暗黙知をシステムへ落とし込む難しさなど、「使えない」と言われる背景を議論した。
今回はさらに一歩進み、実際の失敗・成功事例から「どうすれば使えるところまで持っていけるのか」を探った。高末の事例を起点に、配車関連6社が導入・定着のプロセスを提示。さらにパネルディスカッションでは、システム選定以前にユーザー側が何をすべきかまで踏み込んだ。

▲(前列左から)内門氏、井出氏、LOGISTICS TODAY鶴岡モデレーター、木地谷氏、後藤氏、松下氏、矢野氏、(後列左から)岸川氏、畑本氏
配車を知る人が作っても「使えなかった」
議論の出発点となったのが、高末の経験した冒頭の事例だ。
同社がシステム化を進めたのは、関東-関西間で中ロット貨物を混載輸送する「タカスエロット便」。1日700件の貨物を扱い、大型トラック50台が幹線輸送を担う。集荷、幹線、配達へのオーダー分割や、複数荷主の積み合わせ、さらに1台の車両を複数ドライバーが乗り継ぐなど、配車条件は複雑だった。
Excel(エクセル)による管理が限界を迎え、同社は3000万円を投じて配車支援システムを構築した。
しかも、開発を進めたのは配車を知らない担当者ではない。後藤氏自身も配車係の経験を持ち、現場を知る人材を開発チームに加えていた。
それでも、完成したシステムを現場に持ち込むと答えは「使えない」だった。
一度分割したオーダーを簡単に戻せない。途中で変更が入るたびに手間がかかる。大量の車両や貨物を検索する操作性も、現場のスピードについていかない。
問題は、単に「機能が足りない」ということではなかった。
実際の配車は、決めた計画をそのまま実行する仕事ではない。荷主からの変更、積載状況、車両の動きなどを見ながら、配車担当者が絶えず組み替えている。その動きを、開発段階で十分に仕様として表現できていなかった。
後藤氏は、配車経験者が開発に参加していたにもかかわらず、「完成形のイメージができていなかった」と振り返った。
そこから同社は、3年をかけて開発チーム、社内システム部門、現場の配車担当者を改めてつなぎ直した。
現場で出た要望をすべてシステムに盛り込むのではない。「工夫すれば今の機能で使えるもの」「改修しなければ使えないもの」「いま対応する必要がないもの」に分類し、チームリーダーが判断する。
後藤氏が最後に挙げた教訓はシンプルだった。
「使えない」で諦めるのではなく、「どうしたら使えるのか」を考える。そして、機能を増やす前に「そもそも何のために導入したのか」に戻る。
現場へ「作ったから使って」と渡すだけでも、現場の要求をすべて受け入れるだけでも進まない。現場とシステム会社の間で、何を直し、何を残すかを判断する人の存在が重要だった。
6社が示した「遠回りをなくす方法」
「皆さんは、この3000万円と3年という遠回りをしたいですか」。高末の事例を受け、続くセッションでは6社がそれぞれの導入事例から、「使える状態」までの道筋を示した。
ナビタイムジャパンの内門氏は、最初から100点の配車を求めない考え方を示した。
同社はナビゲーションを起点とする強みから、大型車の規制や車格、道路状況を考慮した経路設計を得意とする。一方、現在の配車を100%再現することを前提にはせず、必要最低限の条件から70-80点の配車を素早く作り、人が修正する。ネットスーパーやEC配送などでは、経路変更によって配送効率が10-20%向上した例もあるという。
パスコの井手氏と栁原氏が示したのは、現場へ入り込むオンボーディングの重要性だ。

▲(右)パスコ栁原氏
あるリネンサプライ企業では、経営主導でシステム導入を決めたものの、ベテラン配車担当者が強く反発。栁原氏が現場から追い返されるところから始まったという。それでも通い続け、社内の橋渡し役を介して対話を重ねた結果、現在は若手がシステムで配車案を作成し、ベテランが判断・承認する体制へ変わった。
Hacobuの木地谷氏は、熟練者の配車を単に「最適化」するのではなく、その判断手順を再現するアプローチを提示した。
荷物を見る順番、得意先を組み合わせる順番、同じ車に載せるか分けるか。こうしたベテランの優先順位を写し取り、「なぜその配車になったかを説明できる、直せる、議論できる」仕組みにする。AIの進化によって、この「再現型」の実装可能性が高まっているとした。
オプティマインドの松下氏が強調したのは、「使えるためには、使うまでが大事」という点だ。
完全自動化を目標に掲げていた企業に対しても、本来の課題がベテランへの属人化なら、「誰でも現状に近い配車を組める」ことへゴールを置き直す。パッケージかフルカスタマイズかという二択ではなく、目的を再定義しながら導入プロセスを設計することが重要だとした。
構造計画研究所の矢野氏は、「何をシステム化し、何を人に残すのか」を最初に決める必要性を指摘した。
仕様書だけで完成形まで進めるのではなく、プロトタイプを現場に触ってもらい、使い勝手を確認しながら改良する。高末のように完成後に初めて現場とのずれが明らかになる事態を避けるうえでも、途中段階で検証するプロセスが重要になる。
ライナロジクスの岸川氏は、システム導入後の「定着期間」までをあらかじめ織り込んだ事例を紹介した。
BtoB配送を手掛ける企業では、導入当初、「これでは走れない」とドライバーから不満が噴出した。経営トップは「全員が早く帰れるようにするためのシステムだ」と目的を説明するとともに、半年間は試行錯誤が必要だと伝えた。配車担当者とドライバーが数か月かけて条件を調整し、最終的には帰社時間の平準化と、配車担当者の定時退社につながった。
アプローチは異なる。
しかし共通していたのは、「一発で完成させない」「100点を最初から求めない」「現場を開発の外側に置かない」という考え方だった。
システムを探す前に「人」と「目的」を決める
では、ユーザー企業は何から始めるべきなのか。
6社によるパネルディスカッションでは、「配車システム導入を長期化させず、余計なコストを発生させないためには何が必要か」を議論した。

各社から出たのは、「決める」「人選」「ブートキャンプ」「短くしない」「抽出の工夫、判断の工夫」「プロジェクト管理」といった言葉だった。
共通していたのは、システム選定の前に、現行業務を棚卸しし、誰が何を決めるのかを明確にする必要があるという点だ。
木地谷氏は、プロジェクト開始時に関係者がまとまった時間を確保し、業務を集中的に洗い出す方法を「ブートキャンプ」と表現した。
月1回の会議で少しずつ整理していては、「あの条件もあった」「このルールも必要だった」と追加要件が出続ける。配車担当者、管理者、経営層、必要に応じて営業担当者まで集まり、現在の業務を早い段階で一気に棚卸しすることが重要だとした。
一方、井手氏は「人選がすべて」と強調した。
必要なのは、現場を理解しながらITにも一定の理解があり、現場とベンダーの間をつなげる人材だ。一人で両方を満たせなくても、現場に強い人とITに強い人がチームになればよい。
さらに、誰をリーダーにするかだけではなく、どの拠点、どの業務から始めるかも重要になる。社内で発言力を持ち、周囲を動かせる人材をプロジェクトに参加させられるかが成否を左右するとの意見も出た。
問題は、そうした人ほど社内で忙しいことだ。だからこそ経営が、「片手間で進めるDX」ではなく、会社として時間を使うプロジェクトだと位置付ける必要がある。
一方、「短く、安く導入すること自体を目的にしない方がいい」との指摘もあった。
配車は、どの荷物をどの車両に載せ、どの順番で運ぶかを決める、事業収益にも直結する業務だ。
TMS(輸配送管理システム)や配車システムを、月額数万円で導入してすぐ成果が出る単純なツールとして捉えれば、ユーザーとベンダーの期待値がずれ、「使えなかった」という結果にもつながりかねない。
もちろん、最初から大規模開発をする必要があるわけではない。1営業所や限定した業務から試す方法もある。
重要なのは、導入前に「何を変えるのか」「どこまでやるのか」を決め、経営と現場、ベンダーで期待値を合わせることだ。
議論はさらに、「誰が配車を決めるのか」に広がった。
荷主と運送会社では、同じ配車計画を見ていても求めるものが異なる。
運送会社には、ドライバーのシフトや労働時間、車種・車格、荷物の組み合わせ、道路事情、軒先条件、突発的な運行変更まで含めて、実際に車を走らせる責任がある。
しかも、「この荷物同士は一緒に積めない」「この車格ではこの納品先に入れない」といった情報は、配車担当者やドライバーの頭の中に残っていることも多い。
一方、荷主は出荷情報を持っていても、実運送の詳細なデータや現場知識まで自社内に蓄積されているとは限らない。物流子会社、3PL、地域の運送会社、自社の営業部門など、巻き込む関係者が多いことも難しさになる。
そのため、荷主が積載率や輸送コストを基準に作った「最適な配車」が、運送会社にとってそのまま実行可能とは限らない。
議論では、システム選定より先に「誰が配車権、意思決定権を持つのか」を明確にすべきだとの意見が示された。
荷主が配車を主導するなら荷主側がシステムを整える。運送会社に効率化を委ねるなら、運送会社側が配車システムへ投資する。
ただし、両者の利害が完全に一致するわけではない。
今後重要になるのは、感覚ではなくデータを基に協議することだ。
荷待ち時間、積載率、契約に含まれていない作業などを可視化し、荷主と運送会社が同じ事実を見ながら条件を調整する。
配車システムは、日々のオペレーションを組むためだけでなく、両者が物流を議論するための「物差し」にもなり得る。
「現場オペレーションのための配車システム」と、「荷主と運送会社が共通言語を持つための配車システム」。同じ「配車システム」という言葉でも、その役割を分けて考える必要がありそうだ。
配車の前に「何台必要か」を読めるか
最後のパートでは、配車そのものからさらに一歩手前に視点を移し、「そもそも何台の車が必要になるのかを、荷量が確定する前に予測できないか」というテーマが取り上げられた。
マトリックスフローの畑本氏は、過去の出荷実績をAIに学習させ、翌日、1週間後、1か月後などの出荷物量を予測する仕組みを紹介した。
狙いは、ベテラン担当者の経験や勘をなくすことではない。これまで「来週は物量が増えそうだ」「この荷主はセール後に出荷が増える」と人が判断してきたノウハウをデータとして再現し、車両や倉庫作業員を事前に手配できる状態をつくることだ。
同社が3PL企業で手掛ける事例では、WMS(倉庫管理システム)に蓄積された過去の出荷実績から出荷先別、カテゴリー別の物量を予測し、倉庫内のシフト計画に活用。予測精度96.7%を示したケースも紹介された。
ただし、畑本氏はSKU単位まで細分化すれば同じ精度になるとは限らないとし、「何に使う予測なのか」から逆算して予測単位を設計する必要性を強調した。
畑本氏の説明を受け、配車システム各社との議論では、需要予測と実際の配車をつなぐ際の課題も浮かび上がった。
小売や量販店の配送では、配車を組む段階で最終的な出荷量が確定していないことも珍しくない。現在も売上額などからカゴ車本数を推測し、それを基に必要車両数を見込むケースがある。
荷量の確定を待ってから車両を集めようとしても、必要な台数を確保できず、高額なスポット車両に頼ることになりかねない。そのため、一定の精度で物量を先読みできれば、配車を段階的に組み、早めに車両を確保するための材料になるとの見方が示された。
一方、単純に「物量が何個出るか」が分かれば、そのまま必要車両数が決まるわけではない。
同じ物量でも、パレットなのかカゴ車なのか、バラ積みなのかで必要な積載スペースは変わる。議論では、出荷物量予測と配車計画の間に、荷姿や容積を含めた「物流量」へ変換する工程が必要になるとの指摘も出た。
さらに、物量だけでなく、荷物が出荷時刻までに揃うのか、バースが使えるのか、荷役人員を確保できるのかといった情報まで連動しなければ、実際の配送計画にはつながらない。
つまり、配車の最適化は配車システムの中だけでは完結しない。
需要予測、倉庫作業、人員配置、バース、車両手配。それぞれの情報をつなぐことで初めて、「荷量が確定してから配車する物流」から、「先回りして準備する物流」へ変えられる可能性がある。
ただし、ここでも最後に残るのは人の判断だった。
AIが高精度の物量予測を出しても、その数字をどこまで信じて車両を手配するのか。予測が外れた時、誰が判断の責任を持つのか。
議論では、AIが配車担当者に置き換わるのではなく、担当者自身の予測とAIの予測を比較し、判断を支える使い方が現実的だとの考え方も示された。
「使える」を決めるのは、システムの外側
高末が経験した3000万円と3年の遠回りから始まった今回の議論は、最後には配車そのものを越え、需要予測や倉庫、人員、車両手配まで広がった。
しかし、そこで繰り返し出てきた答えは共通していた。
100点の自動化を最初から求めない。何をシステムに任せ、何を人に残すのかを決める。現場をプロジェクトの外に置かない。経営と現場で目的を合わせる。そして、導入後も使いながら修正する。
配車システムが「使えるか、使えないか」は、ソリューションの性能だけで決まるものではない。
むしろ、誰が何のために使い、どこまでをシステムに任せるのかを導入前に決められるか。その準備こそが、「使えない」を避ける重要なポイントなのかもしれない。
■「より詳しい情報を知りたい」あるいは「続報を知りたい」場合、下の「もっと知りたい」ボタンを押してください。編集局にてボタンが押された数のみをカウントし、件数の多いものについてはさらに深掘り取材を実施したうえで、詳細記事の掲載を積極的に検討します。
※本記事の関連情報などをお持ちの場合、編集局直通の下記メールアドレスまでご一報いただければ幸いです。弊社では取材源の秘匿を徹底しています。
LOGISTICS TODAY編集局
メール:support@logi-today.com
LOGISTICS TODAYでは、メール会員向けに、朝刊(平日7時)・夕刊(16時)のニュースメールを配信しています。業界の最新動向に加え、物流に関わる方に役立つイベントや注目のサービス情報もお届けします。
ご登録は無料です。確かな情報を、日々の業務にぜひお役立てください。


































