TMS改修の選定ポイント/選び方/種類

TMSの改修を依頼しようとすると、現行ベンダーの保守契約内で対応できる範囲、外部の専門ベンダーへ個別に委託すべき範囲、クラウド型TMSへ機能ごと乗り換えたほうが早い範囲が入り混じり、どこから手を付ければよいか分かりにくくなりがちです。選定の出発点は、対象製品やベンダーを比較する前に、自社の何がどれくらい困っているかを言語化することです。

本記事では、TMS改修を検討する前に整理すべき自社の課題、改修の3つのアプローチ、依頼先を比較する7つの評価軸、内製・外部委託・ハイブリッドの選び分け、RFPとPoCの進め方、よくある失敗を解説します。改修の依頼先や手法を絞り込みたい担当者の方が、比較条件をそろえて判断できる内容です。

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

▼全体ガイドの記事
・TMS改修の完全ガイド

TMS改修前に整理すべき自社の課題

依頼先を探し始める前に、配車ロジック、帳票・伝票、外部連携のどこに困りごとが集中しているかを特定することが先決です。困りごとを一文で説明できれば、比較すべき依頼先の種類やRFPに書くべき条件が明確になります。

軽微な帳票修正なのに見積もりが数百万円に膨らむ、逆に配車ロジックの大幅な調整を数万円の感覚で依頼してしまう、といったずれは珍しくありません。一般的な目安として、軽微な修正は数万円〜数十万円・2〜4週間、特定車両向けの配車ロジック調整は数十万円〜数百万円・数週間〜3ヶ月程度とされています。自社が想定する規模がこの目安のどこに位置するかを、依頼先へ相談する前に整理しておきます。

想定と実際のずれをなくすには、過去1年程度に発生した改修依頼を洗い出し、依頼内容ごとの金額と対応期間を一覧にしておくと効果的です。社内に記録が残っていない場合は、現行ベンダーへ過去の請求内訳の開示を依頼するところから始めます。

現行ベンダー以外に依頼できるかどうかが分からない場合は、ベンダーロックインが課題です。一方、ベンダーは複数あるが仕様書が整っておらず、誰に頼んでも調査から始まる場合は、社内の属人化・ブラックボックス化が課題です。両者は対策が異なるため、どちらが自社の主因かを分けて整理しておくと、選定条件を作りやすくなります。

仕様書がベンダー社内にしか存在しない、あるいは開発時の担当者しか把握していないという状態は、契約上は他社に依頼できても実質的にロックインされているのと変わりません。まずは現行システムの仕様がどこまで文書化されているかを、依頼先探しの前に確認しておきます。

TMS改修の3つのアプローチ

TMS改修の進め方は、大きく保守契約内改修型、個別委託改修型、SaaS機能追加・移行型の3つに分けられます。どれか1つに固定する必要はなく、対象領域ごとに使い分けることも可能です。

たとえば、帳票修正は保守契約内改修型で対応しつつ、配車ロジックの大幅な調整だけは個別委託改修型の専門ベンダーへ依頼するというように、対象領域ごとにアプローチを組み合わせる企業も少なくありません。無理に1つの方式へ統一しようとせず、業務ごとの最適解を積み上げる発想が現実的です。

保守契約内改修型は、現行ベンダーとの月額保守契約の範囲内、またはチケット・ポイント制の枠内で軽微な修正を依頼する方式です。追加の発注手続きが少なく着手が早い一方、保守範囲と追加費用の境界が契約に明記されていないと、軽微な変更でも都度5万〜12万円程度の最低作業料金が発生することがあります。個別委託改修型は、現行ベンダー以外の専門ベンダーへスポット契約で改修を依頼する方式で、現行システムの仕様書が整っていることが前提になります。

保守契約の枠内で対応してもらえると思っていた変更が、実は「仕様変更」として別途見積もりの対象になっていたという行き違いも起こりがちです。契約更新のタイミングで、対象業務の一覧と、それぞれが保守範囲か追加費用対象かをあらためてすり合わせておくと、こうした行き違いを防げます。

SaaS機能追加・移行型は、困っている業務だけをクラウド型TMSの標準機能へ切り出し、残りの業務は既存システムを使い続ける方式です。法改正対応がSaaS側の標準アップデートに含まれることが多く、スクラッチ・オンプレ型のように法改正やOS更新のたびに追加保守費用が発生するリスクを抑えやすい一方、既存システムとの二重運用や連携部分の整合性確認が新たな検討事項になります。

切り出す業務を決める際は、現行システムのどのデータをクラウド側へ渡す必要があるか、逆にクラウド側で確定した情報を現行システムへどう戻すかという双方向のデータフローを先に設計しておくことが重要です。設計を後回しにすると、現場で二重入力が発生したまま運用が固定化してしまいます。

依頼先・手法を比較する評価軸

依頼先や手法は、要件の具体度、技術的な適合性、費用体系、スケジュール、保守引き継ぎ、連携実現性、将来の拡張性という軸で比較します。同じ質問を各候補へ提示すると、営業説明の分かりやすさに左右されにくくなります。

第一に、現行システムの言語・データベース・インフラ構成をどこまで理解したうえで見積もっているかを確認します。表面的な要望だけを聞いて即答する依頼先より、既存コードやデータ構造の確認を提案する依頼先のほうが、着手後の手戻りは少なくなります。第二に、費用体系が月額固定型、従量・時間課金型、チケット・ポイント制のいずれかを確認し、軽微な修正が積み重なった場合の総額イメージをすり合わせます。

依頼先によっては、現行システムのソースコードを一切確認せずに「対応可能です」と即答するケースもあります。こうした回答は、着手後に想定外の技術的制約が見つかり、追加費用や納期遅延につながるリスクが高いため、見積もり段階で現行システムの資料をどこまで確認したかを具体的に質問することが有効です。

第三に、2〜4週間単位のアジャイルサイクルに対応できるか、それとも従来型のウォーターフォールでしか対応できないかを確認します。第四に、改修後の保守運用を誰がどのように引き継ぐか、ドキュメント整備の範囲を確認します。第五に、今回の改修が将来別の対象領域へ広がったときに同じ依頼先で対応できるか、他システムとの連携拡張に耐えられる作りかも、あわせて確認しておくべき点です。

保守引き継ぎについては、改修範囲に関する設計書やテスト結果を誰が保管し、次回の改修時にどのように参照できるかまで確認しておくと、担当者が変わった場合にも対応がスムーズになります。ドキュメントを残さない依頼先を選ぶと、次の改修が再び手探りから始まることになりかねません。

内製・外部委託・ハイブリッドの選び分け

誰が改修を実行するかは、社内にエンジニアリソースがあるかどうかだけでなく、業務知識をどちらが持っているかによっても変わります。

社内に開発リソースがあり、配車ロジックの制約条件のような現場の暗黙知を熟知したメンバーがいる場合は、内製での改修が向いています。一方、社内にエンジニアがいない、または現行システムの技術スタックに詳しい人材が退職しているといった場合は、仕様調査から任せられる外部委託が現実的です。どちらが自社の状況に近いかを、着手前に率直に評価します。

内製を選ぶ場合でも、担当者が他の業務と兼務していることが多いため、改修に充てられる工数をあらかじめ確保しておく必要があります。片手間で進めようとすると、テストが不十分なままリリースされ、現場で不具合が発覚するリスクが高まります。

ハイブリッドは、現場の要件整理や暗黙知の言語化は自社が担い、実装とテストは外部ベンダーへ委託する分担です。業務知識を持つ現場担当者と、開発を担う外部ベンダーの間で認識がずれないよう、要件を文書化してから依頼する進め方が有効です。特定車両タイプの配車ルールのように現場判断が絡む改修ほど、この役割分担のメリットが大きくなります。

要件定義を自社が担う場合は、配車ルールの例外条件を箇条書きで済ませず、実際の配送データを使った具体例として整理すると、外部ベンダーへの伝達精度が上がります。抽象的な言葉だけで要件を伝えると、実装後に「思っていたものと違う」という手戻りが発生しやすくなります。

見積もり依頼とPoCの進め方

見積もり依頼では、機能の有無だけでなく、対象範囲と現場の運用条件を具体的に示すことが重要です。技術的なリスクが不安な場合は、モックアップやPoCで検証してから本開発に進みます。

見積もり依頼書には、対象となる車両タイプや営業所、現行の配車ルール、対応してほしい例外条件、現行システムの技術構成、希望リリース時期を記載します。「配車ロジックを改善してほしい」という抽象的な依頼ではなく、「大型車が通行できない道路を除外条件に加えたい」のように具体的に書くと、各社の見積もり精度がそろい比較しやすくなります。

見積もり依頼書には、現行システムの導入時期や過去の改修履歴も添えておくと、依頼先が技術的な制約を事前に見積もりへ反映しやすくなります。改修を重ねてきたシステムほど想定外の依存関係が潜んでいることが多く、履歴の共有は着手後のトラブルを減らすうえで有効です。

PoCの費用感は30万〜300万円、期間は1〜8週間程度が目安とされ、本開発費用の10〜20%程度を目安にすることが多いとされています。検証対象を1つに絞り、UI・UXの検証と裏側のロジック検証を切り分け、技術的なリスクが低いと判断できればPoC自体を省略してモックアップやプロトタイプに予算を寄せる進め方も有効です。特定車両タイプの配車ロジック検証では、現場の暗黙知とアルゴリズムのすり合わせが、帳票修正の検証では取引先ごとのEDI適合確認がそれぞれ鍵になります。

PoCの実施後は、検証で見つかった課題を「今回の改修で解消すべき課題」と「将来の改修へ持ち越す課題」に仕分けておくと、本開発のスコープが際限なく広がることを防げます。PoCの結果を関係者へ共有する際も、この仕分けを明示しておくと合意形成がスムーズになります。

TMS改修の選定でよくある失敗を避ける方法

よくある失敗は、価格の安さだけで依頼先を決め、着手後に想定外の追加費用や納期遅延が発生することです。対象範囲と責任者を明確にし、現場と情報システムの視点を選定に反映します。

着手後に「ついでにここも直してほしい」という要望が積み重なると、部分改修のはずが当初の予算・納期を大きく超えることがあります。追加要望が出た場合は、今回のスコープに含めるか、次回の改修として切り分けるかをそのつど判断し、記録に残しておくことが有効です。具体的な依頼候補を確認したい場合は、TMS改修のパッケージ・クラウド製品一覧を参照すると、SaaS機能追加・移行型で検討できる製品を比較しやすくなります。

追加要望への対応方針は、現場担当者だけで判断せず、予算と納期の責任者を交えて確認することが望ましいです。現場の善意による「ついでの対応」が積み重なると、当初のスケジュール感が崩れ、後続の改修計画にも影響が及びます。

保守契約内改修型を選ぶ場合、どこまでが月額料金の範囲でどこからが追加費用になるかを契約書に明記しないと、軽微な変更のたびに想定外の請求が発生します。改修範囲が判明した段階で、対象業務、想定工数、追加費用が発生する条件を書面で確認し、口頭合意だけで進めないようにします。

境界が曖昧なまま契約すると、依頼先ごとに「軽微な変更」の定義が異なり、同じ内容の依頼でも対応の可否が分かれることがあります。具体的な作業時間の目安を契約書に明記しておくと、双方の認識のずれを事前に防げます。

TMS改修導入前に確認しておきたいポイント

依頼先の候補を絞った後も、費用体系や技術対応力だけでなく、自社の運用に合うかどうかまで確認しておくことで、着手後の認識違いを防げます。特に複数の依頼先を組み合わせる場合は、責任範囲の切り分けをあらかじめ明確にしておくことが重要です。

金額が小さいからと1社だけに見積もりを依頼すると、相場感がつかめないまま契約することになります。数万円〜数十万円規模の軽微な修正であっても、同じ条件を2〜3社へ提示し、費用体系とスケジュール感を比較することをおすすめします。

仕様書やソースコードが整理されていれば、現行ベンダー以外に相談することも選択肢になります。ただし、他社への切り替えには現行システムの調査コストがかかるため、金額差だけでなく調査期間も含めて比較することが必要です。

まとめ

TMS改修の選定では、費用感とスケジュール感のずれ、ベンダーロックインと属人化を切り分けて自社の課題を特定し、保守契約内改修型、個別委託改修型、SaaS機能追加・移行型のどのアプローチが合うかを判断します。そのうえで、技術適合性、費用体系、スケジュール対応、保守引き継ぎ、拡張性という評価軸で候補を比較し、内製・外部委託・ハイブリッドのどれで実行するかを決めることが重要です。

「配車ロジックを改善したい」という抽象的な要望のままでは、依頼先ごとの見積もりや提案の前提がそろいません。対象の車両タイプや営業所、現行の運用ルール、希望時期まで書面化してから、2〜3社の見積もりとPoCで比較することが、選定の失敗を避ける近道です。

保守契約内改修型・個別委託改修型・SaaS機能追加・移行型のどれが自社に合うか、内製と外部委託のどちらで進めるべきかは、現行システムの技術的な状況によって変わります。判断材料が不足している場合は、現状把握の段階から専門家に相談することで、選定のやり直しを防げます。riplaはフルスクラッチ開発の立場から、現行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を創業。