TMS（輸配送管理システム）の開発・導入を成功させるかどうかは、ベンダーに渡すRFP（提案依頼書）と要件定義書の精度でほぼ決まります。輸配送の業務は、配車のルール、荷待ちの記録、デジタコや労務システムとの連携、企業をまたいだデータのやり取りなど、現場固有の「泥臭い要件」の塊です。これらを曖昧なままRFPに書くと、ベンダーごとに解釈がばらつき、見積もりも比較できず、契約後に「そんな仕様は聞いていない」という追加費用トラブルに発展します。逆に、要件を数値と責任分界まで踏み込んで言語化できれば、適正な見積もりと現場で使えるシステムを引き寄せられます。
本記事は、TMSのRFP・要件定義書・提案依頼書の作り方を、機能要件・連携要件・非機能/法令要件・ベンダー選定の4軸で具体的に解説する「要件定義特化」の記事です。とくに、企業間連携の責任分界、デジタコ・労務連携、改正物流効率化法やデータ不整合への対応など、競合記事が触れない実務要件を数値とともに整理します。読み終えるころには、自社のRFPに書き込むべき項目が明確になるはずです。なお、TMS導入の全体像をまだ把握していない方は、まずTMSの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・TMSの完全ガイド
機能要件の書き方（配車・動態・運賃）
RFPの中核は機能要件です。ただし「配車を自動化したい」「動態管理がほしい」という抽象的な書き方では、ベンダーは自社製品の標準機能を当てはめるだけで、現場の実態に合わない提案になります。機能要件は、自社の業務制約を条件レベルまで分解して書くことが鉄則です。ここでは配車・動態・運賃という主要機能について、RFPに落とすべき粒度を示します。
配車条件・制約を要件化する書き方
配車機能の要件定義で最重要なのは、自社の制約条件をすべて洗い出して明文化することです。「冷凍と常温は混載不可」「この納品先は特定ドライバーのみ」「午前指定の荷物を優先」「1台あたり最大訪問件数」など、ベテラン配車担当者の頭の中にある暗黙のルールを、条件として書き出します。これを怠ると、生成された配車案を毎回手直しすることになり、自動配車の意味が失われます。RFPには「対応すべき配車制約の一覧」を別表として添付し、各制約が標準機能で実現可能か、カスタマイズが必要かをベンダーに回答させると、提案の差が明確になります。
あわせて、配車対象の規模を数値で示すことが見積もり精度を高めます。1日の配送件数、車両台数、納品先数、ドライバー数といった規模感を明記すれば、ベンダーは必要な処理性能や画面設計を具体的に見積もれます。MVP（最小限の機能から始める）方式なら2〜3ヶ月・100〜300万円から着手できますが、いきなり全制約を完璧に作り込もうとすると、配車表のスクラッチで大手から「初回1億円・納期1年」と提示された実態のように、投資が膨らみます。RFPでは「初期リリースで満たすべき制約」と「将来対応でよい制約」を分けて優先度を示すことが、現実的な見積もりを引き出すコツです。
運賃体系・実績項目を漏れなく要件化する
運賃計算の要件定義では、自社の料金体系の全パターンを書き出すことが欠かせません。距離制・重量制・個建てといった基本形態に加え、エリア別割増、燃料サーチャージ、付帯作業料、待機料金、傭車（協力会社）への支払運賃など、契約ごとの細かいルールを要件として列挙します。実際の運賃契約書を添付し、「これらをシステムで計算できること」と明記すれば、標準機能で足りるか、カスタマイズが必要かをベンダーに判断させられます。運賃要件の書き漏らしは、稼働後に手計算が残るという形で導入効果を削ります。
実績管理についても、把握したいKPIを要件として明示します。積載率、実車率、車両別・ドライバー別の生産性、配送件数といった指標のうち、自社が経営判断に使うものを列挙し、「これらを集計・出力できること」を要件化します。とくに、運行・拘束時間の実績を集計し、2024年問題の上限（時間外労働年960時間、拘束時間原則年3,300時間）を監視できることは、後述の法令要件とも連動する重要項目です。出力フォーマット（CSV・帳票・ダッシュボード）まで指定しておくと、運用イメージのずれを防げます。
マスタ整備とデータ移行を要件に含める
機能要件の見落としで多いのが、マスタ整備とデータ移行です。TMSは車両マスタ、ドライバーマスタ、納品先マスタ、運賃マスタといった各種マスタが正確に整っていなければ、配車も運賃計算も正しく動きません。RFPには「移行対象となる既存データの種類と件数」「マスタの初期登録を誰が行うか」「移行時のデータクレンジング（重複・誤りの整理）の責任分担」を要件として書いておきます。これを曖昧にすると、稼働直前にマスタ整備が終わらず、本番開始が遅延する事態を招きます。
あわせて、稼働後にマスタを誰がどう保守するかも要件化します。新しい車両やドライバーの追加、運賃改定、納品先の変更といった日常的な更新を、現場の担当者が無理なく行える管理画面でなければ、運用が回りません。一括登録・一括更新（CSVインポート等）の機能要件を明記しておくと、運用負荷を抑えられます。マスタとデータ移行は地味な領域ですが、ここを要件から抜かすと、稼働後に「データが不正確で使えない」という根本的な失敗につながるため、初期要件にしっかり織り込むことが大切です。
連携要件と企業間の責任分界の要件化
TMSの要件定義で、競合記事がもっとも手薄なのが連携要件、とりわけ企業をまたいだデータ連携の責任分界です。「API連携で全体最適」という理想論では、契約後に責任の押し付け合いが起こります。連携はTMS単独では完結せず、相手システムや相手企業の協力が前提になるため、RFPの段階で「誰が、どのデータを、どう保証するか」まで踏み込んで要件化することが、後のトラブルを防ぎます。
トランザクション不整合・ロールバックの要件
企業間連携で見落とされがちなのが、トランザクション（一連の処理）の途中で起きる不整合への対処です。たとえば自社側の処理は完了したのに、相手企業へのデータ送信がエラーになった場合、両社のデータがずれたまま放置されると、配送指示の二重化や欠落といった事故につながります。RFPには「連携処理が途中で失敗した場合の検知方法」「再送・ロールバック（処理の巻き戻し）の仕組み」「不整合が起きた際のアラートと復旧手順」を要件として明記すべきです。これらを曖昧にすると、障害時に「どちらのシステムの責任か」で揉めることになります。
あわせて、複数ベンダーが関わる場合の責任境界を要件・契約として定義しておくことが重要です。自社TMS、相手企業のシステム、連携基盤がそれぞれ別ベンダーだと、障害時の切り分けが難しくなります。RFPで「障害発生時の一次切り分けの責任範囲」「ログの保存と相互開示」を求めておけば、運用フェーズでの押し付け合いを防げます。内部統制の観点では、J-SOX対応として処理証跡（ログ）の保全やロールバック設計を要件に含めることも、後付けの追加開発を避けるうえで有効です。
デジタコ・労務システム連携の要件
既存のデジタルタコグラフ（デジタコ）や労務システムとの連携も、RFPに具体的に書くべき要件です。多くの運送会社はすでにデジタコで運行記録を取っており、ここにTMSや荷主指定アプリが加わると、ドライバーが同じ情報を二度入力する二重管理が発生します。RFPには「既存デジタコの機種・データ形式」を明記し、「デジタコの運行データをTMSに取り込み、ドライバーの二重入力を発生させないこと」を要件として求めます。これにより、既存資産を捨てずに連携できるかをベンダーに判断させられます。
さらに踏み込むなら、動態・運行データを勤怠・給与システムへ流す労務連携を要件に含めることをおすすめします。実際の拘束時間データを労務システムへ自動連携すれば、2024年問題の上限を「人の集計」ではなく「システムの仕組み」で監視できます。この労務連携まで踏み込んだ要件は競合記事でもほとんど触れられていませんが、罰則を伴う法規制時代には大きな価値を持ちます。RFPで「運行実績データを勤怠・給与システムへ連携し、拘束時間上限の超過アラートを出せること」を求めておくと、コンプライアンスを仕組みで担保できるベンダーを選別できます。
非機能要件と法令要件の盛り込み方
機能要件だけでなく、性能・可用性・セキュリティといった非機能要件と、輸配送特有の法令要件もRFPに盛り込む必要があります。これらは見落とされやすい一方で、稼働後の安定性やコンプライアンスを左右します。とくにTMSはドライバーが現場で使うため、性能要件と法令対応を曖昧にすると、後から高コストの追加開発を招きます。
性能・可用性・モバイル要件の数値化
非機能要件は、感覚ではなく数値で書くのが原則です。配車処理が「何件の配送・何台の車両を、何秒以内に計算できるか」、動態画面が「同時に何台を表示しても遅延しないか」といった性能要件を数値化します。可用性についても、「稼働率99.9%以上」「障害時の復旧目標時間」を明記します。TMSは配送が止まると事業が止まるため、可用性は事業継続要件そのものです。これらを曖昧にすると、ピーク時に処理が遅延して使い物にならない、といった事態を招きます。
TMS固有の非機能要件として、モバイル・オフライン対応も重要です。ドライバーは電波の弱いエリアや地下駐車場でアプリを使うため、「通信が切れても入力でき、復旧後に自動同期されること」を要件化しておくと、現場の使い勝手が大きく変わります。バッテリー消費や端末スペックの前提もRFPに書いておくと、提案のずれを防げます。動態管理アプリは現場のドライバーが毎日使うため、机上の性能だけでなく、実際の運行環境で動くかを要件として問うことが欠かせません。
改正物流効率化法・2024年問題への対応要件
法令要件は、TMSの要件定義で外せない柱です。2024年4月からドライバーの時間外労働は年960時間、拘束時間は原則年3,300時間までに制限されています。RFPには「これらの上限を超過しないよう運行・拘束時間を集計し、超過前にアラートを出せること」を要件として明記します。法令の数値を要件に直接書き込むことで、「労務管理に対応」という曖昧な提案ではなく、具体的なアラート機能の有無で比較できます。
さらに、2026年4月本格施行の改正物流効率化法への対応も要件化します。この法律では、年間貨物3,000万トンキロ以上（または年9万トン以上）の特定事業者にCLO（物流統括管理者）の選任や中長期計画の策定、荷待ち削減が義務付けられ、違反には罰金が科されます。RFPには「荷待ち時間を客観データとして記録・集計できること」「荷待ち削減の取り組みを定量的に報告できること」を盛り込みます。法令対応を後付けすると、新規織り込み時の2〜3倍のコストがかかるため、最初から要件に含めておくことが結果的にコストを抑える賢明な進め方です。
RFPの構成とベンダー選定の進め方
要件を洗い出したら、それをRFP（提案依頼書）という文書に構成し、ベンダーに提示します。RFPは見積もりを引き出すための単なる依頼書ではなく、自社の業務を理解しているベンダーを見極める選定ツールでもあります。構成と評価方法を整えることで、価格だけでなく業務適合度で比較できるようになります。
RFPに盛り込む基本構成と記載項目
RFPの基本構成は、プロジェクトの背景・目的、自社の現状業務、機能要件、連携要件、非機能・法令要件、予算と納期の前提、提案してほしい内容、評価基準という流れで組み立てます。背景には「2024年問題・改正物流効率化法への対応」「属人的配車からの脱却」といった導入の狙いを書き、ベンダーが目的を共有できるようにします。現状業務には、配送件数・車両台数・既存システム（デジタコ・WMS・基幹）を具体的に記載し、提案の前提をそろえます。
予算と納期は、隠さず前提を示すことが良い提案を引き出すコツです。「クラウドSaaSなら月数万〜数十万円・導入1〜3ヶ月、スクラッチなら小規模300〜1,000万円・3〜6ヶ月」といった相場感を踏まえ、自社の想定レンジを伝えると、ベンダーは現実的な提案に集中できます。あわせて、追加開発が発生した場合の人月単価を事前に取り決める旨をRFPに記載しておくと、稼働後に「追加開発の人月単価が1.5倍になる」といった契約の罠を避けられます。単価テーブルを事前に固定させることが、後の費用膨張を防ぐ実務的な防御策です。
ベンダーの業務理解を見抜く選定チェック
RFPへの回答を評価する際は、機能の○×だけでなく、ベンダーが輸配送の泥臭い業務をどこまで理解しているかを見抜くことが大切です。荷待ち記録の責任分界、デジタコ二重管理、企業間連携のトランザクション不整合といった難所について、具体的な解決アプローチを提案できるかが、業務理解度のリトマス試験紙になります。これらに踏み込んだ提案をするベンダーは、現場で使えるシステムを作れる可能性が高いといえます。
あわせて、補助金活用や開発手法の提案力も評価軸にできます。国交省の物流施設DX推進実証事業費補助金（システム連携で上限2,500万円・補助率1/2）や、経産省のデジタル化・AI導入補助金2026（ITツール最大450万円）を見据えた提案ができるベンダーは、コスト面でも頼りになります。riplaはフルスクラッチ受託にAI駆動開発を組み合わせ、開発速度を3〜5倍に高めて期間を30〜70%短縮した実績があり、業務から逆算した要件整理を一貫して支援します。RFPは、こうした業務理解と提案力を持つパートナーを見極めるための土台になります。
提案を比較する際は、保守・運用フェーズの体制まで確認しておくことをおすすめします。導入時の開発力だけでなく、稼働後の障害対応の窓口、法改正への追従、機能追加時の費用感まで含めて評価しないと、運用が始まってから「気軽に相談できない」「追加開発が高額で頼めない」という事態に陥ります。RFPには「保守内容と費用」「法改正対応の進め方」「追加開発時の人月単価」を必ず回答項目に含め、長期で付き合えるパートナーかどうかを見極めましょう。要件定義は、初期の見積もり比較で終わらせず、運用まで見据えた選定にすることが成功の条件です。
まとめ
TMSのRFP・要件定義書は、機能要件（配車制約・運賃・実績）、連携要件（トランザクション不整合・デジタコ/労務連携・企業間の責任分界）、非機能/法令要件（性能・モバイル・2024年問題・改正物流効率化法）、ベンダー選定の4軸で組み立てると漏れがありません。とくに、配車制約の条件化、企業間連携のロールバック設計、拘束時間上限のアラート要件、荷待ち記録の客観化といった「数値と責任分界まで踏み込んだ要件」が、現場で使えるシステムを引き寄せます。法令対応の後付けは2〜3倍のコストを招くため、最初から要件に含めることが賢明です。
要件定義で大切なのは、機能の一覧化ではなく、自社の業務制約と責任分界をベンダーに正確に伝えることです。RFPは見積もりを引き出すだけでなく、輸配送の泥臭い実務を理解したパートナーを見極める選定ツールでもあります。riplaはフルスクラッチ受託とAI駆動開発を組み合わせ、業務から逆算した要件整理とRFP策定を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。