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

TMS更改の発注は、RFPの準備、複数社の比較、契約範囲の明確化の順に進めます。この順で進めると、相見積もりの精度が上がり、契約後のトラブルも防ぎやすくなります。外注先の選び方や費用、契約前の要件確認もあわせて解説します。

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

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

TMS更改を中心に、配車ロジックや運賃計算ルールなど4つの専門領域を示す図。
業務の複雑さとシステム連携が外注検討の背景になります。

TMS更改を自社内だけで完結させるのは、現実的ではありません。特に、配車ロジックや運賃計算ルールはきわめて複雑です。さらに、GPSによる動態管理やWMS・会計システムとの連携には、専門的な開発・運用ノウハウも欠かせません。

多くの荷主企業・運送会社では、情報システム部門の人員が限られています。そのため、本業を止めずに更改プロジェクトを進めるには、外部パートナーへの発注・委託が前提になります。

TMS更改の外注ニーズが高まる背景

TMS更改の外注ニーズを強めているのは、システムの老朽化、2024年問題への対応、属人的な運用の3つです。いずれも更改を先送りしにくい理由になるため、外注の検討が早まりやすくなっています。

  • 老朽化とサポート終了(EOL):オンプレミスで10年以上稼働したTMSは、OSやブラウザのセキュリティ要件に追従できず、更改を迫られるケースが増えています。
  • 2024年問題:ドライバーの年間時間外労働960時間の上限規制に対し、配車計画の段階で拘束時間超過を自動で警告する機能は、法令遵守上ほぼ必須です。
  • 属人的な運用:Excelや紙、配車担当者の経験に頼ると、退職時にノウハウが失われるリスクがあります。

加えて、システムで業務を標準化する要請も強まっています。いずれも高度な専門性が求められるため、内製よりも、TMSや物流業務に精通したベンダーへの委託が合理的です。

「更改/改修/リプレイス/移行」の違いと発注範囲の決め方

発注前には、自社が求める対応が「更改」なのか「改修」なのかを言葉にしておきます。対応の規模によって委託範囲も見積もりの前提も変わるため、対応の区分と要件の優先度は、次のように整理できます。

  • 改修:既存システムの一部機能を修正する小規模な対応。
  • 更改・リプレイス:システム全体を新しい基盤へ刷新する大規模な対応。
  • MUST(必須):拘束時間チェックなど、欠かせない要件。
  • WANT:AIによる動的ルート最適化など、段階的に追加する要件。

区別が曖昧なままRFPを出すと、ベンダーごとに前提がずれ、見積もりを並べて比べられなくなります。一方、MUSTとWANTを発注前に切り分けておけば、初期の委託範囲を絞れるため、予算とリスクを抑えられます。

ポイント

社内に配車や運賃計算の専門知識と情報システム部門の人員がどれだけあるかが、外注の要否を分けます。迷う場合は、業務の複雑さと社内の余力を比べてから決めます。

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

委託先は、SaaS・パッケージベンダー、SIer・開発会社、コンサル一気通貫型の3タイプに大別されます。得意領域やコスト構造、カスタマイズの自由度が異なるため、自社の要件と照らして選びます。なお、選び方を誤ると、標準機能が自社の運賃ルールに合わず、カスタマイズ費用が想定の3倍になることもあります。

SaaSベンダー・パッケージベンダーへの委託

SaaSやパッケージTMSは、標準機能を中心に導入する方式です。自社の要件に合うかどうかは、下の特徴と照らして判断します。

  • 費用:初期の支出を抑えやすく、月額数万円から導入できます。
  • 運用:標準機能が整い導入が速く、法改正はベンダーの更新で対応されるため、負荷が軽い方式です。
  • 適する企業:1〜2拠点で業務が標準的な運送会社に向いています。
  • 独自要件:取引先ごとに異なるEDIや伝票形式、個別の運賃が多い企業では、標準機能を超える改修が必要になります。

3拠点以上を抱える場合や、古い基幹システムがAPIに対応していない場合のように、複数の条件に当てはまると、標準機能では足りなくなる場面が増えます。

SIer・開発会社へのスクラッチ委託

フルスクラッチなら、自社の業務に合わせて完全に構築できます。ただし大規模な現場では、運賃計算や周辺システム連携の複雑さが、選定の判断材料になります。

  • 複雑な運賃:特殊車両割増、深夜早朝割増、距離逓減制など多階層のルール。
  • 周辺システム連携:既存システムと密に情報をやり取りする大規模な現場。

費用は数千万円から億単位に及ぶこともあります。一方で、業務の独自性が高い企業ほど、投資効果を得やすい選択肢です。

要件定義の精度は品質とコストに直結するため、発注側にも一定の関与が求められます。要件が曖昧なまま委託すると、開発中に仕様変更が頻発し、費用とスケジュールが膨らんでしまいます。

発注前には、同業種・同規模のTMS構築経験や、配車・物流業務の知見があるかを確かめておきます。

コンサル一気通貫型への委託

要件定義や業務改革のコンサルティングから開発・導入・定着支援まで、一貫して委託できます。

  • 要件整理から伴走:情報システム部門の体制が不十分な企業は、発注側の負担を軽減できます。
  • 発注内容が未定:「何を発注すればよいか分からない」段階から相談でき、必要な機能を見極めて費用増を抑えられます。
  • スモールスタート:要件が固まる前から相談し、1業務・1拠点から段階的に拡張できます。

段階的に進める方式は、全社一斉導入のリスクを避けたい企業に適しています。

ポイント

委託先は、標準機能で足りるか、独自の業務を作り込む必要があるかで選び分けます。標準的な業務で1〜2拠点ならSaaSやパッケージ、独自性の高い業務ならSIer・開発会社が候補になります。

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

TMS更改の発注手順を、RFP準備、相見積もりと選定、契約の順に示す図。
比較前に提案条件をそろえる段階が、後の契約範囲につながります。

段階ごとに何を決めるかを先に定めておくと、各社の提案条件がそろい、相見積もりを正しく比べられます。契約の段階で委託範囲を明確にしておけば、契約後のトラブルも防ぎやすくなります。流れは、RFPの準備、比較・選定、契約の順に進みます。

RFP(提案依頼書)と要件定義の準備

RFPの作成と要件定義では、提案条件と現場の実態をそろえるため、次の準備を進めます。課題や予算の整理、MUSTとWANTの切り分け、現場の業務の洗い出し、移行データの一覧化の4つが中心です。

  1. 現行TMSの課題と必要機能、予算、希望日程を、RFPに盛り込みます。さらに、WMS・基幹・会計との連携も示しておきます。
  2. MUSTとWANTを分けてRFPに示し、各社の提案条件をそろえます。
  3. 情報システム部門だけでなく、配車担当者やドライバーも加わって、現場の業務を洗い出します。
  4. データ移行に備えて、Excelや紙で管理している顧客マスタや運賃ルールを一覧にします。

複数社への相見積もりと比較・選定

発注先は1社だけで決めず、最低でも3社程度から相見積もりを取ることをおすすめします。金額だけでは提案の質の差が見えにくいため、比べる観点を金額以外にも広げておきます。

  • 課題理解:提案が自社の課題を捉えているか。
  • 業務実績:TMSや物流業務の経験があるか。
  • 見積範囲:連携開発やデータ移行が含まれているか。

見積もりは、本体費用と連携・改修費用が分かれているかを確かめます。連携費用が別扱いになっていると、安く見える見積もりでも総額が膨らみやすいため、前提条件と除外項目を発注前にすり合わせておきます。

契約形態(請負/準委任)と委託範囲の取り決め

請負契約は成果物の完成に責任を負う形式で、要件が固まった開発工程に向いています。一方、準委任契約は業務の遂行に対して報酬を支払う形式で、要件がまだ流動的なコンサルや要件定義に適しています。

契約書では、どの作業を誰が受け持つかを明確にします。また、データ移行、稼働後の保守・サポート、追加開発の単価も取り決めておきます。範囲が曖昧なままだと、稼働後に契約外のトラブルが起こりやすいため、契約前に書面で合意しておく必要があります。

ポイント

相見積もりは、提案条件をそろえてから比べるのが目安です。条件がそろわないまま金額だけを比べると、前提の違いで総額の差が見えにくくなります。

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

TMS更改の費用項目として、本体、連携・カスタマイズ、地図基盤ライセンス、入力サポート要員の人件費を並べた図。
費用の対象範囲を広げると、本体以外の支出も比較に含められます。

周辺連携が前提のTMSでは、本体以外にも費用が発生します。見積額の表面だけで判断すると、その分が後から重なり、予算超過や計画頓挫につながる恐れがあります。

提供形態別の費用感と発注単位

提供形態によって費用感は異なります。また、利用者数、車両台数、拠点数も発注単位に影響するため、自社の規模に応じて見積もりを取ります。

  • クラウド・SaaS型:月額数万円から。
  • パッケージ・リプラットフォーム型:数百万円から数千万円。
  • フルスクラッチ型:数千万円から億円規模。

「4年以上使うならオンプレミスが安い」と一般に言われますが、TMSでは法改正やOS・ブラウザの要件変更が頻発します。さらに、オンプレミスは都度の有償保守で、クラウドより維持コストが膨らみやすい傾向があります。初期費用だけでなく、数年間のTCO(総保有コスト)で比べるのが基本です。

本体より高くなりやすい連携・カスタマイズ費用

見落とされがちなのが、連携費用とカスタマイズ費用です。なかでも基幹システムや端末との連携費用は、事前に確かめておく必要があります。

  • 基幹システム連携:100万円から500万円かかることがあります。
  • バーコード・ハンディ端末連携:50万円から500万円程度の費用になる場合があります。

「本体は500万円だったが、連携で1,000万円を超えた」というケースも実際にあります。そのため、本体に含まれる範囲と、追加費用になる範囲を確かめておきます。

独自の伝票形式や複雑な運賃ルールのカスタマイズは、パッケージを使う場合でも数千万円に膨らむことがあります。

デジタル地図基盤(ゼンリン等)のライセンス費用も隠れコストです。加えて、AIモデルの定期再学習の工数や、並行運用期間の入力サポート要員の人件費も、見落とせない費用です。

ポイント

見積額は、本体費用と連携・カスタマイズ費用を合わせた総額で比べるのが目安です。初期費用だけで選ぶと、後から想定外の費用が重なりやすくなります。

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

TMS特有の要件を発注時に漏らすと、稼働後に必要な機能が使えなくなる恐れがあります。そのため、固有の確認事項を要件に含めておきます。

2024年問題対応・運賃計算など要件の発注漏れ防止

2024年問題への対応や運賃計算は、RFPに書き漏らすと稼働後に困る要件です。発注前に、委託先の提案がこれらを満たすかを確かめておきます。

  • 時間外労働:配車計画段階で拘束時間超過を自動計算し、警告する機能。
  • バース予約:荷待ち時間削減に向けた予約システムとの連携。
  • 運賃計算:距離・時間に加え、冷蔵冷凍などの特殊車両割増を扱う。

時間外労働の上限は年間960時間です。この機能は、その上限を守るうえで欠かせません。

運賃ルールを自動で集計できれば、請求漏れや計算ミスを防げます。ただし、要件をRFPに明記しないと、追加開発の分だけ費用とスケジュールが膨らみます。

ベンダーの緊急サポート体制とデータ移行の取り決め

TMSは配車業務そのものを支えるため、稼働初日の連携障害は配車の停止や大規模な遅延につながりかねません。そこで、緊急時のサポート体制を確かめておきます。

  • 緊急対応:休日・夜間のオンコール対応と、障害時のエスカレーションルートを取り決めます。
  • 移行担当:Excel、Access、紙で管理する顧客マスタや運賃ルールを、誰がどう整備し、新しいシステムへどう受け渡すかを決めます。
  • データ整備:重複排除や表記ゆれの統一を、誰が担うかを明確にします。曖昧なままだと、移行が長引いて稼働の遅れにつながります。

現場定着(チェンジマネジメント)の委託範囲

どれほど高機能なTMSでも、現場で使われなければ結局お蔵入りになります。

  • 現場の不安:配車担当者はAIの例外対応に、ドライバーはGPS監視に懸念を抱くことがあります。
  • 定着支援:現場の懸念に向き合う支援を、委託範囲に含めます。
  • 試験導入:全社導入の前に、特定の営業所や1拠点・数台で試すパイロット方式。
  • 導入支援:シンプルなUI/UXや現場向けの教育まで手がけられる相手を選ぶと、定着の確度が高まります。

小さな成功体験を重ねると抵抗感が薄れ、自然な定着につながります。

ポイント

TMS特有の要件は、法令対応や運賃計算、緊急時の対応まで含めて発注前に一度洗い出しておくと、稼働後の欠けを減らせます。

まとめ

発注時には、更改と改修を区別したうえで、要件をMUSTとWANTに分けて委託先を選びます。RFPの準備に始まり、見積もりの比較、契約範囲の確認へと進めると、トラブルを抑えやすくなります。

費用は、連携やカスタマイズ、運用まで含めたTCOで判断します。そのうえで、法令対応や運賃計算、緊急時の支援を要件に含めます。データ移行についても、どこまでを誰が担うかを決めておきます。

自社だけで判断しにくいときは、要件定義から伴走できるパートナーに相談し、スモールスタートで始めることをおすすめします。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。