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