TMS更改でフルスクラッチを選ぶことは、契約満了やEOS/EOLという期限に間に合わなければ本末転倒になるため、原則として非推奨とされます。ただし、既存TMSに独自の運賃ロジックや傭車先連携が深く組み込まれている場合は、期限内でもフルスクラッチを選ばざるを得ないことがあります。
- フルスクラッチ開発を選ぶ理由と適用範囲
- 既存業務・データ・外部連携の整理
- 開発期間・費用・体制を踏まえた判断
▼全体ガイドの記事
・TMS更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TMS更改の位置づけ（期限内におけるフルスクラッチの是非）
TMS更改でフルスクラッチの是非を検討する前に、まず本記事が扱う論点の位置づけを明確にしておく必要があります。同じフルスクラッチでも、技術の選択肢として語るか、経営投資として語るか、期限管理として語るかで、判断の基準は大きく変わるためです。
TMSのモダナイゼーション・TMS刷新との違い
「TMSのモダナイゼーション」では、フルスクラッチは5つの技術的アプローチのうちの「リビルド」に相当します。既存TMSを廃棄し、クラウドネイティブなアーキテクチャでゼロから再構築する手法として、他の4手法と比べて語られます。
「TMS刷新」では、フルスクラッチによる大規模投資をどう経営層に説明し、TCO・50%ルールやROIといった投資判断の材料をもとに稟議を通すかに重心が置かれます。
これに対し本記事は、TMS更改のフルスクラッチを期限管理の視点から論じます。保守契約の満了やEOS/EOLという確定した期限の中で、そもそも選んでよいのか、選ばざるを得ない場合にどう期限内に完遂させるのかを扱います。技術的な位置づけの詳細や投資判断の材料は、両姉妹記事の完全ガイドで確認できます。
期限のある更改案件でフルスクラッチが原則非推奨とされる理由
フルスクラッチは要件定義から設計・開発・テストまでを一から構築するため、小規模でも半年〜1年、大規模になれば1年以上かかることが珍しくありません。また、ウォーターフォール型で進めると、途中の仕様変更でスケジュールが大きく遅れやすく、契約満了・EOS/EOLというデッドライン超過のリスクが極めて高くなります。
パッケージ・SaaSへの移行であれば、業務プロセスをシステムの標準機能に合わせるFit to Standardの方針を徹底することで、数ヶ月〜半年程度での導入が可能です。
期限が確定しているTMS更改では、開発期間の長さそのものが最大のリスク要因になります。そのため、原則としてパッケージ・SaaSへのリプレースを優先し、フルスクラッチは限られた条件でのみ選ぶ例外的な手法と位置づけるのが実務上の考え方です。
それでもTMS更改でフルスクラッチが選ばれるケース
原則は非推奨ですが、TMSという領域の特性上、期限の制約があってもなおフルスクラッチを選ばざるを得ないケースが一定数存在します。
独自運賃ロジック・傭車先との複雑な連携が競争優位に直結する場合
自社独自の配車ノウハウや運賃計算アルゴリズムが競争優位性（コア・コンピタンス）に直結し、既存のパッケージ・SaaSでは代替できない場合は、期限の制約があってもフルスクラッチを選ばざるを得ません。また、複数の傭車先・配送業者との連携が極めて複雑で、SaaSの標準的なAPI・EDIでは要件を満たせない場合にも、フルスクラッチが候補になります。
こうしたケースでは、既存パッケージへのFit to Standardを試みても現場の業務が回らず、定着に失敗して再度の入れ替えコストが生じるリスクの方が大きくなります。そのため、期限内に収まる範囲でスコープを絞り込んだフルスクラッチを選ぶほうが、結果的に合理的という判断になります。
老朽化した独自ロジックの解析（リバースエンジニアリング）が必要な場合
長年にわたって改修を重ねたTMSでは、運賃計算ルールや傭車先ごとの個別運用がブラックボックス化し、仕様書もないまま属人的に維持されているケースが少なくありません。このような状態のシステムを更改する際は、既存ロジックをそのまま移植するか、この機会に見直すかの判断が、期間と費用対効果の両方を大きく左右します。
現行の仕様を読み解く（リバースエンジニアリング）だけで多くの工数がかかるため、期限内のスクラッチは炎上するリスクが高くなります。それでも、独自ロジックが複雑で、パッケージへの置き換えが事実上不可能な場合には、リバースエンジニアリングの工数を見込んだうえでフルスクラッチを選ばざるを得ません。
期限内に完遂するためのスケジュール管理
フルスクラッチを選ぶなら、期限内に完遂させるためのスケジュール管理を徹底することが欠かせません。
段階移行・Must/Want切り分けとタイムボックス管理
期限のあるフルスクラッチでは、全機能を一度に作り切ろうとするのは避けたい進め方です。そのため、EOS/EOLで外せないコア機能（配車計画の生成・運賃計算・車載器との連携）を先に開発し、契約満了までに第一弾としてリリースします。周辺機能は期限後の段階開発に回し、Must要件とWant要件を厳格に切り分けることが不可欠です。
また、最終工程であるテスト・移行フェーズの完了日を確定の期限日に固定し、そこから要件定義・設計・開発の締切を逆算して割り振る「タイムボックス型」のスケジュール管理を徹底します。こうすると、仕様検討に時間をかけすぎて後工程がしわ寄せを受ける事態を防げます。
並行稼働とロールバック計画（コンティンジェンシープラン）
全拠点・全便を一度に切り替える一括移行（ビッグバン方式）は、フルスクラッチという開発規模が大きい手法との組み合わせでは特に致命傷になりやすいため、避けるべき選択です。
そこで有効なのは、業務影響の小さい拠点やルートから段階的に移行する方法です。新旧システムを一定期間並行稼働させ、配車計画と運賃計算の結果が一致するかを確かめながら、対象を広げていきます。
さらに、万が一新システムに致命的な不具合が発生した場合に備えて、旧システムへすぐ戻せるロールバック計画（コンティンジェンシープラン）を事前に明文化します。移行リハーサルでその実効性を確認しておくことが、期限内完遂の最後の保険になります。
フルスクラッチの費用感とTCO
期限を守れる体制が整っても、フルスクラッチは他の選択肢より費用が大きくなりやすいものです。そのため、投資判断の基準を持っておく必要があります。
規模別費用感（データ移行・連携切替コスト込み）
小規模（基本機能・単一拠点）であれば、初期費用300万〜1,000万円、開発期間3〜6ヶ月が目安です。中規模（複数拠点・外部連携あり）では、初期費用1,000万〜3,000万円、開発期間6〜12ヶ月です。大規模（複数拠点・高度自動化等）では、初期費用3,000万円〜1億円超、開発期間12ヶ月以上という水準になります。
TMS更改では、新規導入相当の費用に加えて、更改特有のデータ移行・連携切替のコストが上乗せされます。たとえば、既存の運賃マスタ・輸送実績データのクレンジングとマスタ整備には数百万円規模、基幹システム連携には100万〜500万円、ハンディターミナル・バーコード連携には50万〜500万円が見込まれます。この点を予算計画に織り込んでおく必要があります。
TCO・50%ルールによる投資判断
フルスクラッチとパッケージ・SaaSのどちらが適するかを考える目安に、「50%ルール」があります。パッケージのカスタマイズ費用が本体価格の50%を超える場合は、フルスクラッチの方が中長期的なコスト効率が良くなるとされ、実務上の判断基準として用いられます。
TMS更改では、単年度の初期費用だけでなく、3〜5年スパンのTCOでこの判断を行うことが重要です。
延長保守費用を払いながら、老朽化した独自ロジックを騙し騙し使い続けた場合の累計コストと、フルスクラッチで作り直した場合の初期投資・新しいランニングコストの累計を比べます。両者の損益分岐点がいつ訪れるかを算出すれば、期限に追われるなかでも根拠のある投資判断ができます。
依頼先選定とプロジェクト体制
期限内に完遂できるフルスクラッチにするには、依頼先の実力とプロジェクト体制の両方を事前に見極めておく必要があります。
ベンダー選定の実務ポイント
依頼先を選ぶ際は、要件定義から伴走してもらえるかを確認します。あわせて、ブラックボックス化した既存TMSのロジックを読み解くリバースエンジニアリングの経験があるかを見ておきます。運賃マスタ・輸送実績データの移行や、配送業者・WMS・基幹システムとの連携切替を経験しているかも、判断材料になります。
期限のあるフルスクラッチでは、Must/Want要件を切り分ける提案力やタイムボックス管理の進め方を見ておきたいところです。さらに、リリース後も保守や機能追加を続けられる体制があるかも、合わせて評価の対象になります。
期限順守の実績確認
フルスクラッチは、スケジュールが長期化しやすい手法です。だからこそ、契約満了やEOS/EOLという期限を過去に守ってきた実績があるかどうかが、依頼先選定の最終的な決め手になります。
提案段階では、工程別のスケジュールを具体的に描けているかを確かめます。そのうえで、遅延しそうなときの代替案（スコープの絞り込みや段階リリースへの切り替えなど）も示せるかを見ておくと、見極めの材料になります。
あわせて、進捗が週次で見える体制があるかや、仕様変更を口頭で済ませず変更要求として起票するルールが徹底されているかも確認すると、期限内に完遂できる相手かを見極められます。
まとめ
ここまでは、TMS更改のフルスクラッチ・オーダーメイド開発について、期限内での是非の位置づけと、フルスクラッチが選ばれるケースを見てきました。さらに、期限内に完遂するためのスケジュール管理、フルスクラッチの費用感とTCO、依頼先選定とプロジェクト体制も解説しました。
TMS更改のフルスクラッチは、契約満了・EOS/EOLという期限との相性が悪く、原則非推奨です。ただし、独自運賃ロジックや傭車先との複雑な連携が競争優位に直結する場合は、選択肢として現実的に成り立ちます。そのためには、Must/Want要件の切り分け、タイムボックス管理、段階移行とロールバック計画を組み合わせます。
50%ルールに基づくTCO比較で投資判断の根拠を持ち、期限を守ってきた実績のある依頼先を選ぶことが、TMS更改でフルスクラッチを成功させる鍵です。経営判断の進め方や技術手法の詳細は、姉妹記事「TMS刷新」「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を創業。