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

TMS改修の発注は、現状の棚卸しとRFP準備、複数社の見積比較、契約形態の決定の順に進めると、費用増や認識のずれを防ぎやすくなります。

発注側が依頼範囲と改修のゴールを先に決めておくと、各社の見積もりを同じ条件で比べられます。全体像はTMS改修の完全ガイドでも確認できます。

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

TMS改修を外注する前に押さえる全体像

TMS改修で外注できる作業と発注側が担う判断を4枚のパネルで示した図
作業を委ねても、実現する業務要件の決定は社内に残ります。

発注側が依頼範囲と改修のゴールを整理しておかないと、ベンダーは正確な見積もりや提案を出せません。

範囲やゴールが曖昧なままだと、見積金額がばらつき、各社を比べられなくなります。

TMS改修で外注できる範囲とできない範囲

外注では、画面や帳票の作り込みだけでなく、要件定義や設計、移行、保守まで任せられます。

  • 要件・設計:要件定義の支援、配車ロジックや運賃計算の設計。
  • 開発・連携:画面と帳票の開発、WMS(倉庫管理システム)や基幹システムとの連携。
  • 移行・保守:移行リハーサル、リリース後の保守。

一方で、配車ルールや取引先ごとの運賃体系、例外対応の判断基準は現場の暗黙知です。これらを社内で言語化しないまま丸投げすると、失敗につながります。

業務要件の優先順位付けと意思決定は、発注側が担います。

MUST(必須)とWANT(できれば欲しい)を分けて整理しないと、機能も費用も膨らみます。

外注先には作業を任せられますが、実現したいことを決める役割は委ねられません。この役割分担を最初に押さえることが、発注成功の第一歩です。

「改修」「リプレイス」「移行」による発注内容の違い

改修内容によって、必要な技術力や移行経験は変わります。発注内容は、改修、リプレイス、移行のどれに当たるかで整理しましょう。

  • 改修:既存システムを活かし、一部の機能を追加・修正。
  • リプレイス:老朽化したシステムを、新しいものに置き換え。
  • 移行:システムをクラウドへ載せ替え。

部分改修では、現行システムの開発元や技術に詳しい会社が有利になります。たとえば、「2024年問題に対応する拘束時間の自動警告機能だけを追加する」なら部分改修にあたります。

リプレイスや移行では、現行資産の調査とデータ移行の経験が問われます。

「Excel運用をやめ、配車から請求まで一貫させる」なら、リプレイスに近い大規模案件です。

規模を取り違えて、小規模な会社に大型案件を、大手に小さな改修を頼むと、頓挫や割高につながるおそれがあります。

依頼内容を自社で言語化しておけば、適切な相談先を絞り込めます。

ポイント

業務要件のうち、必ず必要なもの(MUST)と、あれば望ましいもの(WANT)を分けられていなければ、見積もりを取る前に社内で整理してください。

TMS改修の発注先の種類と特徴

委託先は、受託開発のSIer、TMSパッケージやSaaSのベンダー、一気通貫型の開発会社に分かれます。

各社は、得意領域も費用の構造も異なります。

発注側は、自社の改修内容、予算、社内体制を踏まえ、各タイプの強みと注意点を比べて選びましょう。

SIer・受託開発会社への委託

SIerや受託開発会社は、フルスクラッチを得意とし、パッケージでは吸収しきれない独自要件に適しています。

  • 対応範囲:独自伝票、複雑な運賃ルール、特殊車両の割増計算。
  • 費用と期間:数千万円から億円規模になる場合があり、開発期間も長くなりがちです。

要件定義に時間をかけ、相応の予算を確保できる中堅以上の企業に適した選択肢です。

要件がうまく伝わらないと、「言った・言わない」のトラブルになりやすい点に注意が必要です。

請負契約では、原則として仕様書に書かれたものが作られます。そのため、発注側の文書整備が成否を左右します。

現行システムを別の会社が開発していた場合は、仕様調査費用の扱いを見積もりの段階で確かめておく必要があります。

TMSパッケージ/SaaSベンダーへの依頼

パッケージやクラウドSaaSは、初期費用を抑えられ、導入も速い方法です。

標準的な業務に合わせられる企業や、1拠点・数台から始めたい運送会社に適しています。

  • 標準機能:配車、運賃計算、動態管理など。
  • 利用規模:月額数万円から利用できるサービスもあり、1拠点・数台から始められます。

ただし、標準機能に業務が収まらない場合は注意が必要です。たとえば、3拠点以上でルールが異なる、古い基幹システムがAPIに対応していない、取引先ごとにEDIや伝票形式が異なるといった点が複数当てはまると、費用がかさみます。

初期費用が数十万円でも、連携とカスタマイズを重ねて数千万円に膨らむ例があります。見積もり前に、標準機能でどこまで賄えるかを見極めておくと、費用の見通しが立ちます。

コンサルから開発まで一気通貫で担う会社

コンサルから開発・導入まで担う会社は、要件が固まる前の相談から、現場への定着までを支援します。

  • 上流支援:課題整理やRFP作成、改修方針の設計。
  • 導入支援:配車現場の巻き込み、データ移行、稼働後の定着までの伴走。

要件定義と開発を別々の会社に頼むと、調整コストが生じ、責任の所在も曖昧になりがちです。

一気通貫型なら、この分断を避けられます。

開発だけを切り出して頼むと、現場で使われないシステムになり、投資が無駄になることもあります。業務成果と定着まで伴走する会社であれば、お蔵入りのリスクを下げられます。

ポイント

改修が部分的か、全面的な作り替えかで候補が変わります。部分改修なら現行システムに詳しい会社、全面的な作り替えなら要件定義から任せられる会社を候補に入れるとよいでしょう。

TMS改修を発注・外注する進め方とステップ

TMS改修の発注に向けた現状整理、見積比較、契約選びの順を示す図
準備を整えてから比較し、工程に合う契約へ進む順序が見て取れます。

外注は、現状の洗い出しとRFP準備、複数社への見積依頼と比較、契約形態の決定の順に進めます。

同じ基準で各社を比べれば、後から費用が増えたり、認識がずれたりするのを防げます。

現状棚卸しとRFP(提案依頼書)の準備

まず、業務とシステムの現状を洗い出します。担当者ごとの業務手順、Excelや紙での運用、他システムとの連携を、ひとつずつ書き出しておきます。

  • RFPの記載事項:目的、対象業務、必須・希望要件、連携先、予算・納期、保守希望。
  • TMSの数値:車両台数、拠点数、1日あたりの配車件数、運賃計算の複雑さ。

洗い出した現状をもとにRFP(提案依頼書)を作れば、ベンダーは具体的な提案や精度の高い見積もりを出せます。

RFP作成に不安がある場合は、この工程から支援するコンサル型の会社に相談できます。

複数社への見積依頼と比較

見積もりは、できれば3社程度の複数社から取りましょう。同じRFPを渡せば、提案と金額を同じ基準で比べられます。

  • 費用内訳:連携開発、データ移行、保守が見積もりに含まれているか。
  • 提案と相性:提案の具体性、物流業務への理解、担当者との意思疎通。

1社だけでは、金額の妥当性や相場を判断しにくくなります。一方で、複数社を比べると、各社の得意領域や考え方の違いも見えてきます。

費用項目を見落とすと、後から金額が膨らむことがあります。そのため、総額だけで選ばず、項目別に確認する必要があります。

契約形態(請負/準委任)の選び方

契約形態は請負と準委任に分かれます。それぞれの責任範囲と適する工程を整理しておくと、選びやすくなります。

  • 請負:完成まで責任を負い、仕様が固まった改修に適しています。
  • 準委任:作業や役務の提供が中心で、要件が流動的な段階やアジャイル開発向け。

TMS改修では、要件定義は準委任、開発は請負というように、工程ごとに契約を分ける方法が現実的です。要件が固まる前に請負契約を結ぶと、仕様変更のたびに追加見積もりが発生し、割高になることがあります。

契約は費用とリスクの配分に直結します。そのため、各工程の不確実性を踏まえて契約を設計する必要があります。

ポイント

要件が固まっているかどうかが、契約形態を選ぶ目安です。固まっていない工程は準委任、固まった工程は請負と分けると、仕様変更による追加見積もりの負担を減らせます。

発注時に注意すべきTMS特有の落とし穴

TMS改修の発注前に確認する費用、緊急時のサポート、段階導入の3項目を示す図
費用・稼働・導入範囲の観点で、発注前の確認箇所を整理できます。

一般的なシステム開発とは異なる、物流特有の注意点があります。見積もり後の追加費用や、稼働後の現場の混乱を防ぐには、発注前に押さえておく必要があります。

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

見落とされやすいのが、他システムとの連携費です。基幹システムとの連携は100万円から500万円、バーコードやハンディ端末との連携は50万円から500万円かかる場合があります。

  • 費用の逆転:本体500万円に対して、連携費が1,000万円になる例もあります。
  • 個別改修:独自伝票や複雑な運賃ルールは、フルスクラッチ相当で数千万円に達する場合があります。

連携先と方式(API・EDI・ETLなど)を明確にしたうえで、連携費と改修費を本体と分けて見積もってもらいましょう。

本体価格だけでなく、TCO(総保有コスト)とROI(投資対効果)で全体を判断します。

緊急時のベンダーサポート体制の確認

TMSは、物流現場を止められないシステムです。稼働初日の連携障害で配車が止まれば、大規模な配送遅延につながりかねません。

  • 対応時間:休日や夜間を含めた対応範囲を、契約時に決めておく。
  • 保守条件:オンコール、障害時の連絡経路、復旧目標時間(SLA)。

平日の日中だけ対応するベンダーに24時間稼働の業務を任せると、情シス担当者が対応を一人で抱え込むおそれがあります。

サポート条件は、見積もりの安さに隠れて見落とされがちです。そのため、発注前に対応範囲を詰めておく必要があります。

スモールスタートによる「お蔵入り」の防止

全社や全拠点へ一括で導入すると、現場の反発や想定外の問題で頓挫し、高額なシステムがお蔵入りになるおそれがあります。

  • 小規模に開始:1拠点・数台で試し、効果を見ながら段階的に広げる。
  • 現場で試験:営業所やルートでの運用と、ノウハウの蓄積。
  • 早期に参加:配車担当者やドライバーに使ってもらい、展開時の抵抗を和らげます。

パイロット導入を提案する会社かどうかも、評価の対象にするとよいでしょう。小さく試し、合わなければ中止できれば、投資リスクを抑えられます。

ポイント

連携費と改修費を本体と分けて見積もってもらえるか、サポート時間が稼働時間と合っているかが、見積もり比較の目安です。ベンダーの見積もりで確かめられない項目は、比較の前に問い合わせましょう。

外注を成功させる契約・コミュニケーションのコツ

発注後も、委託先に任せきりにしていては、プロジェクトは前に進みません。そのため、ドキュメントを整えるとともに、現場の受け入れ体制も準備しておきます。

要件の曖昧さをなくすドキュメント整備

外注トラブルの多くは、要件の曖昧さから生まれます。発注側の暗黙の前提は、ベンダーには伝わらないことがほとんどです。

  • 業務要件:配車ルール、運賃計算の例外、取引先ごとの帳票の違い。
  • 進行記録:議事録や仕様変更の履歴を残し、双方で決定事項を確認する。

顧客情報や運賃ルールのマスタデータは、発注側で整えておきます。Excelや紙の情報を誰が整理し、移行するかを決めておかないと、失敗につながります。

現場を巻き込んだ受け入れ体制

配車担当者やドライバーを巻き込まずに進めると、使いにくさや業務との不一致が稼働後に表面化し、定着しないことがあります。

  • 体制:発注段階から現場代表を含むチームづくり。
  • 不安への配慮:「AIに仕事を奪われる」「GPSで監視される」といった懸念を聞き、システムは現場を助ける道具だと伝えます。
  • 受け入れ確認:テストで出た現場の意見を、システムに反映する。

現場に使いこなされるかどうかは、この受け入れの進め方で大きく変わります。

ポイント

社内で要件を文書にまとめられない項目は、発注前に整理の担当者を決めておきましょう。誰が整理するかが決まらないまま進めると、失敗につながるおそれがあります。

まとめ

TMS改修を外注するときは、依頼内容を整理し、自社に合う委託先を選ぶことが出発点になります。

SIer、パッケージ・SaaS、一気通貫型では、得意領域と費用の構造がそれぞれ異なります。

現状の洗い出し、RFP準備、複数社の比較、工程に合った契約の順に進めると、納得のいく発注に近づきます。

連携費用、緊急時のサポート、段階的な導入にも注意が必要です。要件を文書にまとめ、現場を受け入れ体制に巻き込むことが、成果につながります。

発注前の準備に時間をかけることが、投資対効果を高める近道です。

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

会社紹介

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

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

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

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

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

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