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

WMS改修とは、既存WMS（倉庫管理システム）を全面的に作り替えるのではなく、「特定ロケーションのピッキング動線だけを見直したい」「ハンディターミナルの特定画面を軽微に修正したい」といった、特定機能・特定モジュールに絞った小規模な修正を指します。これまで解説してきた「WMSのモダナイゼーション」「WMS刷新」「WMS更改」「WMSのリニューアル」「WMSのリアーキテクチャ」「WMSリプレイス」の6記事群は、いずれも既存WMSを全面的に作り替えることを前提としており、技術手法・経営判断・契約起点・UX起点・アーキテクチャ・ベンダー選定という異なる切り口で全面刷新を論じてきました。その中で、フルスクラッチ・オーダーメイド開発（既存WMSを事実上廃棄し、クラウドネイティブなアーキテクチャでゼロから再構築するリビルドというアプローチ）も、その延長線上で語られてきました。いずれの記事も、対象読者は数千万円〜数億円規模の投資を検討できる企業を想定していました。本記事は、これら6記事群とは逆の視点に立ちます。全面的に作り替える「フルスクラッチ・オーダーメイド開発」と、部分的に手を加える「WMS改修」という2つの選択肢を正面から対比し、費用・期間・向き不向きのどこで線引きすべきかを整理します。どちらの選択肢が正解かは企業ごとの状況によって異なるため、自社に当てはめて読み進めることが理解を深める近道です。

本記事では、部分改修とフルスクラッチ・オーダーメイド開発の違いにフォーカスして解説します。両者の規模感・費用感の対比、WMS改修が向いているケース、フルスクラッチに切り替えるべき具体的な判断指標、そして判断を誤らないための実務的な進め方までを体系的にお伝えします。どちらの選択肢にも一長一短があるため、優劣で語るのではなく、自社の状況に照らして適切に使い分けるための視点を提供します。「今の改修案件は本当に部分改修で済むのか、それとも思い切って作り直すべきなのか」という迷いを抱える物流部門・情報システム部門の方にとって、判断の物差しとなる内容です。目の前の見積もりや要望を前に立ち止まったときに、読み返して判断材料として活用してください。

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

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

部分改修とフルスクラッチ・オーダーメイド開発の違い

WMS改修とフルスクラッチ・オーダーメイド開発は、どちらも「既存WMSに何らかの形で手を入れる」という点では共通していますが、規模・費用・アプローチの前提がまったく異なります。まずはこの違いを、他の記事群との位置づけも含めて整理しておきます。両者の違いを正しく理解しないまま話を進めると、経営層への説明や見積もり比較の場面で、まったく異なる規模の話を同じ土俵で議論してしまうという混乱が生じやすくなります。

「WMSリプレイス」が自社スクラッチ維持か他社製品への乗り換えかというビルド・バイ判断を、「WMS刷新」が経営インパクトの定量化と稟議承認のプロセスを、「WMSのリアーキテクチャ」がマイクロサービス化というアーキテクチャの技術的な再設計を、「WMSのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチの使い分けを、それぞれ扱ってきました。これらの記事群の中で語られる「リビルド」や「フルスクラッチ」は、既存WMSを土台にしつつも、ロケーションマスタ・在庫データベースの構造そのものを含めてクラウドネイティブなアーキテクチャで作り直す、最も大規模な選択肢として位置づけられています。本記事が扱うのは、このフルスクラッチという選択肢そのものではなく、「フルスクラッチという大きな投資に踏み切るべきか、それとも部分改修で済ませるべきか」という、選択そのものを判断するための軸です。他の6記事群がいずれかの選択肢を前提として深掘りするのに対し、本記事は2つの選択肢を天秤にかけるための判断材料を提供するという点で、独自の位置づけを持っています。実務では、最初は「特定のロケーションだけ改修したい」という小さな相談から始まったプロジェクトが、要件を詰めていくうちに「実はシステム全体に手を入れないと解決しない」というフルスクラッチ相当の課題であったと判明するケースも珍しくありません。本記事で示す対比の軸は、そうした見誤りを防ぎ、着手前の段階で正しいスコープを見極めるための道具として活用してください。

基幹システム全体の再構築にあたるフルスクラッチ開発は、8,000万円〜数億円以上の費用と、1年以上という長期間を要します。これに対して、特定機能に絞った部分改修であれば500万〜2,000万円程度の範囲に収まりやすく、ごく軽微な画面修正のみであれば数十万円〜というさらに低い予算でも実施可能な場合があります。この費用差は10倍から100倍以上にも及ぶことがあり、開発期間の差も、フルスクラッチが1年以上を要するのに対し、部分改修は約1〜3ヶ月と、数分の1から10分の1程度に短縮されます。両者は単に「規模が大きいか小さいか」という量的な違いだけでなく、投資判断の重さそのものが異なります。フルスクラッチは経営層の稟議を要する大型投資であるのに対し、部分改修は部門予算の範囲内で意思決定できることが多く、この意思決定プロセスの重さの違いが、そのまま開発期間の差にも表れています。また、体制の面でも違いがあります。フルスクラッチはPM・現場リーダー・IT部門・外部ベンダーという複数の関係者からなるプロジェクト体制を組み、要件定義・設計・開発・移行という各フェーズに専任担当者を配置するのが一般的であるのに対し、部分改修は物流部門の現場責任者と情報システム部門の担当者、依頼先の担当者数名という小さな体制で完結することが多く、この体制の軽さもまた、意思決定から着手までのスピード感の違いを生み出しています。

部分改修が向いているケース

フルスクラッチと比較したうえで、どのような条件が揃えば部分改修という選択が合理的になるのかを具体的に見ていきます。逆に言えば、これから挙げる条件のいずれかに当てはまらない場合は、部分改修という選択肢そのものを慎重に見直す必要があるということでもあります。

現在のWMSが安定して稼働しており、業務プロセス全体を大きく変える予定がない場合には、部分改修が適しています。「特定ロケーションのピッキング動線だけが非効率」「ハンディターミナルの特定画面の入力が面倒」というように、現場の課題が局所化されており、その課題を解決すれば当面の業務は問題なく回るという見通しが立つのであれば、フルスクラッチよりも部分改修でスピーディーに改善するほうが投資対効果は高くなります。逆に言えば、部分改修が向いているかどうかを判断する第一のチェックポイントは、「システム全体ではなく、特定の一部分だけに困りごとが集中しているか」という点です。困りごとが複数の機能・複数の拠点にまたがって同時多発的に発生している場合は、部分改修を積み重ねてもいたちごっこになりやすく、次章で述べる判断指標を確認しておくべきです。実務上のもうひとつの目安として、直近1年以内に大きなシステムトラブル（原因不明のエラー、データ不整合、長時間の業務停止など）が発生していないかどうかも参考になります。安定稼働が続いている企業は基盤そのものが健全であるケースが多く、部分改修という選択肢の前提条件を満たしていると考えられます。

フルスクラッチのような大型投資に踏み切る予算的な余裕がない、あるいは繁忙期を控えて今すぐ現場の課題を解消したいという場合、部分改修は現実的な選択肢になります。前の記事で解説したとおり、部分改修であれば約1〜3ヶ月という短納期で完了し、既存のデータベースやインフラをそのまま流用できるため、要件定義・設計の期間も大幅に短縮できます。この進め方が有効なのは、あくまで「今ある課題を、今あるシステムの枠内で解決できる」という前提が成り立つ場合です。現状分析の段階で、課題が本当に局所的なものかどうかを丁寧に見極め、影響範囲がロケーション単位・画面単位にとどまることを確認したうえで着手することが、低予算・短納期という部分改修のメリットを最大限に活かすための前提条件になります。あわせて、部分改修を選ぶ企業の多くは「まずは小さく試してみて、効果が見えたら次の改修に進む」という段階的な投資スタイルを取っています。1回の改修で得られた効果（作業時間の短縮、誤ピッキングの削減など）を数値で記録しておくことで、次の改修を提案する際の説得材料にもなり、結果的に社内での改修活動そのものが継続しやすくなるという副次的な効果も期待できます。

フルスクラッチに切り替えるべき判断指標

部分改修を続けるか、フルスクラッチによる全面的な作り直しに踏み切るかは、感覚ではなく具体的な指標に基づいて判断すべきです。ここでは代表的な3つの指標を解説します。いずれも定量的に確認できる指標であるため、日頃から関連するデータを記録しておくことが、いざというときの迅速な意思決定につながります。

第一の指標が、保守費用が開発費（初期改修費）の年間15〜20%という一般的な相場を大幅に超えているかどうかです。改修を重ねるたびに保守外の追加費用が積み上がり、年間で数十万円〜数百万円規模に達している場合は、改修を続けるコストと、思い切って作り直すコストを比較検討すべきタイミングです。実際に、月額保守費用5万円のシステムに対して保守外の追加改修費用が年間平均80万円発生していた企業が、クラウドERPへの全面刷新を決断し、結果としてランニングコストを40%削減できたという事例も報告されており、この種の逆転現象が起きていないかを定期的に点検する価値があります。第二の指標が、システムの複雑度です。度重なる改修の結果、プログラムが複雑に絡み合う「スパゲッティ状態」に陥り、少しの改修でも想定外の不具合（デグレード）が多発するようになった場合、部分的な改修そのものがリスクの高い行為になっています。第三の指標が、ブラックボックス化の度合いです。WMSを構築した当時の担当者がすでに退職しており、内部構造を誰も説明できない状態でなお部分改修を繰り返すことは、深刻な事故を招くリスクを高めます。この3つの指標のいずれかに強く当てはまる場合は、部分改修という選択肢そのものの前提が崩れていると考えるべきです。

もうひとつの判断軸が、要望の性質そのものです。倉庫の業務フローそのものを抜本的に見直したい、複数拠点を統合管理したいといった要望は、そもそも部分改修の範囲を超えています。また、自動倉庫やAGV（無人搬送車）、ピッキングロボットといった高度なマテハン機器との独自連携を新たに構築したい場合や、既存の自社開発の基幹システムと密結合な連携をゼロから再設計したい場合も、標準的な部分改修では対応しきれず、フルスクラッチによる作り込みが必要になります。実際の判断で迷うのは、「最初は部分改修のつもりだったが、要件整理を進めるうちに複数の機能に影響が及ぶことが分かった」というケースです。このような場合は、無理に部分改修の枠組みに押し込めるのではなく、対象範囲を再定義し、フルスクラッチも選択肢に含めて改めて費用対効果を比較検討する姿勢が重要です。特に、要件整理の過程で「この改修をするなら、ついでにあの機能も直したい」という要望が現場から次々と追加されていく状況は、対象範囲が部分改修の枠を超えつつある兆候として注意深く観察すべきです。要望が雪だるま式に膨らんでいると感じたら、いったん立ち止まって全体像を俯瞰し、部分改修の積み重ねで対応すべきか、フルスクラッチとしてまとめて対応すべきかを再検討するタイミングです。

判断を誤らないための実務的な進め方

部分改修とフルスクラッチのどちらを選ぶかという判断は、一度きりの決断ではなく、継続的に見直していくべきものです。ここでは判断を誤らないための2つの実務的なポイントを解説します。一度どちらかに決めたら固定するのではなく、システムを取り巻く状況の変化に応じて柔軟に見直す姿勢が求められます。

ブラックボックス化が進んだWMSであっても、いきなりフルスクラッチへ全面移行するのではなく、まずは現行仕様を文書化する「読める化」を先行させることが重要です。仕様書が残っていない、あるいは古い仕様書が実態と乖離しているWMSでは、フルスクラッチに切り替えるにしても、既存のロジックを解析するリバースエンジニアリングの工数が別途発生します。この読める化の工程を、部分改修の一環として小さく始めておくことで、フルスクラッチに切り替える際の初期分析コストを事前に圧縮できるだけでなく、読める化を進める過程で「実はこの部分は部分改修でも対応できる」という発見が得られることもあります。読める化と改修の判断は対立するものではなく、両輪として進めることで、どちらの選択肢を取るにしても後工程の手戻りを減らせます。具体的には、部分改修を1件依頼するたびに、その対象範囲のデータフロー図や画面遷移図を成果物として依頼先から納品してもらう運用にしておくと、改修を重ねるうちに自然とシステム全体のドキュメントが蓄積されていきます。この積み重ねが、将来フルスクラッチを検討する段階になった際の初期分析コストを大きく圧縮する資産になります。

判断に迷う場合は、いきなりフルスクラッチに踏み切るのではなく、まず小さな部分改修を1件実施し、その過程で得られる情報（影響範囲の広さ、デグレードの発生有無、現場の反応、想定外の追加費用の有無）を材料に、次の判断を下すという段階的なアプローチも有効です。この小さな改修がスムーズに完了し、追加のトラブルもなければ、当面は部分改修を積み重ねる方針で問題ないと判断できます。逆に、たった1件の改修でも影響範囲の調査に想定以上の時間がかかった、デグレードが複数箇所で見つかったという場合は、システムの複雑度が想定より高いというシグナルであり、フルスクラッチへの切替を早めに検討すべきです。あわせて、経営層や関係部門との間で「保守費用が開発費の20%を超えたら見直しを検討する」「同じ画面に3回以上改修が発生したら根本原因を調査する」といった判断ラインをあらかじめ合意しておくことで、感覚や声の大きさに左右されず、データに基づいた冷静な意思決定ができる体制を整えておくことをお勧めします。こうした判断ラインを情報システム部門だけで抱え込まず、物流部門の責任者や経営層とも共有しておくことで、いざフルスクラッチへの切替を提案する局面になった際にも、唐突な大型投資の提案として受け取られることなく、これまでの改修の積み重ねの延長線上にある自然な意思決定として合意形成を進めやすくなります。

まとめ

本記事では、WMS改修とフルスクラッチ・オーダーメイド開発の違いについて、両者の位置づけ、規模感・費用感の対比、部分改修が向いているケース、フルスクラッチに切り替えるべき判断指標、そして判断を誤らないための実務的な進め方を体系的に解説しました。フルスクラッチが8,000万円〜数億円以上・1年以上を要するのに対し、部分改修は500万〜2,000万円程度・約1〜3ヶ月と、費用も期間も大きな開きがあります。現行WMSが安定稼働し課題が局所化している場合は部分改修が合理的である一方、保守費用が開発費の20%を超過している、スパゲッティ化・ブラックボックス化が進んでいる、業務フローの抜本的見直しが必要であるといった場合は、フルスクラッチへの切替を検討すべきタイミングです。どちらの選択肢が優れているという話ではなく、自社の課題の局所性・システムの健全度・投資できる予算と期間という3つの軸を照らし合わせ、そのときどきで最適な選択を積み重ねていくことこそが、WMSと長く付き合っていくための現実的な姿勢と言えます。まずは現行仕様の読める化を進めながら、小さな部分改修を通じてシステムの複雑度を見極め、判断に迷う場合は改修とフルスクラッチの両方に精通したパートナーに相談することをお勧めします。

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

株式会社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を創業。