TMSのリアーキテクチャのフルスクラッチ・オーダーメイド開発について

TMSのリアーキテクチャとは、配車計画の立案・走行ルートの最適化・運賃計算・車両とドライバーの動静管理を担ってきた既存のTMS（輸配送管理システム）に対して、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ（5R）のうち特にリファクタリング・リビルドをさらに深掘りし、モノリスからマイクロサービスへの分解、ドメイン駆動設計（DDD）、API-first設計、クラウドネイティブアーキテクチャパターンという「構造そのものの設計」に焦点を絞って取り組む技術専門のプロジェクトを指します。同じ「TMS」を扱う記事群でも、「TMSのモダナイゼーション」が扱うリビルド（フルスクラッチ）は既存システムを丸ごとゼロから作り直すという規模軸の話であり、「TMS刷新」が扱う予算確保は経営層の投資判断という文脈です。「TMS更改」は契約満了までの残存期間内でパッケージ・SaaSを選ぶかフルスクラッチにするかという期限起点の判断を、「TMSのリニューアル」はドライバーアプリや配車ダッシュボードのUI/UXデザインをフルスクラッチで作り込むかという顧客体験起点の判断を扱います。これに対し本記事群が扱うフルスクラッチ・オーダーメイド開発は、配車最適化エンジンとGPS・テレマティクスストリーム処理基盤という特定のコンポーネントを、独立したマイクロサービスとしてゼロから設計・構築すべきかという、アーキテクチャ構造そのものに根差した技術的判断に焦点を絞ります。IT部門・アーキテクト・エンジニアなど技術者に向けて、実務に踏み込んだ内容を解説します。

本記事では、TMSのリアーキテクチャにおけるフルスクラッチ・オーダーメイド開発について、マイクロサービス化をフルスクラッチで進めるべきかどうかの判断基準、GPS・テレマティクスストリーム処理基盤をオーダーメイドで構築する際の要点、配車最適化エンジンをコア業務ドメインとしてフルスクラッチ投資する際の考え方、そして開発を成功させる体制・依頼先選定までを、具体的な数値とともに体系的に解説します。既存パッケージやSaaSの限界を感じ、アーキテクチャそのものを自社仕様でゼロから作り替えることを検討しているIT部門・アーキテクト・エンジニアにとって、投資判断の精度を高めるための材料が身に付く内容です。

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

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

TMSのリアーキテクチャの位置づけ（フルスクラッチ投資を検討する論点）

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

「TMSのモダナイゼーション」が扱うリビルド（フルスクラッチ）は、既存TMSを丸ごとゼロから作り直すという規模軸の話であり、「TMS刷新」が扱う予算確保は輸送コスト増・積載効率低下・傭車比率上昇の改善を根拠にした経営層の投資判断という文脈です。「TMS更改」は契約満了までの残存期間内でパッケージ・SaaSを選ぶかフルスクラッチにするかという期限起点の判断を、「TMSのリニューアル」はドライバーアプリや配車ダッシュボードのUI/UXデザインをフルスクラッチで作り込むかという顧客体験起点の判断を扱います。これに対し本記事群が扱うフルスクラッチ・オーダーメイド開発は、配車最適化エンジンとGPS・テレマティクスストリーム処理基盤という特定のコンポーネントを、独立したマイクロサービスとしてゼロから設計・構築すべきかという、アーキテクチャ構造そのものに根差した技術的判断に焦点を絞ります。

既存のSaaSやパッケージ製品には、標準機能の枠内でしかカスタマイズできないという限界があり、荷主ごとに個別化された運賃体系や高度な配車最適化アルゴリズムのように競争優位性へ直結する領域では、この制約がボトルネックになりやすいものです。特に配車最適化エンジンやGPS・テレマティクスストリーム処理基盤は、汎用パッケージでは対応しきれない自社固有の要件（車両特性、道路の幅員制限、荷主ごとの積み合わせルール、地域特有の交通事情）を抱えていることが多く、ベンダーロックインを避けたいという判断とあわせて、フルスクラッチによるマイクロサービス構築が検討の俎上に上がります。ただし、TMSのすべてをマイクロサービスとしてフルスクラッチ構築することは推奨されておらず、対象を絞った投資判断が求められます。

フルスクラッチを選ぶべきかの判断基準

TMSのアーキテクチャをフルスクラッチでマイクロサービス化すべきかどうかは、感覚ではなく客観的な数値の閾値と業務要件で判断することが重要です。

業界のコンセンサスとして、マイクロサービスが確実に価値を提供するのは、1日100万回以上のリクエストを処理する規模のシステムであり、かつ開発組織が50名以上のエンジニアを抱えている場合とされています。この閾値を下回るTMSでフルスクラッチのマイクロサービス化を進めると、ネットワークレイテンシの管理や分散データの一貫性維持、Jaeger等の複雑な監視ツールの運用にかかる「マイクロサービス税（運用オーバーヘッド）」が、独立したスケーラビリティという本来の利点を上回ってしまいます。あわせてTMSドメインでは、既存パッケージ・クラウドSaaSのカスタマイズ費用が本体価格の「50%」を超える場合に、長期的にはフルスクラッチ開発の方がコスト効率が良くなるという「TCOの50%ルール」も判断材料になります。自社の配車件数・リクエスト規模・開発体制がこれらの閾値に達していない場合は、まずはモジュラーモノリス（内部的にはドメインごとに整理しつつ、デプロイ単位は1つにまとめる設計）として構築し、将来の規模拡大に応じて段階的にマイクロサービスへ分離していく方が、現実的な投資判断になります。

TMSのフルスクラッチによる独立サービス化は、極めて特殊な配車ロジックと多拠点管理を要する場合に正当化されやすくなります。具体的には、建材の重量物制約、医薬品の厳密なトレーサビリティ・温度帯管理、複数キャリアとの混載といった独自要件を要する大手物流企業や荷主企業が該当します。また、倉庫・営業所が3拠点以上ある、EC・複数チャネルとのデータ連携が必要、古い基幹システムとAPI連携が必要、自動倉庫等の物流機器と連携したい、取引先ごとに異なるEDIフォーマットがあるという5つの要件のうち複数該当する場合も、標準パッケージでは対応が困難なためスクラッチ開発が視野に入ります。さらに、お中元や年末商戦のように平時の3〜5倍の配送量が発生する企業では、配車計算の処理能力を自社のタイミングでスケールアウト（負荷分散）させる設計が必要になり、独立サービス化が強みを発揮する典型的な条件です。

GPS・テレマティクスストリーム処理基盤のオーダーメイド開発

GPS・テレマティクスストリーム処理基盤をオーダーメイドで構築する場合、汎用的な監視ツールの導入とは異なり、インフラそのものの設計と初期投資に相応の覚悟が必要になります。

GPS・テレマティクスストリーム処理基盤をオーダーメイドで構築する際には、KafkaやKinesisといったメッセージブローカー本体だけでなく、それを動かすKubernetesクラスター、サービス間通信を制御するサービスメッシュ、そして分散トレーシング（Jaeger・OpenTelemetry）や監視スタック（Prometheus・Grafana）までを一式で設計・構築する必要があります。これらは単体の製品を導入すれば済むものではなく、位置情報という自社固有のデータ特性（更新頻度、データ形式、トンネル・山間部での欠損時の扱い）に合わせてパイプライン全体をカスタムメイドで組み上げる作業になります。あわせて、デジタルタコグラフやハンディターミナルといった車載デバイスとの独自の連携インターフェースを開発・実装する場合、別途50万円〜500万円程度の追加開発費用を見込む必要があり、これらは汎用テンプレートの流用だけでは対応しきれない部分として必ず残ります。

フルスクラッチによるマイクロサービス構築は、モノリス（またはモジュラーモノリス）と比較して初期開発コストが約40%高くなるとされています。これは、Kubernetesクラスターやサービスメッシュ、分散トレーシングといったインフラと自動化ツールの初期設定そのものに相応の工数がかかるためであり、GPS・テレマティクスストリーム処理基盤のように常時大量データを扱うコンポーネントでは、この初期投資の割合がさらに大きくなる傾向があります。この初期コストの上振れを許容し、中長期的なTCO（総所有コスト）の削減や独立したスケーラビリティという利点を優先できるかどうかが、フルスクラッチを選ぶかどうかの実質的な判断基準になります。

配車最適化エンジンのオーダーメイド開発

配車最適化エンジンは、自社の競争優位性に直結しやすい領域であるがゆえに、フルスクラッチ投資の是非を最も慎重に検討すべきコンポーネントです。

ドメイン駆動設計の考え方では、業務ドメインを「コア業務ドメイン」と「コモディティ領域」に切り分けて投資判断を行うことが推奨されます。独自の配車ロジックや荷主ごとの複雑な運賃計算アルゴリズムのように、競争優位性に直結し要件変更が頻繁に発生する配車最適化エンジンはコア業務ドメインに該当し、トップクラスのエンジニアを配置して独立したマイクロサービスとしてフルスクラッチで作り込む価値があります。一方、標準的な決済処理や一般的な通知配信、認証基盤のようなコモディティ領域まで自社でフルスクラッチ構築するのは「車輪の再発明」であり、API-first設計によって外部SaaSや既存システムをAPIとしてカプセル化・再利用する方が合理的です。この切り分けを誤ると、本来投資すべき配車最適化エンジンへのリソースが分散し、開発期間・費用の両面で非効率が生じます。開発会社を選定する際は、Node.js、TypeScript、React、Next.js、AWS、GCPといったモダンな技術スタックを採用し、将来的な保守人材の確保がしやすいかどうかも確認しておくべき点です。

配車最適化エンジンをフルスクラッチで成功させるための前提条件が、プロジェクト全体費用の40〜60%をデータの準備・整備に予算化できるかという点です。住所データの不均一なフォーマット、ジオコードの欠落、重複登録といった品質の低いデータをそのままアルゴリズムに投入すると、期待した最適化効果が得られないばかりか、現場からの信頼を失うリスクもあります。データ準備を軽視せず適切に投資した組織は、本番環境でのROI達成を6〜12ヶ月早く実現できるという知見もあります。実際の費用感としては、中規模（複数拠点・API連携あり）で初期費用1,000万円〜3,000万円・開発期間6〜12ヶ月、大規模（複数倉庫・高度自動化・多拠点）で初期費用3,000万円〜1億円超・開発期間12ヶ月以上が目安であり、大手企業では独自の「配車計画テーブル」構築のみで初回開発費1億円（納期1年）という提示を受けた事例も存在します。フルスクラッチという大きな投資判断をする以上、アルゴリズム開発そのものと同等かそれ以上にデータ基盤への投資を織り込んでおく必要があります。

フルスクラッチ開発を成功させる体制・依頼先選定

ここまで見てきた判断基準を踏まえると、TMSのリアーキテクチャをフルスクラッチで成功させるためには、専門人材の体制構築と依頼先選定の両方をしっかり固めることが欠かせません。

フルスクラッチによるマイクロサービス構築には、ドメインエキスパート（ドメイン駆動設計による境界分離を担う）、プラットフォームエンジニア（Kubernetes・サービスメッシュ・CI/CDの運用を担う）、SRE（分散トレーシングによる障害局所化を担う）という専門人材が必須です。配車最適化エンジンの場合はさらに、配車アルゴリズムや機械学習モデルを扱う配車最適化（AI・データ）エンジニアも必要になります。これらの人材は市場全体で「極めて希少で高価」とされており、開発組織の規模が10〜15人未満の場合、高価な専門エンジニアがインフラ維持に忙殺されてしまい、ビジネス価値を生み出す前にコストだけが先行するリスクがあります。独立した小規模チームが各マイクロサービスを自律的に運用できる体制（いわゆるコンウェイの法則に沿った組織設計）が整うまでは、フルスクラッチによる本格的なマイクロサービス化は見送るべきという指摘も踏まえ、自社の体制成熟度を客観的に評価しておくことが重要です。

依頼先を選ぶ際は、単にフルスクラッチでシステムを開発できる技術力だけでなく、ドメイン駆動設計によるコア業務ドメインとコモディティ領域の切り分け、ストラングラーフィグパターンによる段階的な移行設計、そして配車最適化エンジンやGPS・テレマティクスストリーム処理基盤といった高難度コンポーネントの構築実績があるかを確認することが重要です。あわせて、要件定義からの伴走と段階拡張（アジャイル・MVP）の提案力、既存基幹システム・WMSとのAPI/EDI連携や泥臭いデータ移行・マスタ整備のノウハウ、週次定例等の密なコミュニケーション体制を持っているかも見極めのポイントです。契約前の提案段階で、規模閾値（1日のリクエスト量・開発組織規模）を踏まえたうえでフルスクラッチが本当に妥当かを客観的に助言してくれるかどうかも、信頼できるパートナーを見極める材料になります。プロジェクト開始後は、コア業務ドメインへの投資配分とコモディティ領域のAPI活用方針を定例会議で継続的に確認し、限られた予算と希少な専門人材を最も価値の高い領域に集中投下できているかを常にモニタリングすることが、フルスクラッチ開発を成功に導く鍵です。

まとめ

本記事では、TMSのリアーキテクチャにおけるフルスクラッチ・オーダーメイド開発について、フルスクラッチ投資を検討する論点の確認、フルスクラッチを選ぶべきかの判断基準、GPS・テレマティクスストリーム処理基盤のオーダーメイド開発、配車最適化エンジンのオーダーメイド開発、そして開発を成功させる体制・依頼先選定を体系的に解説しました。1日100万リクエスト・エンジニア50名以上という規模閾値、TCOの50%ルール、モノリス比約40%高い初期コストに加え、多拠点・特殊な配車ロジック・繁忙期スケーラビリティというTMS特有の判断基準が示す通り、フルスクラッチによるマイクロサービス化はアジリティ・スケーラビリティと引き換えに高度な運用基盤コストと希少人材確保という初期投資を伴う判断です。配車最適化エンジンとGPS・テレマティクスストリーム処理基盤というコア業務ドメインにフルスクラッチ投資を集中させ、体制成熟度を見極めながら、Bounded Context単位の切り分けと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を創業。