TMS更改の発注/外注/依頼/委託方法について

TMS（輸配送管理システム）の更改を検討し始めたものの、「どの会社に、何を、どこまで依頼すればよいのか」が分からず、最初の一歩で立ち止まってしまう担当者は少なくありません。TMSは配車・運賃計算・動態管理・WMSや基幹システムとの連携など機能が広範に及ぶため、発注範囲の切り分けを誤ると、後から追加費用が膨らんだり、現場で使われないシステムになったりするリスクが高まります。特に「本体価格は500万円だったのに、連携開発で1,000万円を超えた」というケースは珍しくありません。

この記事では、TMS更改を外注・委託する際の発注先の種類、依頼から契約までの進め方、見落としがちな費用構造、そして2024年問題対応やデータ移行といったTMS特有のチェックポイントまでを体系的に解説します。請負契約と準委任契約の違いや、RFP（提案依頼書）に盛り込むべき要件、相見積もりで比較すべき観点も具体的に示しますので、はじめてTMS更改を発注する方でも、失敗のリスクを抑えながら適切なパートナーへ依頼できるようになります。読み終える頃には、自社が「どの委託形態を、どの範囲で選ぶべきか」を判断できる状態を目指します。

▼全体ガイドの記事
・TMS更改の完全ガイド

TMS更改を外注すべき理由と発注前に押さえる全体像

TMS更改を自社内で完結させるのは現実的ではありません。配車ロジックや運賃計算ルールはきわめて複雑で、加えてGPSによる動態管理やWMS・会計システムとの連携など、専門的な開発・運用ノウハウが求められるためです。多くの荷主企業・運送会社では情報システム部門の人員が限られており、本業の業務を止めずに更改プロジェクトを進めるには、外部パートナーへの発注・委託が前提となります。

TMS更改の外注ニーズが高まっている背景には、大きく分けて3つの圧力があります。1つ目はシステムの老朽化とサポート終了（EOL）です。オンプレミスで10年以上稼働してきたTMSは、OSやブラウザのセキュリティ要件に追従できず、更改を迫られるケースが増えています。2つ目は2024年問題への対応で、ドライバーの年間時間外労働960時間の上限規制に対し、配車計画段階で拘束時間超過を自動警告する機能が法令遵守上ほぼ必須となりました。

3つ目は、Excelや紙、属人化した配車マンの経験に依存した運用の限界です。担当者の退職とともにノウハウが失われるリスクが顕在化し、システムによる標準化への要請が強まっています。これらはいずれも高度な専門性を要するため、自前での内製ではなく、TMSや物流業務に精通したベンダーへの委託が合理的な選択肢となっているのです。

発注の前に、自社が求めているのが「更改」なのか「改修」なのかを言語化することが重要です。改修は既存システムの一部機能を修正する小規模な対応、更改やリプレイスはシステム全体を新しい基盤へ刷新する大規模な対応を指します。この区別が曖昧なままRFPを出すと、ベンダーごとに前提がずれ、見積もりの比較ができなくなります。

発注範囲を決める際は、要件をMUST（必須）とWANT（あれば望ましい）に切り分ける作業が欠かせません。たとえば「2024年問題対応の拘束時間チェック」はMUST、「AIによる動的ルート最適化」は段階的に追加するWANTとして位置づける、といった整理です。この切り分けを発注前に行うことで、初期の委託範囲を絞り、予算とリスクをコントロールしやすくなります。

TMS更改の発注先となる委託先の種類と特徴

TMS更改の委託先は、大きく3つのタイプに分けられます。それぞれ得意領域やコスト構造、カスタマイズの自由度が異なるため、自社の要件と照らし合わせて選ぶことが大切です。発注先のタイプを誤ると、「標準機能では自社の運賃ルールに対応できない」「カスタマイズ費用が想定の3倍になった」といったミスマッチが起こります。

クラウド型のSaaSやパッケージTMSへの委託は、初期費用を抑えやすく、月額数万円から導入できる点が魅力です。標準機能が整っているため導入スピードも速く、1〜2拠点規模で業務がある程度標準的な運送会社には適しています。法改正への追従もベンダー側のアップデートで対応されるため、運用負荷が軽い点も利点です。

一方で、取引先ごとに異なるEDIや伝票フォーマット、独自の運賃ルールが多い企業では、標準機能の範囲を超えるカスタマイズが必要になります。3拠点以上を抱える、古い基幹システムがAPIに非対応、といった条件が複数該当する場合、SaaSの標準では限界が来やすいため、発注前に自社要件との適合度を慎重に見極める必要があります。

SIerや開発会社にフルスクラッチで委託する場合、自社の業務に完全に合わせたシステムを構築できます。複雑な運賃計算（特殊車両割増・深夜早朝割増・距離逓減制など多階層のルール）や、既存の周辺システムとの密な連携が求められる大規模な現場に向いています。費用は数千万円から億単位に及ぶこともありますが、業務独自性が高い企業ほど投資対効果を発揮しやすい選択肢です。

ただし、要件定義の精度がそのまま品質とコストに直結するため、発注側にも一定の関与が求められます。要件が曖昧なまま委託すると、開発途中での仕様変更が頻発し、費用とスケジュールが膨張します。実績として同業種・同規模のTMS構築経験があるか、配車や物流業務の知見があるかを発注前に確認することが、失敗を避ける鍵となります。

近年増えているのが、要件定義や業務改革のコンサルティングから開発・導入・定着支援までを一気通貫で委託できるパートナーへの発注です。自社に情報システム部門の体制が十分にない場合、要件整理の段階から伴走してもらえるため、発注側の負担を大きく軽減できます。とくに「何を発注すればよいか分からない」という初期段階の企業には有効です。

このタイプは、業務全体を俯瞰したうえで「本当に必要な機能」を見極め、過剰な作り込みによるコスト増を抑えられる点も利点です。要件が固まる前から相談でき、1業務・1拠点から小さく始めて段階的に拡張していくスモールスタート型のアプローチを取りやすいため、いきなり全社導入するリスクを避けたい企業に適しています。

TMS更改の発注・外注の進め方（依頼から契約まで）

TMS更改の発注は、思いつきでベンダーへ問い合わせるのではなく、準備・比較・契約という段階を踏むことで成功確率が高まります。発注プロセスを丁寧に設計することで、相見積もりの精度が上がり、契約後のトラブルも未然に防げます。ここでは依頼から契約までの流れを3つのステップで解説します。

発注の出発点は、自社の現状と要望を整理したRFP（提案依頼書）の作成です。RFPには、現行TMSの課題、必要な機能、連携が必要な周辺システム（WMS・基幹・会計）、想定予算、希望スケジュールを明記します。ここで先述のMUST／WANTの切り分けを反映させておくと、各社の提案がぶれず、横並びで比較しやすくなります。

RFP作成と並行して、現場を巻き込んだ現状棚卸しを行うことが重要です。情報システム部門だけでなく、実際に配車を担う担当者やドライバーの意見を集めることで、現場で使われる要件が定義できます。Excelや紙でバラバラに管理されている顧客マスタや運賃ルールの整理も、この段階で着手しておくと、後のデータ移行がスムーズになります。

発注先は1社だけで決めず、最低でも3社程度から相見積もりを取ることをおすすめします。比較すべきは金額だけではありません。提案内容が自社の課題を正しく理解しているか、TMSや物流業務の実績があるか、連携開発やデータ移行をどこまで含めているかといった観点を総合的に評価します。

とくに見積書では、本体費用と連携・カスタマイズ費用が明確に区別されているかを確認してください。安く見える見積もりでも、連携費用が別途扱いになっていると、最終的な総額が大きく膨らみます。後から追加費用で揉めないよう、見積もりの前提条件と除外項目を発注前にすり合わせておくことが肝心です。

発注先が決まったら、契約形態を明確にします。代表的なのは請負契約と準委任契約です。請負契約は成果物の完成に責任を負う形態で、要件が固まっている開発工程に向いています。一方、準委任契約は業務の遂行に対して報酬を支払う形態で、要件が流動的なコンサルティングや要件定義フェーズに適しています。

契約時には、委託範囲と責任分界点を文書で明確にしておくことが欠かせません。データ移行は誰が行うのか、稼働後の保守・サポートはどこまで含まれるのか、追加開発が発生した場合の単価はどうなるのかを取り決めておきます。曖昧なまま発注すると、稼働後に「これは契約範囲外」というトラブルが起こりやすいため、書面での合意が重要です。

発注時に確認すべき費用と「隠れコスト」

TMS更改の発注で最も注意すべきは、表面的な見積金額だけで判断しないことです。TMSは周辺システムとの連携が前提となるため、本体価格以外に多くの費用が発生します。発注前にこの費用構造を理解しておかないと、予算が大幅に超過し、プロジェクトが頓挫しかねません。

費用感は提供形態によって大きく異なります。クラウド・SaaS型は月額数万円から利用でき、初期投資を抑えたい企業に向いています。パッケージやリプラットフォーム型は数百万円から数千万円、フルスクラッチ型は数千万円から億円規模が一般的な相場です。発注単位も、利用ユーザー数や車両台数、拠点数によって変動するため、自社の規模に応じた見積もりを取ることが大切です。

判断の際に押さえておきたいのが「4年の壁」という考え方です。一般に「4年以上使うならオンプレミスが安い」と言われますが、TMSは法改正やOSアップデート、ブラウザのセキュリティ要件変更が頻発するため、オンプレミスでは都度の有償保守でクラウドより維持コストが膨らみやすい特性があります。初期費用だけでなく、数年間のTCO（総保有コスト）で比較する視点が欠かせません。

TMS更改で最も見落とされやすいのが、連携費用とカスタマイズ費用です。基幹システムとの連携には100万円から500万円、バーコードやハンディ端末との連携には50万円から500万円程度がかかることがあり、「本体は500万円だが連携で1,000万円を超えた」というケースは実際に起こります。発注時には、どこまでが本体に含まれ、どこからが連携の追加費用なのかを必ず確認してください。

さらに、業務独自性が高いほどカスタマイズ費用が膨張します。独自の伝票フォーマットや複雑な運賃ルールを無理にシステム化しようとすると、パッケージのカスタマイズがフルスクラッチ相当の数千万円に跳ね上がることもあります。加えて、デジタル地図基盤（ゼンリン等）のライセンス費用、AIモデルの定期再学習工数、並行運用期間の入力サポート要員の人件費といった運用コストも、発注前に見込んでおくべき隠れコストです。

外注で失敗しないためのTMS特有チェックポイント

TMSには、他の業務システムにはない固有の要件があります。これらを発注時の要件に漏れなく含めておかないと、稼働後に「肝心の機能が使えない」という事態に陥ります。ここでは、外注で特に注意すべきTMS特有のチェックポイントを整理します。

TMS更改では、2024年問題への対応を要件に必ず含める必要があります。具体的には、配車計画の段階で「このルートは拘束時間を超過する」と自動計算し、事前に警告する機能です。年間960時間の時間外労働上限を遵守するうえで欠かせない機能であり、荷待ち時間削減のためのバース予約システム連携も重要な要件となります。

もう1つ忘れてはならないのが、複雑な運賃・コスト計算の自動化です。距離や時間だけでなく、冷蔵冷凍などの特殊車両割増、深夜早朝休日割増、距離逓減制といった多階層のルールをマスタに登録し、実績から自動集計できるかを確認します。これにより請求漏れや計算ミスを防げます。これらの要件をRFPに明記しておかないと、発注後の追加開発でコストとスケジュールが膨らみます。

TMSは配車という業務の根幹を担うため、稼働初日に連携障害が起きると、配車が停止し大規模な遅延につながります。発注時には、ベンダーの緊急サポート体制を必ず確認してください。休日や夜間のオンコール対応、障害発生時のエスカレーションルートが取り決められているかは、運送会社にとって死活問題です。

データ移行の取り決めも見落とせません。ExcelやAccess、紙でバラバラに管理されてきた顧客マスタや運賃ルールを、誰がどのように整備して移行するのかを契約段階で明確にします。データのクレンジング（重複排除や表記ゆれの統一）を誰が担うかが曖昧だと、移行作業が泥沼化し、稼働が大幅に遅れる原因になります。

どれほど高機能なTMSを発注しても、現場で使われなければ「お蔵入りシステム」になってしまいます。ベテランの配車マンには「AIに配車を任せたらイレギュラーに対応できないのでは」という不安があり、ドライバーには「GPSで監視されるだけではないか」という抵抗感が生まれがちです。こうした現場の心理に正面から向き合う定着支援を、委託範囲に含めることが成功の分かれ目です。

有効なのは、いきなり全社導入するのではなく、特定の営業所や1拠点・数台で試験導入するパイロット方式です。小さな成功体験を現場で積み重ねることで、抵抗感が薄れ、自然な定着につながります。ITリテラシーに配慮したシンプルなUI/UXや、現場向けの教育プログラムまで支援できるパートナーを選ぶと、定着の確度が高まります。

まとめ

TMS更改の発注・外注を成功させるには、まず「更改」と「改修」の違いを整理し、要件をMUSTとWANTに切り分けたうえで、自社に合った委託先のタイプ（SaaS、スクラッチ、コンサル一気通貫）を選ぶことが出発点となります。発注プロセスでは、RFPの準備、複数社からの相見積もり、契約形態と委託範囲の明確化という3ステップを丁寧に踏むことで、後のトラブルを大幅に減らせます。

費用面では、表面的な本体価格ではなく、連携・カスタマイズ・運用を含めたTCOで判断することが重要です。さらに、2024年問題対応や複雑な運賃計算、緊急サポート体制、データ移行、そして現場定着のためのチェンジマネジメントまでを発注時の要件に含めておくことで、「お蔵入り」を防ぎ、投資を確実に回収できるTMS更改が実現します。自社だけで判断が難しい場合は、要件定義の段階から伴走できるパートナーに相談し、スモールスタートで小さく始めることをおすすめします。

▼全体ガイドの記事
・TMS更改の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。