TMSリプレイスは、3つの選択肢から方向性を選び、7つの評価軸で候補を比べて決めます。
機能数や知名度だけで選ぶと、稼働後に標準機能とのずれが表面化するため、まず輸送形態と現行システムの限界を整理します。課題の整理から候補の比較、RFI・RFP、PoCまでを順に解説します。
▼全体ガイドの記事
・TMSリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
TMSリプレイス選定前に整理すべき自社の課題
候補製品を探す前に、現行TMSのどこに限界があるかを特定します。配車計画、実車動態管理、実績集計、他システム連携を確認し、課題を一文で説明できる状態にまで整理すると、必要な製品タイプが見えてきます。
スクラッチ開発の属人化と改修コスト増
自社開発のTMSでは、開発担当者の異動・退職の影響や、仕様書と実際のコードのずれを確認します。保守費が初期開発費の年10〜20%を超える場合や、法改正のたびに費用を見通せない場合は、属人化や改修負担を疑う材料になります。
既存パッケージ・SaaSの機能不足とコスト増の切り分け
利用中のパッケージやSaaSへの不満は、機能と料金に分けて考えます。配車の柔軟性やリアルタイム連携の不足と、車両台数に応じた従量課金では、選ぶべき製品が異なるためです。
カスタマイズ費用が本体価格の50%を超える場合は、次の候補を比べる際に、標準機能との適合度を慎重に確認します。同じ保守負担を繰り返さないための比較軸になります。
選定前の課題整理に含める現場の反発リスク
導入を主導する部門と、日々の配車を担う現場とでは、見ている点が異なります。画面や手順の変更への懸念を後回しにすると、稼働後に手作業が残ったり、旧システムへ戻ったりするおそれがあります。
選定の初期から、現場の不便さと変更への不安を分けて聞き取っておきます。そうすれば、製品比較と並行して運用面の課題も把握できます。
TMSリプレイス先となる3つの選択肢
選択肢は、スクラッチ改修の継続、パッケージ・SaaSへの移行、コア機能を自社開発するハイブリッドの3つです。選ぶときは、製品名よりも、優先する業務をどの形態が担えるかで判断します。
まず、各案の向き不向きは次のように整理できます。
- スクラッチ改修：独自の輸送業務や連携を維持したい場合の候補です。
- パッケージ・SaaS：標準的な業務や法改正対応をベンダーに任せたい場合に向きます。
- ハイブリッド：競争力の核は個別開発し、周辺機能は既存サービスと連携する構成です。
スクラッチ改修継続型
独自の輸送形態や商習慣に合わせた開発が必要なら、改修継続が候補になります。6つの複雑要件のうち3つ以上に当てはまる場合も、改修継続との適合性を検討します。
ただし、再度数千万円規模の初期投資を確保できるかも、判断の材料になります。独自要件だけでなく、継続的な開発体制も確認します。
パッケージ・SaaS乗り換え型とハイブリッド型
標準的な配車や法改正対応を任せたい場合は、パッケージ・SaaSが候補になります。また、周辺機能は既存サービスに任せ、配車や積載の中核だけを個別開発する構成も選べます。
いずれの型でも、標準化する業務と独自業務の境界は先に決めておきます。ハイブリッド型では、さらにAPI連携と責任分担の設計も必要になります。
パッケージ・SaaSは、利用開始の早さが利点です。一方で、ハイブリッド型は連携設計の工数を見込んだうえで、自社の開発体制で運用できるかを確認する必要があります。
製品選定で比較すべき7つの評価軸
製品は7つの評価軸で横並びに比較します。各社に同じ質問をし、回答とデモの条件をそろえておくと、説明の印象に左右されにくくなります。
輸送形態への適合性・配車の柔軟性・連携性
車両構成や配送エリア、荷主ごとの制約に、配車ロジックが対応できるかを確認します。加えて、急な欠車や条件変更のときに計画を組み直せるか、労働時間管理と連動するかも評価します。
基幹・倉庫管理システムとのAPIやEDI連携では、対象データ、同期の方向、エラー時の復旧方法を確認します。連携があるかどうかだけでなく、障害時の運用まで比べます。
リアルタイムの見える化・UI適性・サポート・料金体系
車両の動きと配送の進捗をリアルタイムで見られるか、荷主と共有できるかを調べます。配車担当者や乗務員が使いやすい画面かどうかは、デモで実際に操作して確かめます。
サポートの対応時間と、障害時の連絡経路も比較します。料金は、車両台数課金かID課金かに加えて、デバイスや地図APIの費用も含めて見積もります。3〜5年の総保有コストで比べると、初期料金だけでは見えない費用が分かります。
採点基準だけでなく、確認の方法も各社でそろえます。「配車計画に対応」という回答では、標準機能か追加開発かが分からないためです。デモ、仕様書、契約条項などの根拠を記録し、未確認の項目は保留にすると、後から回答の解釈が変わるのを防げます。
ビルド・バイ判断の定量的な基準
ビルドを続けるか、バイへ移行するかは、定量基準を併用して判断します。「50%ルール」と「3の基準」を共通の物差しにすると、見積もりや要件を候補ごとに同じ条件で比べられます。
「50%ルール」によるカスタマイズ費用の割合
カスタマイズ費用がパッケージ本体価格の50%を超える場合は、標準機能との適合度を見直します。導入後も改修の保守負担が残るため、TCOの削減効果が小さくなる可能性があります。
この水準は、スクラッチ改修の継続やハイブリッド構成を再検討する目安になります。見積もりは、内訳を分けて比べます。
「3の基準」による複雑要件の該当数
複雑要件は6項目あり、前半の3つは、3拠点以上、業務の属人化、複数チャネルのECです。後半の3つは、レガシー基幹連携、取引先別EDI、自動倉庫連携です。
6項目のうち3つ以上に当てはまるなら、スクラッチ改修の継続を検討します。該当が2つ以下なら、パッケージ・SaaSで投資回収期間を1.5〜4年程度に収めやすくなります。ただし、TCOは5〜10年で見て、従量課金による逆転も確認します。
RFI・RFP・比較評価の進め方
比較評価は段階ごとに候補を絞り込んでいきます。全体の期間は3〜4か月程度が目安です。
RFIによる10社前後からの絞り込み
RFI（情報提供依頼）は、発行から回収まで1〜2週間ほどかけ、10社前後を3〜5社へ絞り込みます。その際は、対応する輸送形態、車両規模、既存システムとの連携実績など、必須要件を確認します。導入実績の業種や車両規模を書面で求めておくと、営業説明だけでは分からない適合度を比べやすくなります。
RFP作成から比較評価までの流れと期間
RFP（提案依頼）には、対象拠点、車両台数、配送エリアを記載します。加えて、連携要件と解決したい課題も書き込みます。作成には、現場への聞き取りを含めて1〜3か月ほどかけます。
提案と見積の受領に2〜3週間、デモやPoCを含む評価に1〜2か月かけ、候補を2〜3社へ絞ります。要件は、「必須」「望ましい」「将来」に分けて整理します。
候補製品の概要はTMSリプレイスのパッケージ・クラウド製品一覧で確認できます。
PoC・Fit&Gap検証の確認項目
資料だけでは、実運用への適合性は判断できません。そのため、テスト環境で実測し、Fit&Gap検証を経て候補を1〜2社へ絞り込みます。
デモでは、自社の契約形態や例外処理を実際に使い、管理者と現場の双方が操作します。説明を聞くだけでは把握しにくい運用の負荷も、ここで確認できます。
Fit to Standardの徹底と過度なカスタマイズの回避
Fit&Gap検証には2〜8週間ほどかけ、標準機能で対応できる業務と、追加開発や連携が必要な業務を分けて整理します。
そのうえで、標準機能に業務を合わせる「Fit to Standard」を基本にすると、過度なカスタマイズによる保守費や改修リスクを抑えやすくなります。
現場の配車担当者を巻き込んだ実測PoC
PoCは2〜4週間のスプリントで行います。テストする内容は、実データのサンプル移行、月末締め処理などのピーク負荷、外部システム連携です。
経営層と情報システム部門だけでなく、配車担当者にもUI・UXを評価してもらいます。特に、日々の業務で使えるかどうかは、現場で実際に確かめます。
PoC前後の実測値の比較と稟議の根拠
PoCの前に、配車計画の作成時間、連携先への手入力回数、問い合わせ件数を記録しておきます。検証後の値と比べれば、変化を具体的に評価できます。
ベンダーの一般値は、そのまま使わず、自社の車両台数や案件規模に置き換えて効果を算出します。さらに、SaaSを導入しても残るアカウント管理や仕様変更の工数を差し引いて、投資を判断します。
TMSリプレイス選定で失敗を防ぐための確認ポイント
候補を絞った後は、料金、データ移行、契約終了時の備えを確認します。導入後に運用が止まるのを避けるため、移行と継続利用の条件も選定に含めます。
料金以上に選定へ影響するデータ移行の難しさ
車両・乗務員マスタや実績データの整理には、数か月単位の工数がかかることがあります。そのため、移行支援の範囲に加えて、試験移行や並行運用への支援内容を契約前に確かめます。
次のロックインを避けるための契約条件
データの持ち出しやAPI仕様、契約終了時の返却条件に加えて、SLAも文書で確認します。口頭の説明だけで済ませず、重要な条件は書面やメールに残しておきます。
車両台数に応じた課金と連携の追加費用が重なると、数年後にTCOが逆転することがあります。そのため、長期の料金シミュレーションで確認しておきます。
車両台数が少ない場合の評価軸
車両台数が少なくても、輸送への適合性、連携、サポートは確認します。特に、少人数の体制では、問い合わせ対応や初期設定の分かりやすさが定着に影響します。
7つの評価軸から優先する項目を先に決めておくと、候補どうしの比較基準がぶれにくくなります。
ハイブリッド構成の判断と責任分界
配車アルゴリズムなどを自社開発し、周辺業務をSaaSに任せる場合は、正とするデータの所在を決めておきます。連携エラーが起きた際の復旧担当も、事前に定めます。
どこまでを誰が受け持つかが曖昧だと、障害対応が遅れ、問い合わせが自社開発側へ集中するおそれがあります。
まとめ
TMSリプレイスは、まず現行システムの課題を特定し、改修継続、パッケージ・SaaS、ハイブリッドから方向性を選びます。次に、7つの評価軸と定量基準で候補を比べます。
RFI・RFPの後は、Fit&Gapと現場が参加するPoCを行い、資料だけでは分からない負荷を調べます。特に、標準機能に合わない業務を無理に合わせると、二重入力が残る可能性があります。
必須要件で候補を絞る段階と、実測で運用を確かめる段階は、分けて進めます。riplaは、要件整理やSaaSと基幹システムの連携、独自業務の個別開発を支援しています。
▼全体ガイドの記事
・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を創業。