TMSのリアーキテクチャのPoC・プロトタイプ・モックアップ開発について

TMSのリアーキテクチャとは、配車計画の立案・走行ルートの最適化・運賃計算・車両とドライバーの動静管理を担ってきた既存のTMS（輸配送管理システム）に対して、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ（5R）のうち特にリファクタリング・リビルドをさらに深掘りし、モノリスからマイクロサービスへの分解、ドメイン駆動設計（DDD）、API-first設計、クラウドネイティブアーキテクチャパターンという「構造そのものの設計」に焦点を絞って取り組む技術専門のプロジェクトを指します。同じ「TMS」を扱う記事群でも、「TMSのモダナイゼーション」におけるPoCは5Rのどれを選ぶべきかを見極めるための技術検証全般を扱う総論であり、「TMS刷新」におけるPoCは経営層への投資対効果アピールを目的とした小規模な効果検証を扱います。「TMS更改」は契約満了までの残存期間内で標準機能への適合度（Fit to Standard）を検証するPoCを、「TMSのリニューアル」はドライバーアプリ・配車ダッシュボード・荷主ポータル向けのUIプロトタイプによるユーザビリティ検証を扱います。これに対し本記事群が扱うPoCは、モノリスからマイクロサービスへの分解が技術的に実現可能かどうか、特に配車最適化エンジンの独立サービス化とGPS・テレマティクスストリーム処理基盤という2つの難所を「垂直スライス」という最小単位で切り出し、アーキテクチャ設計そのものの妥当性を検証するという、他のいずれとも異なる技術的な位置づけを持ちます。IT部門・アーキテクト・エンジニアなど技術者に向けて、実務に踏み込んだ内容を解説します。

本記事では、TMSのリアーキテクチャにおけるPoC・プロトタイプ・モックアップ開発について、システム全体を一気に作り替えるのではなく「垂直スライス」という単位で検証を進める考え方、GPS・テレマティクスストリーム処理基盤のプロトタイプ検証の進め方、配車最適化エンジンのPoCとGo/No-Go判断の基準、そしてPoCを本開発へつなげる実務のポイントまでを、具体的な数値とともに体系的に解説します。アーキテクチャ再設計に着手する前に、技術的な実現性を小さく検証しておきたいIT部門・アーキテクト・エンジニアにとって、PoCの設計そのものの精度を高めるための判断軸が身に付く内容です。

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

▼全体ガイドの記事
・TMSのリアーキテクチャの完全ガイド

TMSのリアーキテクチャの位置づけ（垂直スライスによる技術検証という論点）

TMSのリアーキテクチャにおけるPoCの位置づけを正しく理解するには、まず本記事群が扱う論点を、近接する4つの記事群と切り分けておく必要があります。同じ「TMS」というキーワードでも、何を検証対象とするPoCなのかが記事群ごとにまったく異なるためです。

「TMSのモダナイゼーション」におけるPoCは、既存の輸送実績データ・運賃マスタが新環境へ正確に移行できるかという「移行の正確性」を検証する総論であり、「TMS刷新」におけるPoCは輸送コスト増・積載効率低下・傭車比率上昇の改善効果を経営層に示す小規模なトライアル導入を扱います。「TMS更改」は契約満了までの残存期間内で標準機能への適合度（Fit to Standard）を検証するPoCを、「TMSのリニューアル」はドライバー・配車担当者・荷主向けのUIプロトタイプによるユーザビリティ検証を扱います。これに対し本記事群が扱うPoCは、モノリスからマイクロサービスへの分解が技術的に実現可能かどうか、特に配車最適化エンジンの独立サービス化とGPS・テレマティクスストリーム処理基盤という2つの難所を「垂直スライス」という最小単位で切り出し、アーキテクチャ設計そのものの妥当性を検証するという、他のいずれとも異なる技術的な位置づけを持ちます。

TMSのアーキテクチャ全体を薄く広く検証しようとすると、境界設計の妥当性やデータ整合性の課題が表面化しないまま「検証できた気になる」危険性があります。そこで有効なのが、特定のビジネス機能をデータベースからAPI、インフラまで一気通貫で切り出す「垂直スライス」というPoCの単位です。TMSであれば、たとえば「特定エリアの配車最適化処理」や「一部車両のGPS・テレマティクスデータ収集基盤」といった、業務的にもインフラ的にも自己完結する単位を選ぶことで、システム全体を作り込まなくても、アーキテクチャ設計が抱えるリスク（サービス境界の妥当性、データ一貫性の担保、スケーラビリティ）を現実的なコストで検証できます。輸送配車系TMSのPoCでは、開発期間3ヶ月〜、費用感100万円〜500万円程度が一つの目安として報告されています。

TMSのリアーキテクチャにおけるPoCの進め方

アーキテクチャ再設計のPoCは、システム全体のモダナイゼーションにおける最初のパイロットフェーズ（目安3〜6ヶ月）に位置づけられ、技術的実現性の検証と、後続フェーズへ進むべきかどうかの判断材料を揃えることが目的になります。

垂直スライスの選定では、システム全体を薄く作るのではなく、ドメイン専門家とエンジニアが参加するEventStormingのようなワークショップを通じて特定した3〜5つのコアビジネスドメインの中から、検証価値が高くリスクの高い1つを選び出すことが重要です。TMSであれば「特定エリアの配車最適化処理」を選べば配車最適化エンジンのマイクロサービス分離という論点を、「一部車両のGPS・テレマティクスデータ収集基盤」を選べばストリーム処理基盤という論点を、それぞれ集中的に検証できます。この2つは技術的な性質がまったく異なるため、両方を検証したい場合でも同時並行ではなく、まずどちらか一方に絞って知見を蓄積してから、もう一方に着手する順序立てが現実的です。数日〜数週間の使い捨てコードで実現可能性だけを確認する「アーキテクチャスパイク」を組み合わせれば、配車エンジンを分離した際のレスポンスタイムや、数千台規模のGPSストリーム処理がクラウド上でスケーラブルに捌けるかといった論点を、本格投資の前に低コストで検証できます。

PoC段階から取り入れておきたいのが、既存モノリスは稼働させたまま新サービスを周囲に並行構築する「ストラングラーフィグパターン」です。APIゲートウェイを介して一部のトラフィックだけを新しいマイクロサービスへルーティングし、問題が発生した場合には即座に旧来のコードへフォールバックできる状態を維持しながら検証を進めます。この進め方であれば、PoC段階で万が一想定外の不具合が見つかっても、稼働中の輸送業務そのものへの影響を局所化でき、本番相当のトラフィックを使った現実的な検証がしやすくなります。

GPS・テレマティクスストリーム処理基盤のプロトタイプ検証

GPS・テレマティクスストリーム処理基盤のプロトタイプ検証では、リアルタイム性の要求水準がどこまで必要かを見極めることが最初の論点になります。

GPS・テレマティクスデータの連携方式は、Kafkaのようなメッセージブローカーでイベントが発生した瞬間に処理を確定させる「Push型」と、一定間隔でデータを取得・照合する「Pull型（バッチ照合）」の2つに大別できます。Push型は現在地の即時反映やリアルタイムのルート逸脱検知のようにミリ秒〜秒単位での確定が求められる業務に適する一方、イベントが紛失した場合の補償処理（リトライ・再送）の実装難易度が高くなります。Pull型は5〜10分程度の遅延が許容される業務、たとえば配送実績の定期集計や運賃精算データの照合であれば、シンプルなスケジューラで実装でき、障害発生時にも自己修復しやすいという利点があります。プロトタイプ検証の段階で、TMSのどの機能にどちらの方式が適しているかを業務要件と突き合わせて確認しておくことが、後工程での設計手戻りを防ぎます。

GPS・テレマティクスストリーム処理基盤のプロトタイプでは、OpenAPI 3.0のような仕様で同期通信のAPI契約を、AsyncAPIのような仕様で非同期・イベント駆動通信の契約をそれぞれ先に定義し、Prism・Mockoonといったツールでモックサーバーを自動生成する進め方が有効です。これにより、位置情報を受け取る配車最適化エンジンや配車ダッシュボードといった呼び出し側が、ストリーム処理基盤本体の完成を待たずに開発・結合テストを進められます。あわせて、Pact・Spring Cloud Contractのようなコンシューマ駆動契約テストをCI/CDに組み込んでおくことで、プロトタイプ段階で定めた契約が後工程で破壊的に変更されるリスクを未然に防止できます。

配車最適化エンジンのPoC・Go/No-Go判断

配車最適化エンジンのPoCでは、単に「動くものができたか」ではなく、マイクロサービスとして本格投資すべきかどうかを客観的な基準で判断することが求められます。あわせて、TMS特有の技術的リスクを洗い出しておくことも欠かせません。

パイロットフェーズ（最初の四半期）の終了時点で、以下の4つの早期成功シグナルを達成できているかどうかがGo/No-Goの明確な判断基準になります。1つ目は、配車最適化エンジンが独立したAPI・サービスとしてきれいに分離できていること、2つ目は自動テスト・自動デプロイのCI/CDパイプラインが初期段階で確立されていること、3つ目は移行した最初のコンポーネントが他システムに悪影響（リグレッション）を与えることなく独立して動作していること、4つ目は依存関係による開発のブロックや手戻りが減り、エンジニアリングの速度そのものが向上し始めていることです。これに加え、TMSでは配車アルゴリズムが渋滞状況・ドライバーの拘束時間（年間960時間上限規制）・積載率という複数条件をクリアできるか、ベテラン配車担当者の暗黙知をパラメータとして正しく組み込めているかという精度検証、そして数千台規模のGPS・テレマティクスデータをリアルタイムかつ遅延なく処理できるかという負荷検証も、Go/No-Goの判断材料に含めるべきです。これらが達成できない場合は、無理に本格開発へ進めるのではなく、ドメインの境界設計やチームのDevOps体制そのものを見直すNo-Go判断を下すべきとされています。

配車最適化エンジンのPoCで見落とされがちなのが、アルゴリズムそのものの検証よりも先に、入力となる住所・配送先データの品質を確認する工程です。あるTMSの配車最適化プロジェクトでは、不均一な住所フォーマットやジオコードの欠落・重複といったデータ品質の問題を先に解消するため、プロジェクト開始を意図的に4ヶ月遅らせ、データクレンジングと自動ジオコーディングの仕組みを整備しました。その結果、当初9ヶ月かかると見積もられていた最適化エンジン本体の開発フェーズが、わずか3ヶ月で完了しています。また、既存の受注管理システム（OMS）やWMSとのデータ連携についても、フォーマットの不一致やAPI連携エラーが起きると現場で二重入力が発生し業務停止に直結するため、PoCの段階で連携仕様の食い違いを洗い出しておくことが、後続のマイクロサービス開発フェーズの期間見積もりを大きく左右する重要な工程です。

PoCを本開発につなげる実務ポイント

PoCで得られた知見を無駄にせず本開発へ着実につなげるためには、予算の位置づけと依頼先選定の両方をあらかじめ整理しておくことが欠かせません。

アーキテクチャ再設計のPoCは、ビジネス収益を直接生む投資ではなく、インフラの土台作りとドメイン分析、技術的実現性の検証そのものに対する投資と位置づけて予算化することが重要です。パイロット拠点・パイロットエリアを選ぶ際は、業務影響が比較的小さく、かつGPS・テレマティクスストリーム処理基盤や配車最適化エンジンが抱える技術的難所を代表的に含む対象を選定すると、限られた検証期間の中でも有意義な知見を得やすくなります。PoCの結果、期待した効果予測を下回るシナリオでも一定の投資対効果を確保できるかという安全マージンをあらかじめ確認しておくことが、本開発への移行判断をスムーズにします。

PoCの依頼先を選ぶ際は、単発の試作品を作れるかどうかではなく、ドメイン駆動設計によるBounded Contextの特定、API-first設計によるモック開発、そしてストラングラーフィグパターンによる並行検証までを一貫して設計できる技術力があるかを確認することが重要です。契約前の提案段階で、垂直スライスの選定理由とGo/No-Go判断の基準をどこまで具体的に示せるかを確認し、単に「試しに作ってみる」だけでなく本開発への移行を見据えた検証設計を提案してくれるパートナーかどうかを見極めましょう。プロジェクト開始後は、パイロットフェーズの節目ごとに検証結果を可視化する定例報告を設け、Go/No-Goの判断を関係者間で共有できる体制を整えておくことが重要です。

まとめ

本記事では、TMSのリアーキテクチャにおけるPoC・プロトタイプ・モックアップ開発について、垂直スライスによる技術検証という位置づけの確認、PoCの進め方、GPS・テレマティクスストリーム処理基盤のプロトタイプ検証、配車最適化エンジンのPoC・Go/No-Go判断、そしてPoCを本開発につなげる実務ポイントを体系的に解説しました。システム全体を薄く検証するのではなく、特定エリアの配車最適化処理や一部車両のGPS・テレマティクスデータ収集基盤といった垂直スライスに絞り、ストラングラーフィグパターンで既存システムと並行させながら検証することが鉄則です。データクレンジングへの先行投資によって最適化エンジンの開発期間が9ヶ月から3ヶ月へ圧縮された実例、そしてドライバーの拘束時間規制や暗黙知のパラメータ化というTMS特有の精度検証が示す通り、PoC段階でのデータ品質検証と現場要件の網羅性確認こそが本開発の成否を分けます。4つのGo/No-Go基準を関係者間で共有し、垂直スライス単位の検証実績が豊富なパートナーに早めに相談することをお勧めします。

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