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