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