TMS更改のフルスクラッチ・オーダーメイド開発について

TMS更改におけるフルスクラッチ・オーダーメイド開発の検討は、技術的アプローチの1つとしてリビルドを位置づける「TMSのモダナイゼーション」や、経営判断としての大規模投資の是非を扱う「TMS刷新」とは異なり、保守サポート契約の満了やTMS製品・OS・ミドルウェアのEnd of Support/End of Life（EOS/EOL）という「動かせない期限」がある中で、フルスクラッチという最も時間のかかる選択肢を選んでよいのかという、期限管理の視点からの是非を問うテーマです。要件定義から設計・開発・テストまでを一から積み上げるフルスクラッチは、契約満了までに完遂できなければ本末転倒であり、TMS更改においては原則として非推奨とされる選択肢です。しかし、既存TMSに独自の運賃ロジックや複雑な傭車先連携が深く組み込まれている場合には、期限内であってもフルスクラッチを選ばざるを得ないケースが存在します。

本記事では、TMS更改のフルスクラッチ・オーダーメイド開発について、期限のある更改案件でフルスクラッチが原則非推奨とされる理由の確認から、それでもTMS更改でフルスクラッチが選ばれるケース、期限内に完遂するためのスケジュール管理、フルスクラッチの費用感とTCO、そして依頼先選定とプロジェクト体制までを、具体的な数値とともに体系的に解説します。契約満了やEOS/EOLが迫る中でフルスクラッチという選択肢の是非に悩んでいる運送会社・物流部門の情報システム担当者にとって、判断のための材料が得られる内容です。

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

▼全体ガイドの記事
・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では、運賃計算ルールや傭車先ごとの個別運用がブラックボックス化し、仕様書も存在しないまま属人的に維持されているケースが少なくありません。このような状態のシステムを更改する場合、既存ロジックをそのまま「移植」するのか、この機会に見直すのかという判断が、期間と費用対効果の両方を大きく左右します。仕様書がない状態からの現行解読（リバースエンジニアリング）だけで多くの工数を要するため、期限内スクラッチが炎上するリスクは高いものの、独自ロジックの複雑さゆえにパッケージへの置き換えが事実上不可能な場合には、リバースエンジニアリング工数を見込んだうえでフルスクラッチを選ばざるを得ません。

期限内に完遂するためのスケジュール管理

フルスクラッチを選ぶと決めた場合、期限内に完遂させるための徹底したスケジュール管理が不可欠になります。

期限のあるフルスクラッチでは、全機能を一度に作り切ろうとするのではなく、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万円といった、更改特有のデータ移行・連携切替コストが上乗せされる点を予算計画に織り込んでおく必要があります。

フルスクラッチとパッケージ・SaaSのどちらを選ぶべきかを判断する目安として、パッケージのカスタマイズ費用が本体価格の50%を超える場合はフルスクラッチの方が中長期的なコスト効率が良くなるという「50%ルール」が実務上の判断基準として用いられます。TMS更改では、この判断を単年度の初期費用だけでなく、3〜5年スパンのTCOで行うことが重要です。延長保守費用を払い続けながら老朽化した独自ロジックを騙し騙し使い続けた場合の累計コストと、フルスクラッチで作り直した場合の初期投資・新しいランニングコストの累計を比較し、損益分岐点がいつ訪れるかを算出することで、期限に追われる中でも根拠のある投資判断ができます。

依頼先選定とプロジェクト体制

期限内に完遂できるフルスクラッチ案件にするためには、依頼先の実力とプロジェクト体制の両方を事前に見極める必要があります。

依頼先を選定する際は、要件定義からの伴走が可能か、老朽化した既存TMSのブラックボックス化したロジックを解析するリバースエンジニアリングの経験があるか、既存の運賃マスタ・輸送実績データの移行や配送業者・WMS・基幹システムとの連携切替の実績が豊富かを確認することが重要です。期限のあるフルスクラッチ案件では、Must/Want要件の切り分けやタイムボックス管理の提案力、そしてリリース後も継続的に保守・機能追加できる体制があるかも合わせて評価しましょう。

フルスクラッチのようにスケジュールが長期化しやすい手法だからこそ、契約満了・EOS/EOLという期限を過去に順守してきた実績があるかどうかを確認することが、依頼先選定の最終的な決め手になります。提案段階で、工程別のスケジュールと、遅延が発生しそうになった場合の代替案（スコープの絞り込みや段階リリースへの切り替えなど）をどこまで具体的に描けているかを確認し、進捗が週次で可視化される体制、仕様変更を口頭で済ませず変更要求として起票するルールが徹底されているかもあわせてチェックすることで、期限内に完遂できるパートナーかどうかを見極められます。

まとめ

本記事では、TMS更改におけるフルスクラッチ・オーダーメイド開発について、期限内におけるフルスクラッチの是非という位置づけの確認、それでもTMS更改でフルスクラッチが選ばれるケース、期限内に完遂するためのスケジュール管理、フルスクラッチの費用感とTCO、そして依頼先選定とプロジェクト体制を体系的に解説しました。TMS更改において、フルスクラッチは契約満了・EOS/EOLという期限との相性が悪く原則非推奨ですが、独自運賃ロジックや傭車先との複雑な連携が競争優位に直結する場合には、Must/Want要件の厳格な切り分け、タイムボックス管理、段階移行とロールバック計画という期限内完遂のための手法を組み合わせることで、選択肢として現実的に成立させることができます。50%ルールに基づくTCO比較で投資判断の根拠を持ち、期限順守の実績がある依頼先を選ぶことが、TMS更改でフルスクラッチを成功させる鍵です。経営判断のプロセスや技術手法の詳細については、姉妹記事「TMS刷新」「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を創業。