配車最適化エンジンの分離を検討し始めても、どこから着手すべきか、一括で作り直すべきか段階的に進めるべきか、社内に十分な体制があるのかを整理しないまま進めると、途中で頓挫しやすくなります。TMSのリアーキテクチャの選定とは、既存TMSのどの技術的負債から着手し、どの進め方・評価軸・依頼先で構造刷新を実行するかを見極める作業です。TMSのモダナイゼーションのように5手法の中から総論的に選ぶ話ではなく、モノリスからマイクロサービスへの分解という1テーマに絞って進め方を決める点が特徴です。
本記事では、着手前に整理すべき自社の課題、リアーキテクチャの3つの進め方、判断すべき評価軸、開発会社・依頼先選定のポイント、PoC・アーキテクチャスパイクの進め方、失敗を避ける方法を解説します。配車最適化エンジンとGPS/テレマティクスストリーム処理基盤の分離を検討するIT部門・アーキテクトの方が、自社に合った進め方を絞り込めるよう実務の流れに沿って整理します。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・TMSのリアーキテクチャの完全ガイド
TMSのリアーキテクチャ着手前に整理すべき自社の課題
最初に行うべきは、製品資料を集めることではなく、既存TMSのどこにアーキテクチャ上の技術的負債が集中しているかを特定することです。負債の所在を一文で説明できれば、進め方・評価軸・依頼先を絞り込みやすくなります。
配車ロジックの密結合化を確認します
配車計画・ルート最適化ロジックがユーザー管理や請求処理と同じモノリスの中に密結合したまま存在していると、ロジックの微調整のたびに全体のリグレッションテストとリリース調整が必要になります。デプロイ頻度、1回のリリースにかかる調整工数、配車ロジック変更の待ち行列の長さを確認すると、密結合がどの程度ボトルネックになっているかが見えてきます。
GPS/テレマティクス処理基盤の逼迫を確認します
車両台数やセンサー項目数の増加でGPS・テレマティクスデータの処理が遅延し始めている場合は、ストリーム処理基盤の逼迫が課題です。現在のクラウド集中処理でレイテンシと帯域コストがどこまで膨らんでいるか、ルート逸脱検知などの即時応答性がどの程度遅れているかを数値で押さえておくと、エッジコンピューティングへの投資判断がしやすくなります。両方の課題が併存する企業も多く、その場合はどちらを先に着手するかの優先順位づけが選定の出発点になります。既存の受注管理システム(OMS)やWMSとのデータ連携でフォーマット不一致やAPIエラーによる手入力・二重入力が常態化している場合も、アーキテクチャ上の技術的負債として同じ棚卸しの対象に含めておくと、後工程での認識違いを防げます。
リアーキテクチャの3つの進め方
主な進め方は、ストラングラーフィグによる段階移行型、一括再構築するビッグバン型、コア・サテライト構成のハイブリッド型の3つです。どれを選ぶかは、事業を止められる時間の余裕と、社内のリスク許容度によって変わります。
ストラングラーフィグ段階移行型
APIゲートウェイでレガシーモノリスの周囲に新サービスを稼働させ、カナリアリリースやフィーチャートグルで「まずはA営業所の5台のトラックのみ」といった小規模範囲から適用し、旧システムと並行稼働させながら6〜18ヶ月かけて拡大していく方法です。輸送業務を止められない企業が現実的に選びやすい進め方ですが、旧システムと新サービスが並行稼働する期間の運用負荷が増える点は織り込んでおく必要があります。
一括再構築型とコア・サテライト型
一括再構築型は、新アーキテクチャを一から作り込み、一定期間の並行稼働を経て一斉に切り替える方法で、境界設計さえ固まっていれば移行期間の複雑さを抑えられる半面、切り替え日の失敗が業務全体に波及するリスクが大きくなります。コア・サテライト型は、配車最適化エンジンのような競争優位性に直結するコア業務ドメインだけをフルスクラッチで作り込み、認証や通知といったコモディティ領域は既存システムやSaaSを残してAPI連携する構成です。すべてを作り直す必要がない分、投資を絞り込みやすいアプローチといえます。どの型を選ぶ場合でも、GPS/テレマティクスストリーム処理基盤と配車最適化エンジンという2つの技術要素のどちらを先に着手するかによって、必要な体制やスケジュールの前提が変わる点は共通して押さえておく必要があります。
リアーキテクチャを判断する評価軸
進め方を決めたら、実際にリアーキテクチャへ踏み切るべきかを、規模・コスト・要件の3方向から評価します。印象や流行だけで判断せず、自社の数値に照らして確認することが重要です。
規模閾値とTCOの50%ルールを確認します
マイクロサービス化が正当化されやすい目安は「1日100万リクエスト以上かつエンジニア50名以上」で、これを下回ると運用オーバーヘッドがメリットを上回りがちです。加えて、既存パッケージ・SaaSのカスタマイズ費用が本体価格の50%を超える場合は、フルスクラッチの方が長期的にコスト効率が良いと判断される「50%ルール」も、社内の見積もりと突き合わせて確認する価値があります。初期コストはモノリス比で約40%高くなる前提のうえで、インフラコストは短期的に増加しつつも長期では15〜35%削減、保守費用は30〜50%低下、TCO全体で20〜45%削減、投資回収期間は12〜36ヶ月が標準という推移も、社内稟議の説明材料として押さえておくと判断しやすくなります。
外部連携要件とスケーラビリティ要求を確認します
倉庫・営業所3拠点以上、EC・複数チャネル連携、古い基幹システムとのAPI連携、自動倉庫等の物流機器連携、取引先ごとに異なるEDIフォーマットという5つの複雑な外部連携要件のうち3つ以上該当する場合、標準パッケージでは対応が難しくスクラッチ開発が視野に入ります。建材の重量物制約、医薬品の厳密なトレーサビリティ・温度帯管理、複数キャリアとの混載といった極めて特殊な配車ロジックがある企業も同様です。また、お中元や年末商戦のように平時の3〜5倍の配送量が発生し、配車計算の処理能力を自社タイミングでスケールアウトさせたい企業では、独立サービス化が強みを発揮します。これらの条件に該当する数が少ないうちは、無理にすべてを分離せず、負債の大きいコンポーネントから着手する方が投資対効果を保ちやすくなります。
評価軸を数値化する際は、担当者ごとの主観で採点するのではなく、確認方法まで統一しておくことが重要です。たとえば「外部連携に対応できる」という回答だけでは、API連携なのかCSVの手動出力なのか、障害時にどちらが復旧を担うのかが分かりません。デモで確認したのか、仕様書で確認したのか、契約条項で確認したのかを記録に残し、未確認の項目は点数を付けずに保留にすることで、営業説明の分かりやすさに評価が引っ張られることを防げます。
開発会社・依頼先選定のポイント
進め方と評価軸が固まったら、実際に構造刷新を任せる開発会社を選びます。機能一覧や実績数の多さよりも、自社の技術的負債にどう向き合ってくれるかを基準に絞り込みます。
段階拡張の実績とモダンな技術スタックを確認します
要件定義から伴走し、アジャイル・MVPによる段階拡張を実際に進めた実績があるかを確認します。あわせて、Node.js、TypeScript、React、Next.js、AWS、GCPといったモダンな技術スタックを採用しているかも重要です。将来の保守人材を確保しやすいかどうかが、長期運用のしやすさに直結します。提案書に並ぶ実績社数や機能一覧だけで判断せず、自社と近い規模・業種でストラングラーフィグ型の段階移行を実際に完遂した経験があるかを、具体的な工程やつまずいた点まで踏み込んでヒアリングすることが有効です。
密なコミュニケーション体制と基幹連携の経験を確認します
既存の基幹システムやWMSとのAPI・EDI連携、そして泥臭いデータ移行・マスタ整備のノウハウを持っているかを確認します。週次定例などの密なコミュニケーション体制が組めるか、AI駆動開発などによって開発期間を短縮できる体制があるかも、依頼先を比較する材料になります。費用感の目安としては、TMSドメインの中規模スクラッチ開発で初期費用1,000万円〜3,000万円・開発期間6〜12ヶ月、大規模で初期費用3,000万円〜1億円超・開発期間12ヶ月以上とされ、独自の配車計画テーブル構築のみで初回開発費1億円(納期1年)の見積もり事例も存在します。SRE・インフラエンジニアは月額80万〜130万円、PM・アーキテクトは月額80万〜140万円(大規模案件では最大220万円)、配送最適化(配車)AI・データエンジニアは月額150万〜250万円という希少人材相場も、体制コストの見積もりに含めておく必要があります。加えて、独立した配車エンジンの背後で稼働し続ける地図APIのライセンス費用(ゼンリンAPIの場合、配車計画APIで月額55,000円〜220,000円程度)、デジタコやハンディターミナルとの独自連携インターフェース開発費用(50万円〜500万円程度)、車両・ドライバーごとの通信端末ランニングコスト(スマホアプリで月額1,500円程度、車載デバイスで月額2,200円程度)といったTMS特有の周辺コストも、依頼先選定の見積もり比較に含めておくと、導入後の想定外の費用増を避けやすくなります。フルスクラッチ開発の保守費用は、中規模システムで月額10万円〜30万円、大規模システムで月額30万円〜100万円が目安です。
PoC・アーキテクチャスパイクの進め方
依頼先の候補を絞ったら、本開発の前にPoC・アーキテクチャスパイクで技術的不確実性を解消します。資料や提案書だけで判断せず、実際に動くものを見て評価します。数日から数週間の使い捨てコードで実現可能性を検証するアーキテクチャスパイクを組み合わせると、本開発に入る前に配車エンジン分離時のレスポンスタイムのような技術的な不安要素をあらかじめ潰しておけます。
垂直スライスでPoCの対象を絞ります
「特定エリアの配車最適化処理」や「一部車両のGPS・テレマティクスデータ収集基盤」など、DB・API・インフラまでを一気通貫で切り出した最小単位を最初のモジュールに選びます。PoC単体の期間は3ヶ月〜、費用感は100万円〜500万円程度が目安とされ、配車エンジン分離時のレスポンスタイムや数千台規模のGPSストリーム処理のスケーラビリティ検証が中心になります。
Go/No-Go基準を最初の四半期で判定します
パイロットフェーズにあたる最初の四半期で、配車最適化エンジンがAPI・サービスとして明確に分離できているか、CI/CDパイプラインが初期段階で確立できているか、最初のコンポーネントが他システムに悪影響なく独立稼働できているか、開発速度が向上し始めているかの4点を確認します。いずれかが未達であればNo-Goと判断し、ドメイン境界設計やDevOps体制の見直しを依頼先と行います。
リアーキテクチャの失敗を避ける方法
よくある失敗は、境界設計を急いで進めることと、分散を目的化してしまうことです。どちらも、性急にマイクロサービス化を進めた結果として起こりやすい落とし穴です。
分散型モノリス化を避けます
DDDによる境界定義が甘いままサービスを分割すると、サービス間が密結合になり、一つの変更に複数サービスの同時リリースが必要になる「分散型モノリス」化を招きます。境界設計にかける時間を惜しまないことが、最大の遅延リスクを避ける最も確実な方法です。
過剰な分散を目的化しないようにします
マイクロサービスとサーバーレスで構築した監視システムがデータ転送コストの膨張を招き、モジュラーモノリスへ統合し直すことでインフラコストを90%削減したという反面教師の事例もあります。規模閾値を下回るのに流行を理由に細かく分割すると、運用オーバーヘッドがメリットを上回りやすくなります。具体的な技術要素の候補を確認したい場合は、TMSのリアーキテクチャのパッケージ・クラウド製品一覧を参照すると、比較の土台にしやすくなります。
TMSのリアーキテクチャ選定前に確認しておきたいポイント
候補となる進め方や依頼先を絞った後も、体制、予算、期間の観点から見落としがないかを確認しておくと、着手後の想定外を減らせます。特に地図APIや車載デバイス連携といったTMS特有の周辺コストは見落とされがちなため、あわせて確認しておく必要があります。
開発チームが少人数でも進められますか
開発チームが10〜15名未満の場合、サービスメッシュなどの複雑インフラを維持する運用オーバーヘッドがメリットを上回りやすいのが実情です。配車最適化エンジンなど負債が最も深刻な1コンポーネントに対象を絞り、外部の専門人材と組んで部分的に着手する方法が現実的です。
すべてをフルスクラッチにする必要がありますか
必要ありません。コア・サテライト型のように、競争優位性に直結する配車最適化エンジンだけをフルスクラッチで作り込み、それ以外は既存システムやSaaSを残す構成が現実的な選択肢です。TCOの50%ルールや外部連携要件の該当数を基準に、どこまでを作り直すかを線引きします。
どのくらいの期間を見込む必要がありますか
パイロット(PoC・技術検証)は3〜6ヶ月、MVPは6〜12ヶ月、本番移行は12〜18ヶ月が目安で、大規模なビジネスドメイン再構築を伴う全体移行は通常12〜18ヶ月かかります。データクレンジングへの先行投資次第で後続フェーズの期間が短縮される場合もあるため、初期段階の準備工程を軽視しないことが重要です。
まとめ
TMSのリアーキテクチャの選定では、配車ロジックの密結合化とGPS/テレマティクス処理基盤の逼迫という自社の技術的負債を特定し、ストラングラーフィグ型・一括再構築型・コア・サテライト型から進め方を選びます。そのうえで規模閾値・TCOの50%ルール・外部連携要件・スケーラビリティ要求という評価軸で判断し、実在するモジュールを使ったPoCでGo/No-Go基準を確認することが重要です。
依頼先はモダンな技術スタックと基幹連携の経験で選びます
機能数や知名度ではなく、要件定義からの伴走実績、モダンな技術スタック、既存基幹システム・WMSとの連携経験、密なコミュニケーション体制を基準に依頼先を絞り込みます。分散を目的化せず、規模閾値とTCOの50%ルールに照らして必要な範囲だけを構造刷新することが、投資対効果を保つ鍵になります。
まずは技術的負債の棚卸しから始めます
配車ロジックの密結合、GPS処理基盤の逼迫、監視オーバーヘッドの増加のうち、自社で最も深刻な項目を洗い出すことが選定の出発点です。既製パッケージやSaaSのカスタマイズでは吸収しきれない独自の配車ロジックや多拠点管理の要件がある場合、フルスクラッチによる構造刷新が有力な選択肢になります。riplaはフルスクラッチ開発の立場から、進め方の選定支援から配車最適化エンジンの分離設計、既存基幹システムとの連携までを一貫して支援しています。
▼全体ガイドの記事
・TMSのリアーキテクチャの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。