TMS(輸送管理システム)のリニューアルを検討し始めたものの、「そもそも誰に発注すればよいのか」「外注と委託は何が違うのか」「契約はどう結べば失敗しないのか」と、発注の入り口で立ち止まってしまう物流・情シス担当の方は少なくありません。配車システムや物流管理システムは社内業務の根幹に関わるため、発注先の選び方ひとつでプロジェクトの成否が大きく変わります。とくに2024年問題への対応や老朽化したシステムのEOL(サポート終了)を背景に刷新を迫られているケースでは、発注の判断を誤ると数百万円から数千万円規模の投資が「お蔵入りシステム」に終わるリスクすらあります。
本記事では、TMSのリニューアルを発注・外注・委託する際の具体的な進め方を、発注先の4タイプの選び方から、相見積もりの比較方法、請負契約と準委任契約の使い分け、そして本体価格に隠れた連携・カスタマイズ費用の見抜き方まで体系的に解説します。「本体500万円のはずが連携で1,000万円かかった」といった発注後の想定外を防ぎ、スモールスタートで小さく試しながら段階的に拡張していく現実的な外注の進め方をお伝えします。発注担当者がベンダーと対等に交渉できる知識を、この記事一本で身につけていただける内容です。
▼全体ガイドの記事
・TMSのリニューアルの完全ガイド
TMSのリニューアルを外注する前に押さえるべき全体像

TMSのリニューアルを外注する際は、いきなり開発会社へ問い合わせるのではなく、まず「なぜ外注するのか」「どこまでを任せるのか」を社内で整理することが出発点になります。配車・物流管理は属人化しやすい業務であり、発注の目的が曖昧なままだと、ベンダーに丸投げした結果、現場が使わないシステムが出来上がってしまいます。ここでは外注を成功させる前提として、発注前に共有しておきたい全体像を解説します。
なぜ自社開発ではなく外注・委託が選ばれるのか
TMSのリニューアルを自社の情シス部門だけで内製しようとすると、配車最適化アルゴリズムや動態管理、デジタル地図基盤との連携といった専門領域でつまずきがちです。運送業・物流業の多くは情シスの人員が数名規模にとどまり、本業のインフラ運用と並行して大規模開発を担うのは現実的ではありません。そのため、専門知見とリソースを持つ外部の開発会社へ発注・委託する選択が一般的になっています。
外注のメリットは、最新の技術トレンドや他社の導入ノウハウを取り込めること、そして開発リソースを変動費として扱えることにあります。一方で、業務の独自性をベンダーへ正確に伝えられないと、現場の運用に合わないシステムが納品されるリスクが残ります。外注はあくまで「自社が主体となって専門家の力を借りる」ものであり、丸投げではないという前提を、発注前に社内で共有しておくことが重要です。
「発注・外注・依頼・委託」の違いと契約形態の整理
「発注」「外注」「依頼」「委託」は日常的に同じ意味で使われがちですが、契約の観点では整理しておくと交渉がスムーズになります。発注は注文を出す行為そのもの、外注は社外のリソースに作業を出すこと、委託は業務の遂行を任せることを指します。システム開発の現場では、これらが最終的に「請負契約」または「準委任契約」のいずれかの法的な形態に落とし込まれます。
請負契約は「完成した成果物」に対して責任と対価が発生する形態で、要件が固まった開発フェーズに向いています。準委任契約は「業務の遂行」に対して対価が発生する形態で、要件定義やコンサルティングなど成果物を明確に定義しにくいフェーズに適しています。TMSのリニューアルでは、上流の要件整理を準委任で進め、開発を請負で発注するといった組み合わせが現実的です。この区別を理解しておくと、トラブル時の責任範囲をめぐる認識のズレを未然に防げます。
TMSリニューアルの発注先となる4タイプと選び方

TMSのリニューアルを発注できる相手は、大きく4つのタイプに分かれます。それぞれ得意領域とコスト構造が異なり、自社の規模や業務の独自性に合わない発注先を選ぶと、後から大幅なカスタマイズ費用が発生します。ここでは発注先の4タイプの特徴と、自社に合う相手の見極め方を解説します。
SaaSベンダー・パッケージベンダー・SIer・専門開発会社の特徴
発注先の第一の選択肢はSaaS型TMSベンダーです。月額数万円から利用でき、初期投資を抑えてスピーディに導入できる反面、自社独自の運賃ルールや帳票には標準機能で対応しきれない場合があります。第二はパッケージベンダーで、業界標準の機能をベースにある程度のカスタマイズが可能ですが、改修費が積み上がると数百万から数千万円規模になります。
第三は大手SIerで、大規模な基幹連携やグループ全体のシステム統合に強い一方、小回りが利きにくく費用も高額になりがちです。第四はフルスクラッチ対応の専門開発会社で、独自業務を細かく作り込める反面、開発費は数千万円から億円規模に達することもあります。自社の課題が「標準機能で足りるのか」「独自業務をどこまで残すのか」によって、最適な発注先は大きく変わります。
拠点数・業務独自性で見る発注先の判断基準
発注先を選ぶ際の実務的な判断基準として、拠点数と業務の独自性が有効な物差しになります。営業所が1〜2拠点で、運賃計算や配車ルールが比較的標準的な場合は、SaaS型やパッケージで十分に対応できるケースが多くなります。導入のスピードとコストを重視するなら、まずは標準的なサービスから検討するのが合理的です。
一方で、3拠点以上を抱え、取引先ごとに異なるEDIや伝票フォーマットを運用している場合や、古い基幹システムがAPI連携に対応していない場合は、標準パッケージでは無理が生じます。これらの条件が複数該当するなら、カスタマイズ前提のパッケージや専門開発会社への発注を視野に入れるべきです。発注先のミスマッチは、後から「結局フルスクラッチ並みの追加費用がかかった」という事態を招くため、初期段階での見極めが肝心です。
SaaSの限界点とスクラッチへの分岐点
多くの比較記事は「おすすめSaaS」を列挙して終わりますが、発注の現場で本当に重要なのは「SaaSでは対応できなくなる分岐点」を見極めることです。冷蔵・冷凍などの特殊車両割増、深夜早朝休日割増、距離逓減制といった多階層の運賃ルールを抱えている場合、SaaSの標準マスタでは表現しきれないことがあります。こうした独自性が強いほど、カスタマイズ可能な発注先を選ぶべきです。
判断の目安としては、「複数拠点」「API非対応の古い基幹との連携」「取引先ごとに異なるEDI・伝票フォーマット」のうち複数が該当する場合、SaaSの標準機能だけでは現場が回らない可能性が高まります。この分岐点を発注前に自社で整理しておけば、ベンダーからの提案を鵜呑みにせず、自社に必要な作り込みの範囲を主体的に判断できます。安価なSaaSに飛びついた結果、現場で二重入力が残るという失敗は、この見極めで防げます。
発注前に準備すべきドキュメントと社内体制

発注の成否は、問い合わせる前の準備で8割が決まると言っても過言ではありません。要件が曖昧なまま複数社に声をかけると、各社の見積もり前提がバラバラになり、比較しても意味のある判断ができなくなります。ここでは発注前にそろえておくべきドキュメントと、社内の推進体制について解説します。
RFP(提案依頼書)と要件定義(MUST/WANT)の整理
発注前に最も重要なドキュメントがRFP(提案依頼書)です。現行システムの課題、リニューアルで実現したいこと、連携が必要な周辺システム、予算感、希望スケジュールを文書化し、各社へ同じ条件で提示します。RFPがあれば、ベンダーは前提をそろえて提案でき、発注側は同じ土俵で各社を比較できるようになります。
要件を整理する際は、「絶対に必要なMUST要件」と「あれば望ましいWANT要件」を切り分けることが効果的です。例えば「2024年問題に対応した拘束時間の事前警告」はMUST、「AIによる動的ルート最適化」はWANTといった具合に優先順位を付けると、予算超過時にどこを削るかの判断がしやすくなります。MUSTとWANTの切り分けは、ベンダーに丸投げせず発注側が主導することで、後の仕様変更による費用膨張を抑えられます。
現場を巻き込むPJチーム編成
発注を成功させるには、情シス担当だけでなく、実際にシステムを使う配車担当やドライバーをプロジェクトチームに巻き込むことが欠かせません。配車のノウハウは現場に蓄積されており、その知見をRFPや要件に反映しないと、机上の理想だけが先行したシステムが出来上がります。発注前の段階から現場のキーパーソンを巻き込むことで、要件の精度が上がり、導入後の定着もスムーズになります。
チーム編成では、経営層の意思決定者、情シスの取りまとめ役、現場代表の配車担当を最低限そろえることをおすすめします。発注の意思決定権が誰にあるのかをベンダーに明示しておくと、提案や交渉のスピードが上がります。現場を置き去りにした発注は、稼働後の「使われないシステム」という最悪の結果を招くため、体制づくりは発注準備の要となります。
外注先の選定プロセスと見極めのポイント

RFPがそろったら、いよいよ外注先の選定に入ります。ここでありがちな失敗が、提示された本体価格だけで発注先を決めてしまうことです。TMSの発注では、本体価格に表れない連携費用やカスタマイズ費用が後から積み上がるため、見積もりの内訳まで踏み込んで比較する必要があります。ここでは選定プロセスと見極めのポイントを解説します。
複数社からの相見積もりと比較方法
外注先は、最低でも3社程度から相見積もりを取ることをおすすめします。1社だけの見積もりでは、提示金額が相場として適正なのか判断できず、交渉の余地もなくなります。同じRFPをもとに各社へ提案を依頼すれば、機能の網羅性、費用、スケジュール、サポート体制を横並びで比較できます。
比較する際は、総額だけでなく「何にいくらかかっているのか」という内訳に注目してください。要件定義、設計、開発、テスト、データ移行、連携開発、保守といった項目ごとの金額を並べると、各社の見積もりの考え方や、安く見える提案の裏に隠れた前提が見えてきます。極端に安い見積もりは、必要な工程が含まれていない可能性があるため、内訳の確認が欠かせません。
実績・技術力・緊急サポート体制の確認
発注先の見極めでは、物流・運送業界での開発実績があるかを必ず確認します。配車最適化や動態管理、運賃計算といったTMS特有の領域は、業界知識がないベンダーには要件の意図が伝わりにくく、開発が遠回りになります。過去のプロジェクト事例や、類似業種での導入実績をヒアリングし、自社の課題を理解できる相手かを見極めてください。
見落とされがちですが、緊急時のサポート体制の確認も極めて重要です。配車システムが稼働初日に連携障害で止まれば、配車が停止し大規模な配送遅延につながります。土日・夜間のオンコール対応の有無、障害発生時のエスカレーションルート、復旧までの目標時間を発注前に書面で確認しておきましょう。「動いて当たり前」の業務だからこそ、止まったときに誰がどう動くのかを取り決めておくことが、発注後の安心につながります。
連携・カスタマイズ費用の「隠れコスト」を見抜く
TMSの発注で最も注意すべきが、本体価格に隠れた連携・カスタマイズ費用です。基幹システムとの連携には100万円から500万円、バーコードやハンディ端末との連携には50万円から500万円程度がかかることが珍しくありません。「本体500万円だが連携で1,000万円」という構造は実際に頻発しており、本体価格だけで判断すると予算が大きく狂います。
さらに、独自の伝票フォーマットや複雑な運賃ルールを無理にシステム化しようとすると、カスタマイズ費用がフルスクラッチ相当の数千万円規模に跳ね上がることもあります。運用面でも、デジタル地図基盤のライセンス費、AIモデルの定期再学習工数、並行運用期間中の入力サポート要員の人件費など、見積書の表面に出てこないコストが存在します。発注前にこれらの「隠れコスト」をベンダーへ明示的に質問し、TCO(総保有コスト)の視点で各社を比較することが、想定外の出費を防ぐ鍵になります。
契約形態と発注時の注意点

発注先が決まったら、契約形態を適切に選ぶことで、発注後のトラブルやコスト膨張のリスクを大きく減らせます。TMSのリニューアルは要件が固まりにくく、開発の途中で仕様が変わることも多いため、契約の組み立て方が重要になります。ここでは契約形態の使い分けと、発注時に気をつけたい点を解説します。
請負契約と準委任契約の使い分け
請負契約は成果物の完成に責任を持つ契約で、仕様が明確に固まった開発フェーズに適しています。発注側は完成品に対して対価を支払うため、品質に対する保証を得やすい一方、要件が曖昧なまま請負で契約すると、追加要望のたびに高額な仕様変更費が発生します。要件が定まっていない段階で請負契約を急ぐのは、発注側にとってリスクが高い選択です。
準委任契約は業務の遂行に対して対価が発生する契約で、要件定義やコンサルティング、アジャイル的な開発に向いています。TMSのリニューアルでは、上流の要件整理やPoC(概念実証)を準委任で柔軟に進め、仕様が固まった段階で開発を請負へ移行する組み合わせが現実的です。フェーズごとに最適な契約形態を選ぶことで、発注側の柔軟性とコストコントロールを両立できます。
スモールスタート・段階開発で発注リスクを抑える
いきなり数千万円規模の全社一括導入を発注するのは、発注側にとって大きな賭けになります。要件が固まりきらないまま大規模発注に踏み切ると、現場に合わないシステムが完成したときの損失が甚大です。これを避ける現実的なアプローチが、1拠点・数台の車両から小さく始めるスモールスタートです。
特定の営業所やルートでパイロット導入を行い、現場の反応や運用ノウハウを蓄積してから全体展開する段階開発であれば、発注リスクを最小限に抑えられます。「小さく試してダメならやめる」「うまくいった部分から横展開する」という発注スタイルは、要件が固まる前から相談に乗ってくれるパートナーと組むことで実現します。発注先を選ぶ際は、こうした段階的な拡張に柔軟に対応できる体制があるかも確認しておくとよいでしょう。
外注を成功させるための発注後のマネジメント

発注はゴールではなく、プロジェクトのスタートです。契約を結んだ後にベンダー任せにしてしまうと、進捗の遅れや認識のズレが後から表面化し、手戻りや追加費用を招きます。ここでは外注したプロジェクトを成功に導くための、発注後のマネジメントについて解説します。
ベンダー任せにしない進捗・品質管理
外注したからといって、発注側がプロジェクトから手を引いてよいわけではありません。定期的な進捗会議を設け、開発の各フェーズで成果物を確認し、要件とのズレがないかをこまめにチェックすることが重要です。とくにデータ移行は失敗が起きやすい工程であり、Excelや紙でバラバラに管理されてきた顧客マスタや運賃ルールを、誰がどう整理して移行するのかを発注側も主体的に関与して決める必要があります。
移行リハーサルやトライアルを本番前に実施し、想定外のトラブルを事前に潰しておくことも欠かせません。発注側が品質管理に関与することで、ベンダーとの認識のズレを早期に発見でき、納品後の大きな手戻りを防げます。外注は「任せる」ことと「丸投げする」ことの違いを意識し、発注側が主体的にプロジェクトを動かす姿勢が成功の前提となります。
現場定着を見据えたチェンジマネジメント
どれだけ優れたシステムを発注しても、現場が使わなければ投資は無駄になります。配車マンには「AIに配車を任せたら無理な配車やイレギュラーに対応できないのでは」という不安があり、ドライバーには「GPSで監視されるだけではないか」という抵抗感があります。こうした反発のメカニズムに正面から向き合い、発注段階から定着支援を見据えておくことが重要です。
具体的には、ITリテラシーに配慮した操作しやすいUI/UXを要件に盛り込み、十分な教育期間を設けることが効果的です。パイロット導入で小さな成功体験を積み重ね、「楽になった」という実感を現場に広げていくことで、システムは自然と定着していきます。発注先を選ぶ際には、開発して終わりではなく、稼働後の定着支援まで伴走してくれるパートナーかどうかを見極めることが、長期的な投資効果を左右します。
まとめ

TMSのリニューアルを発注・外注・委託する際は、発注先の4タイプの特徴を理解し、自社の拠点数や業務独自性に合った相手を選ぶことが出発点になります。発注前にRFPと要件(MUST/WANT)を整理し、現場を巻き込んだ推進体制を整えておけば、複数社の相見積もりを同じ土俵で比較できます。本体価格に隠れた連携・カスタマイズ費用、地図ライセンスやAI再学習などの運用コストまで含めたTCOの視点で判断することが、想定外の出費を防ぐ鍵です。
契約面では請負と準委任をフェーズごとに使い分け、スモールスタートと段階開発で発注リスクを抑えることが現実的な進め方です。そして発注後もベンダー任せにせず、進捗・品質管理と現場定着のためのチェンジマネジメントに主体的に関与することで、投資を成果につなげられます。発注は丸投げではなく、専門家の力を借りながら自社が主導する取り組みであるという前提を持って臨めば、TMSのリニューアルは現場が本当に使える仕組みへと結実するはずです。
▼全体ガイドの記事
・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を創業。
