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

TMS刷新においてフルスクラッチ（オーダーメイド）開発を選ぶという判断は、単なる技術選定ではなく、投資規模が数千万円から1億円を超えることも珍しくない、経営そのものを左右する意思決定です。既製パッケージやSaaSへの移行に比べて初期費用と開発期間が最も大きくなる一方、自社の配車・運賃計算プロセスに独自の価値を作り込め、輸送コスト増・積載効率低下・傭車比率上昇という経営インパクトを根本から解消できる手法でもあるため、「なぜフルスクラッチを選ぶのか」「どうやって大規模投資の稟議を通すのか」「2024年問題を踏まえてどう進めるのか」「物流部門・傭車先・情報システム部門をどう巻き込むのか」という経営・プロジェクト推進上の意思決定を丁寧に積み重ねられるかどうかが、プロジェクトの成否を大きく左右します。

本記事では、TMS刷新におけるフルスクラッチ・オーダーメイド開発に焦点を当て、自社独自開発を選ぶ経営判断の考え方、大規模投資の稟議を通すためのポイント、2024年問題を踏まえたプロジェクトスケジュールとチェンジマネジメント、物流部門・傭車先・情報システム部門を巻き込んだプロジェクト体制構築、そしてベンダー選定プロセスとフルスクラッチ特有のリスクまでを、具体的な考え方とともに体系的に解説します。技術的な実装手法そのものの詳細はTMSのモダナイゼーションの記事に譲り、本記事では「なぜ・いつ・誰を巻き込んで進めるか」という経営とプロジェクト推進の実務に焦点を当てます。

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

▼全体ガイドの記事
・TMS刷新の完全ガイド

TMS刷新におけるフルスクラッチ・オーダーメイド開発とは（経営判断としての位置づけ）

TMS刷新でフルスクラッチ・オーダーメイド開発を検討するということは、パッケージやSaaSという「既製品」を選ばず、自社の配車・運賃計算プロセスのためだけにシステムをゼロから作り込むという選択を意味します。この選択は技術的な最適解を探す作業である以上に、経営として「なぜ既製品では足りないのか」を説明し、大規模な投資に見合うリターン、すなわち輸送コスト・積載効率の改善を描けるかという判断そのものです。

「TMSのモダナイゼーション」記事群では、フルスクラッチは5つの技術的アプローチのうち「リビルド」に相当し、配車ロジック・運賃計算エンジンとデータモデルをどう技術的に再設計するかという実装面に重心を置いて解説しています。「TMS開発」記事群では、これから新規にTMSを立ち上げるグリーンフィールドの前提でフルスクラッチの適否を扱います。これに対し本記事が扱うTMS刷新のフルスクラッチは、経営層が数千万円規模の投資をどう意思決定し、2024年問題を踏まえてどう進め、物流部門・傭車先・情報システム部門をどう巻き込みながらプロジェクトを推進していくかという、経営判断・プロジェクト推進のプロセスに重心を置きます。技術的な実装手法の詳細を知りたい方は、モダナイゼーション記事をあわせてご覧ください。

フルスクラッチを選択する最大の経営的理由は、自社独自の競争優位性を生み出す配車・運賃計算プロセスを支えるためです。市販のパッケージでは対応しきれない、拠点をまたぐ複雑な配車ルール、荷主ごと・傭車先ごとに異なる運賃計算ロジック、自動倉庫やコンベア等の物流機器との高度な連携がある場合、システムを業務に完全に合わせることで、積載効率と配送生産性を高め、輸送コスト増・傭車比率上昇という経営インパクトを根本から解消できます。パッケージを無理に自社に合わせようと過度なカスタマイズを行うと、システムが複雑化し、将来的なバージョンアップが困難になるほか、特定のベンダーに依存してしまうベンダーロックインのリスクが生じるため、これを避ける目的で最初から拡張性を確保したフルスクラッチを選ぶ企業もあります。ただしフルスクラッチは自由度が高い反面、開発に1年以上の期間と高額な投資が必要となり、移行リスクも最も高くなる手法であることを経営層はあらかじめ理解しておく必要があります。

大規模投資の稟議を通すための経営判断ポイント

フルスクラッチ開発は多額の初期費用がかかるため、稟議をスムーズに通すには、単純な金額の妥当性だけでなく、投資判断そのものの納得感を高める説明が求められます。

初期費用が高額であっても、運用開始後の保守・ランニング費用を含めたTCO（総所有コスト）で評価することが基本です。既製パッケージのカスタマイズ費用が本体価格の50%を超える場合には、フルスクラッチ開発の方が中長期的なコスト効率が良くなるという「50%ルール」が判断の目安になります。あわせて、大規模なTMS刷新では初期費用3,000万円〜1億円超の投資に対し、10名以上の要員削減効果や配送生産性の向上により、回収期間はおよそ4〜5年、10年後の想定累積ROIは130〜180%といった具体的なリターンを見込めることを提示すると説得力が高まります。「業務が便利になる」といった定性的な理由ではなく、「積載率を◯%向上させる」「傭車比率を◯%低減させる」といった具体的な数値を設定し、経営的インパクトを定量的に示すことが稟議の通過率を左右します。あわせて、すべてを一気に移行するのではなく優先順位をつけて影響の少ない拠点・ルートから段階的にリリースする計画を示すことで、予算超過やシステム停止リスクを抑えられるという安心材料も提示します。

大規模投資の稟議では、単なる安さではなく「成功を担保する計画であること」を説明することが重要です。10億円規模の基幹システム刷新を行ったキングジムの事例では、コンペにおいて複数の提案の中から「最も高コストな提案」をしたコンサルティング会社を選定しています。その理由は、旧システムのブラックボックス解明や業務標準化への道筋が明確で、プロジェクト失敗のリスクを最小化できると判断されたためです。この事例が示すのは、フルスクラッチのような大規模投資においては、初期見積もりの安さよりも「本当にプロジェクトを完遂できる計画・体制を提示しているか」という観点で選定した方が、結果的にトータルコストとリスクの両方を抑えられるという教訓です。TMS刷新の稟議資料でも、金額の比較表だけでなく、各社の提案が抱えるリスクとその対策までを併記することで、経営層の意思決定を後押しできます。加えて、一括切り替えによる業務停止や現場の猛反発といった致命的リスクを避けるため、MVP（最小機能）から小さく始めて段階的に拡張するアジャイル的な進め方を採ることを説明し、投資リスクを段階的に最小化していることをアピールすることも有効です。

2024年問題を踏まえたプロジェクトスケジュールとチェンジマネジメント

フルスクラッチ開発は開発期間が1年以上に及ぶことも珍しくないため、稼働開始のタイミングをいつに設定するかというスケジュール設計と、現場の受け入れ態勢づくりが特に重要になります。

フルスクラッチで構築したTMSへの切り替えは、配車ロジックや運賃計算が刷新前とまったく異なる可能性があるため、稼働直後は現場が新しい操作に習熟するまでの混乱が避けられません。この混乱が2024年問題への対応や2026年4月施行の改正物流効率化法の期限直前と重なると、業務停止や荷主対応の遅延といった深刻な事業リスクに直結します。開発期間が1年以上に及ぶフルスクラッチだからこそ、法改正の施行スケジュールから十分な余裕を持って逆算した稼働目標日を設定し、そこから要件定義・開発・テストの各工程のスケジュールを引くことが不可欠です。開発期間が長期にわたるほど、当初想定していた稼働目標日が近づいた際に開発の遅延が発覚するリスクも高まるため、プロジェクトの節目ごとに「このまま進めば法改正の期限に間に合うか」を確認し、間に合わない見込みが出た場合は段階的な機能提供やパイロット拠点での先行稼働に切り替えるといった柔軟な判断も必要になります。

現場の意見をすべて取り入れようとすると、機能が膨張しスケジュールが破綻する「部分最適の罠」に陥ります。そのためプロジェクト開始時に「全社的な導入の目的とゴール」を関係者全員で明確にし、優先順位を判断する基準を共有しておくことが不可欠です。また、新しいシステムや配車フローへの現場の反発を防ぐためには、経営層自らが「なぜ刷新が必要か」を語り続けるコミュニケーションプランを設計するチェンジマネジメントの実践も欠かせません。導入の目的を「監視」ではなく「不当な荷待ち時間の証拠を残し、ドライバーの労働環境を守るための仕組みである」と再定義し、輸送コスト増・積載効率低下・傭車比率上昇という具体的な課題とあわせて現場が納得できるようなコミュニケーションを、プロジェクトの初期段階から継続的に行うことが、稼働後の定着を左右します。

物流部門・傭車先・情報システム部門を巻き込んだプロジェクト体制構築

フルスクラッチ開発は「ベンダーへの丸投げ」が最も失敗しやすいパターンとされています。稟議を通した後は、発注側である物流部門・傭車先・情報システム部門が主体となって推進体制を築く必要があります。

経営層から十分な権限委譲を受けたプロジェクト責任者を置き、物流部門・情報システム部門の代表者が参画する全社横断のPMO（プロジェクト管理組織）を構築することが不可欠です。あわせて、定期的にステアリングコミッティ（運営委員会）を開催し、経営層と進捗や重要事項を共有する仕組みを作ることで、プロジェクトの途中で発生する重大な意思決定を迅速に処理できる体制を整えます。フルスクラッチのような長期プロジェクトでは、途中で荷主構成や取扱品目、法改正の詳細運用が変化することも珍しくないため、ステアリングコミッティが定期的に「このプロジェクトの前提は今も正しいか」を確認する場として機能することが、プロジェクトの迷走を防ぐ重要な役割を果たします。

配車業務には、「このルートは混みやすい」「この荷主は時間指定が厳しい」といった、ベテラン配車担当者の頭の中にしかない暗黙知が業務の多くを占めているケースがあります。こうした属人的なノウハウを正確に要件定義に落とし込むには、実際に配車を組んできた現場のベテラン担当者をプロジェクトの初期段階から巻き込むことが不可欠です。情報システム部門だけで要件定義を進めてしまうと、机上では正しく見えても実際の輸配送実務とはずれているという問題に、開発の終盤や稼働後になって初めて気づくことになりかねません。あわせて、別会社である傭車先にも、運賃計算ロジックや連携方法についてのヒアリングを要件定義の段階から実施し、教育コストの低いシンプルなUIを一緒に検討することが重要です。物流部門の中でも特に配車・運賃交渉の実務に精通した担当者を要件定義チームに正式にアサインし、稼働後もシステムの意思決定に関与し続けられる体制を作っておくことが、フルスクラッチの成果を最大化する実務上のポイントです。

ベンダー選定プロセスとフルスクラッチ特有のリスク

フルスクラッチ開発を託すパートナー選びは、プロジェクトの成否の8割を決めるとも言われるほど重要な工程です。体制構築と並行して、丁寧なベンダー選定プロセスを設計する必要があります。

要件の曖昧さは、後々の追加費用やスケジュール遅延の最大の原因です。自社の配車・輸配送業務の課題、定量的な目標、予算、希望稼働時期、そしてセキュリティ・可用性・SLAといった非機能要件を具体的に文書化したRFP（提案依頼書）を発行することが出発点になります。選定にあたっては初期費用の安さだけで選ぶのは厳禁で、価格に加えて物流・輸配送業務への理解度、輸送実績データ・運賃マスタ移行のノウハウ、既存の基幹システムやWMSとのAPI・EDI連携の実績、プロジェクト管理とコミュニケーション能力、稼働後のアフターサポート体制を総合的に評価する必要があります。情報システム部門だけでなく物流部門や経営層も含めた多角的な視点で評価することが重要で、複数ベンダーから相見積もりを取るだけでなく、最終候補のベンダーが過去に手掛けたクライアント企業に直接ヒアリングを行うリファレンスチェックを実施し、実際の対応力や遅延の有無を確認することで、本質的な実力を見極めることができます。

スルガ銀行と日本IBMの間では、次期勘定系システムの構築において自社の業務要件に合わないパッケージ選定と要件定義の甘さからプロジェクトが白紙撤回となり、最終的に日本IBM側に約42億円の賠償命令が下される事態にまで発展しました。この事例が突きつけているのは、発注者側が要件定義の主体性を持たず、実質的にベンダー任せの「丸投げ」状態でプロジェクトを進めてしまうと、たとえ相手が実績あるベンダーであっても致命的な失敗を招きかねないという教訓です。TMS刷新においても、物流部門・情報システム部門が自ら業務要件を正確に定義し、進捗をプロジェクト全体で管理する体制を整えて初めて、フルスクラッチという大規模投資に見合う成果を得られます。すべての拠点・協力会社を一度にフルスクラッチで刷新しようとする「ビッグバン方式」も同様にリスクが高いため、業務影響の小さい拠点やルートから徐々に新環境へ切り替える段階的移行を採用し、新旧システムの並行稼働期間を繁忙期を避けて設けることが、フルスクラッチのようなハイリスク・ハイリターンな投資におけるリスクヘッジの基本です。

まとめ

本記事では、TMS刷新におけるフルスクラッチ・オーダーメイド開発について、自社独自開発を選ぶ経営判断の考え方、大規模投資の稟議を通すためのポイント、2024年問題を踏まえたプロジェクトスケジュールとチェンジマネジメント、物流部門・傭車先・情報システム部門を巻き込んだプロジェクト体制構築、そしてベンダー選定プロセスとフルスクラッチ特有のリスクを体系的に解説しました。フルスクラッチは配車・運賃計算プロセスに独自の競争優位性を作り込め、輸送コスト増・積載効率低下・傭車比率上昇という経営インパクトを根本から解消できる一方、投資規模は数千万円から1億円を超え、TCOと50%ルールによる中長期評価、そして「安心を買う」リスクヘッジの視点なしに稟議を通すのは困難です。法改正の施行時期から逆算したスケジュール設計、強力な権限を持つPMOの設置とベンダーへの丸投げを避ける体制構築、そして現場のベテラン配車担当者・傭車先を巻き込んだ要件定義までを一体で計画することが、フルスクラッチによる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を創業。