配送・運送システムのRFP（提案依頼書）や要件定義書は、現場の業務整理、社外との協議、移行と契約条件の明確化を順に進めると、手戻りを抑えられます。
RFPの内容は、現場要件と外部連携、データ移行、契約条件に分けると整理しやすくなります。全体像は配送/運送業界のシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・配送/運送業界のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場ヒアリングと業務標準化による要件の固め方
要件定義は、機能の一覧より先に、現場が日々どう動いているかを正確につかむことから始まります。配車担当やドライバー、運行管理者、事務の手順を、現場ヒアリングで確かめます。また、無駄や手戻りも洗い出します。
現状（AsIs）を整理し、あるべき業務（ToBe）を描く作業が、AX（業務改革）にあたります。現状とあるべき姿の差が分かると、それが的確な要件を書くための前提になります。
AsIs業務フローの可視化と目的の明確化
まずは、受注から配車、運行、実績記録、請求までの一連の流れを図にして、現状の業務フローを書き出します。図には、登場人物と帳票、システム、所要時間を書き込みます。こうすると、属人化した工程や二重入力の箇所が見え、現場と合わない要件を防げます。
あわせて欠かせないのが、導入目的を明確にすることです。「DXが流行っているから」といった動機で高機能なシステムを入れると、現場の反発で頓挫する例があります。
RFPの冒頭には、具体的な課題と、それを数値でどう改善するかを記します。目的が定まると、提案が課題解決に絞られるため、各社の提案を比較しやすくなります。
- 配車：属人化の解消
- 労働時間：2024年問題を踏まえ、上限内に収めること
- 請求業務：月末残業の解消
導入目的を言葉にできるかどうかが、要件定義の質を左右する最初の関門です。
過剰カスタマイズを避ける業務標準化の判断
現場の要望には「今のやり方をそのままシステムにしてほしい」という現状追認が含まれがちです。そのため、要望をすべて要件に入れると、過剰なカスタマイズにつながるおそれがあります。
過剰なカスタマイズは、バージョンアップを難しくし、ベンダーロックインや高止まりする保守費を招きます。そこで発注側は、業務標準化の視点から今のやり方を問い直します。
判断では、その業務が競争力の源泉か、単なる慣習かを見分けます。たとえば、荷主との特殊な契約条件や独自の運賃体系は、自社の強みになるため、手をかける価値があります。
- 競争力に直結する業務：必要に応じて作り込む
- 昔から続く慣習：標準機能に業務を合わせる
要件定義書には、標準機能とカスタマイズの範囲を、それぞれの理由とあわせて記します。切り分けが曖昧だと、ベンダーは安全を見込んで高めに見積もるため、費用が膨らみます。
標準化の判断は、発注側が主体となって担う仕事です。
荷主EDI・協力会社など外部連携の事前協議
配送・運送業界のシステムは、他業種と比べて外部関係者との連携が業務の中心になります。荷主EDI、協力会社（傭車先）との発注・精算、異なる物流系統との接続が、要件に関わってきます。これらは自社だけでは決められないため、相手との事前協議が欠かせません。
荷主EDIの仕様確認と3か月前協議の重要性
荷主とEDIで連携する場合、仕様は荷主側が定めていることが多く、運送会社はそれに合わせる形になります。このため、対象の荷主ごとに、データ、形式、送受信のタイミングを確認しておきます。
確認した仕様は、仕様書にまとめておきます。これを怠ると、開発の後半になって荷主の形式に対応できないことが分かり、大きな手戻りが発生します。
荷主側のシステム更改で連携仕様が変わる場合も、注意が必要です。特に物流EDIの仕様変更では、最低でも3か月前から事前協議を始めます。
- 現在の連携先：荷主の一覧をRFPで共有する
- 仕様変更の予定：荷主ごとに有無をベンダーへ伝える
事前協議が遅れると、運送会社側の改修が間に合わず、現場が混乱します。一方で、共有された情報があれば、ベンダーは将来の改修を見越して設計できます。
外部連携の要件には、現在の接続だけでなく、相手側の変更への追従も含めておきます。社外との折衝には時間がかかるため、スケジュールにも余裕を持たせます。
協力会社・傭車先との連携範囲の要件化
自社車両だけでは運びきれず協力会社に委託する場合は、傭車先との連携も要件に含めます。委託の発注、運行状況の共有、運賃精算のどこまでをシステム化するかは、発注側が決めます。
協力会社が小規模でシステムを持たない場合は、相手のITレベルに合わせて手段を選びます。たとえば、Web画面での発注や、メール・FAXの併用も要件に織り込みます。
自社の理想だけで要件を固めると、協力会社が対応しきれず、連携が形だけのものになることがあります。そのため、相手のITリテラシーや業務量に応じて、システムで扱う範囲に線を引きます。
- システムで扱う範囲：相手が対応できる業務を選ぶ
- 従来の方法を残す範囲：相手の事情に応じて決める
運賃精算の自動化は、社内の経理負担を減らす効果があります。ただし、対象を絞り、まず運賃テーブルと委託実績だけをシステム化するといった優先順位づけも有効です。
外部連携は、相手の事情を織り込んでこそ機能します。
データ移行とマスター整備の要件化
データ移行とマスター整備は軽く見られがちですが、プロジェクトの成否を左右します。過去データを移し、荷主や車両、運賃、配送先などの各マスターを整えます。
整備が不十分だと、不要なデータを処理するだけのシステムになります。そこで、RFPには移行対象のデータ量と、マスター整備の責任分担を明記します。
配送先・運賃マスタのクレンジング要件
長年運用してきた運送会社のマスターには、重複や表記揺れ、取引のない古い配送先が混在しがちです。たとえば、住所の違いで同じ配送先が複数登録されることもあります。
廃止された運賃が残っている場合もあります。そのまま移行すると、配車の際に誤ったデータを参照して、現場が混乱します。
- 重複排除：同じ配送先の登録を一つにまとめる
- 表記統一：住所などの書き方を揃える
- 不要データの削除：古い配送先や廃止済みの運賃を整理する
要件定義では、移行前のクレンジング工程をはっきり位置づけておきます。データの正誤を判断できるのは、業務を知る発注側です。
RFPには役割分担を記しておきます。たとえば、マスターの正誤判断と整備は発注側が担い、移行作業の仕組みはベンダーが提供する、といった形です。
責任の所在が曖昧なままだと、本番直前にマスターが整わず、稼働できない事態を招きます。クレンジングの出来は、稼働後の使い心地も左右します。
現場のITリテラシーを踏まえた操作要件
運送現場には、高齢のドライバーやITに不慣れな人もいます。そのため操作性は機能と同じくらい大切で、複雑なシステムは使われず、紙に戻ることがあります。
現場で使われ続けるシステムにするには、操作性を要件の段階から確かめておく必要があります。その方法は4つあります。
- 操作要件：スマートフォンやタブレットで数タップで扱え、直感的なUIであることをRFPに明記する
- 画面の確認：提案の時点で、実物の操作感を見る
- 現場での試用：可能であればドライバーや配車担当に操作してもらう
- 代表者の参加：現場の立場の人を要件定義に加え、稼働後の抵抗を減らす
操作性はカタログのスペックだけでは分かりません。そのため、現場で使えるかを前提に評価することが大切です。高機能でも使えない要件は欠陥です。
riplaは、フルスクラッチ受託と国内開発の立場から、現場の業務とITリテラシーを起点に要件を整理することを重視しています。
SLA・協力義務など契約面の押さえどころ
要件定義書とRFPには、技術仕様だけでなく、契約や運用の前提も含めておきます。稼働後の保守・サポートを定めるSLA（サービス品質保証）も、その一つです。
発注側が負う協力義務も理解しておく必要があります。協力義務が曖昧なままだと、想定したサポートを受けられず、自社の対応不足を巡って争う事態になることもあります。
SLAと保守費の要件化
配送・運送システムは、止まると配送が滞る基幹業務です。そのため、障害時の復旧時間、受付時間、問い合わせへの応答速度を、SLAとして明記します。
返信が遅いと、現場の困りごとが放置され、定着を妨げます。たとえば、格安アプリでサポート返信に3日かかり、1年未満で乗り換えて二重コストを払った事例も報告されています。
保守費も、要件の段階で把握しておきます。一般に、システムの保守費は開発費の15〜20％が目安です。仮に、開発費が3,000万円なら、年間450〜600万円程度かかります。
初期費用だけで判断すると、稼働後の資金繰りが苦しくなります。
- 保守費の内訳：RFPでベンダーに明示を求める
- 24時間対応：その有無をベンダーに確認する
- オプション料金：追加費用を明らかにする
継続費用を含めた総保有コスト（TCO）で比べると、選定で後悔しにくくなります。一方で、安さを優先した結果、サポートが不足する事態は避けたい失敗です。
ユーザーの協力義務と要件凍結の取り決め
システム開発は、発注側の協力があって初めて成り立ちます。法的にも、ユーザーには開発への協力義務があり、怠るとユーザー側が責任を問われます。
旭川医科大学とNTT東日本の事件では、控訴審でユーザーの協力義務違反が認定されました。要望は全169項目のうち、124項目が開発対象外と判断されました。
さらに、ユーザー側のみに約14億1,500万円の支払いが命じられました。要件が曖昧なまま、開発の途中で大量の追加要望を出した姿勢が問われた事例です。
要件定義では、契約上の線引きと、発注側が決めるべき事項を合わせて整理しておきます。
- この教訓から、ベンダーと要件を確定させる期限と、凍結時期を決めておくことが重要です。
- 凍結後の追加要望は、別途の費用とスケジュールで扱うと契約しておき、際限のない追加によるコスト膨張を防ぎます。
- 関係部署の意見は要件定義の段階で集め、発注側が期限内に決めます。発注側は丸投げせず、主役として関わります。
riplaは、フルスクラッチ受託と国内開発の立場から、発注側と協力して要件を固め、責任の所在をはっきりさせる進め方を重視しています。
まとめ
配送・運送システムの要件定義は、現場の業務を洗い出し、導入目的をはっきりさせることから始めます。そのうえで、発注側が業務標準化を判断し、過剰なカスタマイズを避けます。
荷主とは3か月前から協議を始め、協力会社には、ITレベルに合わせた連携方法を決めます。データ移行では、クレンジングと責任分担を明記します。
SLAと保守費（開発費の15〜20％が目安）は、TCOで比べます。協力義務と要件凍結は契約で決め、コスト膨張と法的リスクを抑えます。
旭川医大の約14億円の判決は、発注側の協力義務がいかに重いかを示しています。要件定義では丸投げせず、発注側が決めるべき事項は期限内に確定させ、主役であり続けることが大切です。
現場業務と外部連携、データ、契約の観点から要件を整理すると、提案を比べやすくなり、稼働後の手戻りも抑えられます。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、発注側と一緒に要件を固める進め方を得意としています。着手前に完全ガイドで全体像を確認する方法もあります。
▼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を創業。