TMSのリニューアルの選定ポイント/選び方/種類

TMSのリニューアルを外部に依頼しようとすると、UIデザインを得意とする制作会社、業務システムの改修を専門とする開発会社、既存の配車ロジックごと作り直す提案をしてくる会社など、アプローチの異なる提案が並び、比較の軸を定めないまま検討を進めてしまう企業も少なくありません。選定の出発点は、ドライバーアプリ・配車ダッシュボード・荷主ポータルのどこに最も強い課題があるかを明らかにすることです。

本記事では、TMSのリニューアル選定前に整理すべき自社課題、フルスクラッチ型・ヘッドレス型・パッケージ更新型という3つのアプローチ、提案や開発パートナーを比較する評価軸、選び分けの考え方、提案依頼(RFP)とPoCの進め方を解説します。これから相談先を探す担当者の方が、比較の観点をそろえ、自社に合う進め方を具体的に絞り込める内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・TMSのリニューアルの完全ガイド

TMSのリニューアル選定前に整理すべき自社の課題

最初に行うべきことは、提案会社の実績一覧を集めることではなく、ドライバー、配車担当者、荷主のどの利用者にどのような不満が集中しているかを特定することです。課題が一文で説明できれば、比較対象に含めるべき提案タイプと不要な機能が見えやすくなります。あわせて、現状の画面をどの部門がどの頻度で使い、どの操作にどれだけ時間がかかっているかを簡単にでも記録しておくと、提案会社との初回面談で認識のずれが起きにくくなります。

アプリの利用率が特定の年齢層で低い、紙の伝票管理へ戻ってしまう拠点がある、といった状況は、ドライバー向けUIに課題があるサインです。手袋を着けたままのタップのしやすさ、屋外・夜間での視認性、入力項目の少なさなど、実際の利用環境を踏まえた要件を洗い出しておくと、提案会社との会話がかみ合いやすくなります。拠点によって定着度合いに差がある場合は、車両の年式や利用端末の違いが原因になっていないかもあわせて確認すると、必要な検証範囲を見誤りにくくなります。

配車担当者がガントチャートや地図表示を何度も見比べている、ドラッグ&ドロップでの組み替えに時間がかかっている場合は、ダッシュボードの情報設計に課題がある可能性があります。リアルタイムのワーニング表示や二重手配の防止といった機能面の課題と、単に画面が見づらいという表示面の課題を分けて整理すると、必要な提案の種類を判断しやすくなります。繁忙期にだけ操作ミスが増える場合は、平常時のデモでは再現しにくいため、実際の繁忙期の案件量を想定した検証を依頼できるかも確認しておきます。

配送状況の可視化画面が古いままだと、荷主からの問い合わせが減らず、取引条件の交渉でも見劣りする可能性があります。荷主からの改善要望を具体的に集め、単なる「見た目を新しくしたい」という要望から一歩踏み込んで、どの操作や表示が不満の原因になっているかを言語化しておくことが大切です。営業担当や顧客対応窓口が日頃受けている指摘をヒアリングし、荷主側の利用シーン(スマートフォンでの確認が多いか、複数拠点の担当者が同時に見るかなど)まで把握しておくと、選定時の要件が具体化しやすくなります。

TMSのリニューアルにおける3つのアプローチ

主なアプローチは、配車ロジックからUIまで全体を作り直すフルスクラッチ型、既存の中核部分を残しUI層だけをヘッドレス構成で再構築する型、パッケージ製品側の画面テンプレートやオプション機能を活用する型の3つです。実際の提案は複数の要素を組み合わせるため、分類名よりも、自社の最優先課題をどのアプローチで解決できるかを確認します。同じ「リニューアル」という言葉を使っていても、提案会社によって想定する作業範囲が異なるため、見積もりを比較する前に、どこまでを再構築の対象とするかを共通認識にしておくことが欠かせません。

配車ロジックや帳票なども含めて全面的に作り直すタイプです。他社と差別化したい独自の配車ルールや、既存パッケージでは吸収しきれない業務フローを持つ企業に向いています。自由度が高い分、要件定義から本番稼働までの期間と費用は大きくなりやすく、段階的な進め方の設計が重要になります。複数拠点・多車種にまたがる複雑な配車ルールを持つ企業ほど、既製の仕組みでは表現しきれない部分が多くなりやすく、フルスクラッチが現実的な選択肢として残ります。

既存の配車エンジンやデータベースが安定している場合に、API経由でつなぐBFF層を挟みながらUI層だけを再構築するタイプです。中核ロジックへの影響を抑えながら操作体験を大きく改善できる一方、既存システム側のAPI整備状況によって難易度が変わるため、事前の技術調査が欠かせません。既存システムがAPIを外部に公開していない場合は、追加の接続基盤を構築する工程が必要になり、当初の想定より工期が延びることもあるため、提案段階でこの前提を確認しておくと後戻りを防げます。

現行のTMSパッケージやクラウド製品自体を、UIが改善された新しいバージョンや画面オプションへ切り替えるタイプです。独自の作り込みは最小限に抑えられますが、対応できる見た目や操作導線の範囲は製品側の仕様に依存するため、自社が最も改善したい画面が対象に含まれるかを確認する必要があります。導入コストを抑えやすい一方、他社と同じ標準機能に留まりやすいため、荷主向けポータルなど差別化したい画面まで含めて検討する場合は、範囲を分けて他のアプローチと組み合わせることも検討します。

比較すべき評価軸

候補となる開発パートナーや提案は、UI/UX設計力と現場巻き込み手法、技術選定と既存システム連携力、費用・期間・セキュリティという軸で比較します。同じ質問を各社へ提示し、提案内容と実績をそろえると、担当者の印象ではなく適合度で判断できます。

提案会社が過去にどのような業務システムのUI/UXを手がけてきたか、Figma等でのプロトタイピングをどう進めるか、現場ヒアリングやユーザーテストをどのように設計するかを確認します。デザインだけを得意とする会社と、業務システムの構造まで理解して設計できる会社では、配車業務特有の複雑なUIへの対応力が異なります。過去の実績を確認する際は、単に納品物としての画面デザインを見るだけでなく、現場のドライバーや配車担当者からどのように意見を集め、どこを妥協しどこを譲らなかったかという進め方まで質問すると、自社のプロジェクトでの動き方を推測しやすくなります。

管理者向け画面の技術選定(ReactやNext.jsなど)と、ドライバー向けアプリの技術選定(React NativeやFlutterなど)の妥当性に加え、既存の配車エンジンやデータベースとAPI連携する際の設計力を確認します。GPSの常時測位やオフライン対応が必要な場合は、実際にどのような検証を行うかを具体的に質問し、抽象的な「対応可能です」という回答で終わらせないことが大切です。通信が不安定な山間部や地下駐車場などでの利用が想定される場合は、オフライン時のデータ保持と復帰後の同期方法まで踏み込んで確認すると、リリース後のトラブルを未然に防ぎやすくなります。

見積もりは、対象範囲(拠点数・画面数・連携先システム数)を明確にしたうえで比較しないと、金額だけを見て判断を誤ります。プロトタイプ検証、PoC、本格開発という段階ごとの期間の目安を確認し、位置情報や個人情報を扱う場合の権限管理、通信の暗号化、ログ保存についても質問します。比較結果は「デモで確認」「提案書で確認」のように根拠を残し、未確認事項は保留にすることで、説明の分かりやすさだけに評価が引っ張られることを防げます。

フルスクラッチ・ヘッドレス・パッケージ更新の選び分け

独自の配車ルールが競争力に直結し、既存パッケージでは吸収しきれないならフルスクラッチ、中核ロジックは維持しつつ操作体験を大きく改善したいならヘッドレス構成、最小限の投資で早期に改善したいならパッケージ更新が第一候補になります。

配車ルールや料金体系が事業の競争優位性に直結しており、既製の仕組みでは表現しきれない場合はフルスクラッチが選択肢になります。ただし、その独自性に投資するだけの事業上の理由があるかを見極めることが前提です。単に「作り込みたい」という思いだけで進めると、費用と期間が膨らみやすくなります。

既存の配車ロジックに大きな不満がなく、UIだけを改善したい場合は、ヘッドレス構成による部分刷新が費用対効果に優れます。とはいえAPI整備の状況によっては想定より難易度が上がることもあるため、事前調査を省略しないことが重要です。予算や体制の制約が大きく、まずは小さく試したい場合は、パッケージ側の更新やテンプレート活用から着手し、効果を見ながら次の投資を判断する方法も現実的です。

提案依頼(RFP)とPoCの進め方

比較資料や提案依頼では、機能の有無だけでなく、実際の車両・案件を使った検証シナリオと合格条件を示します。プロトタイプの確認は説明を聞くだけで終わらせず、ドライバーや配車担当者に実際に操作してもらうことが重要です。

提案依頼には、対象拠点、車両台数、既存システムの構成、現行フロー、解決したい課題を記載します。そのうえで、実際の配車パターンや例外処理(急な欠便、緊急配車の割り込みなど)を示し、非機能要件として権限管理、操作ログ、障害時対応、サポート窓口、既存データの移行方法まで含めます。各要件を「必須」「望ましい」「将来」の3段階に分けると、すべてを必須として候補を狭めすぎる事態を避けられます。

PoCでは、実際に協力できるドライバーと配車担当者を数名選び、通常業務の中でプロトタイプを操作してもらいます。タップのしやすさ、屋外・夜間での視認性、入力にかかる時間を記録し、開発会社側の説明だけに頼らず自社で評価します。合格条件には、操作完了までの時間、問い合わせが必要になった箇所、紙運用に頼らず完結できたかどうかを含めると、デモでは見えない現場の負荷を比較できます。協力してもらうドライバーは、デジタル機器への抵抗感が強い層とすでに使いこなしている層の両方を含めておくと、平均的な評価だけでは見落としがちな操作のつまずきポイントを発見しやすくなります。

選定の失敗を避ける方法

よくある失敗は、見た目のデザイン案だけで比較し、既存システムとの連携やドライバー側の操作性を検証しないことです。目的と評価責任者を明確にし、現場、情報システム、荷主対応部門の視点を選定に反映します。

洗練されたデザインカンプでも、実際の配車ロジックとの整合や既存システムとの連携が伴わなければ機能しません。デザイン案の見栄えだけで評価するのではなく、必須要件を満たさない提案は除外し、残った候補を費用対効果と現場の操作性で比べます。

誰が新画面の研修を担当するか、リリース後の問い合わせ窓口を誰が持つか、拠点ごとの展開スケジュールをどう管理するかが曖昧では、開発が完了しても定着は進みません。効果測定の基準値(操作完了時間、紙運用への回帰率など)を導入前に記録し、リリース後に同じ条件で比較する体制もあわせて準備します。

展開範囲を最初から全拠点へ広げることも失敗の原因になります。課題が大きく協力を得やすい拠点から始め、運用が安定したことを確認してから対象を広げます。試行期間中は、システムの設計不備と単なる操作習熟の問題を分けて記録し、不要な追加開発を避けながら定着を進めることが重要です。具体的な製品・ベンダーの候補を確認したい場合は、TMSのリニューアルのパッケージ・クラウド製品一覧もあわせてご覧ください。

TMSのリニューアル導入前に確認しておきたいポイント

候補を絞った後は、費用の安さだけでなく、既存システムとの連携実績や現場での実際の操作性まで確認します。比較資料の見た目だけでは分からない条件を事前に検証することで、導入後に定着が進まないリスクを抑えられます。

車両台数の多さだけで判断するものではありません。少数の拠点でも、ドライバーの高齢化による操作拒否や荷主からの不満が強い場合は検討価値があります。反対に、現行の操作性で現場が困っていないなら、優先度を下げて他の投資を先に検討する選択も妥当です。

API連携の仕様が整っていれば、配車エンジンやデータベースを大きく変更せずにUI層だけを再構築できる可能性があります。ただし、既存システムの内部構造やAPIの有無によって難易度が変わるため、提案を受ける前に技術調査を行うことをおすすめします。

開発会社が操作マニュアルの作成や初期研修を支援する場合もありますが、日々の定着支援や拠点ごとの説明会は自社側の体制が中心になることが一般的です。契約前に、研修支援の範囲、リリース後の問い合わせ窓口、追加の改善要望への対応方法を確認しておくと、リリース後の混乱を減らせます。

まとめ

TMSのリニューアルの選定では、ドライバーアプリ、配車ダッシュボード、荷主ポータルのどこに課題が集中しているかを特定し、フルスクラッチ型、ヘッドレス・BFF型、パッケージ更新型のいずれのアプローチが適するかを見極めます。そのうえで、UI/UX設計力、技術選定と連携力、費用・期間・セキュリティという評価軸で候補を比較し、実際のドライバー・配車担当者を交えたPoCで操作性まで確認することが重要です。

アプローチの選択は、機能の多さではなく、既存の配車ロジックをどこまで残し、どこから作り変えるかによって判断します。既製の仕組みでは複雑な配車ルールや荷主ごとの個別要件に対応できない場合、無理に合わせると現場の手作業が残ります。riplaはフルスクラッチ開発の立場から、既存TMSとの連携を保った部分刷新から、業務要件に合わせた全面的な再構築まで支援しています。

▼全体ガイドの記事
・TMSのリニューアルの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。