配車・物流管理システムの要件定義は、現状と目的の整理から始め、連携と法令の要件を数値にして、現場を理解するベンダーを選ぶ流れで進みます。
配車・物流の業務は、ベテラン担当者の経験と勘に頼ってきたため、暗黙知を言葉にして伝えるのは簡単ではありません。全体像は配車/物流管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・配車/物流管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
RFP・要件定義書に盛り込むべき基本項目
RFP（提案依頼書）は、実現したいことを伝え、適切な提案と見積を得るための文書です。特に、目的や背景を具体的に書いておくと、ベンダーは自社に合った提案を組み立てやすくなります。
目的が曖昧なRFPでは、的外れな提案や過大な見積しか返らないことがあります。そのため、配車・物流管理システムのRFPは、「なぜ作るのか」という目的と背景を明確にすることから始めます。たとえば、2024年問題への対応、属人的な配車からの脱却、問い合わせ電話の削減といった課題を、具体的に書き出します。
現状業務・課題・導入目的（As-Is/To-Be）の記述
発注側は、配車の属人知を含めて現状業務（As-Is）と理想像（To-Be）を並べて整理し、何を変えたいのかをベンダーにも分かる形で示します。現行の配車表やデジタコの状況、文書化されていない制約までを、4つの面から書き出します。
- 業務と規模：車両・ドライバー・1日の配送先の数などの具体的な数字
- 現行の仕組み：配車表がExcelかホワイトボードか、デジタコの導入状況
- 暗黙の制約：配送先とドライバー、車両と地域の組み合わせなど、文書化されていないルール
- 導入目的：属人的な配車の課題と、システム化で変えたいこと
規模や実態は、言葉だけでなく数値で書くと、ベンダーに正確に伝わります。
配送先ごとの担当ドライバーや午前指定荷物の優先ルールは、文書化されていないことがあります。そのため、こうした暗黙のルールを洗い出すことが、配車要件定義の肝になります。制約を要件に落とし込めるかどうかが、現場で使えるシステムを左右します。
機能要件と非機能要件の切り分け
要件定義書では、システムの振る舞いを示す機能要件と、性能などの非機能要件を分けて書きます。
- 機能要件：配車計画、動態管理、運行日報、拘束時間管理など
- 優先度：必須・推奨・任意、またはMoSCoW（Must/Should/Could/Won’t）の区分
- 非機能要件：配車画面の同時利用人数、追跡車両数、応答速度、復旧目標、圏外動作
すべてを必須にすると費用が膨らむため、優先度の付け方が予算管理の鍵になります。
朝の配車組みや運行中はアクセスが集中するため、非機能要件も実務に合わせて具体化します。
非機能要件を曖昧にすると、稼働後に遅くて使えない問題が起き、改修費がかさむことがあります。機能と非機能の両面を要件に書き込むことが、堅実なRFPにつながります。
企業間連携と責任分界の要件化
配車・物流管理システムは、荷主・倉庫・運送会社や既存のデジタコとデータをやり取りします。そのため、誰が何を記録し、トラブル時に誰が責任を負うかを決めておかないと、運用後に責任の押し付け合いが起こります。
企業間連携の責任分界は、多くのRFPで空白になっている、配車・物流システム特有の重要論点です。特に、責任分界を要件化できるかが、配車システムの要件定義の難所になります。
荷待ち記録の責任分界・客観エビデンスの要件
2026年4月本格施行の改正物流効率化法では、年間貨物3,000万トンキロ以上、または年9万トン以上の特定事業者に義務が生じ、違反には罰金もあります。この法改正に伴い、荷待ち時間の記録も要件化のテーマになります。
- 義務の内容：CLO（物流統括管理者）選任・中長期計画・荷待ち削減
- 記録の責任：倉庫担当者の入力にするか、ドライバーの自己申告を荷主が認めるか
- 証跡のデータ：双方が証拠として合意する記録の種類
企業間の責任分界は、要件定義の段階で曖昧なまま残りがちです。そのため、客観的な証跡を残せる連携を要件に書き込んでおくことが大切です。
証跡としては、バース予約システムや荷主のWMSとの同期、トラックの入退場時刻、ドライバーアプリのGPSログなどを要件に含められます。
荷待ち記録では、誰の入力を正とし、どのデータを証跡とするかを企業間で合意しておくことが欠かせません。合意しておけば、運用後の水掛け論を防げます。
連携トランザクション・異常系・ロールバックの要件
WMSや基幹システムとのAPI連携では、正常系だけでなく障害時の動きも要件に含めます。片方の処理Aが完了しても、もう片方への送信Bがエラーになると、データの不整合が起こり得ます。
- 検知と復旧：障害の見つけ方と、データ整合性の回復方法
- 再送と冪等性：再度送る際の処理と、重複を防ぐ方法
- 責任と連絡：複数ベンダー間の原因切り分けや、境界の取り決め、障害時の体制
要件にロールバックを含めないと、連携が原因のデータ事故で現場が止まるおそれがあります。さらに、J-SOXの観点でも、企業間のデータ整合性は内部統制の対象になり得ます。異常系を要件化することが、連携の品質を決めます。
複数ベンダーが関わる場合は、配車システム、WMS、荷主の基幹システムの各社で責任境界を定めます。整合性チェックと障害時の連絡体制まで書いておくと、対応が遅れる事態を避けやすくなります。
労務・法令対応の数値要件化
要件には、どの法令の数値基準を、システムでどう担保するかを明記します。数値要件に対する提案内容を見れば、ベンダーの法令理解も判断できます。
労務・法令対応を数値で要件化すると、配車システムならではの差別化になります。さらに、法令理解を測るベンダー選定の試金石にもなります。
拘束時間・時間外労働の上限の要件化
2024年4月から、トラックドライバーの時間外労働は年960時間、拘束時間は原則年3,300時間までという上限が適用されています。要件定義書には、この上限をシステムでどう管理するかを具体的に書きます。
- 配車時の警告：当月・当年の拘束時間累計を表示し、上限を超える場合は注意を促す
- 自動集計：日次・月次・年次それぞれの拘束時間を、人の手を介さず算出
- しきい値通知：上限の80%と90%の時点で発するアラート
動態管理で取得した実拘束時間を、勤怠・給与システムへ連携する要件も定められます。労務システムとの接続まで明記すると、法令対応の確実性が上がります。
多くの製品が労務連携まで踏み込んでいないため、要件化は差別化につながります。また、NX総合研究所は、2030年度に輸送能力が約34%不足するとの試算を示しています。
ドライバー一人ひとりの労働時間を法令内で最大限活かす管理は、経営課題になっています。
デジタコ連携・二重入力回避の要件
既存デジタコ（デジタル式運行記録計）の運行データと新システムのアプリの情報が重なると、ドライバーに二重入力の負担が生じます。既存デジタコを使う会社では、この二重管理が大きな論点になります。
- 取り込み方法：メーカー・機種・データ形式（CSV/API等）
- 正データ：既存デジタコと新システムのどちらを正とするかの取り決め
- 入力負担：ドライバーに手間を増やさない設計
取り込みを怠ると、動態管理機能が負担になり、現場の反発を招くことがあります。管理される側のドライバーの操作負担を抑える配慮を要件に書き込むことが、現場定着の前提になります。
ベンダー選定と提案評価のチェックリスト
複数のベンダーを公平に比べるため、評価軸とチェックリストを事前に用意しておくと、ベンダー選定の精度を高められます。そのうえで、機能の豊富さに加えて、自社の運行実態や細かな業務をどこまで理解しているかも見極めます。
費用相場・追加開発単価・契約条件の確認
見積を評価するには、配車・物流管理システムの費用相場を把握しておく必要があります。費用の目安は方式や規模によって異なり、たとえばクラウドSaaSは初期0〜数十万・月数万〜数十万、期間1〜3ヶ月です。
- オンプレパッケージ：初期400〜500万、年保守10〜20%、期間3〜6ヶ月
- スクラッチ：小規模300〜1,000万、中規模1,000〜3,000万、大規模3,000万〜1億超
- MVP：2〜3ヶ月・100〜300万円から着手可能
スクラッチの保守は月30〜100万が目安です。また、配車表のスクラッチ見積では、大手から初回1億円・納期1年を提示された実例もあります。
追加開発の人月単価が、リリース後に当初の1.5倍へ上がる契約もあります。そのため、契約条件では追加開発の単価に注意が必要で、単価テーブルを事前に決めておきます。RFPでは、追加開発単価、保守範囲、契約期間後の単価改定ルールを、ベンダーに提示してもらいます。
riplaは、AI駆動開発により開発速度を3〜5倍に高め、期間を30〜70%短縮した実績があります。こうした生産性の実績も、見積の妥当性を見る手がかりになります。
現場理解・法令理解・補助金活用の評価軸
ベンダーの現場理解は、配車の暗黙ルールやドライバーの負担への提案から評価します。デジタコ連携や荷待ち記録の責任分界への提案も、評価の材料になります。
- 現場の制約：具体的な業務課題に踏み込んだ提案の有無
- 提案の検証：デモやPoCで実際の配車データを使い、制約を扱えるかの確認
- 補助金活用：対象制度を踏まえた投資提案の可否
「AIで全部自動化できる」という理想論は、現場で使えないシステムになるおそれがあります。そのため、現場や法令への理解を具体的な提案で確かめます。
補助金を活用した提案ができるかも、ベンダーを評価する軸の一つになります。
たとえば、物流施設DX推進実証事業費補助金（国交省）では、システム連携が上限2,500万、自動化機器が上限1億1,500万です。最大は1億4,000万、補助率は1/2です。
一方、デジタル化・AI導入補助金2026（経産省）は、ITツールが最大450万、補助率1/2です。小規模賃上げの場合は、補助率が最大4/5になります。
補助金を織り込んだ提案は、投資対効果まで考えるベンダーかどうかを判断する材料になります。発注側は、要件定義から選定まで一貫した視点で進めます。
非機能要件・移行・運用保守の要件化
稼働後の状況まで見据えることが、導入後の後悔を減らします。システムを長く安定して使うには、非機能要件、データ移行、運用保守も定義しておく必要があります。
機能や連携の要件に比べて目立ちにくいものの、これらは導入後に決めておけばよかったと感じやすい領域です。
要件定義書に稼働後の現実を盛り込むと、トラブルの少ない導入につながります。そのうえで、使い続けるための仕様も定めておきます。
性能・可用性・モバイル動作の非機能要件
朝の配車組みや運行中はアクセスが集中するため、利用状況に合わせて測定できる条件で非機能要件を示します。対象には、配車担当者とアプリの同時接続数も含まれます。求める水準は、同時利用者数や追跡車両数、ピーク時の応答速度を、具体的な数値で定めます。
- 性能：ピーク時の応答速度と、追跡できる車両数
- 画面と動態の反映：配車画面は3秒以内、100台の動態は5秒間隔で更新
- 可用性：稼働率、障害時の復旧目標時間、バックアップ方針
- 圏外対応：入力の保持と、通信回復後の自動同期
ドライバーアプリは、トンネルや山間部でも使われます。圏外で入力できないと、現場でデータが入らず使えない事態につながるため、利用シーンに沿って要件化します。
データ移行・運用保守・教育の要件
Excel配車表や旧システムから新システムへ移すデータを決め、移行の責任分担と検証方法を要件定義書に盛り込みます。
- 移行データ：車両・ドライバー・配送先の各マスタ、過去の運行実績
- 保守範囲：障害・問い合わせ対応、法改正への追従
- 支援内容：サポート時間帯と費用、マニュアル、現場向け操作研修
移行を軽く見ると、稼働直前にマスタが整っておらず慌てることがあります。マスタ整備は、稼働後の使い勝手を左右します。
法改正対応を後付けすると、最初から織り込む場合の2〜3倍のコストがかかります。そのため、保守契約に含めるかを明確にしておきましょう。
配車担当者やドライバーが無理なく使い始められるよう、教育・定着支援まで要件に含めます。
まとめ
配車／物流管理システムのRFP・要件定義書は、現状と目的の整理から始め、機能と非機能、企業間連携、労務・法令の要件を明確にします。要件を切り分けたうえで、責任分界や法令の数値、ベンダー評価の軸を順に組み立てると、要件の漏れを防げます。
荷待ちの責任分界、連携の異常系、拘束時間の数値管理を要件に含めます。加えて、デジタコの二重入力回避も盛り込みます。
発注側が、費用相場や追加開発単価を踏まえ、現場と法令を理解するベンダーを選ぶことが、導入の成否を左右します。
荷待ちの責任分界や連携の異常系を要件に書けるかで、現場で使えるシステムになるかが分かれます。
riplaは、フルスクラッチ受託とAI駆動開発の立場から、配車・物流の要件定義とRFP作成を一貫して支援しています。全体像の確認には、あらためて完全ガイドをご活用ください。
要件定義では、ベテラン配車担当者の暗黙知を言葉にし、企業間の責任分界まで定めます。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。