TMSのリニューアルは、外注する理由と任せる範囲を社内で整理し、発注先のタイプを比べて候補を絞るところから始まります。RFPで要件をそろえて相見積もりを取り、契約形態を決めたうえで段階的に導入し、発注後も発注側が進捗と品質を管理します。
▼全体ガイドの記事
・TMSのリニューアルの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TMSのリニューアルを外注する前に押さえるべき全体像
配車や物流管理は担当者の経験に頼りやすく、目的が曖昧なままだと、現場で使われないシステムになりかねません。そのため、開発会社へ問い合わせる前に、外注する理由と任せる範囲を社内で整理しておきます。
自社開発に比べて外注・委託が選ばれる理由
自社の情シス部門だけで開発を進めると、配車最適化アルゴリズムや動態管理で行き詰まりがちです。デジタル地図基盤との連携にも専門知識が必要です。
運送業や物流業では、情シスの人員が数名規模にとどまることもあるため、本業のインフラ運用と大規模開発を並行するのは現実的ではありません。
- 専門知見：外部の開発会社が持つ技術と、他社への導入ノウハウを借りられます。
- 人員調整：開発に必要な人手を、変動費として扱えます。
ただし、業務の独自性が開発会社に正しく伝わらなければ、現場に合わないシステムが納品される恐れがあります。外注は、自社が主体となって専門家の力を借りる進め方だといえます。
「発注・外注・依頼・委託」の違いと契約形態の整理
発注は注文を出すこと、外注は社外に作業を出すこと、委託は業務の遂行を任せることを指します。日常の会話では、依頼もこれらと近い意味で使われます。
- 請負契約：完成した仕事に対して、責任と対価が伴います。
- 準委任契約：業務の遂行そのものに対して、対価が支払われます。
請負は要件が固まった開発に、準委任は要件定義やコンサルティングに向いています。たとえば、上流工程は準委任で進め、開発は請負にする組み合わせも現実的です。
契約形態を整理しておくと、トラブルが起きたときの責任範囲について、認識のずれを防ぎやすくなります。
TMSリニューアルの発注先となる4タイプと選び方
TMSの発注先は4タイプに分かれ、得意な領域とコストの構造がそれぞれ異なります。自社の規模や業務に合わない相手を選ぶと、後からカスタマイズ費用が膨らんでしまいます。
SaaSベンダー・パッケージベンダー・SIer・専門開発会社の特徴
費用と対応範囲を発注先ごとに比べれば、標準機能で足りるか、独自業務を作り込む必要があるかを判断できます。
- SaaS：月額数万円から使え、初期投資を抑えて導入できます。ただし、独自の運賃や帳票は、標準機能で対応できない場合があります。
- パッケージ：業界標準の機能を基に、カスタマイズできます。改修費は数百万から数千万円規模に上ります。
- 大手SIer：大規模な基幹連携やグループ全体のシステム統合に強い反面、小回りが利きにくく、費用も高額になりがちです。
- 専門開発会社：独自業務への対応を得意とし、フルスクラッチの場合は数千万円から億円規模になることもあります。
どの発注先が合うかは、標準機能で足りる業務が多いか、独自業務を残すかで決まります。
拠点数・業務独自性で見る発注先の判断基準
拠点数と業務の独自性を基準にすると、発注先の候補を絞り込めます。たとえば、営業所が1〜2拠点で業務も標準的であれば、SaaSやパッケージで足りる場合が多くあります。
- 標準業務：導入の速さと費用を重視するなら、まず標準サービスを候補にします。
- 独自業務：複数拠点や個別の連携がある場合は、カスタマイズできる発注先も候補に入ります。
3拠点以上を抱え、取引先ごとに異なるEDIや伝票を使う場合は、標準パッケージでは無理が生じます。また、古い基幹システムがAPI連携に対応していない場合は、標準パッケージでは対応が難しくなります。
これらの条件が複数当てはまるなら、カスタマイズ前提のパッケージや専門開発会社が候補になります。発注先を取り違えると、追加費用がフルスクラッチ並みになりかねないため、初期段階での見極めが欠かせません。
SaaSの限界点とスクラッチへの分岐点
SaaSの標準機能で足りるかを確かめるには、まず自社固有の運賃ルールや連携条件を洗い出します。
- 特殊な運賃：冷蔵・冷凍車、深夜早朝休日、距離逓減制の割増などが挙げられます。
- 複数の制約：複数拠点、古い基幹との連携、個別EDIや伝票の扱いを確かめます。
多階層の運賃ルールは、SaaSの標準マスタで表現しきれないことがあります。独自性が強い場合は、カスタマイズできる発注先を候補に入れます。
複数の制約が重なると、標準機能のままでは現場が回らない可能性が高まります。事前に範囲を整理しておけば、必要な作り込みを自社で判断できます。
安価なSaaSを選んでも、現場で二重入力が残ったままでは課題は解消しません。したがって、スクラッチへの分岐点は発注前に見極めておく必要があります。
発注前に準備すべきドキュメントと社内体制
発注の成否は、問い合わせ前の準備で8割が決まると言っても過言ではありません。実際、要件が曖昧なまま複数社へ依頼すると、見積もりの前提がそろわず比較できません。
RFP（提案依頼書）と要件定義（MUST/WANT）の整理
RFP（提案依頼書）は、同じ条件を各社へ示すための文書です。そこには、現行システムの課題と実現したいことに加え、周辺連携、予算感、希望日程も盛り込みます。
RFPで前提をそろえておけば、各社は同じ前提で提案でき、発注側も同じ条件で比べられます。
- MUST要件：導入に欠かせない条件を決めます。
- WANT要件：あれば望ましい条件を、MUSTと分けて整理します。
たとえば、2024年問題に対応する拘束時間の事前警告はMUST、AIによる動的ルート最適化はWANTに分けられます。優先順位が決まっていれば、予算を超えそうなときに、どこを削るかを判断できます。
要件の優先順位は、発注側が主導して決めます。ベンダー任せにしないことが、仕様変更による費用の膨張を抑えることにつながります。
現場を巻き込むPJチーム編成
情シスだけでなく、配車担当やドライバーもチームに加えます。配車の知見をRFPや要件に反映させないと、机上の理想ばかりが先行しかねません。
- 経営層：プロジェクトの意思決定を担います。
- 情シス：全体を取りまとめる役です。
- 配車担当：現場の代表として、業務の知見を伝えます。
最低限、経営層の意思決定者、情シスの取りまとめ役、配車担当の三者はそろえておくことをおすすめします。
発注前の段階から現場のキーパーソンを加えておくと、要件の精度が上がり、導入後の定着もスムーズに進みます。意思決定権が誰にあるのかをベンダーに伝えておくと、提案や交渉で話が前に進みます。
現場を置き去りにすると、稼働後に使われないシステムになる恐れがあります。体制づくりは、発注準備の中心に置くべき作業です。
外注先の選定プロセスと見極めのポイント
RFPがそろったら、外注先の選定に進みます。本体価格だけで決めると、連携費用やカスタマイズ費用が後から積み上がります。そこで、見積もりは内訳まで比べます。
複数社からの相見積もりと比較方法
外注先は、最低でも3社程度から相見積もりを取ることをおすすめします。1社だけでは金額の妥当性を判断しにくく、交渉の余地も限られるためです。
- 提案内容：機能がどこまで網羅されているか、スケジュールが現実的かを見ます。
- 費用内訳：工程ごとの金額と、サポート体制の内容を比べます。
RFPを各社に提示すれば、機能や費用、日程を横並びで比べられます。支援体制についても、同じ条件で見比べられます。総額だけでなく、何にいくらかかるかまで確認しておきます。
見積もりを要件定義から保守までの工程ごとに並べ、設計、開発、テスト、データ移行、連携開発をそれぞれ示してもらうと、各社の前提が見えてきます。特に、極端に安い見積もりは工程が抜けている可能性があります。
実績・技術力・緊急サポート体制の確認
物流・運送業界での開発実績を確かめます。配車最適化や動態管理、運賃計算には業界の知識が欠かせず、知見がなければ要件の意図が伝わりにくくなります。
- 導入実績：類似業種の事例をもとに、課題をどれだけ理解しているかを見ます。
- 緊急対応：休日や夜間に連絡できる体制かを確かめます。
配車システムが稼働初日に連携障害で止まれば、配車が停止し、大規模な配送遅延につながります。
そのため、土日や夜間のオンコール対応の有無と、障害時のエスカレーションルートを確かめておきます。
復旧までの目標時間も含めて、発注前に書面で取り決めておく必要があります。障害が起きたときに誰がどう動くかを決めておくことが、発注後の安心につながります。
連携・カスタマイズ費用に潜む「隠れコスト」
本体価格とは別にかかる連携・カスタマイズ費用には、注意が必要です。基幹システムとの連携には100万円から500万円かかることが珍しくありません。バーコードやハンディ端末との連携にも、50万円から500万円程度かかることがあります。
- 連携費：基幹、バーコード、ハンディ端末との接続を見ます。
- 運用費：ライセンス、再学習、人員にかかる費用が対象です。
「本体500万円だが、連携で1,000万円」という構造は、実際に頻発しています。本体価格だけで判断すると、予算が大きく狂うおそれがあります。
独自の伝票フォーマットや複雑な運賃ルールを無理にシステム化しようとすると、カスタマイズ費用が数千万円規模まで跳ね上がることもあります。
運用面にも、見積書の表面には出てこないコストがあります。たとえば、デジタル地図基盤のライセンス費や、AIモデルの定期再学習にかかる工数です。並行運用期間中に入力を支える要員の人件費も、こうした隠れたコストに含まれます。
これらを発注前にベンダーへ質問し、TCO（総保有コスト）で各社を比べれば、想定外の出費を防げます。
契約形態と発注時の注意点
契約形態を適切に選べば、発注後のトラブルや費用の増加を抑えられます。TMSは要件が固まりにくく、開発の途中で仕様が変わることもあります。
請負契約と準委任契約の使い分け
契約を選ぶときは、完成した成果を求めるのか、業務の遂行を依頼するのかを基準にします。
- 請負：仕様が明確な開発に適し、完成品の品質を保証してもらいやすい契約です。
- 準委任：要件定義やコンサルティング、アジャイル開発に向きます。
要件が曖昧なまま請負にすると、追加の要望が出るたびに高額な変更費が生じます。そのため、要件が定まる前に請負を急ぐのは、リスクを伴います。
TMSでは、要件整理やPoC（概念実証）を準委任で進め、仕様が確定した後に開発を請負へ移す方法が現実的です。こうすれば、柔軟性と費用管理を両立できます。
スモールスタート・段階開発による発注リスクの抑制
要件が固まらないまま数千万円規模の全社導入を発注すると、現場に合わなかったときの損失が大きくなります。
- 小さく開始：1拠点、数台の車両といった小さな範囲から試します。
- 段階展開：パイロットの後に現場の反応を見て、全体へ広げていきます。
特定の営業所やルートで試せば、運用の知見を得てから展開を判断できます。合わなければ中止する判断もでき、うまくいった部分から広げられます。
要件が固まる前から相談に乗ってくれる相手であれば、段階的な拡張を進めやすくなります。そのうえで、発注先の体制も確かめておきます。
外注を成功させるための発注後のマネジメント
発注の後こそ、プロジェクトが本格的に動き出す段階です。契約後にベンダー任せにすると、進捗の遅れや認識のずれが表面化し、手戻りや追加費用を招きかねません。そのため、発注側も管理に関わります。
ベンダー任せにしない進捗・品質管理
定期的に進捗会議を開き、各フェーズで仕上がったものを一つずつ確かめます。要件とのずれは、こまめに見つけることが肝心です。
- 移行準備：顧客マスタや運賃ルールを整理する担当者を決めます。
- 事前確認：本番の前に、移行のリハーサルやトライアルを行います。
顧客マスタや運賃ルールがExcelや紙で管理されている場合は、移行の方法も発注側が決めておきます。データ移行は失敗が起きやすい工程です。
発注側が品質管理に関われば、認識違いを早く見つけられ、納品後の手戻りも防げます。とはいえ、任せることと丸投げは違います。
現場定着を見据えたチェンジマネジメント
現場で使われなければ、どれほど優れたシステムでも投資が無駄になります。特に、配車担当にはAIへの不安があり、ドライバーにはGPS監視への抵抗感があります。
- 使いやすさ：ITリテラシーに配慮したUI/UXを、要件として盛り込みます。
- 教育と試行：教育期間を設けたうえで、パイロットで成功体験を積みます。
配車担当なら無理な配車や例外への対応を、ドライバーならGPSによる監視を、それぞれ心配しがちです。そのため、発注の段階から定着支援も考えておきます。
現場で「楽になった」という実感が広がれば、システムは根づいていきます。稼働後も支えてくれるパートナーかどうかが、長期的な効果を左右します。
まとめ
TMSの発注では、4タイプの特徴を踏まえて、拠点数や業務の独自性に合う相手を選びます。RFPとMUST/WANT要件を整え、現場も含めた体制を作っておけば、相見積もりを比べやすくなります。
判断にはTCOを使い、連携やカスタマイズに加え、地図ライセンスやAI再学習も含めて比べます。契約形態は工程ごとに使い分け、段階的な導入と発注後の管理を続けることで、現場で使える仕組みに近づけます。
▼全体ガイドの記事
・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を創業。