TMSリプレイスの発注は、現状の棚卸しと要件整理、ベンダー選定と契約、移行と定着の順に進めると、抜け漏れを防げます。
発注先の選び方、社内の準備、契約と費用の判断も、この流れに沿って行います。全体像はTMSリプレイスの完全ガイドもご覧ください。
▼全体ガイドの記事
・TMSリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
TMSリプレイスを外注する前に押さえる全体像
TMS発注で最初に決めたいのは、何を誰にどこまで任せるかです。ここが曖昧なままだと、各社の見積もりに含まれる範囲がそろわず、金額を比べても意味がありません。
発注・外注・委託・依頼の違いと使い分け
発注、外注、委託、依頼は、日常では似た意味で使われがちです。ただ、工程の任せ方を決める場面では、言葉の違いをそろえておかないと、社内とベンダーの認識がずれやすくなります。依頼は発注を広く言う日常語なので、以下では残る3語を整理します。
- 発注：対価を払って、成果物や作業を正式に注文する広い意味の言葉です。
- 外注：社内でも担える業務を、専門性やリソースの都合で社外に出す形です。
- 委託：業務そのものを相手に任せる、契約上の考え方です。
設計から保守まで任せる一括委託と、要件定義は自社で行い開発だけを外注する工程分割発注とでは、費用とリスクの大きさが変わります。
たとえば、配車ロジックや運賃ルールは自社で要件を握り、実装だけをベンダーに任せる折衷型が、現実的な落としどころになることもあります。ただ、言葉の定義にこだわるより、自社が握る工程と外に出す工程を分けて書き出すほうが、判断はぶれにくくなります。
内製と外注の判断基準
TMSを完全に内製できるのは、物流企業の一部に限られます。そのため、技術領域と業務の独自性を見て、どこまでを外注するかを決めていきます。
- 高度な技術：配車最適化、地図エンジン、動態管理には、専門的な技術が欠かせません。
- 独自業務：複数拠点や個別の連携要件が重なると、外注での開発が必要になります。
- 標準業務：標準的な配車や運賃ルールであれば、SaaSの導入支援で足りることもあります。
リアルタイム処理を含む場合、社内にエンジニア組織がなければ、完全内製は現実的ではありません。拠点が3拠点以上ある、取引先ごとに異なるEDIや伝票形式を扱う、古い基幹システムがAPI非対応であるなどの条件が複数当てはまると、標準機能では吸収しきれないため、要件を一つずつ確かめます。
すべてを任せきりにすると、ベンダーが業務を理解しきれず、現場で使えないシステムになるおそれもあります。だからこそ、業務の独自性を見極めてから発注方針を決めることが大切です。
TMSリプレイスの発注先の種類と特徴
発注先は大きく、SIer・システム開発会社、パッケージ・SaaSベンダー、コンサルティング会社の3タイプに分かれます。自社の課題に合う相手を選ぶことが、比較の出発点になります。
SIer・システム開発会社
業務が特殊で、既存の基幹システムとの密な連携が必要なら、SIerが候補になります。
- 適合性：独自の運賃体系や複雑な配車ルールに、どこまで合わせられるかです。
- 費用と期間：数千万円から億単位に達することも珍しくなく、期間も半年から1年以上かかります。
- 業界実績：物流・運送系のTMSを構築した実績があるかを、選定時に見ます。
ただ、要件を明確に伝えられなければ、技術力が高くても自社業務とのずれは残ります。
物流業務への理解が浅い会社では、現場の事情が伝わらず、手戻りが頻発します。そのため、技術力に加えて、物流の業務を理解している相手かどうかも見極めることが欠かせません。
パッケージ/SaaSベンダーとコンサルティング会社
標準機能で業務が回るのか、要件整理から支援が必要なのかによって、候補は変わってきます。そのうえで、各社の得意領域を見極めることになります。
- パッケージ・SaaS：月額数万円から、標準機能を使えるサービスです。
- コンサル会社：要件整理から発注先の選定、開発、定着まで支援します。
- 一気通貫の体制：要件のブレや責任の押し付け合いを抑えられます。
SaaSは初期費用を抑えて短期間で導入でき、さらに法改正やセキュリティ要件の変更にも、アップデートで対応できます。
配車や動態管理の標準機能で業務が回る企業には、SaaSが費用対効果の高い選択肢になります。一方で、現場のやり方を変えにくく独自業務が多いと、標準機能では応えきれないことがあります。
業務改革の方向づくりを外から支えてもらう形で、コンサル会社を使う企業も増えています。コンサルから開発まで一社で担う体制であれば、段階的な拡張もしやすくなります。
発注・外注の進め方（プロセス）
発注の流れは、現状の棚卸しから移行・定着まで、大きく3段階に分けて考えると見通しが立ちます。
現状棚卸しとRFP・要件定義の準備
まずは現行の業務とシステムを洗い出し、リプレイスの目的と課題を言葉にしておきます。
- 業務の把握：配車、運賃計算、ドライバーへの指示の流れを、一覧にします。
- データ連携：WMSや会計システムと、どんなデータをやり取りしているか。
- 要件の優先度：MUST要件とWANT要件に分けます。
現場の配車担当やドライバーを巻き込まないと、実態と異なる要件が後から見つかります。そのため、業務を洗い出す段階から現場の声を集めておくと、手戻りを減らせます。
洗い出した内容をもとに、RFP（提案依頼書）と要件定義の骨子を作ります。要件を整理しておくと、見積もりの精度を高められます。ただ、すべてをMUSTにすると見積もりが上がるうえ、優先度が伝わらないと各社の提案を比べにくくなります。
ベンダー選定・見積比較・契約
RFPが固まったら、複数社に提案と見積もりを依頼して、金額以外の点も含めて比べます。
- 比較社数：相見積もりは、最低でも3社程度から取るのが基本です。
- 評価項目：提案の具体性、TMSの実績、サポート体制です。
- 契約条件：納期や検収、保守の範囲を、文書に残します。
ただ、極端に安い見積もりは、連携やカスタマイズが含まれていないことがあり、後から追加費用が発生するおそれがあります。契約書には、データ移行や他システム連携の責任の範囲、追加要望の変更管理のルールも書き込んでおきます。
見積書が「一式」とだけ書かれている場合は、工程ごとの内訳を出してもらい、費用の中身をつかんでから契約します。
移行リハーサルから稼働・定着まで
いきなり全社で一斉に稼働させず、リハーサルとトライアルを挟んで問題を探すのが定石です。
- 先行導入：特定の営業所や一部ルートに限って、まず試します。
- 結果の検証：配車データと運賃計算が正しいかを、一つずつ確かめます。
- 稼働後の支援：並行運用とサポート要員の手配です。
パイロット移行では、連携不具合やマスタの不整合を本番前に洗い出せます。一方で、稼働初日に連携障害が起きると配車が止まり、配送遅延や信用問題につながります。
休日・夜間のオンコール対応とエスカレーション経路は、発注時に決めておくと混乱を抑えられます。
▶ 詳細はこちら：TMSリプレイスの進め方
発注前に準備すべきドキュメントと社内体制
準備が不十分なまま相談すると、的確な提案は得にくくなります。そこで、資料と社内体制を先に整えておきます。
RFP・要件定義書に盛り込むべき項目
RFPには、業務とシステムの条件を具体的に書き込みます。条件がそろっていれば、各社の見積もりを同じ前提で比べられるからです。
- プロジェクト情報：目的、背景、現行課題、予算感、スケジュール。
- 規模と機能：対象拠点数、車両台数、必要な機能要件。
- 連携と法令：周辺システム、2024年問題への対応要件。
- 非機能要件：アクセス数、応答速度、可用性、セキュリティ。
また、運賃計算の複雑さは書き込んでおく必要があります。取引先ごとのEDIや伝票の違いも、あわせて伝えます。WMSや会計システム、ハンディ端末、自動倉庫との連携についても、示しておきます。
条件が曖昧だと、見積もりが膨らむか、見落としによる追加請求につながります。特に、拘束時間や時間外労働、荷待ち時間の記録など、法令に対応する要件は必ず明記しておきます。
要件を整理したRFPがあれば、各社の提案を同じ条件で比べられ、発注後の認識のずれも減らせます。
現場を巻き込むPJ体制づくり
情シスだけでは現場の実態を判断しきれず、現場だけでは技術面の判断が難しくなります。そのため、役割を分けたチームを組み、社内の各部署が担う役割を明確にしておきます。
- 情報システム部門：システム面の検討を担います。
- 配車担当とドライバー代表：業務と現場の要件を伝えます。
- 意思決定できる経営層：重要事項の判断に加わります。
- 社内窓口の責任者：要望を集約して優先順位をつけます。
部署ごとにバラバラにベンダーへ要望を伝えると、要件が膨らみ、収拾がつかなくなるおそれがあります。
発注前に窓口を一本化しておくと、社内の要望を整理して伝えられます。さらに、発注後の連絡もスムーズになり、手戻りを減らせます。
外注で失敗しないためのTMS特有チェックポイント
TMSには、一般的なシステム開発にはない落とし穴があります。予算超過や稼働後のトラブルを防ぐには、発注前の確認が欠かせません。
隠れコスト（連携・カスタマイズ・運用）の見極め
総額を把握するには、本体価格に加えて、初期開発と運用に加わる費用も見ておく必要があります。
- 基幹連携：基幹システムとの連携開発に、100万円から500万円かかります。
- 端末連携：バーコードやハンディ端末とつなぐ開発費が、50万円から500万円に及びます。
- 運用費：デジタル地図基盤のライセンスや、AIルート最適化モデルの定期再学習の工数が、稼働後も続きます。
こうした費用は珍しくなく、「本体は500万円でも、連携費で1,000万円を超えた」という事態も頻発しています。そのため、費用は導入時の総額だけでなく、並行運用中の入力サポート要員の人件費も含めて、総保有コスト（TCO）で比べると全体像をつかみやすくなります。
運用費は隠れコストになりやすく、見落としやすい費用です。見積もりの段階で隠れコストを洗い出せるかどうかは、ベンダーの信頼性を測る目安にもなります。
2024年問題・運賃計算など業務要件の伝え方
業務要件を明確に伝えておけば、手戻りや稼働後の計算ミスを防げます。
- 労働時間：年間960時間の時間外労働上限を踏まえ、警告を出す機能。
- 荷待ち：荷待ち時間の削減に向け、バース予約と連携する仕組み。
- 運賃：特殊車両割増、深夜早朝・休日割増、距離逓減制などのルール。
配車計画の段階で拘束時間超えに気づけるかは、法令遵守に直結します。
運賃計算は、距離や時間だけでは決まらず、ルールが何層にも重なります。このため、一つひとつのルールを正確に伝える必要があります。
ルールが曖昧だと、請求漏れや計算ミスが起きます。そこで、自社のルールを一覧にして、具体例とともに提示します。
ベンダーの緊急サポート体制の確認
物流は土日や夜間も動いているため、障害が起きた時間帯によっては、すぐに対応できる体制が求められます。障害で配車が止まると、配送遅延が顧客に影響します。
- 受付時間：平日日中のみか、休日・夜間も含むか。
- 初動：障害の連絡先と、対応を始めるまでの時間。
- 連絡経路：エスカレーションの流れと、SLA（サービス品質保証）の内容。
まず、対応範囲は発注前に確かめ、その内容を契約書やSLAに書き込みます。
支援が手薄だと、障害のたびに自社の情シスが対応に追われ、現場の対応力まで損なわれかねません。そのため、サポートの品質も価格と同じくらい重視して、ベンダーを選ぶ必要があります。
委託契約と費用の考え方
契約形態によって、責任の範囲と支払い方が変わります。そのうえで、TMS特有の費用構造も踏まえて予算を組みます。
請負契約と準委任契約の違い
要件が固まっているか、作業内容がまだ流動的かによって、契約の種類を選び分けます。
- 請負契約：成果物の納品を約束し、完成させる責任を負う形です。
- 準委任契約：専門的な作業そのものに報酬を払い、成果物の完成は約束しません。
- 工程ごとの使い分け：要件定義は準委任、開発は請負が現実的です。
請負は、要件が固まった作業に適しています。ただ、変更が入るたびに追加費用が生じやすく、要件が曖昧だと認識のずれが問題になります。
また、準委任は、仕様がまだ流動的な作業や、リリース後の継続的な改善・拡張に向きます。このため、工程に合う契約を選べば、無駄なリスクとコストを抑えられます。
費用相場とTCO/ROIの見方
提供形態によって費用の幅が大きく変わるため、初期費用だけでなく、運用費と導入効果も比べます。
- フルスクラッチ：数千万円から億単位に及びます。
- パッケージのリプラットフォーム：数百万円から数千万円の範囲です。
- クラウド・SaaS：月額数万円から利用できます。
連携費やカスタマイズ費、運用コストは初期費用に上乗せされるため、提示された初期費用だけで決めると判断を誤るおそれがあります。
「4年以上使うならオンプレが安い」という一般論もあります。ただ、TMSは法改正やOSアップデート、ブラウザのセキュリティ要件の変更が頻発するため、一概には言えません。
一方で、オンプレは都度の有償保守があり、クラウドより維持費が膨らみやすい点に注意が必要です。そのため、初期費用と数年分の運用費をTCOで比べます。
ROIでは、配送時間の短縮、残業削減、請求漏れ防止を評価します。たとえば、動的ルート最適化では、平均8〜12%の短縮効果が見込まれます。
▶ 詳細はこちら：TMSリプレイスの見積相場・費用
まとめ
TMS発注では、自社で握る工程と外部に任せる範囲を決めたうえで、準備を整えてベンダーと向き合うことが基本です。
発注先の特性を踏まえてRFPや社内体制を整え、業務要件や隠れコスト、サポート体制を確かめると、手戻りを減らせます。
連携費やカスタマイズ費が本体価格を上回ることもあります。だからこそ、初期費用だけでなく、TCOとROIで判断することが大切です。
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を創業。