TMS改修の選定は、製品や依頼先を探す前に、どの業務で支障が出ていて何を変えたいのかを特定することから始まります。課題が定まったら、改修方式と担当体制を決め、候補各社へ同一条件で相談します。
課題の範囲が見えると、保守契約内の修正、専門会社への個別委託、クラウド型TMSへの移行を比べやすくなります。背景や全体の進め方は、下の全体ガイドで確認できます。
▼全体ガイドの記事
・TMS改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TMS改修前に整理すべき自社の課題
最初に確かめるのは、配車ロジック、帳票・伝票、外部連携のどこで問題が起きているかです。問題を具体的に説明できると、相談先の種類と見積もり依頼に必要な条件を選びやすくなります。
費用感とスケジュール感のずれ
帳票の小さな修正に大きな予算を見込んだり、配車ロジックの変更は安く済むと考えたりすると、依頼先との間で費用や期間の期待が食い違います。
一般的な目安では、軽微な修正は数万円〜数十万円で2〜4週間、特定車両向けの配車ロジック調整は数十万円〜数百万円で数週間〜3ヶ月程度です。相談の前に、自社の要望がどちらに近いかを整理しておきます。
過去1年程度の改修について、依頼内容、請求額、対応期間を一覧にすると、自社の想定と実績を照らし合わせられます。記録が見当たらなければ、現行ベンダーに過去の請求内訳を確認します。
ベンダーロックインと属人化の度合いの切り分け
現行ベンダー以外に頼めるか分からないなら、ベンダーロックインが疑われます。複数社へ相談できても仕様書がなく、各社が調査から始める状態なら、仕様の属人化やブラックボックス化が中心の課題です。原因によって必要な対策が違うため、両者を分けて選定条件に反映します。
仕様書を現行ベンダーだけが保管していたり、特定の開発担当者しか仕様を把握していなかったりすると、契約上の自由があっても他社への移行は容易ではありません。まずは、設計や運用の情報がどこまで文書になっているかを調べます。
TMS改修の3つのアプローチ
改修の方式は、現行ベンダーの保守契約の中で済ませるか、専門会社へ委託するか、SaaSへ移すかで分かれます。方式ごとに向いている課題の範囲が違うため、課題と照らし合わせると候補を絞りやすくなります。
- 保守契約内で修正：小規模な変更を現行ベンダーに依頼する場合
- 専門会社へ個別委託：既存システムの仕様を共有して、個別に改修を進める場合
- SaaSへ機能を移行：課題領域を、クラウド型TMSの標準機能で置き換える場合
たとえば帳票は保守契約内で修正し、複雑な配車ロジックは専門会社へ任せる形が考えられます。全業務を同じ方式にそろえるより、課題の性質と既存環境に応じて担当を分けるほうが現実的です。
保守契約内改修型と個別委託改修型
保守契約内改修型は、月額契約やチケット・ポイントの範囲で小規模な修正を依頼する方式です。手続きは比較的簡単です。ただし、契約上の対象範囲が曖昧だと、軽微な変更にも5万〜12万円程度の最低作業料金がかかる場合があります。
個別委託改修型は、別の専門会社へ案件単位で発注する方法です。そのため、依頼先が現行環境を把握できるよう、仕様書などの情報を用意しておく必要があります。
依頼側は保守内と考えていても、ベンダーが仕様変更として別料金を見積もることがあります。そこで、契約更新時に対象業務を一つずつ確認し、保守に含む作業と追加料金になる作業を合意しておきます。
SaaS機能追加・移行型
SaaS機能追加・移行型は、課題のある業務をクラウド型TMSへ移し、それ以外では既存システムを継続利用する方法です。法改正対応が標準更新に含まれる場合は、個別保守の負担を抑えられます。
一方で、移行後は二重運用や既存システムとのデータ連携を検討しなければなりません。移行対象を決めたら、既存側からSaaSへ渡す情報と、SaaSで確定して既存側へ戻す情報を両方向から洗い出します。連携を後回しにすると、現場で同じ内容を二度入力する運用が残るおそれがあります。
依頼先・手法を比較する評価軸
候補を比べるときは、要件の理解度と既存技術との適合を、まず確かめます。そのうえで、費用の決まり方と納期、保守の引き継ぎを見ます。
他システムとの連携と将来の拡張性も、あわせて確認します。同じ質問と前提をそろえておけば、提案の印象だけで判断するのを避けられます。
技術的な適合性と費用体系
技術面では、利用言語、データベース、インフラ構成を確認したうえで見積もっているかを尋ねます。既存コードやデータ構造の調査を提案する会社なら、着手後の制約を事前につかみやすくなります。
費用は、月額固定、従量・時間課金、チケット・ポイント制のどれかを確認します。小さな修正が続いた場合の総額も、あわせて比べておきます。
資料やソースコードを見ないまま対応可能と答える候補には、その判断の根拠を確かめます。見積もり時に何を調査し、どの制約を想定したのかを具体的に聞けば、後から追加費用や納期変更が生じる可能性を比べられます。
スケジュール対応・保守引き継ぎ・拡張性
進行方法は、2〜4週間単位で見直すアジャイル型に対応できるか、従来型のウォーターフォールを前提とするかを確かめます。改修後の保守担当と引き継ぐ資料の範囲も、あわせて決めておきます。
さらに、次の対象領域や外部システム連携へ広げる場合に、同じ構成で対応できるかを確認します。
設計書やテスト結果の保管先と、次回の改修で参照する方法まで決めておくと、担当者が交代しても情報を引き継げます。逆に、資料が残らなければ、次の依頼で同じ調査を繰り返すことになります。
内製・外部委託・ハイブリッドの選び分け
実行体制は、配車や帳票などの業務知識を誰が持つか、改修後の運用を誰が担うかも含めて選びます。開発人員の有無だけで決めるものではありません。
内製と外部委託の判断基準
開発人員がいて、配車ルールなど現場固有の判断も理解しているなら、社内で改修を進めやすいでしょう。反対に、エンジニアがいない、または現行技術に詳しい担当者が不在なら、仕様の調査から頼める外部委託が候補になります。人員と知識の両面から、実行可能性を見極めます。
内製で進める場合は、担当者が別業務と兼務するときの作業時間を先に確保します。空き時間だけで進めると、検証が足りないままリリースし、現場で問題が表面化する可能性があります。
ハイブリッドにおける要件定義と実装の分担
ハイブリッドでは、自社が要件を整理し、外部会社が実装とテストを担います。現場の知識を開発側へ正確に渡すため、依頼前に要件を文書にまとめます。
特定車両の配車ルールなど、現場の判断が実装に影響する改修では、役割分担を活かせます。
配車ルールの例外は、抽象的な説明だけでなく、実際の配送データに沿った例で示します。入力と期待する結果を共有できれば、依頼側と実装側の解釈違いを減らせます。
見積もり依頼とPoCの進め方
見積もりの比較には、必要機能だけでなく対象範囲と実際の運用条件を伝えることが欠かせません。実現性に不確かさが残る場合は、モックアップやPoCで論点を確かめてから本開発を判断します。
見積もり依頼に明記する対象範囲と現場条件
依頼書には、対象車両や営業所、現行ルールを書きます。必要な例外対応とシステム構成、希望時期も記します。
「配車を改善したい」だけでなく、「大型車が通れない道路を除外する」のように変更内容まで具体化すると、各社が同じ前提で見積もれます。
導入時期と過去の改修履歴も共有します。変更を重ねたシステムでは既存機能との依存関係が見えにくいことがあるため、履歴があれば候補各社が調査範囲や制約を検討しやすくなります。
PoCの検証対象の絞り方
PoCでは検証テーマを1つに絞り、画面の使いやすさと処理ロジックを別々に評価します。費用は30万〜300万円、期間は1〜8週間程度が目安です。本開発費の10〜20%程度を目安とするケースもあります。
配車ロジックを試すなら現場の判断と計算結果の一致を、帳票を改修するなら取引先ごとのEDI適合を確認します。検証対象に応じて、PoCで答えを出す問いを先に決めます。ただし、リスクが小さければPoCを省き、モックアップや試作品の確認に予算を回す方法もあります。
検証後は、今回の開発で対応する課題と将来へ回す課題を分けて記録します。結果と残課題を関係者間で共有してから本開発へ進むと、検証をきっかけに範囲が膨らむのを防げます。
TMS改修の選定でよくある失敗を避ける方法
金額だけを基準に発注すると、後から追加費用や遅れが生じることがあります。そのため、依頼範囲と決定責任者を明らかにし、現場と情報システム双方の条件を選定に含めます。
対象範囲が際限なく広がる失敗
追加要望を都度受け入れると、予算や納期に影響します。そこで、今回対応するものと次回へ送るものに分け、判断を記録します。
SaaS移行も候補にする場合は、TMS改修のパッケージ・クラウド製品一覧で製品を確認できます。
追加作業を受け入れるかは、現場だけで決めず、予算と納期を管理する担当者も交えて判断します。小さな変更でも積み重なれば、後続の改修予定まで動かしてしまうためです。
保守範囲の境界を曖昧にしたまま契約する失敗
保守型を選ぶなら、月額料金に含む作業と別料金になる変更を、契約書で区別しておきます。対象業務、想定工数、追加費用の条件は書面で確かめ、口頭の確認だけで依頼を始めないようにします。
「軽微な変更」の意味は会社によって異なるため、同じ依頼でも解釈が分かれる場合があります。作業時間や追加料金が発生する基準を文書に残し、双方の認識を合わせます。
TMS改修導入前に確認しておきたいポイント
候補を絞った後は、費用や技術力に加えて、自社の運用条件と合うかを確認します。複数社を組み合わせる場合は、連携や障害対応の責任者も決めておきます。
小規模な改修における相見積もり
小規模な修正でも1社だけでは、金額や期間の妥当性を見極めにくくなります。そのため、数万円〜数十万円の案件も、同じ条件で2〜3社に提示し、見積もりと対応時期を比べます。
現行ベンダー以外への相談の検討
仕様書やソースコードを共有できる状態なら、別会社への相談も選択肢です。ただし、新しい会社が現行環境を調べる時間と費用が必要になるため、提示額だけでなく調査期間を含めて比較します。
まとめ
TMS改修では、まず業務上の問題とシステム情報の不足を整理します。そのうえで、保守内の修正、個別委託、SaaSへの移行を課題ごとに選び、同じ条件で技術適合性や費用、納期、保守体制を比べます。
依頼範囲の書き出しと依頼先の比較
依頼内容は、対象車両や営業所、現行ルールまで具体化します。例外条件と希望時期も、依頼書に明記します。共通の依頼書を複数社へ渡し、必要に応じてPoCで不確かな点を検証すると、提案の前提をそろえて判断できます。
判断に迷うときの専門家の知見の活用
適切な方式や体制は、既存システムの技術構成と社内の業務知識によって変わります。判断材料が足りないときは、現状調査から専門家へ相談し、課題と依頼範囲を整理してから候補を選びます。riplaは、フルスクラッチ開発の立場から、現行TMSの仕様整理、改修範囲の検討、依頼先選定を支援しています。
▼全体ガイドの記事
・TMS改修の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。