TMSのRFP（提案依頼書）と要件定義書は、機能・連携・非機能と法令・ベンダー選定の4つの観点で組み立てると、漏れを防げます。
特に、配車の制約や企業間の責任分界は、数値と責任の範囲まで書くことが要点です。全体像はTMSの完全ガイドからご覧ください。
▼全体ガイドの記事
・TMSの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
機能要件の書き方（配車・動態・運賃）
RFPの中核は機能要件です。ただし「配車を自動化したい」「動態管理がほしい」といった抽象的な書き方だと、ベンダーは自社製品の標準機能を当てはめるだけになり、現場に合わない提案が届きます。そこで、業務上の制約は条件のレベルまで分解して書くことが大切です。配車・動態・運賃という主要機能について、RFPに落とすべき粒度を示します。
配車条件・制約を要件化する書き方
配車機能の要件定義で最も重要なのは、自社の制約条件を洗い出して明文化することです。ベテラン配車担当者の頭の中にある暗黙のルールは、次の例のように条件の形で書き出します。
- 温度帯の混載：冷凍と常温は混載不可
- 納品先ごとの担当：この納品先は特定ドライバーのみ
- 時間指定の扱い：午前指定の荷物を優先
- 車両ごとの上限：1台あたり最大訪問件数
こうした条件を書き出さないと、生成された配車案を毎回手直しすることになり、自動配車の意味が失われます。そのため、RFPには「対応すべき配車制約の一覧」を別表として添付します。各制約が標準機能で実現できるか、カスタマイズが必要かをベンダーに回答させると、提案の差が明確になります。
あわせて、配車対象の規模を数値で示すと、見積もりの精度が高まります。規模は、件数・台数・納品先・人員の数を並べて伝えると、ベンダーが見積もりやすくなります。
- 1日の配送件数：配車の対象となる日々の件数
- 車両台数：配車に使う車両の数
- 納品先数：配送先の数
- ドライバー数：配車に充てられる人員の数
これらを添えておけば、ベンダーは必要な処理性能や画面設計を具体的に見積もれます。
MVP（最小限の機能から始める）方式なら2〜3ヶ月・100〜300万円から着手できます。一方で、最初から全制約を完璧に作り込もうとすると、投資が膨らみます。配車表をスクラッチで作る案件では、大手から「初回1億円・納期1年」と提示された例もあります。
RFPでは、「初期リリースで満たすべき制約」と「将来対応でよい制約」を分けて優先度を示すことが、現実的な見積もりを引き出すコツです。
運賃体系・実績項目の要件化
運賃計算の要件定義では、自社の料金体系の全パターンを書き出すことが欠かせません。料金の決まり方は、基本の形から個別の契約ルールまで層ごとに分けて書き出すと、漏れを防げます。
- 基本形態：距離制、重量制、個建て
- 割増・サーチャージ：エリア別割増、燃料サーチャージ
- 契約ごとの細かいルール：付帯作業料、待機料金、傭車（協力会社）への支払運賃
そのうえで、実際の運賃契約書を添付し、「これらをシステムで計算できること」と明記すれば、標準機能で足りるか、カスタマイズが必要かをベンダーに判断させられます。運賃要件を書き漏らすと、稼働後も手計算が残り、導入の効果が削られます。
実績管理についても、経営判断に使うKPIを要件として明示します。どの指標を見るかは、積載の効率から人と車の生産性まで、目的に合わせて選びます。
- 積載率：車両の積載量に対する積み込みの充足度
- 実車率：走行のうち荷物を積んでいる割合
- 配送件数：一定期間に処理した配送の数
- 生産性：車両別・ドライバー別に見る稼働の成果
これらを集計・出力できることも、要件として書いておきます。とくに重要なのが、運行・拘束時間の実績を集計し、2024年問題の上限（時間外労働年960時間、拘束時間原則年3,300時間）を監視できることです。これは後述の法令要件とも連動します。
RFPで出力フォーマット（CSV・帳票・ダッシュボード）まで指定しておけば、運用イメージのずれを防げます。
マスタ整備とデータ移行の要件化
機能要件の見落としで多いのが、マスタ整備とデータ移行です。TMSは、車両マスタやドライバーマスタ、納品先マスタなどの各種マスタが正確に整っていなければ、配車も運賃計算も正しく動きません。運賃マスタは、運賃計算の前提です。
マスタ整備とデータ移行では、移行の範囲と担当を、RFPの段階で具体的に書いておきます。
- 既存データ：移行対象となる種類と件数
- マスタの初期登録：誰が行うか
- データクレンジング：移行時の重複・誤りの整理と、その責任分担
これを曖昧にすると、稼働直前にマスタ整備が終わらず、本番開始が遅延する事態を招きます。
また、稼働後にマスタを誰がどう保守するかも要件化します。新しい車両やドライバーの追加、運賃改定、納品先の変更といった日常の更新を、現場の担当者が無理なく行える管理画面でなければ、運用が回りません。一括登録・一括更新（CSVインポート等）の機能要件を明記すれば、運用の負担を抑えられます。
マスタとデータ移行は地味な領域ですが、要件から抜けると、稼働後に「データが不正確で使えない」という根本的な失敗につながります。だからこそ、初期要件にしっかり織り込むことが大切です。
連携要件と企業間の責任分界の要件化
TMSの要件定義で、競合記事がもっとも手薄なのが連携要件です。とりわけ、企業をまたいだデータ連携の責任分界は、見落とされやすい部分です。「API連携で全体最適」という理想論のままでは、契約後に責任の押し付け合いが起こります。
連携はTMS単独では完結せず、相手システムや相手企業の協力が前提です。だからこそ、RFPの段階で「誰が、どのデータを、どう保証するか」まで踏み込んで要件化しておくと、後のトラブルを防げます。
トランザクション不整合・ロールバックの要件
企業間連携で見落とされがちなのが、トランザクション（一連の処理）の途中で起きる不整合への対処です。たとえば、自社側の処理は完了したのに、相手企業へのデータ送信がエラーになったケースを考えます。このとき両社のデータがずれたまま放置されると、配送指示の二重化や欠落といった事故につながります。
RFPには、不整合を早く見つけて元に戻すための仕組みを明記します。
- 検知方法：連携処理が途中で失敗したことをどう検知するか
- 再送・ロールバック：再送と処理の巻き戻しの仕組み
- アラートと復旧手順：不整合が起きた際の通知と復旧の流れ
これらを曖昧にすると、障害時に「どちらのシステムの責任か」で揉めることになります。
あわせて、複数ベンダーが関わる場合の責任境界を、要件と契約の両方で定義しておく必要があります。自社TMS、相手企業のシステム、連携基盤がそれぞれ別ベンダーだと、障害時の切り分けが難しくなります。
そこで、RFPに「障害発生時の一次切り分けの責任範囲」「ログの保存と相互開示」を求めておけば、運用フェーズでの押し付け合いを防げます。また、内部統制の観点では、J-SOX対応として処理証跡（ログ）の保全やロールバック設計を要件に含めることも、後付けの追加開発を避けるうえで有効です。
デジタコ・労務システム連携の要件
既存のデジタルタコグラフ（デジタコ）や労務システムとの連携も、RFPに具体的に書くべき要件です。多くの運送会社はすでにデジタコで運行記録を取っています。そこにTMSや荷主指定アプリが加わると、ドライバーが同じ情報を二度入力する二重管理が発生します。
既存のデジタコとの連携は、機種とデータ形式まで含めてRFPで求めます。
- 既存デジタコの仕様：機種とデータ形式を明記する
- 運行データの取り込み：デジタコの運行データをTMSに取り込み、ドライバーの二重入力を発生させない
RFPで求めておけば、既存の資産を捨てずに連携できるかを、ベンダーに判断させられます。
さらに踏み込むなら、動態・運行データを勤怠・給与システムへ流す労務連携を要件に含めることをおすすめします。実際の拘束時間データを労務システムへ自動連携すれば、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への回答は、機能の○×に加えて、ベンダーが輸配送の泥臭い業務をどこまで理解しているかで見ます。回答の差が出やすいのは、現場で揉めやすい箇所です。
- 荷待ち記録：荷待ち時間の記録と、その責任分界
- デジタコの二重管理：同じ運行情報を二度入力させない設計
- 企業間連携の不整合：トランザクションのずれへの対処
これらの難所について、具体的な解決アプローチを提案できるかが、業務理解度の見極めに役立ちます。難所に踏み込んだ提案をするベンダーは、現場で使えるシステムを作れる可能性が高いといえます。
あわせて、補助金の活用や開発手法の提案力も、評価の観点に加えられます。見据える制度は、物流分野とIT導入の二つです。
- 物流施設DX推進実証事業費補助金：国交省、システム連携で上限2,500万円・補助率1/2
- デジタル化・AI導入補助金2026：経産省、ITツール最大450万円
これらを見据えて提案できるベンダーは、コスト面でも頼りになります。
riplaはフルスクラッチ受託にAI駆動開発を組み合わせ、開発速度を3〜5倍に高めて期間を30〜70%短縮した実績があり、業務から逆算した要件整理を一貫して支援します。RFPは、こうした業務理解と提案力を持つパートナーを見極めるための出発点になります。
提案を比較する際は、保守・運用フェーズの体制まで確認しておくことをおすすめします。導入時の開発力と並べて見ると、運用後の差が見えてきます。
- 障害対応の窓口：稼働後にどこへ連絡すれば対応してもらえるか
- 法改正への追従：法改正に合わせて改修してもらえるか
- 機能追加時の費用感：追加開発にかかる費用の目安
これを省くと、運用が始まってから「気軽に相談できない」「追加開発が高額で頼めない」という事態に陥ります。
RFPには「保守内容と費用」「法改正対応の進め方」「追加開発時の人月単価」を必ず回答項目に含め、長期で付き合えるパートナーかどうかを見極める必要があります。要件定義は、初期の見積もり比較で終わらせず、運用まで見据えて選ぶことが成功の条件です。
まとめ
TMSのRFP・要件定義書は、機能要件、連携要件、非機能と法令要件、ベンダー選定の4つの観点で組み立てると漏れを防げます。機能要件では配車制約・運賃・実績を、連携要件ではトランザクション不整合やデジタコ・労務との連携、企業間の責任分界を押さえます。
非機能と法令要件では、性能・モバイルに加えて2024年問題と改正物流効率化法を盛り込みます。とくに、配車制約の条件化や企業間連携のロールバック設計は、数値と責任分界まで踏み込むことで、現場で使えるシステムを引き寄せます。
拘束時間上限のアラートや荷待ち記録の客観化も、踏み込んだ要件として書いておくべき項目です。法令対応の後付けは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を創業。