TMSのモダナイゼーションのPoC・プロトタイプ・モックアップ開発について

TMSのモダナイゼーションとは、オンプレミスのサーバーや、取引先ごとに個別化されたEDI連携で長年運用してきた既存TMS（輸配送管理システム）を、クラウドネイティブな環境や最新のアーキテクチャへと刷新する取り組みです。ゼロからTMSを新規に構築する「TMS開発」がグリーンフィールドのプロジェクトであるのに対し、本記事が扱うのは、すでに稼働している既存TMSを前提としたブラウンフィールドの刷新であり、PoC（概念実証）で検証すべき内容も新規導入とは大きく異なります。新規導入のPoCが「ゼロから作る配車機能が現場業務を満たすか」を検証するのに対し、モダナイゼーションのPoCでは「既存の輸送実績データ・運賃マスタを正しく移せるか」「輸送業務を止めずに新旧システムを並行運用させても配車計画・運賃計算の結果がずれないか」「配送業者・傭車先との既存連携システムが問題なく切り替わるか」といった、移行そのものの実現可能性を検証することに主眼が置かれます。この検証を怠ったまま本開発に進むと、稼働直前になって運賃計算が合わない、取引先とのEDI連携が機能しないといった深刻な問題に直面しかねません。TMSは配送業者・傭車先という社外の関係先と密接に結びついたシステムであるため、検証の巧拙が自社内だけでなく取引先との信頼関係にも直結する点を踏まえてPoCを設計する必要があります。

本記事では、対象システム種別を問わない「システムのモダナイゼーション」総論とは異なり、TMSに対象を限定したうえで、PoC・プロトタイプ・モックアップにフォーカスして解説します。PoCの位置づけと失敗時の影響範囲、輸送実績データ・運賃マスタ移行のPoC、配送業者・傭車先との連携システム切替のリハーサル、並行運用時の検証ポイント、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ（5R）別に見たPoCの違いまでを体系的に解説します。

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

▼全体ガイドの記事
・TMSのモダナイゼーションの完全ガイド

TMSのモダナイゼーションにおけるPoCの位置づけ

モダナイゼーションのPoCが何を検証するものかを理解するには、新規導入のPoCや総論記事が扱うPoCとの違い、そして失敗した場合の影響範囲を押さえておく必要があります。

「TMS開発」記事が扱う新規導入のPoCは、まだ存在しない業務フローに対して「この配車ロジックで本当に現場の業務が回るか」「配送ルートは実際の道路事情・納品先の制約に合っているか」を、実データを使って一から検証するものです。一方、「システムのモダナイゼーション」総論が扱うPoCは、対象システムの種類を問わず、選定した技術的アプローチ（5R）が技術的に実現可能かどうかを検証する、いわば移行手法そのものの実現可能性検証に重心を置いています。本記事が扱うTMSのモダナイゼーションPoCは、この両者の中間に位置づけられます。すでに存在する輸送実績データ・運賃マスタ・配送業者や傭車先との取引ルールを前提としつつ、それを新しい環境に正確に移せるか、旧システムで運用していたEDI連携が新環境でも問題なく機能するか、稼働中の輸送業務を止めずに新旧システムを並行運用させても配車計画・運賃計算の結果がずれないかという、「移行の正確性」を検証することが最大の目的になります。単に画面が動くかどうかではなく、「今と同じ輸配送オペレーションが、より新しい環境で再現できるか」を確かめる点が、モダナイゼーションPoC特有の視点です。

TMSのモダナイゼーションでPoCを軽視できないのは、失敗した際の影響範囲が単一システムにとどまらないためです。TMSは上位のWMS（倉庫管理システム）から出荷指示データを受け取り、配送業者・傭車先へ配車指示を出し、実績データを会計・販売管理システムへ渡すという連携が正しく機能して初めて、出荷から配送完了・請求までの全体プロセスが成立します。もし移行後の運賃計算ロジックにわずかなずれが生じれば、荷主・取引先への誤請求や、逆に自社の収益を損なう過小請求につながりかねません。さらに深刻なのは、配送業者・傭車先とのEDI連携がうまく引き継げず、配車指示や実績データのやり取りが止まってしまうことです。TMSは単独で稼働することが稀なシステムであるだけに、連携先の一つでもトラブルが起きれば、輸配送業務全体が滞る事態に発展しかねません。新規導入であれば稼働開始前に十分な検証期間を確保しやすい一方、モダナイゼーションでは既存の輸送業務を止められないという制約の中で検証を行う必要があるため、限られた時間の中でいかに実効性の高いPoCを設計するかが、プロジェクト全体の成否を左右する重要な論点になります。TMSは机上での要件定義が極めて困難なシステムでもあります。道路の幅員制限や納品先の暗黙のローカルルールといった、配車担当者の頭の中にしかない暗黙知が多く、モダナイゼーションのPoCであっても、既存の運用実態を無視した検証設計をしてしまうと、実際の移行時に「想定していなかった例外パターンで配車計画が破綻する」という事態を招きかねません。

輸送実績データ・運賃マスタ移行のPoC・リハーサル

モダナイゼーションPoCの中核をなすのが、既存の輸送実績データ・運賃マスタを新環境に移すデータ移行の検証です。本番移行での失敗を防ぐために、事前のリハーサルで何を確認すべきかを見ていきます。

データ移行のPoCでまず検証すべきなのが、顧客データ、配送マスタ、独自の運賃ルール、過去のルート設定といった既存の輸送実績データ・運賃マスタが、新システムへ正確に移行できるかという実機検証です。カタログスペックやデモ用の綺麗なダミーデータではなく、実際に運用してきた本番相当のデータを使って検証することで、机上の検討では見えなかった課題が浮かび上がります。長年運用してきたTMSでは、既存システムやExcel・紙伝票で属人的に管理されている顧客情報や複雑な運賃ルールが散在し、フォーマットも統一されていないことが珍しくありません。この検証を省略して机上の想定だけで本開発に進んでしまうと、新システム稼働後に配車計画の精度が下がり、システムが使い物にならなくなってしまうトラブルが発生します。PoCの段階で、実際にデータクレンジングルールを適用してみることで、どの程度のデータが自動処理で整理でき、どの程度が人手による確認を要するのかを定量的に把握でき、この実測値は本開発のスケジュールと費用を精緻化するうえで非常に価値のある情報になります。

データ移行のPoCで次に重要なのが、既存の基幹システム、会計システム、販売管理システムなどとの間で、データの受け渡し方法（API、EDI、CSVなど）やデータ変換仕様に食い違いやミスマッチがないかを確認するI/F検証です。特に運賃マスタは、顧客・拠点・車両サイズ・配送距離といった複数の条件が組み合わさって金額が決まる複雑な構造を持っていることが多く、旧システムの計算ロジックを新システムでどう再現するかの変換仕様が、実際のデータに対して正しく機能するかを検証する必要があります。複数拠点や複数事業部で異なる運賃ルールを個別に運用してきた場合、この整理・変換検証には想定の数倍の工数がかかることも実務上よく見られます。あわせて、旧システムのデータベースへ自社から直接アクセスできない契約になっているケースが多い点にも注意が必要です。移行テストのたびに旧ベンダーへデータ抽出を依頼する必要があり、依頼のたびにスポット費用が発生することもあるため、PoCの計画段階で旧ベンダーとのデータ抽出条件を事前に確認しておくことが望ましい対応です。あわせて、運賃計算ロジックのPoCでは、荷主向けの標準運賃だけでなく、燃料サーチャージ・待機料金・附帯作業料といった変動要素を含めた実際の請求パターンを網羅的に検証することが重要です。標準的な運賃体系だけを検証して本開発に進んでしまうと、稼働後にイレギュラーな請求ケースで計算結果が合わないという事態が発覚し、荷主・取引先からの信頼を損なうリスクにつながります。

配送業者・傭車先との連携切替リハーサルと並行運用検証

データが正しく移行できることを確認したら、次は実際の運用に近い形で新旧システムを並行運用させ、稼働中の輸送業務を止めずに検証するフェーズに移ります。ここではTMS特有の2つの検証ポイントを解説します。

段階移行を行う場合は、新旧双方のシステム間を中継・同期するための一時的な「連携モジュール」が正常に機能するかの検証が欠かせません。並行運用の検証では、新旧両方のシステムに同じ配車データ・運賃データを反映させ、配車計画や運賃計算の結果が一致し続けるかを継続的に監視します。並行運用を成功させる鍵は、検証項目と合格基準（Exit Criteria）をあらかじめ数値で定義しておくことです。具体的には、「並行稼働・シミュレーション期間中に新旧システムで出力された配車計画・運賃計算の結果が完全に一致するか（データ整合性の完全一致）」「実データの移行から現場の操作、配送業者・傭車先とのシステム間連携に至るまで、本番当日と全く同じ切り替えプロセスを模擬環境でトラブルなく完遂できるか（本番同様の移行リハーサルの完遂）」といった検証項目を洗い出し、それぞれについてどの水準を満たせば合格とするかを事前に決めておくことで、PoCの結果を感覚ではなく事実に基づいて評価できます。あわせて、配車担当者・ドライバーへの物理的な指示は新TMSからのみ出す「指示系統の一本化」を並行運用中も徹底し、どちらのシステムの数字を正として扱うかを現場・取引先に明確に伝えておくことも欠かせません。

並行運用の検証と並行して、万が一致命的な問題が発生した際に旧システムへ切り戻すための「ロールバック計画」もPoCの段階から検証しておく必要があります。切り戻すかどうかを判断する意思決定権限者をあらかじめ合意しておくことに加え、実際に旧システムへ切り戻す手順そのものが機能するかをリハーサルで確認しておくことが重要です。特に見落とされがちなのが、旧TMSのサーバーや、配送業者・傭車先との旧EDI回線を、新TMS稼働後どのタイミングまで維持しておくかという点です。切り替え当日に連携が機能しなかった場合に備え、休日でも直通で対応できるオンコール体制やエスカレーションルートを取引先も含めて事前に取り決めておくことに加え、旧システムのライセンス契約・回線契約を新TMS稼働後最低3ヶ月は解約せずに残しておくことが、想定外の事態に備えるための現実的な対策です。この維持期間中に発生する二重コストも、PoCの段階でプロジェクト予算に織り込んでおく必要があります。切り戻し計画の検証では、旧システムに戻した場合に配送業者・傭車先へどのように連絡を回すか、当日配送中の車両の指示系統をどちらのシステムに一本化するかといった、緊急時のオペレーション手順まで具体的にシミュレーションしておくことが望ましく、単に「システムを元に戻せるか」という技術的な確認にとどめないことが重要です。

技術的アプローチ別に見るPoCの違い・成功のポイント

リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ（5R）は、どれを選ぶかによってPoCで検証すべき内容が変わります。あわせて、PoCを成功させるための体制づくりについても解説します。

リホストやリプラットフォームを選ぶ場合、配車ロジック・運賃計算ロジックそのものは変更しないため、PoCで確認すべきは主に「移行先の環境でも従来どおりのデータ構造・処理速度で動作するか」という技術的な実現可能性です。既存の運賃マスタ・輸送実績データベースを新しいインフラ上に構築し、実際の配車件数に近い負荷をかけて処理速度が業務に耐えるかを検証したり、既存のバッチ処理や連携インターフェースが新環境でもエラーなく動くかを確認したりすることが中心になります。これに対して、リファクタリングやリビルドでは、配車ロジック・運賃計算ロジックといったビジネスロジック自体に手を入れるため、PoCで最も重視すべきは「新システムが旧システムと同じ処理結果を返すか」という機能等価性（回帰検証）です。同一の配車条件・運賃条件を新旧両方のロジックに投入し、算出される配車計画や運賃金額が一致するかを網羅的に検証する必要があり、この検証は手作業では膨大な工数がかかるため、本番相当のデータを自動的に収集し検証スクリプトを自動生成するようなツールやAIを活用し、回帰検証を効率化する動きも広がっています。リプレース（SaaS・パッケージへの移行）を選ぶ場合は、既存の運賃計算ロジックをどこまで標準機能で再現できるかというFit to Standardの検証がPoCの主眼になり、標準機能で対応できない部分をアドオン開発で補うのか、業務側のルールを変更して標準機能に合わせるのかを、PoCの結果を踏まえて早期に判断しておくことが、後工程の手戻りを防ぐポイントです。

TMSのモダナイゼーションにおけるPoCを実りあるものにするには、配車担当者・ドライバー・情報システム部門・配送業者や傭車先の担当者という関係者を早期に巻き込む体制づくりが欠かせません。配車業務は道路の幅員制限や納品先の暗黙のローカルルールなど、配車担当者の頭の中にしかない暗黙知が多く、机上だけで移行仕様を固めてしまうと「実際の現場では使えないシステム」が出来上がってしまうリスクが高いためです。とりわけモダナイゼーションでは「使い慣れた既存システムからなぜ変えるのか」という反発が新規導入時よりも強くなりやすく、システム導入で現場から反発を受ける企業は約50%に達し、そのうち15%は現場拒絶によりシステムがお蔵入りするというデータもあります。PoCの段階で「手書きの運賃計算が不要になった」「取引先とのやり取りがシステム上で完結するようになった」といった現場目線の小さな成功体験を提示できるかどうかが、定着化の鍵を握ります。情報システム部門やベンダーだけでPoCを完結させてしまうと、現場の視点が抜け落ち、本開発の途中や稼働後に「これでは現場で使えない」という問題が発覚しがちです。PoCの計画段階から関係者を巻き込み、それぞれの視点で検証項目を設計し、実際の検証にも参加してもらうことが、稼働後の混乱を防ぎ、モダナイゼーションを実務で機能するものにするための前提となります。特に配送業者・傭車先は自社の社員ではないため、PoCへの協力を仰ぐ際は、切替スケジュールや検証で得られるメリット（連携作業の簡素化・請求データの正確性向上等）を丁寧に説明し、無理なく協力を得られる体制を早期に整えておくことが、外部連携を伴うモダナイゼーション特有の配慮として欠かせません。

まとめ

本記事では、TMSのモダナイゼーションにおけるPoC・プロトタイプ・モックアップについて、PoCの位置づけと失敗時の影響範囲、輸送実績データ・運賃マスタ移行のPoC・リハーサル、配送業者・傭車先との連携切替リハーサルと並行運用検証、5つの技術的アプローチ別に見たPoCの違いを体系的に解説しました。TMSのモダナイゼーションのPoCは、新規導入のように「何を作るか」を検証するのではなく、既存の輸送実績データ・運賃マスタを正確に移し、配送業者・傭車先との連携システムが問題なく機能し、稼働中の輸送業務と並行運用できるかという「移行の正確性」を検証することに主眼があります。マスタデータ・実績の移行検証、I/F・データ変換仕様の確認、Exit Criteriaの数値定義（データ整合性の完全一致・本番同様リハーサルの完遂）、そして切り戻し計画の検証が、稼働後のトラブルを未然に防ぐための鍵となります。まずは対象を絞ったPoCで自社の輸送実績データ・運賃マスタと配送業者・傭車先との連携の移行手順を検証し、確かな判断材料を得たうえで本開発に進むことをお勧めします。特に、複数拠点・複数事業部を抱える企業ほど、いきなり全社的な検証を行うのではなく、最も課題が大きい1拠点・1事業部に絞ってPoCを実施し、そこで得られた知見を横展開する進め方が、限られた予算と期間の中で実効性の高い検証を行うための現実的なアプローチです。

▼全体ガイドの記事
・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を創業。