TMS（輸配送管理システム）の刷新を決めたものの、「どこに、どうやって発注すればよいのか」「外注先の選び方や委託範囲をどう決めればよいのか」で手が止まってしまう企業は少なくありません。TMSは配車・運賃計算・動態管理・WMSや基幹システムとの連携など、業務の根幹に深く関わるため、発注の進め方を誤ると本体価格の数倍に費用が膨らんだり、現場で使われない「お蔵入りシステム」になったりするリスクがあります。
この記事では、TMS刷新を外部に発注・外注・委託する際の具体的な進め方を、発注先の種類の見極め方から、RFP（提案依頼書）の準備、契約形態の選び方、費用相場と隠れコスト、失敗しないためのチェックポイントまで体系的に解説します。物流現場の反発や2024年問題への対応といったTMSならではの論点も踏まえ、この記事を読めば自社に最適な発注の判断ができる状態を目指します。
▼全体ガイドの記事
・TMS刷新の完全ガイド
TMS刷新の発注・外注・委託の全体像
TMS刷新を外部に任せる際、まず押さえておきたいのが「発注」「外注」「委託」「依頼」という言葉の使い分けと、自社で抱えるべき範囲の見極めです。ここを曖昧にしたまま動き出すと、ベンダーとの役割分担が不明確になり、後工程でのトラブルや追加費用の温床になります。
発注・外注・委託・依頼の違いと使い分け
実務上、これらの言葉はほぼ同じ意味で使われますが、契約や責任範囲を考えるうえでは区別すると整理がしやすくなります。「発注」は仕事を正式に注文する行為全般を指し、見積もりに合意して開発を依頼する場面で使われます。「外注」は本来自社で行う業務を外部の専門会社に任せることを意味し、TMSの設計・開発・移行作業を社外に出すケースが典型です。
「委託」は業務の遂行そのものを任せる契約に近く、運用保守やヘルプデスクを継続的に任せる場合に用いられます。「依頼」はより広く相談段階を含む言葉です。重要なのは言葉の厳密な定義よりも、TMSのどの工程（要件定義・設計・開発・データ移行・運用保守）を、誰が、どこまで担うのかを契約前に明文化することです。ここが曖昧だと「言った言わない」の争いに発展しやすくなります。
自社開発と外部委託の判断基準
TMS刷新を自社主導で進めるか、外部に委託するかの判断は、社内のIT人材と業務理解のバランスで決まります。配車ロジックや運賃計算ルールは各社固有の知見が詰まっており、ここを外部任せにしすぎると要件が伝わらず手戻りが増えます。一方で、クラウド基盤の構築やWMS・基幹システムとのAPI連携といった技術領域は、専門ベンダーに外注したほうが品質も速度も上がります。
判断の目安として、3拠点以上で運用している、古い基幹システムがAPI非対応である、取引先ごとに異なるEDIや伝票フォーマットを抱えている、といった条件が複数該当する場合は、パッケージの標準機能だけでは収まらず、外部の開発パートナーによるカスタマイズや連携開発が現実的な選択肢になります。逆に1拠点・少数台でシンプルな運用であれば、SaaSを自社設定で導入する形で外注範囲を最小化できることもあります。
TMS刷新を外注できる発注先の種類と特徴
TMS刷新の発注先は大きく3つのタイプに分かれます。それぞれ得意領域・費用感・関与の深さが異なるため、自社の課題と相性のよい相手を選ぶことが成否を分けます。発注先のタイプを誤ると、安く済ませたつもりが連携開発で大幅に予算超過する、といった事態を招きます。
SaaS・パッケージベンダーへの発注
既成のTMSパッケージやクラウドSaaSを提供するベンダーへの発注は、初期費用を抑えやすく導入も短期間で済むのが強みです。月額数万円から始められるサービスもあり、配車・動態管理・運賃計算といった標準機能はすぐに使えます。標準業務に近い運送会社であれば、最もコストパフォーマンスのよい選択肢になります。
注意点は、標準機能で対応できない独自の運賃ルールや帳票、既存システムとの連携が必要になった場合に、追加開発費が想定外に膨らむことです。「初期費用十万円から」とうたっていても、カスタマイズと連携で結局数百万円から数千万円規模になる例は珍しくありません。発注前に、自社の業務がパッケージの標準範囲に収まるかを必ず確認します。
SIer・システム開発会社への外注
独自性の高い配車ロジックや複雑な連携を求める場合は、フルスクラッチやセミスクラッチで開発できるSIer・システム開発会社への外注が選択肢になります。自社の業務にぴったり合うシステムを構築でき、WMSや自動倉庫、ハンディ端末との連携も柔軟に設計できます。費用は数千万円から億円規模になることもあり、開発期間も長くなる傾向があります。
このタイプに外注する際は、物流・TMSドメインの開発実績があるかを重視します。汎用的な業務システムの開発は得意でも、配車最適化や2024年問題対応といったTMS特有の要件に不慣れな会社だと、要件のすり合わせに膨大な工数がかかります。同業種・近い規模の導入実績を提示できるかどうかが、外注先選定の重要な判断材料です。
コンサル一体型の開発パートナーへの委託
「何をどう刷新すべきか」という上流から相談したい場合は、コンサルティングから開発・定着支援までを一気通貫で担えるパートナーへの委託が適しています。要件が固まる前の段階から業務分析に入り、現状の課題整理、移行方式の設計、現場への定着支援まで伴走してもらえるため、発注側に強いIT人材がいなくてもプロジェクトを前に進めやすくなります。
このタイプは、スモールスタートで1拠点・数台から始め、効果を確認しながら段階的に拡張していくアプローチと相性がよいのが特徴です。ウォーターフォール型で一括導入するよりリスクを抑えられ、現場の反発が出やすいTMSでは特に有効です。窓口が一本化されるため、複数ベンダーの調整負担が減る点もメリットです。
発注前に準備すべきドキュメントと要件整理
発注の成否は、依頼する前の準備でほぼ決まります。要件が曖昧なまま相見積もりを取ると、各社の提案がバラバラになり比較できず、契約後の認識ずれで追加費用が発生します。ここでは発注前に整えておくべきドキュメントと要件整理のポイントを解説します。
現状業務の棚卸しとMUST/WANTの切り分け
最初に行うのは、現状の配車・運行・請求業務がどのように回っているかの棚卸しです。Excelや紙、属人的な判断に依存している部分を洗い出し、現行システムで何ができて何ができていないかを可視化します。この作業を情シスだけで進めず、実際に配車を担当する現場の担当者やドライバーを巻き込むことが、現実に即した要件を引き出す鍵になります。
洗い出した要件は、必ず実現すべき「MUST」と、あれば望ましい「WANT」に切り分けます。すべてを盛り込もうとすると費用も期間も膨張するため、優先順位を明確にしておくことが重要です。たとえば「拘束時間超過の事前警告はMUST、AIによる動的ルート最適化は将来のWANT」というように整理しておくと、ベンダーとの議論がスムーズになります。
RFP（提案依頼書）の作り方
複数のベンダーに発注を検討する場合、RFP（提案依頼書）を用意すると提案の質と比較精度が大きく上がります。RFPには、刷新の目的と背景、対象業務の範囲、MUST/WANTの機能要件、現行システムと連携先の一覧、想定スケジュール、概算予算の上限、求める契約形態などを盛り込みます。これにより各社が同じ前提で提案でき、横並びで比較できるようになります。
RFPを作る余裕がない場合でも、最低限「解決したい課題」「絶対に外せない機能」「連携が必要なシステム」「予算と時期の目安」の4点は文書化しておきます。口頭だけで相談を進めると、各社の解釈がずれて見積もりの根拠が比較できなくなり、結果的に発注判断を誤りやすくなります。
データ移行・連携要件の明確化
TMS刷新で最も見落とされがちで、かつ費用が膨らみやすいのがデータ移行と連携の要件です。顧客マスタや運賃ルールのマスタがExcelや紙でバラバラに管理されている場合、誰がどう整理して移行するのかを事前に決めておかないと、移行段階で泥沼化します。マスタ整備は発注側でしか判断できない部分が多く、ベンダー任せにできません。
連携要件では、WMSやERP、会計・販売管理システムとのデータ連携の必要性と、相手システムがAPIに対応しているかを確認します。フォーマットが合わない場合はAPIやETLによる変換開発が必要となり、基幹連携で100万円から500万円、バーコード・ハンディ連携で50万円から500万円といった追加費用が発生します。発注前に連携対象を洗い出しておくことが、後の予算超過を防ぎます。
TMS刷新の発注・外注の進め方とステップ
準備が整ったら、いよいよ発注のステップに入ります。候補ベンダーの選定から契約、移行方式の合意までを順序立てて進めることで、認識ずれやトラブルを最小化できます。ここでは発注実務の流れを具体的に解説します。
候補ベンダーの選定と相見積もり
RFPをもとに、3社程度の候補ベンダーから提案と見積もりを取るのが一般的です。比較の際は総額の安さだけで判断せず、見積もりに連携費用やデータ移行費用、運用保守費用が含まれているかを必ず確認します。「本体500万円だが連携で1,000万円」という構造は珍しくないため、本体価格だけを比べると後で逆転します。
あわせて、各社の提案が自社の課題をどれだけ理解しているかも評価します。単に機能一覧を並べた提案より、自社の配車業務や2024年問題対応に踏み込んだ提案をしてくる会社のほうが、発注後の手戻りが少なくなります。提案内容の深さは、そのベンダーの物流ドメイン理解度を映す鏡です。
契約形態（請負／準委任）の選び方
システム開発の契約形態は、大きく「請負契約」と「準委任契約」に分かれます。請負契約は成果物の完成に責任を負う契約で、要件が明確に固まっている場合に向いています。仕様が確定している部分は請負で発注すると、予算と納期が読みやすくなります。
一方、要件が固まりきっていない上流工程や、スモールスタートで試しながら進める場合は、作業時間に対して報酬を支払う準委任契約が適しています。TMS刷新では、要件定義は準委任、開発フェーズは請負、というように工程ごとに契約形態を使い分けると、双方のリスクを抑えられます。契約書には検収条件や瑕疵対応の範囲も明記しておきます。
移行方式とスモールスタートの合意
発注時には、旧システムから新システムへの移行方式もベンダーと合意します。一括移行（ビッグバン）は短期間で切り替えられる反面リスクが大きく、段階移行や並行移行はリスクは抑えられるものの一時的に二重入力の負荷がかかります。拠点数や業務の独自性に応じて、どの方式が適切かを見極めます。
特に拠点数が多い、または現場の反発が予想される場合は、特定の営業所やルートで先行導入するパイロット移行が現実解になります。1拠点・数台から小さく始め、ノウハウを蓄積してから全体展開する合意をしておくと、「いきなり数千万円の全社導入」というリスクを避けられます。リリース後も継続的に拡張していく前提で契約を組むと、長期的な失敗を防げます。
発注時の費用相場と「隠れコスト」のリアル
発注の判断で避けて通れないのが費用の問題です。TMS刷新は提供形態によって費用感が大きく異なり、さらに表面的な見積もりには現れない「隠れコスト」が後から効いてきます。ここを理解しておくことが、予算超過を防ぐうえで欠かせません。
提供形態別の費用感
費用の目安は提供形態で大きく分かれます。クラウドSaaS型は月額数万円から始められ、初期投資を抑えたい中小規模の事業者に向いています。パッケージをカスタマイズして導入する形態は数百万円から数千万円、自社専用にフルスクラッチで開発する形態は数千万円から億円規模になるのが一般的です。
注意したいのが「4年の壁」と呼ばれる考え方です。「4年以上使うならオンプレのほうが安い」という一般論がありますが、TMSは時間外労働規制などの法改正、OSアップデート、ブラウザのセキュリティ要件変更が頻繁に発生します。オンプレは都度有償保守が必要となり、結果的にクラウドより維持コストが高くつくケースが少なくありません。発注時はTCO（総保有コスト）で比較する視点が重要です。
連携・カスタマイズの隠れコスト
発注で最も予算を狂わせるのが、本体価格に含まれない隠れコストです。WMSや基幹システムとの連携開発、独自伝票や複雑な運賃ルールへのカスタマイズは、本体価格を大きく上回ることがあります。前述のとおり「本体500万円に対し連携で1,000万円」という逆転は実際に起こります。
さらに運用フェーズでも、デジタル地図基盤のライセンス料、AIによるルート最適化モデルの定期的な再学習工数、移行期間中に新旧システムへ二重入力する現場をサポートする要員の人件費など、見積書には載りにくいコストが発生します。発注前にこれらを洗い出し、ベンダーに見積もりへ含めるよう依頼することで、後からの想定外を防げます。
外注で失敗しないためのチェックポイント
発注先を決める前に、TMS特有の観点で必ず確認しておきたいポイントがあります。これらを見落とすと、稼働後のトラブルや現場での不使用といった深刻な失敗につながります。発注の最終チェックリストとして押さえておきましょう。
ベンダーの緊急サポート体制の確認
TMSは物流の現場が24時間365日動いているため、システムが停止すると配車そのものが止まり、大規模な遅延につながります。発注前に、休日・夜間のオンコール対応があるか、障害時のエスカレーションルートはどうなっているか、緊急時の連絡先と対応時間を必ず確認します。稼働初日の連携障害で配車が停止する事態は実際に起こり得ます。
「サポートは平日日中のみ」というベンダーに発注すると、トラブル対応が情シスに押し付けられ、現場が混乱します。保守契約の範囲と費用、対応SLA（サービス品質保証）を契約段階で明文化しておくことが、安心して運用するための前提条件です。
現場定着・チェンジマネジメントの委託範囲
どれだけ優れたシステムを発注しても、現場が使わなければ投資は無駄になります。ベテランの配車マンは「AIに任せたらイレギュラーに対応できない」「自分の仕事が奪われる」と不安を抱き、ドライバーはGPSによる動態管理を「監視されている」と感じがちです。こうした反発に対応する定着支援を、発注時に委託範囲へ含めるかを検討します。
具体的には、現場のITリテラシーに配慮した操作研修、わかりやすいUI/UXの設計、そしてパイロット導入で小さな成功体験を積ませる進め方です。システムの開発だけを外注し、定着支援は発注側で担うのか、それともパートナーに伴走してもらうのかを最初に決めておくと、「お蔵入りシステム」を防げます。
拡張性・将来対応の確認
TMSは一度導入すると3年から5年は使い続けるため、将来の変化に追従できる拡張性を備えているかを発注前に確認します。具体的には、新しい動態管理のインターフェースや配送ルールを後から追加開発できるか、法改正に合わせてクラウド側でアップデートされるか、共同配送プラットフォームとのAPI連携に対応できるか、といった点です。
中長期では、自動運転トラックやドローン配送といった新技術の登場も視野に入ります。導入時点で完璧を求める必要はありませんが、拡張の余地がない閉じたシステムを発注すると、数年後に陳腐化して再刷新を迫られます。柔軟に拡張できる設計思想を持つベンダーかどうかは、発注判断の重要な軸です。
まとめ
TMS刷新の発注・外注を成功させる鍵は、依頼する前の準備にあります。発注先には「SaaS・パッケージベンダー」「SIer・開発会社」「コンサル一体型パートナー」という3つのタイプがあり、自社の拠点数や業務独自性、社内のIT人材に応じて選ぶことが重要です。発注前には現状業務の棚卸しとMUST/WANTの切り分け、RFPの準備、データ移行・連携要件の明確化を済ませておきましょう。
費用は本体価格だけでなく、連携・カスタマイズ・運用にかかる隠れコストまで含めてTCOで比較し、契約形態は工程ごとに請負と準委任を使い分けます。そして緊急サポート体制、現場定着のチェンジマネジメント、将来の拡張性という3つのチェックポイントを確認することで、「お蔵入り」や予算超過といった失敗を避けられます。1拠点から小さく始め、効果を見ながら段階的に拡張していくスモールスタートの発注が、TMS刷新における最も現実的な進め方です。
▼全体ガイドの記事
・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を創業。