フルスクラッチで作り直すか、部分改修で済ませるかは、改修の規模で決まります。既存の土台を変えずに対応できる課題であれば部分改修で足り、カスタマイズ費用が本体価格の50%を超えるなどの境界線に達したときに、フルスクラッチを検討します。
- TMS改修の位置づけ（フルスクラッチとの対比）
- 部分改修で済ませられる規模の目安
- フルスクラッチへ切り替えるべき境界線
既存のTMS（輸配送管理システム）は、配車計画・ルート最適化・運賃計算・車両とドライバーの動静管理を担います。TMS改修は、このシステム全体は作り替えず、特定の機能やモジュールに絞って行う部分的・小規模な修正のことです。
たとえば、「特定車両タイプの配車ロジックだけを調整したい」「運行日報帳票の一部項目だけを修正したい」といった依頼が、これに当たります。
同じ「TMS」でも、切り口は記事ごとに異なります。「TMSのモダナイゼーション」は、5つの技術的アプローチを横並びに扱う技術手法の総論です。「TMS刷新」は、輸送コスト増・積載効率低下・傭車比率上昇を起点に、いつ全面刷新へ投資すべきかを経営層向けに扱います。
「TMS更改」は、保守契約満了や車載器・GPS端末のリース期限、EOS/EOLという、外部から強制される期限管理が主軸です。「TMSのリニューアル」は、ドライバー向け配車アプリや荷主向けポータルのUX/UIという、顧客体験の刷新が主軸です。
「TMSのリアーキテクチャ」は、マイクロサービス化やストリーム処理基盤の構築を通じて、アーキテクチャ設計そのものを技術的に深掘りします。「TMSリプレイス」は、自社スクラッチを維持するか、別製品・SaaSへ乗り換えるかというビルド・バイの判断を扱います。
一方で、TMS改修の記事は、この前提そのものを問い直します。本当にシステムを作り替える必要があるのか、困っている部分だけを直せば足りるのかを、投資判断の入口で見極めるための切り口です。
そのため、既存TMSに不満はあるものの、フルスクラッチで作り直すほどの予算・期間をかけるべきか判断しかねている物流部門・情報システム部門の方にとって、部分改修という選択肢を含めた現実的な判断軸が身に付く内容です。
TMS改修の全体像は、以下の記事で詳しく扱っています。
▼全体ガイドの記事
・TMS改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TMS改修とは何か（フルスクラッチとの対比という論点における位置づけ）
TMS改修とフルスクラッチ・オーダーメイド開発を比べるには、両者が「作り替えるか、作り替えないか」という根本的に異なる選択肢であることを、まず押さえておく必要があります。
6つの先行記事群との違い（改修は「作り替えない」選択肢）
先ほど挙げた6つの記事は、「TMSのモダナイゼーション」「TMS刷新」「TMS更改」「TMSのリニューアル」「TMSのリアーキテクチャ」「TMSリプレイス」です。6つの記事は切り口こそ異なるものの、いずれも既存TMSに何らかの形で大きく手を入れるか、別のシステムへ乗り換えることを前提にしています。
これに対してTMS改修は、「本当にシステムを作り替える必要があるのか、それとも困っている部分だけを直せば十分なのか」という問いを立てる切り口です。投資判断の入口に立つ企業が、フルスクラッチと部分改修のどちらが自社に当たるかを見極めるための判断軸になります。
部分改修とフルスクラッチの根本的な違い（リフォームと新築）
両者の違いは、「今の家を活かしてリフォームするか、新しい家をゼロから建てるか」というアプローチの違いに例えられます。
部分改修（リライト・一部再構築など）は、現在のシステムを活かしながら、機能の追加や特定の画面・モジュールだけを新しい技術で作り直す手法です。業務への影響を最小限に抑えやすく、従業員が新しい操作を覚える手間も少ないのが利点です。ただし、費用と期間を抑えやすい反面、古いシステムの根本的な設計の古さは残る場合があります。
一方、フルスクラッチ開発は、既存のシステムを捨て、業務要件から見直してゼロからすべてを設計・開発する手法です。自社の業務に完全にフィットしたシステムを作れるなど、自由度は最も高い反面、要件定義の負荷が大きく、コストや期間が大幅に膨らむリスクが最大の手法でもあります。
部分改修で済ませられる規模の目安
既存の業務プロセスを大きく変えず、現状の課題の解決に絞る場合は、部分改修が選ばれます。TMSでは、この考え方に当てはまる改修が典型的な形です。
特定車両タイプの配車ロジック調整・帳票軽微修正という典型例
既存の配車エンジンに対して「この荷主は大型車が通れない」「この商品は冷凍車限定」といった特定のパラメータや制約条件を追加する程度であれば、既存システムの拡張性が高いことを前提に、部分的な調整で対応できます。
同様に、取引先から要求された新しい伝票フォーマットへの対応や、日報に記載する項目の追加（休憩時間の記載欄の追加等）といった帳票レイアウトの修正は、システム全体に影響を与えません。そのため、短期間・低予算の部分改修で対応すべき典型的なケースです。
これらはいずれも、既存TMSの土台となる基本設計を変えずに済む、限定的な機能追加として処理できる規模の課題といえます。
小規模・中規模の部分改修の費用・期間目安
一般的な目安として、一部機能のみの刷新や特定画面の再構築、周辺機能の置き換えといった小規模な部分改修は、数週間〜数ヶ月程度です。一方、既存システムの一部再構築やデータ移行、外部サービスとの連携を伴う中規模な部分改修は、数ヶ月〜1年程度が目安になります。
今後その業務を大きく変える予定がない場合や、現在のシステムがまだ安定して動いており部分的な延命で対応できる場合は、部分改修で十分というのが基本的な考え方です。
TMS改修が扱う特定車両タイプの配車ロジック調整や帳票の軽微な修正は、このなかでもさらに小さい規模の部分改修に当たります。
フルスクラッチへ切り替えるべき境界線
部分改修では対応しきれず、フルスクラッチへの切り替えを判断すべき境界線には、いくつかの明確な指標があります。
カスタマイズ費用の「50%ルール」
既存のパッケージやSaaSで業務要件を満たすためのカスタマイズ費用を見積もった際、その費用がパッケージ本体価格の50%を超えるなら、フルスクラッチ開発の方が長期的なコスト効率（TCO）で有利と判断されます。
TMS改修でも、同じ考え方が当てはまります。当初は特定車両タイプの配車ロジック調整という小さな依頼でも、見積もりを進めるうちに関連する複数の機能へ手を入れる必要が分かることがあります。その結果、カスタマイズ費用が本体価格の半分に迫るようであれば、部分改修で対応する規模を超えているサインと捉えるべきです。
複雑な外部連携要件の「3つの基準」・保守費用の高騰
5つの項目のうち3つ以上に当てはまる場合は、部分改修の枠には収まりきらず、フルスクラッチ開発が必要になる可能性が高いとされています。
その5項目には、倉庫や営業所が3拠点以上あることや、既存の基幹システムが最新のAPI連携に対応していないことが含まれます。ほかにも、取引先ごとにEDIや伝票フォーマットが乱立していることや、自動倉庫やコンベアなどの物流機器と高度に連携したいこと、業務ルールが極めて属人的で、パッケージの標準機能に当てはめるのが難しいことがあります。
一般的な保守費用の相場は、初期開発費の15〜20%とされています。加えて、システムの老朽化で保守工数が増え、この比率を大幅に超えている場合や、保守契約外の追加改修費が毎年高額に積み上がっている場合も、フルスクラッチを検討すべき大きなサインになります。
見極めのための実務プロセス
部分改修とフルスクラッチのどちらにするかは、いきなり決めるのではなく、段階を踏んで見極めることが現実的です。
現状把握（仕様の文書化）
「作った人が退職し、今のシステムが何をしているか誰も説明できない」というブラックボックス化を理由に、中身が分からないままフルスクラッチに飛びつくのは、非常に危険な判断です。
どの手法を選ぶにしても、まずは現行システムの仕様を文書にまとめ、何がどこまで動いているかを把握することが、失敗を防ぐための必須条件です。
たとえば、特定車両タイプの配車ロジックがどう実装されているか、帳票出力の仕組みがどこまでカスタマイズできるかを整理します。その作業自体が、部分改修とフルスクラッチのどちらが適切かを判断する最初の材料になります。
スモールスタートで様子を見てからの判断
最も困っている業務を1つに絞り、部分改修やMVPでスモールスタートします。そのうえで、3〜6ヶ月ほどの仮運用を通じて、既存システムや部分改修では自社の複雑な配車ルール（多拠点連携や独自の積載ロジックなど）を処理しきれないという限界が見えたとき、初めてフルスクラッチ開発への投資を決断します。これが、最もリスクの低い見極め方です。
まず小さく試し、現場の反応と技術的な限界の両方を確かめてから大きな投資判断に進むという順序を守ることが大切です。完璧なシステムを数千万円かけて最初から作る進め方は、この順序と逆になります。
判断を誤らないための注意点
部分改修とフルスクラッチの判断で見落とされやすい注意点は、2つあります。
「なんとなく古い」という理由だけでフルスクラッチに飛びつく危険性
システムが古い、担当者が変わって使いにくいと感じるだけで、フルスクラッチという過大な投資に進むケースは少なくありません。そのなかには、特定車両タイプの配車ロジック調整や帳票の軽微な修正で解決できる課題も含まれています。
感覚的な「古さ」への不満と、業務上の限界に実際に達しているかどうかは、別の問題です。そのため、まずは課題を具体的に言語化し、部分改修で解決できる規模かどうかを冷静に切り分けることが、無駄な投資を避ける第一歩になります。
改修を重ねた結果の技術的負債の管理
一方で、部分改修を無計画に積み重ね続けることにもリスクがあります。個々の改修は低予算・短納期で妥当でも、継ぎ接ぎのようなカスタマイズが何年も重なると、プログラムがスパゲッティ化します。
そうなると、少しの改修でも想定外の不具合が多発することがあります。その時点で、すでに部分改修の限界を超えており、フルスクラッチを検討すべき境界線に達しているサインです。
改修のたびに変更内容を記録し、定期的に「このシステムはまだ部分改修で延命できる状態か」を確かめる習慣を持つことが、判断を誤らないための実務的な備えになります。
まとめ
TMS改修とフルスクラッチ・オーダーメイド開発の違いは、既存のシステムを活かすか、作り替えるかにあります。部分改修で済ませられる規模の目安、フルスクラッチへ切り替えるべき境界線、見極めの実務プロセス、判断を誤らないための注意点を整理しました。
特定車両タイプの配車ロジック調整や運行日報帳票の軽微な修正であれば、既存システムの拡張性を前提に、部分改修で十分対応できます。一方で、カスタマイズ費用が本体価格の50%を超える場合、複雑な外部連携要件が3つ以上当てはまる場合、保守費用が初期開発費の20%を大幅に超える場合は、フルスクラッチへの切り替えを検討するタイミングです。
まずは現状把握とスモールスタートから始め、部分改修の限界が実際に見えてから大きな投資判断に進みます。この順序を守ることが、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を創業。