2026.10.26 DX

配車システムの失敗：定着しない5つの典型と成功させる要件定義の詰め方

配車システムの失敗は、システムが止まることより、入れたのに使われずExcel配車表へ戻る形で起きるのがほとんどです。原因の多くは製品の性能ではなく、配車係が毎日行っている判断や当日の組み替えが、導入前の要件に書かれていなかったことにあります。この記事では、配車システムが定着しない典型を5つに分け、3,000万円の配車支援システムが現場で使われなかった公表例も手がかりに、成功させるための要件定義の詰め方、判定指標、並行稼働の進め方を整理しました。最後に、失敗リスクから見た既製パッケージと受託開発の選び分けを示します。

まとめ：配車システムの失敗を分ける原因と、導入前に決める判定指標

配車システムが失敗する典型は、配車係の暗黙知が要件に入らない、マスタが不正確、ドライバー端末が使われない、拘束時間などの制約が漏れる、当日の組み替えに操作が追いつかない、の5つです。どれも導入後に表面化しますが、原因は導入前の要件定義の段階で作られています。

成功させる条件は2つに絞れます。1つ目は、配車係の1日の判断を「入力・制約・例外」に分けて書き出し、要件の土台にすることです。2つ目は、配車作成時間・手修正率・端末入力率を導入前に測り、本番稼働後に同じ指標で効果を判定することです。この2つがあれば、Excel配車表を止める日も根拠を持って決められます。

調達方法は、自社の制約が既製パッケージの設定項目に収まるかで決めます。収まるなら既製品の方が失敗しにくく、収まらない制約が配車の成否を決めているなら、受託開発で作り込む方が手戻りは小さくなります。

配車システムの失敗とは｜Excelへ戻る・併用が続く・計画だけ残る現れ方

配車システムの失敗は、障害や停止より「使われない」形で現れるのが通例です。まず失敗をどう判定するかを決めておかないと、導入の成否は担当者の印象で語られてしまいます。配車管理システムの機能や費用の全体像は配車管理システムとは？運送業の配車計画・運行計画の機能と費用・導入判断で扱っているため、ここでは失敗の現れ方に絞ります。

失敗の判定基準｜本番稼働から3か月後もExcel配車表を併用しているか

配車システムの失敗は、次の3つの状態のどれかとして現れます。

Excelへ戻る：システムが出した配車表を使わず、配車係が従来のExcel配車表で組み直している
併用が続く：システムに入力はしているが、実際の運行指示は紙やExcelで配っている
計画だけ残る：配車計画は作られるが、ドライバー側の実績入力が戻らず、計画と実績の差が分からない

本記事では、本番稼働から3か月たっても上のどれかが続いている状態を失敗の目安とします。立ち上げ直後の併用は通常の移行期間です。ただ、3か月を過ぎても止める日が決まっていない併用は、二重入力の手間だけが増え、現場の不満が積み上がる段階に入っています。

公表された失敗例｜3,000万円の配車支援システムが現場で使われなかった経緯

失敗が公の場で語られる例は多くありません。その中で具体的なのが、物流ニュースサイトのLOGISTICS TODAYが2026年9月に開いたオンラインイベントの配車システム導入の成否分ける、使える運用設計力で紹介された、高末の事例です。関東と関西を結ぶ中ロット混載輸送で、1日700件の貨物を大型トラック50台が運ぶ事業に向け、3,000万円を投じて配車支援システムを構築したものの、現場で使えなかったと報じられています。

報道によると、分割したオーダーを元に戻しにくい、途中の変更のたびに手間がかかる、大量の車両と貨物を検索する操作が現場の速さに追いつかない、といった点が原因でした。配車経験者が開発に加わっていたにもかかわらず、配車係が計画を絶えず組み替えている動きが仕様に表現されていなかったとされています。同社は3年をかけて開発チーム、社内システム部門、現場の配車担当者をつなぎ直しました。

この事例から読み取れるのは、性能より先に「配車は一度決めて終わる仕事ではない」という前提が要件から抜けていた点です。次の章の5つの典型は、どれもこの抜けの変形です。

配車システムが定着しない5つの典型｜暗黙知・マスタ・端末・制約・変更対応

5つの典型は、影響の大きい順に並べています。実務でまず確かめるのは最初の2つで、ここが崩れていると残りを直しても配車表は使われません。

配車係の暗黙知が要件に入らず、計算結果を毎回手で直し続ける失敗

ベテラン配車係は、時間指定や積載量のような書ける条件のほかに、書かれていない条件を頭の中で同時に見ています。「この納品先は10トン車だと構内に入れない」「このドライバーは月曜の早朝便に入れない」「この荷主は前日夕方に追加が来やすい」といった判断です。配車業務が属人化する構造は配車とは？物流の配車業務の流れと配車計画の組み方・属人化の解き方で詳しく扱っています。

こうした条件が要件に入らないまま導入すると、システムの配車表は毎回どこかが現場で通らず、配車係が手で直すことになります。直す手間が手作業で組む時間を上回った時点が、配車係がExcelへ戻る分岐点です。手で直した箇所を記録していない現場では、何が足りないのかも分からないまま失敗が確定してしまいます。

車両・納品先・時間指定のマスタが不正確で、配車結果が現場で通らない失敗

配車システムの計算は、車両・ドライバー・納品先・荷主・時間指定のマスタを前提にしています。車両の積載量や車格、納品先の進入可能な車格、荷受けの受付時間が古いままだと、計算は正しくても結果は現場で使えません。

マスタ整備は導入プロジェクトの中で後回しにされやすい作業です。初期登録を一度済ませても、納品先の受付時間の変更や車両の入れ替えが反映されなければ、数か月で精度は落ちていきます。そこで確かめたいのがコードの持ち方です。物流のマスタ項目やコードについては、国土交通省が物流情報標準ガイドラインをver3.00に改訂（2025年2月）しており、荷主や協力会社とデータをやり取りする前提なら、自社独自のコード体系を作る前に照らし合わせておくと後の連携で手戻りが減ります。誰がいつマスタを更新するかを、導入前に担当者の名前で決めておくことが対策になります。

ドライバー端末が使われず、運行実績が戻らないまま計画だけが残る失敗

配車システムの多くは、ドライバーがスマートフォンや車載端末で到着・荷卸し・帰庫を入力する前提で作られています。この入力が戻らないと、計画と実績の差が分からず、翌日の配車に反映する仕組みが働きません。

ドライバーが入力しない理由は、運転と荷役の合間に操作する余裕がない、入力しても自分の仕事が楽にならない、の2つに集約されます。入力項目を到着と完了のボタン2つまで減らす、デジタルタコグラフや位置情報から自動で取れる項目は入力させない、入力の結果として翌日の配車や待機時間の記録に返す、の順で手を打つと入力率は上がります。

改善基準告示の拘束時間を制約に入れず、法令上組めない配車が出る失敗

トラック運転者の労働時間には、2024年4月から改正後の改善基準告示が適用されています。厚生労働省のトラック運転者の改善基準告示のページでは、1日の拘束時間は13時間以内を基本に上限15時間、休息期間は継続11時間以上を基本に9時間を下回らないこと、連続運転時間は4時間以内と示されています（2026年10月時点の掲載内容）。

配車システムがこれらを制約として持たないと、計算上は効率のよい配車表でも、前日の帰庫時刻から休息期間が足りず翌朝の便に入れないドライバーが割り当てられます。配車係が結局それを目で確かめて直すことになり、暗黙知の失敗と同じ道をたどる結果です。告示の数値をシステムの判定条件に落とす方法は改善基準告示とは：拘束時間・休息期間の上限を運行管理システムの判定要件に翻訳するで詳しく扱っています。

当日の組み替え・分割・傭車への切り替えに操作が追いつかない失敗

配車は前日に確定して終わる仕事ではありません。当日の追加注文、キャンセル、車両の故障、渋滞による遅れで、計画は午前中から組み替えが続きます。前述の高末の事例で原因に挙げられたのも、オーダーの分割と再統合、途中変更の操作性でした。

導入前のデモは、整ったデータで翌日分の配車を一度組む場面が中心になりがちです。しかし配車係の時間を最も使うのは、組み替えの方です。オーダーを2台に分ける、傭車に切り替える、組んだ便を別の車両に移す、の3つの操作に何クリックかかるかを、自社の実データで試すまで判断を保留してください。

配車システム導入を成功させる条件｜要件定義の詰め方と並行稼働の進め方

失敗の典型を裏返すと、成功の条件は導入前の要件定義と、導入後の判定と切り替えの進め方に集まります。ここでは、受託開発でも既製パッケージでも共通する手順を示します。

要件定義の詰め方｜配車係の1日の判断を入力・制約・例外に分けて書き出す

要件定義は、製品の機能一覧から始めず、配車係の1日の判断を書き出すところから始めます。次の順に進めると、暗黙知と組み替えの操作が要件から漏れにくくなります。

配車係に、受注締めから翌朝の運行指示までの1日分の作業を時刻つきで書き出してもらう
各作業で見ている情報を「入力」（受注・車両・ドライバーの状態）、守っている条件を「制約」（時間指定・車格・拘束時間）、例外的に変えている判断を「例外」（特定荷主の優先・急な追加）に分ける
過去1〜2か月分の配車表と実績を並べ、計画から当日変わった箇所と理由を拾い、例外の一覧に足す
制約と例外のそれぞれについて、システムが計算で守るのか、人が判断して直すのかを決める

4番目の振り分けで、すべてをシステムに任せようとしないことが肝心です。前述のイベントでは、現在の配車を100％再現する前提は置かず、必要最低限の条件で70〜80点の配車を素早く作る考え方が紹介されていました。制約の条件式化の限界は自動配車システムとは？AI配車の仕組みと導入条件・受託開発の判断で扱っています。社内で要件をまとめきれない場合は、要件定義・RFP作成・PMO支援のように要件定義だけを外部に頼む方法もあります。

成功の判定指標｜配車作成時間・手修正率・端末入力率を導入前に測る

導入の成否は、導入前と同じ指標で比べなければ判定できません。導入前に少なくとも2週間分を測っておく指標は次のとおりです。

指標	測り方	失敗の兆候
配車作成時間	受注締めから運行指示を配るまで	導入前より長いまま
手修正率	システム配車のうち手で直した便の割合	3か月後も下がらない
端末入力率	到着・完了の入力があった運行の割合	特定のドライバーで低い
併用期間	Excel配車表を並行で作った日数	終了日が決まっていない

実務で最初に見るのは手修正率です。配車作成時間が縮んでいなくても、手修正率が週ごとに下がっていれば、要件の不足は埋まりつつあります。逆に手修正率が横ばいなら、暗黙知かマスタのどちらかが抜けていると判断できます。

並行稼働の進め方｜1拠点・1便種から始めてExcel配車表を止める日を決める

全拠点・全便種を一度に切り替えると、問題が起きたときに原因を切り分けられません。まずは1拠点の定期便のように、制約が少なく実績データがそろう範囲から始めます。前述のイベントでも、1営業所や限定した業務から試す方法が挙げられていました。

並行稼働の期間には、開始時点で終了日を決めておきます。終了日の判断には、前の表の手修正率と端末入力率を使います。「慣れたら止める」という決め方では、配車係にとってExcelの方が速い状態が続く限り、併用は終わりません。

稼働後の要望は運用で工夫・改修・当面不要に仕分ける判断者を置く

稼働後は現場から要望が大量に出ます。すべてを改修に回すと費用と期間が膨らみ、何も直さなければ不満だけが残るという板挟みです。高末の事例では、現場の要望を「今の機能で工夫できるもの」「改修が必要なもの」「当面不要なもの」に分類し、チームリーダーが判断する体制に組み直したと報じられています。

この仕分けは、配車業務とシステムの両方を理解した人が担う必要があります。システム会社と現場の間で伝言役になる人ではなく、何を直し何を残すかを決める権限を持つ人を、導入前から名前で決めておいてください。

失敗しにくい調達方法の選び方｜既製パッケージと受託開発を分ける判断基準

失敗の典型のうち、暗黙知と当日の組み替えは、製品の標準機能で表せるかどうかで結果が分かれます。調達方法を選ぶ軸は、この2点が既製品の設定項目に収まるかどうかです。製品タイプ別の比較と選定時の失敗は配車管理システムの比較｜3タイプの選び方と費用・受託開発の判断基準にまとめています。

既製パッケージで失敗しにくい条件と、システム導入自体を見送るべき現場

既製パッケージの方が失敗しにくいのは、配車を決める制約が台数・積載量・時間指定・拘束時間に収まり、当日の組み替えが1日に数件程度の現場です。標準機能が業務に合っていれば、要件定義は設定項目の確認で済み、立ち上げも早く進みます。業態別にどんな事例で効果が出たかは配車システムの導入事例：業態別9例で見る配車時間・車両台数の変化と判断基準で確認できます。

一方、固定ルートの定期便だけを走らせている、車両が数台で配車係が1人で十分に回せている、という現場は、配車システム自体を見送ってかまいません。この規模では、システムで縮む配車作成時間より、マスタ整備と端末入力の運用に取られる手間の方が大きくなります。

受託開発で配車システムを作るべき条件と、受託開発でも失敗する進め方

受託開発を選ぶべきなのは、オーダーの分割と再統合、共同配送の按分、荷主ごとの独自の運賃計算、既存の基幹システムとの連携のように、既製品の設定では表せない処理が配車の成否を決めている場合です。この場合、既製品を入れても配車係がExcelで補う部分が残り、それが前の章の手修正率として現れます。

ただし、受託開発なら失敗しないわけではありません。3,000万円を投じて構築した高末の配車支援システムも、配車経験者が開発に加わっていながら現場で使われませんでした。受託開発で失敗する進め方は、要件定義を現場ヒアリング数回で済ませる、組み替えの操作を画面ができてから初めて試す、稼働後の要望の判断者を置かない、の3つです。要件定義の段階で配車係の1日の判断を書き出し、組み替え操作を早い段階の試作で確かめる進め方を、物流システム開発の相談でも前提にしています。