TMSのリニューアル先は、見た目の新しさではなく、ドライバーアプリ、配車ダッシュボード、荷主ポータルのどこに課題が集中しているかで選びます。課題の範囲に合わせて、フルスクラッチ、ヘッドレス・BFF、パッケージ更新を比べます。
課題の整理から選び分け、RFPとPoCの進め方までを順に見ていきます。
▼全体ガイドの記事
・TMSのリニューアルの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TMSのリニューアル選定前に整理すべき自社の課題
リニューアル先を選ぶ前に、自社のどの利用者が何に困っているかを整理しておきます。提案会社の実績から入ると、自社の課題に合わない提案を選んでしまうおそれがあるためです。
ドライバー、配車担当者、荷主では困りごとが違います。
そのため、利用者ごとの不満を分け、現状の画面を使う部門、頻度、時間のかかる操作を記録しておきます。こうして並べると、提案を同じ条件で比べられます。
ドライバー向けアプリの操作性課題
アプリの利用率が低い層や、紙の伝票へ戻る拠点があるなら、ドライバー向けUIに問題がないかを先に確認します。
手袋でのタップ、屋外や夜間の視認性、入力項目の多さを利用環境に沿って洗い出します。また、端末や車両による差も記録しておくと、提案ごとに同じ基準で比べられます。
配車ボード・ダッシュボードの視認性課題
ガントチャートと地図を何度も見比べる、ドラッグ&ドロップに時間がかかるといった状況は、情報設計の課題かもしれません。
そのため、機能が足りないのか、見づらいのかを分けて確認します。さらに、繁忙期の案件量を想定したデモや検証ができるかも見ておきます。
荷主ポータルとブランド体験の課題
配送状況の表示や問い合わせの多さを確認し、「見た目を新しくしたい」の段階から一歩進めて、不満の原因になっている操作や表示を言葉にします。
営業や顧客対応の指摘、スマートフォンでの確認頻度、複数拠点での利用も、要件に反映する対象です。
TMSのリニューアルにおける3つのアプローチ
主な選択肢は3つあり、配車ロジックからUIまで作り直す方法、既存の中核を残してUIを再構築する方法、パッケージの画面や機能を更新する方法です。
分類名だけで比べると違いが見えにくいため、再構築する範囲と既存部分の扱いをそろえて比べます。
フルスクラッチ型UI再構築
配車ロジックや帳票を含めて全面的に作り直すタイプで、独自の配車ルールや既存パッケージでは表現しにくい業務フローに向きます。一方で、要件定義から本番稼働までの期間と費用が大きくなりやすいため、段階的な計画が必要です。
ヘッドレス・BFF型部分刷新
配車エンジンやデータベースを残し、API経由でつなぐBFF層を挟んでUIを再構築します。中核への影響は抑えやすい一方、既存APIの整備状況で難易度が変わります。
APIがない場合は、接続のための基盤まで提案範囲に含めて確認します。
パッケージ更新・テンプレート活用型
現行のTMSやクラウド製品を、改善されたバージョンや画面オプションへ切り替えるタイプです。導入範囲を抑えやすい一方で、改善できる画面は製品の仕様に左右されます。
差別化したい荷主向けの画面だけ、別の方式と組み合わせられるかも確認します。
比較すべき評価軸
候補は、UI/UX設計と現場の巻き込み、技術選定と既存システム連携、費用・期間・セキュリティの3軸で比べます。提案書の印象だけで判断しないよう、各社に同じ質問を出し、確認できた根拠を残します。
- 現場の操作を踏まえたUI/UX設計とユーザーテストの進め方
- 既存の配車エンジン、データベース、アプリとの連携の設計
- 対象範囲をそろえた費用・期間と、権限管理やログ保存の説明
UI/UX設計力と現場巻き込み手法
現場の操作に合うかは、画面の見栄えとは別に確かめる必要があります。そのため、業務システムでのUI/UXの実績、Figmaなどを使った試作、現場ヒアリングとユーザーテストの進め方を確認します。
ドライバーや配車担当者の意見をどう集め、どの判断に反映するかも質問します。
技術選定と既存システム連携力
管理者画面やドライバー向けアプリの技術選定に加えて、配車エンジンやデータベースとのAPI連携も確認します。
GPSの常時測位、オフライン対応、通信が不安定な場所でのデータ保持と復帰後の同期は、具体的な検証方法まで尋ねます。
費用・期間・セキュリティ
拠点数、画面数、連携先をそろえた見積もりで比べ、プロトタイプ、PoC、本格開発の段階ごとの期間を確認します。
位置情報や個人情報を扱う場合は、権限管理、通信の暗号化、ログ保存についても質問し、回答の根拠を記録します。
フルスクラッチ・ヘッドレス・パッケージ更新の選び分け
独自の配車ルールが競争力に直結するなら、フルスクラッチを検討します。中核のロジックを保って操作体験を改善するには、ヘッドレスが候補になります。投資範囲を抑えて早く改善したい場合は、パッケージ更新を中心に考えます。
最優先の課題と残す範囲を先に決めておくと、提案の違いを比べやすくなります。
フルスクラッチを選ぶ判断基準
配車ルールや料金体系が事業の強みに直結し、既製の仕組みでは表現しにくい場合に検討します。
自由度に投資する事業上の理由をはっきりさせ、作り込みたいという希望だけで範囲を広げないようにします。
ヘッドレス構成・パッケージ更新を選ぶ判断基準
配車ロジックに大きな不満がなく、UIを改善したいなら、ヘッドレス構成の費用対効果を検討します。
API整備を事前に調べ、予算や体制の制約が大きい場合は、パッケージ更新から始めます。そのうえで、効果を見ながら次の投資を判断します。
提案依頼(RFP)とPoCの進め方
RFPには機能の有無だけでなく、実際の車両や案件を使う検証シナリオと合格条件を含めます。
プロトタイプは説明を聞くだけにせず、ドライバーや配車担当者が操作できる形で比べます。
提案依頼に載せる業務シナリオと非機能要件
提案依頼には、業務シナリオと非機能要件を次のとおり記載します。
- 対象範囲：対象拠点、車両台数、既存構成
- 現行フローと課題：現行の流れと、解決したい課題
- 例外処理：急な欠便や緊急配車の割り込みなど、例外時の扱い
- 非機能要件：権限管理、操作ログ、障害時対応
- サポートとデータ移行：サポート窓口、データ移行
要件は「必須」「望ましい」「将来」に分けて書きます。こうすると、提案会社ごとに満たせる範囲を見比べられます。
ドライバー・配車担当者を交えたPoC
協力してもらうドライバーと配車担当者には、通常業務に近い形で操作してもらい、タップのしやすさ、視認性、入力時間を記録します。
操作完了時間、問い合わせが必要になった箇所、紙運用に戻らず完結できたかを合格条件に含めます。また、習熟度の異なる利用者も評価します。
選定の失敗を避ける方法
見た目のデザイン案だけで決めると、既存システムとの連携や現場の操作性を見落とすおそれがあります。そのため、目的と評価の責任者を明確にし、現場、情報システム、荷主対応部門の視点を同じ比較表に反映します。
デザインの見た目だけで決める失敗
デザインカンプが洗練されていても、配車ロジックや既存システムとの連携が伴わなければ、実運用にはつながりません。そこで、必須要件を満たす提案を残し、費用対効果と現場の操作性で比べます。
運用ルールと定着支援体制
研修担当、リリース後の問い合わせ窓口、拠点ごとの展開予定は、導入前に決めておきます。
導入前に、操作完了時間や紙運用への回帰率などの基準値を記録しておきます。そうすると、導入後に同じ条件で確認できます。
全拠点へ一度に広げず、協力を得やすい拠点から始める方法も検討します。
TMSのリニューアル導入前に確認しておきたいポイント
候補を絞ったあとは、費用だけでなく、既存システムとの連携実績と現場の操作性も確認します。
比較資料では分からない条件は、事前に検証しておきます。そのうえで、導入後の定着を見据えて契約範囲を確認します。
車両台数が少ない場合の検討価値
優先度は、車両台数だけでなく現場の困りごとで決めます。少数の拠点でも、操作拒否や荷主からの不満が強ければ検討対象になります。一方で、現場が困っていない場合は、他の投資を先にするのも選択肢です。
既存の配車ロジックを残せる範囲
API連携の仕様が整っていれば、配車エンジンやデータベースを大きく変えずにUIを再構築できる可能性があります。ただし、内部構造やAPIの有無で難易度が変わるため、提案前の技術調査で確認します。
ドライバーへの研修の担当範囲
操作マニュアルや初期研修は、開発会社が支援する場合があります。一方で、日々の定着支援や拠点ごとの説明会は、自社側が担うことがあります。
研修の範囲、問い合わせ窓口、追加改善への対応方法は、契約前に確認します。
まとめ
TMSのリニューアルでは、まず利用者ごとの課題を特定し、作り変える範囲を決めます。
フルスクラッチ、ヘッドレス・BFF、パッケージ更新の3つは、UI/UX、連携、費用・期間・セキュリティの観点で比べます。
候補を絞ったら、RFPに業務シナリオと非機能要件を記載し、PoCで現場の操作性を確かめます。提案は機能の多さよりも、既存ロジックを残す範囲と運用・定着支援まで含めて、実行できるかで選びます。
▼全体ガイドの記事・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を創業。