運行管理システムの導入は、製品選びよりも、RFP（提案依頼書）と要件定義書の質で成否が決まります。
進め方は、業務の棚卸し、要件の数値化、責任の整理の順です。この順で進めると、現場で使える製品を選びやすくなります。全体像は運行管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・運行管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
業務要件の棚卸しとRFPの全体構成
要件定義は、現在の運行管理業務を棚卸しするところから始めます。現状の流れを書き出すと、システムで解決すべき課題が見えてきます。
業務フローは、配車の決め方と指示の伝達、進捗把握を中心に描き、拘束時間の集計と荷待ち記録も含めます。この棚卸しを土台に、RFPを組み立てます。
現状業務フローと課題・導入目的の言語化
RFPの冒頭には、導入の目的と背景を明記します。たとえば、拘束時間管理の厳格化や、属人化した配車からの脱却が挙げられます。荷待ち削減義務への対応や問い合わせ電話の削減も、目的の例です。
- 目的と背景：システムで解決したい課題を具体化する
- 現状の業務：受注から配車、運行、点呼、日報、拘束時間集計までを図示する
- 現場の実態：FAX・電話、Excel集計、担当者だけが知るルールも書き出す
- 現場へのヒアリング：配車担当とドライバーから例外処理や困りごとを聞く
目的が曖昧だと、ベンダーの提案が一般論になり、比較軸も定まりません。逆に目的を明確にしておけば、的を射た提案を引き出せます。
業務フローを示せば、ベンダーの提案がシステム化の範囲をどこまで含むかを確認できます。現場の泥臭い実態も、業務理解の深さを見極める材料になります。
経営層や情報システム部門だけで決めると、現場の実態とかけ離れた要件になりかねません。そのため、現場の知見を取り込むことが、導入後の反発を抑え、定着につながります。要件定義は、その知見を吸い上げる工程です。
RFPに盛り込むべき項目の全体構成
RFPでは、ベンダー各社が同じ条件で提案できるよう、依頼内容と評価の前提をそろえます。
- 会社と業務：目的・背景、自社概要、規模、現状フローと課題
- システム要件：必須・任意を区別した機能、性能・可用性・セキュリティ、外部連携
- 導入条件：データ移行、スケジュール、予算感
- 提案と評価：依頼事項とベンダー選定基準
運行管理システムのRFPは、これらの項目で構成します。項目を漏れなく記すと、各社の提案を比較しやすくなります。
自社概要には、車両数、ドライバー数、拠点数を記載します。さらに、1日あたりの配送件数と配送形態も添えます。
規模の数値は、製品の適合性や費用感を左右します。たとえば、クラウドSaaSは初期0〜数十万、月数万〜数十万で、導入期間は1〜3か月です。一方で、スクラッチは、小規模で300〜1,000万、中規模で1,000〜3,000万、大規模で3,000万〜1億超です。
機能は「必須」「あれば望ましい」「不要」の3つに分けます。すべてを必須にすると費用が膨らみ、優先順位が曖昧なままだと、提案の力点も定まりません。
業務に不可欠な機能は必須にし、効果を見て追加できる機能は「望ましい」に分類します。この区分は、予算調整や導入フェーズの判断にも使えます。
機能要件の数値化と法令対応の要件化
機能要件はRFPの中心です。「動態管理ができること」のように書くと曖昧なため、自社の業務に沿って、数値や条件まで明記します。
曖昧な要件は、ベンダーに都合よく解釈され、導入後の「言った言わない」の原因になります。そのため、要件を具体化しておくと、提案の精度や比較のしやすさが高まります。
配車ルール・拘束時間の数値要件の明文化
配車機能では、自社特有の制約を洗い出します。そのうえで、自動配車で扱えるかをベンダーに確認します。
- 担当者の制約：特定の現場に入れるドライバー
- 車両と荷物：車格ごとに積載できる荷物
- 納品条件：得意先ごとの午前指定など
配車の制約をRFPに列挙すると、デモでは分かりにくい実運用への適合性を確かめられます。
法令対応も数値で示します。拘束時間は原則年3,300時間以内、時間外労働は年960時間以内で管理できることを要件にします。また、上限の何％でアラートを出すか、1日の運転時間や連続運転時間の超過を検知できるかも記載します。
法令数値を明記すれば、対応範囲を確認できます。特に2024年問題への対応では、実効性のある管理がベンダーに求められます。
デジタコ・勤怠連携要件と二重管理の回避
連携要件は見落とされやすく、導入後に問題になりがちです。そのため、使用中のデジタコの機種名と、連携の要件をRFPに記載します。
- デジタコ連携：既存機器のデータを取り込めること
- 勤怠連携：動態データから算出した拘束時間を渡せること
- 対応方式：標準機能、カスタマイズ、スクラッチの別
互換性を確認しないと、ドライバーがデジタコと運行管理アプリに同じ情報を入力する状態になり、不満や入力漏れにつながります。勤怠システムとの連携は、労働時間の二重入力をなくし、2024年問題の拘束時間上限管理に役立ちます。
勤怠連携に対応した製品は限られるため、標準パッケージで賄えるか、カスタマイズやスクラッチが必要かも判断します。
企業間連携と荷待ち記録の責任分界の要件化
実運用で揉めやすいのは、荷待ち記録の責任分界と企業間連携の設計です。競合記事では触れられにくい論点です。
荷待ち記録には、運送会社、荷主、着荷主が関わります。そのため、記録者と証拠の承認者を決めておかないと、記録機能が運用されないおそれがあります。ここを要件として明文化できるかが、2026年問題対応の実効性を左右します。
荷待ち記録の責任分界点とエビデンス要件
荷待ちは、自己申告と客観データのどちらで記録するかを決めます。記録の扱いも、RFPに定めておきます。
- 自己申告：ドライバーがアプリで開始・終了を入力する
- 客観記録：予約や倉庫システムから入退場時刻を取得する
自己申告方式は導入しやすい一方で、荷主が申告を証拠として認めるかという課題が残ります。そのため、自社の立場も踏まえて選ぶ必要があります。
客観記録を求める場合は、MOVO Berthなどのバース予約システムや荷主のWMSと同期します。そのうえで、入退場時刻から荷待ち時間を自動で算出します。
誰が、どの方式で、どのデータソースから記録するかを定めておけば、企業間で記録の有無を争う事態を避けられます。義務化への対応を形だけで終わらせないためにも、この点は欠かせません。
外部システム連携のトランザクション・障害要件
荷主の受発注・バース予約システムや自社基幹と連携する場合は、障害時の動きも要件に含めます。
- 障害検知：送信失敗を検知して通知する
- 復旧操作：失敗データを再送し、手動補正できる
- 不整合確認：システム間のデータを照合する手段を持つ
A社の処理が完了しても、B社への送信に失敗するなど、企業間連携では不整合が起こり得ます。そのため、RFPには、再送やロールバックの仕組みを明記します。
複数ベンダーが関わる場合は、各社の責任範囲も契約で定めます。
ベンダーが障害時の対応を具体的に提案できるかは、実運用を理解しているかの判断材料になります。要件定義の品質を測る観点としても、この点は欠かせません。
非機能要件とベンダー選定・提案依頼の進め方
機能要件を固めたら、性能と可用性を定めます。セキュリティや運用保守の要件も、あわせて決めます。
非機能要件を明確にすることが、現場業務を止めずに済む安定運用の前提です。軽視すると、遅延や障害停止につながります。
性能・可用性・運用保守の非機能要件
運行実態に合わせ、性能や可用性、通信が不安定な場所での動作を定めます。
- 性能：車両が増えても地図表示が遅れず、配車計算が許容時間内に終わる
- 可用性：運行時間帯の稼働と、障害時の復旧目標を決める
- 通信障害：オフライン記録後、通信復帰時に同期する
運用保守の要件は、長期コストも左右します。保守費用の目安は、オンプレパッケージで年保守10〜20％、スクラッチで月30〜100万円です。
追加開発の人月単価を契約時に決めないと、運用開始後の改修費が1.5倍になった事例があります。そのため、RFPで単価テーブルを求めます。
電帳法や物流効率化法の改正対応を、保守範囲に含めるかも確認します。後付けの法対応は、新規に織り込む場合の2〜3倍になることがあります。そのため、保守範囲を詰めておくと、総保有コスト（TCO）の想定超過を防ぐ判断材料になります。
ベンダー選定チェックリストと提案依頼の進め方
選定基準を決め、各社の提案を同じ観点で評価します。提案時には、デモに加えて、自社特有の例外業務で動かせるかを確かめます。
- 業務理解：荷待ち、拘束時間、デジタコなどの実務
- 連携実績：自社のデジタコ、勤怠、基幹システム
- 提案の具体性：法令対応と例外業務への適合
- 導入後の条件：追加開発・保守費用と現場定着支援
標準パッケージで要件の大半を満たせる場合は、導入を速く、安く進められます。一方で、独自性が強い配車や連携には、フルスクラッチやカスタマイズが現実的です。
riplaは、フルスクラッチ受託とAI駆動開発を通じて、要件定義の伴走やRFP作成、業務・法令を踏まえた設計を支援します。AI駆動開発では、速度を3〜5倍に高め、期間を30〜70％短縮した実績があります。riplaは、要件定義から開発まで一体で進められます。
要件を機能に落とし込む方法は、関連記事の機能解説もご覧ください。
データ移行要件と補助金活用を見据えた予算設計
移行と予算は、範囲や条件を具体化したうえで、提案を求めます。
- 移行：対象データ、方式、期間中の並行運用
- 補助金：制度の活用想定と申請要件
移行の対象になるのは、Excelや既存システムにある車両マスタ、ドライバー・取引先情報、配車実績などです。移行要件が曖昧だと、稼働直前になって作業負荷が見えてきて、立ち上げが遅れることがあります。
そのため、要件を詰めておくことが、円滑な立ち上げの前提になります。要件の不足は、導入失敗の一因にもなります。
予算には、補助金の活用も見込みます。物流施設DX推進実証事業費補助金（国交省）は、システム連携が上限2,500万円、自動化機器が上限1億1,500万円で、補助率は1/2です。
デジタル化・AI導入補助金2026（経産省）は、ITツールが最大450万円で、補助率は1/2です。小規模事業者の賃上げでは、最大4/5となります。
中小企業省力化投資補助金は200万〜1,000万円で、賃上げにより最大1,500万円です。RFPには活用の想定を記し、採択を見据えた提案を求めます。
制度ごとに申請時期や要件が異なるため、要件定義と並行して情報を集めておくと、実質負担を抑えた計画を立てやすくなります。
まとめ
運行管理システムのRFPは、業務の棚卸しと機能の数値化を土台にします。そのうえで、連携の責任分界、非機能要件と選定基準を軸に構成します。
導入後に揉めやすいのは、配車と拘束時間、デジタコと勤怠の連携です。荷待ち責任、外部連携の障害、追加開発・保守費用も挙がります。これらは、競合記事では触れられにくい論点です。
要件を具体的にRFPへ記すことが、現場で回るシステムを得る近道です。要件定義は製品選定前の準備作業にとどまらず、導入の成否を決める工程です。
業務の実態を棚卸しし、法令数値、連携の責任分界、障害時の挙動までRFPに落とし込みます。これが選定と導入後の運用を確かなものにします。
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を創業。