TMSのリアーキテクチャの発注/外注/依頼/委託方法について

TMSのリアーキテクチャを発注・外注するときは、現状と要件を整理し、RFP（提案依頼書）で複数社に打診してから、提案を比べて契約します。この順に進めると、見積もりの精度と提案の質を高めやすくなります。

全体像は、TMSのリアーキテクチャの完全ガイドもご覧ください。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

TMSのリアーキテクチャを外注・委託する前に押さえる全体像

リアーキテクチャは、単なる入れ替えや改修とは異なります。範囲が曖昧だと、ベンダーとの認識がずれ、見積もりや提案も的外れになりやすくなります。そのため、発注先を比べる前に、自社が外注する作業の範囲を明確にします。

リアーキテクチャとリプレイス・改修の違い

発注側は、改修・リプレイスとリアーキテクチャの違いを押さえたうえで、発注範囲を決めます。

• リアーキテクチャ：複雑に絡み合う配車ロジックやデータ構造を整理し、内部構造から設計し直して、保守性と拡張性を高めます。
• 改修・リプレイス：機能を保ったままUIを新しくする場合に適します。

一方、新しい運賃ルールや動態管理AIの追加、クラウド化では、内部構造の見直しまで必要になるため、リアーキテクチャが必要です。

発注時にはまず、求める作り替えの深さを決めて、委託先へ伝えます。深さが決まって初めて、委託先は規模と費用を見積もれます。

外注・委託が現実的な選択肢になる理由

TMSのリアーキテクチャは、内製で完遂できる企業が限られます。そのため、外注したときに誰が何を担うかと、どんな専門性が必要かを先に整理しておきます。

• 必要な専門性：配車・運賃・動態管理の知識、クラウド設計、データ移行、WMS・ERP・EDI連携まで、幅広い領域が求められます。
• 自社の役割：多くの企業は、要件整理とプロジェクト管理に専念します。幅広い専門性を社内だけで揃えるのは、人材の確保という面でも現実的ではありません。
• 委託先の役割：技術と移行のノウハウを持ち寄り、現場と協力してシステムを組み上げます。

発注側は、委託先と役割を分けながら関わり続けます。発注の進め方と関係づくりが、プロジェクトの成否を左右するからです。

発注先（委託先）の種類とそれぞれの特徴

TMSの発注先は、得意な領域や費用感がそれぞれ異なります。

自社の規模と業務の独自性に合わせて選べるよう、代表的な3種類を比べます。

SIer・システム開発会社への委託

SIer（システムインテグレーター）や開発会社は、もっとも一般的な発注先です。選ぶ際は、任せられる範囲、向く案件と費用、選定の軸を順に確認します。

• 任せられる範囲：要件定義から設計・開発・テスト・運用保守まで一貫して依頼できます。
• 向く案件と費用：独自の配車や運賃計算を含むフルスクラッチに向き、数千万円から億円規模になることもあります。
• 選定の軸：物流・運輸の開発実績を確認します。業界の知識があれば、2024年問題や動態管理の要件を伝えやすくなります。

自社業務に合わせてシステムを組める点が強みです。

とくに物流案件に詳しい会社なら、言語化しきれない課題も提案に反映されることが期待できます。

TMSパッケージ・SaaSベンダーへの委託

標準機能を備えたTMSパッケージやSaaSは、初期投資を抑え、導入を早めたい場合の選択肢になります。まず費用と適合条件を確認します。

• 導入費用：パッケージは数百万円から数千万円、クラウド型SaaSは月額数万円から提供されているものもあります。
• 導入の利点：完成済みの機能を使えるぶん、フルスクラッチより初期投資を抑えられ、導入も早まります。
• 適合性の確認：3拠点以上、API非対応の基幹システム、取引先ごとに異なる伝票やEDI形式があると、追加費用の要因になります。

標準機能で業務を吸収できない条件が重なると、カスタマイズ費用がかさみ、フルスクラッチ相当になる可能性があります。そのため、自社業務の独自性を先に見極めることが、委託先選びの分かれ目になります。

ITコンサル・一気通貫型パートナーへの委託

委託先は、構想段階から支援が必要かどうか、特定の機能だけを頼むかどうかで使い分けます。

• 構想段階から相談：ITコンサルや一気通貫型パートナーなら、要件が固まる前から業務改善とシステム化を一緒に設計できます。
• 特定機能や小規模改修：なお、比較として、フリーランスや小規模開発会社は費用を抑えやすい一方で、大規模開発や長期の保守には限界があります。

リアーキテクチャは、構想段階の質が成否を左右します。そのうえで、プロジェクトの規模と期間に応じて依頼先を決めます。

発注・外注の進め方（依頼から契約までの流れ）

依頼から契約までの進め方によって、見積もりの精度や提案の質が変わります。一般的な流れを、段階ごとに順に見ていきます。

現状の棚卸しと要件の整理

発注前には、自社の現状と要件を、棚卸しと優先づけの2つの面から整理します。

• 現状の棚卸し：利用中のシステムの不満点、Excelや紙で運用している業務、連携先を洗い出します。
• 要件の優先づけ：必須要件（MUST）と希望要件（WANT）に分け、譲れない条件を明確にします。

要件を曖昧にしたままベンダーへ任せると、提案は抽象的になり、見積もりも「一式」になりがちです。

現場の困りごとを具体化すれば、提案の精度が上がります。

自社だけでは整理しにくいときは、上流工程からコンサルに伴走してもらう方法もあります。

RFP（提案依頼書）の作成と複数社への打診

RFP（提案依頼書）は、各社の提案を同じ条件で比べるために作ります。そのため、記載する事項と打診先の条件をそろえておきます。

• 記載する情報：目的と対象業務、必須と希望の要件を中心に、想定予算と納期、既存システムと連携先までまとめます。
• 打診する社数：3社から5社程度が現実的です。多すぎると比較しきれず、少なすぎると相場をつかみにくくなります。
• 候補の確認：TMSや物流システムの実績を見て、領域の違う会社を外しておくと、評価の手間を抑えられます。

提案比較・ベンダー選定と契約形態の決定

提案は金額だけでなく、要件の理解、内容の具体性、管理体制、保守サポートを見て総合的に比べます。最安値の提案が最良とは限りません。

連携費用やカスタマイズ費用が見積もりに含まれる範囲は会社ごとに差が出るため、後述する費用項目と照らして確認します。

要件と成果物が明確であれば、完成に責任を負う請負契約が向いています。一方で、要件を固めながら柔軟に進めるなら、工数ベースの準委任契約が適することが多いです。

両契約は、責任の範囲と費用の精算方法が異なります。そのため、プロジェクトに合わせて選び、検収条件と瑕疵対応の範囲を契約書に記載します。

1. 現状と必須・希望要件を整理する
2. 要件をRFPにまとめ、3社から5社程度へ打診する
3. 提案内容と費用を比較し、委託先を選ぶ
4. 契約形態を決め、検収と瑕疵対応を明記する

発注前に準備すべきドキュメントと社内体制

事前の準備が整うほど、提案の精度は上がり、開発中の手戻りも減ります。

発注前に、必要な資料と推進体制を整えておきます。

要件定義書・現行業務フローの整理

発注前に用意しておく資料と、現場の実態をつかむ方法を整理します。

• 準備する資料：現行業務フロー図と要件定義書を中心に、機能・連携先の一覧や移行データの一覧をそろえます。
• マスタデータ：Excelや紙で分散管理している顧客マスタや運賃ルールを整理し、整備と移行の担当者、基準、期限を決めます。
• 現場へのヒアリング：配車担当者の暗黙知や例外処理を文書にまとめ、ベンダーと共有します。

マスタの担当や基準、期限が決まらないと、データ移行が停滞します。

業務の実態をベンダーと共有すれば、現場で使えないシステムになるリスクを減らせます。

現場を巻き込むプロジェクトチームの編成

発注側は、現場の担当者と意思決定者を含めた体制を整えます。

• 現場メンバーを加える：情報システム部門だけでは実態からずれやすいため、配車担当者やドライバーの代表にも参加してもらいます。
• 要件定義から参加する：ベンダーへ伝える情報の精度が上がり、完成したシステムへの納得感も高まります。
• 役割を決める：意思決定者と現場窓口を、あらかじめ明確にします。

要件定義から参加すると『自分たちが関わってつくった』という意識が生まれ、定着を後押しします。

外注で失敗しないためのTMS特有のチェックポイント

TMSには、一般的なシステム発注では見落とされやすい注意点があります。費用、業務要件、サポートを確認しておくと、見積もりの妥当性を判断しやすくなり、稼働後のトラブルも防ぎやすくなります。

連携・カスタマイズの「隠れコスト」の見積もり

見積もりでは、初期費用に含まれる範囲と、稼働後も続く費用を分けて確認します。

• システム連携：基幹システムやバーコード・ハンディ端末との接続費用が、本体価格に含まれるかを確認します。
• 独自仕様の対応：伝票形式や運賃ルールのカスタマイズは、費用を大きく左右する要因になります。
• 継続費用：デジタル地図基盤のライセンス料、AI再学習の工数、並行運用中の入力支援要員の人件費も含めて、TCOで比べます。

基幹システムとの連携開発は100万円から500万円、バーコードやハンディ端末との連携も50万円から500万円になることがあります。本体が500万円でも、連携に1,000万円かかった例は珍しくありません。さらに、独自伝票や複雑な運賃ルールでは、カスタマイズが数千万円規模に達することもあります。

2024年問題・運賃計算など業務要件の伝達

TMSの要件では、法令対応、運賃計算、配送状況の反映範囲を、委託先に明示します。

• 2024年問題：年間960時間の時間外労働の上限を踏まえ、配車計画の段階で拘束時間を超えるルートを自動で計算して警告する機能を検討します。
• 荷待ち時間：削減に向けて、バース予約機能との連携を要件に含めます。
• 運賃計算：距離や時間、冷蔵冷凍車の扱いから、深夜・早朝・休日の割増や距離逓減制まで、自動化する範囲を決めます。
• 動態管理：渋滞や天候を反映した経路の再計算を検討します。配送時間を平均8〜12%短縮できるとの試算があります。

要件が曖昧だと、後から追加費用が発生しがちです。上の試算は、投資対効果を考えるときの判断材料になります。

緊急時のサポート体制とSLAの確認

休日や夜間の障害は、配車の停止や大規模な配送遅延につながります。そのため、稼働後の支援も、見積もりの安さやデモと合わせて確認します。

• 連絡体制：休日・夜間のオンコール対応と、障害時のエスカレーションルートを定めます。
• SLA（サービス品質保証）：一次対応時間と復旧目標時間を取り決め、対応範囲も確認します。
• 停止時の備え：現場の判断力の低下や社内の負担に備えて、手動運用の手順も委託先と決めておきます。

支援範囲が曖昧なままだと、対応が平日日中だけだったと後から分かり、現場や情報システム部門に負担がかかることがあります。

発注後の進め方と「お蔵入り」を防ぐ工夫

契約後も、現場で使われなければ投資が無駄になります。

進め方と定着支援を工夫して、「お蔵入り」を防ぎます。

スモールスタートと段階発注という現実解

全社一括で数千万円規模を発注すると、リスクが大きくなりがちです。そこで、移行と契約を段階的に進めます。

1. 移行方法を選ぶ：一括移行（ビッグバン）、機能ごとの段階移行、新旧並行移行、パイロット移行から選び、それぞれのメリットとデメリットを比べます。
2. 小規模に試す：1拠点や数台の車両で効果と課題を確かめてから、全体へ展開します。
3. 発注範囲を広げる：1業務、1拠点から始め、成果を見ながら対象を広げ、リリース後も機能を拡張していきます。
4. 長期の支援先を選ぶ：要件が固まる前から相談でき、継続して伴走してくれる委託先は、業界の変化に対応しやすくなります。

現場の定着とチェンジマネジメント

現場が納得できるかどうかで、システムの定着は左右されます。

不安への対応と定着支援は、発注時から一緒に考えておきます。

• 配車担当者の不安：AIでは、勘でしか裁けない無理な配車に対応できないのではという懸念に向き合います。
• ドライバーの懸念：GPSで監視されることへの不安や、入力が増えても現場の負担が減らないのではという懸念を受け止めます。
• 定着支援：ITリテラシーに配慮したUI/UXを用意し、教育の機会を設けたうえで、パイロットで成功体験を積んでもらいます。

残業や請求漏れの減少を現場が実感できれば、受け入れにつながります。こうした定着支援を担えるかどうかも、委託先を選ぶときの視点になります。

まとめ

TMSのリアーキテクチャを発注するときは、作り替えの範囲を決めたうえで、SIer・パッケージベンダー・一気通貫型パートナーの特徴を比べます。

現状の整理から、RFPの作成、提案の比較、契約まで順に進めます。そのうえで、要件定義書や業務フロー、マスタデータも事前に用意します。

連携やカスタマイズの費用、2024年問題や運賃計算、緊急時のサポート体制は、発注前に確認しておきます。

段階的に発注し、現場の定着に取り組むことが、お蔵入りを防ぎ、投資を成果につなげる助けになります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。