老朽化したTMS（輸送管理システム）や配車システムを外部に発注する場合は、委託先と依頼方法の判断が重要です。TMSのモダナイゼーションの発注は、委託先のタイプを選び、準備、契約形態、見積の確認、発注先の絞り込みの順で進みます。
進め方を誤ると、本体価格の数倍にあたる連携費用が後から発覚したり、現場が使わない「お蔵入りシステム」になったりします。
▼全体ガイドの記事
・TMSのモダナイゼーションの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
TMSモダナイゼーションの発注先の種類と特徴
委託先は、大きく分けて三つのタイプに整理できます。タイプごとに得意な領域も、費用感も、柔軟性も異なります。そのため、自社の拠点数や業務の独自性に合わせて、どのタイプが合うかを見極めることが第一歩になります。
タイプを理解しないまま「とりあえず付き合いのあるベンダー」へ相談すると、自社に合わない方式を提案されかねません。そうなると、後で軌道修正するコストがかさみます。
SIer・パッケージベンダーへの発注
既存のTMSパッケージを提供するベンダーや、大手SIerへ発注する方法です。物流業界向けに作り込まれたパッケージは、配車・運賃計算・動態管理といった標準機能が揃っており、要件が一般的であれば短期間で導入できる利点があります。
導入実績が豊富なため、業務フローの型がはっきりしている運送会社には適しています。一方で、独自の伝票フォーマットや複雑な運賃ルールを持つ企業の場合、パッケージの標準機能では収まらず、カスタマイズが膨らみます。
その結果、フルスクラッチ相当の数千万円規模に跳ね上がるケースもあります。「パッケージだから安い」という思い込みは禁物です。発注前に、自社の業務がどこまで標準機能で吸収できるかを見極める必要があります。
クラウド・SaaS提供事業者への委託
月額数万円から利用できるクラウド型・SaaS型のTMSは、初期投資を抑えてスモールスタートしたい企業に向いています。また、1拠点・数台から試し、合わなければやめるという身軽さもあります。
法改正への追従やセキュリティアップデートが提供側で行われるため、オンプレミスのように都度の有償保守が発生しにくく、維持コストを平準化できる点が魅力です。
ただし、SaaSは標準化されている分、現場の「今のやり方を変えたくない」という要望に応えきれない場面があります。SaaSを候補にする際は、標準機能で運用できるかを、次の三つの観点から確認します。
- 拠点数：3拠点以上の配車ルールを標準機能で扱えるか
- 連携方式：基幹システムがAPI非対応でも必要な連携ができるか
- 業務差異：複数の取引先ごとに異なるEDIや伝票形式へ対応できるか
三つすべてに当てはまる場合は、SaaSの標準機能だけでは対応しきれない可能性があります。この分岐点は、発注の前に社内で共有しておきたいところです。
コンサル一気通貫型・専門開発会社への委託
業務コンサルティングから設計・開発・定着支援までを一社で担う開発会社へ委託する方法です。要件が固まりきっていない段階から相談でき、自社の業務独自性に合わせた柔軟な作り込みが可能なため、複雑な運賃ルールや特殊車両を扱う物流企業に適しています。
荷主視点での全体最適や、共同配送・自動運転を見据えた拡張設計まで相談できる点も特徴です。費用はパッケージより高くなる傾向がありますが、現場を巻き込んだ定着支援まで含めてもらえるため、結果的に「お蔵入り」リスクを抑えられます。
発注先を一社に絞らず、パッケージベンダーと専門開発会社の双方から提案を受け、自社の状況に合う方式を比べることをおすすめします。
発注前の準備
発注の成否は、相談に行く前の準備でほぼ決まります。準備が曖昧なまま見積を依頼すると、ベンダーは安全側に振った高めの金額を提示するか、後から追加費用が雪だるま式に増えるかのどちらかになりがちです。
発注側が要件と前提を整理しておけば、各社の提案を同じ土俵で比べられ、見積の精度も格段に上がります。
現状業務の棚卸しとMUST/WANTの切り分け
まず、現在の配車・運行・請求の業務フローを洗い出し、どこに非効率や属人化があるかを一覧にします。そのうえで、新システムに「絶対に必要な機能（MUST）」と「あれば望ましい機能（WANT）」を切り分けます。
この切り分けが甘いと、現場の要望をすべて詰め込んでしまい、開発費が際限なく膨らみます。特にTMSでは、ベテラン配車マンの頭の中にある「経験と勘」のルールが暗黙知として残っていることが多く、これを言語化しておくことが移行成功の鍵になります。
AIによる自動配車を導入しても、イレギュラー対応の判断基準が抜け落ちていれば、現場は使ってくれません。そのため、現状を洗い出す段階で現場担当者を巻き込むことが欠かせません。
RFP（提案依頼書）の作成
複数社へ発注を打診する際は、RFP（提案依頼書）を用意します。RFPには、解決したい課題、想定する拠点数や車両台数、必須機能を明記します。さらに、連携対象システム、予算感、希望スケジュール、そして稼働後のサポート要件まで書き込みます。
同じ条件で各社に提案を求めることで、価格と内容を公平に比較できます。一方で、RFPがないまま口頭で相談すると、各社が前提条件を勝手に解釈し、提案の粒度がバラバラになって比較不能に陥ります。
最低限「何を、いつまでに、いくらくらいで実現したいか」を文書にしておけば、RFPは完璧でなくても、その後の交渉がスムーズになります。
連携対象システムとデータの洗い出し
TMSは、WMS（倉庫管理）やERP・会計・販売管理、ハンディターミナル、バーコードなど多くの周辺システムと連携して動きます。そのため、発注前に、連携が必要なシステムとそのデータ形式、API対応の有無を一覧にしておくと、後の追加費用を防ぐうえで最も効く備えになります。
あわせて、移行対象となる顧客マスタや運賃ルールのマスタが、Excelや紙でどれだけバラついているかも確かめておきます。データ移行は、誰が、いつまでに、どの精度で整備するかが曖昧だと必ず炎上するため、発注時に役割分担を決めておくことが大切です。
発注方式・契約形態の選び方
発注の際は、契約形態の選択が予算管理とリスク分担を大きく左右します。
TMSのモダナイゼーションは要件が途中で変わりやすいため、最初に契約形態の特性を理解し、プロジェクトのフェーズに応じて使い分ける発想が求められます。
請負契約と準委任契約の違い
請負契約は、完成した成果に対して報酬を支払う契約で、仕様が固まっている開発フェーズに適しています。発注側にとっては予算が確定しやすい反面、要件変更のたびに追加契約が必要になるため、変化への柔軟性は低くなります。仕様が確定したあとの本開発は、請負が向いています。
準委任契約は、作業や役務の提供に対して報酬を支払う契約で、要件定義や上流の業務整理のように、進めながら仕様を詰めるフェーズに適しています。
請負と準委任を組み合わせ、上流は準委任、確定後の開発は請負とする「フェーズ分割発注」が、TMSのような変化の多いプロジェクトでは現実的な選択になります。
スモールスタート向けのラボ型・アジャイル発注
一括ですべてを発注する従来型のウォーターフォールは、きれいな流れに見えても、現場では机上の空論になりがちです。
そこで、要件が固まりきらないTMSでは、1業務・1拠点から小さく始め、リリース後も継続的に拡張していくラボ型・アジャイル型の発注が有効です。月単位で開発チームを確保し、優先度の高い機能から順に作ります。
この方式なら、最初に数千万円を投じて全社一括で導入する賭けを避け、効果を確かめながら投資を積み増せます。さらに、「小さく試してダメならやめる」という経営判断がしやすく、現場の反発も段階的に和らげられる点が、ラボ型発注の大きな利点です。
拠点数・業務独自性での選び分け
契約形態と発注先の組み合わせは、自社の規模と業務独自性で決めます。拠点が少なく業務が標準的なら、SaaSを請負に近い形で短期導入するのが合理的です。
逆に、複数拠点・独自の運賃ルール・複雑なEDI連携を抱えるなら、準委任での要件整理から入り、ラボ型で段階的に開発するほうが破綻しにくくなります。
判断に迷う場合は、特定の営業所やルートで試験導入するパイロット発注から始める手もあります。ノウハウを蓄積してから全体展開すれば、全社一括導入で起こりがちな大規模なつまずきを避けられます。
隠れコストと見積の見方
TMSの発注で最も多い失敗が、表面的な本体価格だけを見て契約してしまうことです。
物流システムは連携・カスタマイズ・運用に費用が積み上がる構造を持つため、見積の内訳を分解して総保有コスト（TCO）で判断する視点が欠かせません。
本体より高くなる連携・カスタマイズ費用
TMSの隠れコストの筆頭が連携費用です。基幹システムとの連携に100万〜500万円、バーコードやハンディ端末との連携に50万〜500万円の追加開発費が発生する場合があります。たとえば、「本体500万円のはずが連携で1,000万円かかった」という事態は珍しくありません。
発注時には、連携対象ごとに費用を明示してもらいましょう。さらに、独自伝票フォーマットや複雑な運賃ルールを無理にシステム化しようとすると、カスタマイズ費用がフルスクラッチ相当の数千万円規模に膨らみます。
見積を取る際は、どこまでが標準機能で、どこからが追加開発になるのかの線引きを必ず確認することが大切です。
運用・保守のランニングコスト
初期費用だけでなく、稼働後に継続して発生する費用も見積に含めて比較します。デジタル地図基盤（ゼンリン等）のライセンス料や、AIによる動的ルート最適化のモデル再学習工数も確認が必要です。また、並行運用期間中の入力サポート要員の人件費など、運用フェーズの費用は意外と大きくなります。
これらは契約前の見積では見落とされやすいため、「稼働後3年間でいくらかかるか」をベンダーに試算させると実態が見えてきます。なお、月額制のクラウドであっても、ユーザー数や車両台数の増加に応じて費用が変動する点も確認しておくべきです。
「4年の壁」とTCO/ROIの正しい見方
「4年以上使うならオンプレミスが安い」という一般論は、TMSには必ずしも当てはまりません。物流システムは法改正、OSアップデート、ブラウザのセキュリティ要件変更が頻発するため、オンプレミスは都度の有償保守が重なり、クラウドより維持コストが急増しやすいのです。
そのため、発注の判断は数年単位のTCOで行うべきです。投資回収（ROI）の観点では、配車業務の工数削減や請求漏れ・運賃計算ミスの防止を評価します。さらに、動的ルート最適化で配送時間が8〜12%短縮する効果なども金額に換算し、総コストと比べます。
効果と費用の両面を数字で押さえておくと、社内の投資判断も通しやすくなります。
失敗しない発注先選定とリスク対策
最終的に発注先を一社へ絞り込む際は、価格だけでなく、業界知見・サポート体制・定着支援力という三つの観点で見極めます。
TMSは稼働後の運用が長く続くため、長期的に伴走してくれるパートナーかどうかが投資対効果を決定づけます。
実績と物流業界知見の確認
TMSは物流業務への深い理解がなければ要件を正しく汲み取れません。そのため、2024年問題による拘束時間規制、複雑な運賃体系、動態管理といった物流特有のテーマに精通しているかを、過去の導入実績や事例で確認します。
同規模・同業態の運送会社や荷主への導入経験があれば、提案の精度は格段に上がります。逆に、業界知見の浅いベンダーに発注すると、現場の当たり前を一から説明する負担が発注側にのしかかり、認識のずれから手戻りが頻発します。
提案時の質問の鋭さや、業務課題への踏み込み方を見れば、その会社の知見の深さはおおよそ判断できます。
緊急サポート体制の確認
TMSは配車業務の根幹を担うため、稼働初日に連携障害が起きれば配車が止まり、大規模な配送遅延につながります。そのため、発注前に、休日・夜間のオンコール対応の有無、障害時のエスカレーションルート、復旧までの目標時間といったサポート体制を契約条件として明確にしておく必要があります。
「土日夜間に止まったらすぐ対応してくれるのか」という情シス担当の不安に応えられないベンダーは、稼働後にトラブルを情シスへ押し付ける構図になりがちです。SLA（サービス品質保証）として書面に落とし込めるかどうかが、信頼できる発注先の見極めポイントになります。
チェンジマネジメント・定着支援の有無
どれだけ優れたシステムを発注しても、配車マンやドライバーが使ってくれなければ「お蔵入り」になります。GPSで監視されるという嫌悪感、AIに仕事を奪われるという不安、操作習得への抵抗など、現場の反発の仕組みに正面から向き合える発注先かどうかが重要です。
具体的には、ITリテラシーに配慮したUI設計、現場向けの教育プログラム、パイロット導入での小さな成功体験の設計といった定着支援を提供できるかを確認します。
納品して終わりにせず、現場が成果を実感するまで伴走してくれるパートナーを選ぶことが、投資を無駄にしないための最後の決め手になります。
まとめ
TMSの発注先は、パッケージベンダー、SaaS事業者、コンサルティングから開発まで担う会社の三つに大別できます。業務の独自性や連携要件に合わせて選びましょう。
現状業務の洗い出し、RFPの作成、連携対象の一覧化という準備を丁寧に行うことが、成功の土台になります。
契約形態は請負と準委任を使い分け、要件が変わりやすいTMSでは、スモールスタートとラボ型・段階開発を取り入れると破綻しにくくなります。
本体価格だけで決めず、連携・カスタマイズ・運用費を含むTCOと期待できる効果を比べて、投資を判断します。
業界知見・緊急サポート体制・定着支援力を備えた発注先を選ぶことが、お蔵入りを防ぎ投資を回収する鍵となります。
価格の安さだけでなく、長期的に伴走してくれるパートナーかどうかで、発注先を比べていくことが大切です。
▼全体ガイドの記事
・TMSのモダナイゼーションの完全ガイド
RFPの作成や刷新計画を進める際は、レガシーシステム刷新の完全ガイドブックとAI駆動開発の完全ガイドブックもご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。