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