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

WMS改修は、既存WMSの特定の機能だけを直す小規模な修正です。一方、フルスクラッチ・オーダーメイド開発は既存WMSを作り直す全面的な投資で、費用は8,000万円〜数億円以上、期間は1年以上に及びます。どちらにも一長一短があるため、優劣ではなく、自社の状況に照らした使い分けが要ります。

  • 部分改修とフルスクラッチ・オーダーメイド開発の違い
  • 部分改修が向いているケース
  • フルスクラッチに切り替えるべき判断指標

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

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

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

部分改修とフルスクラッチの費用と期間を左右で比較した図解。
選ぶ方式によって投資規模と所要期間に幅があります。

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

先行する6つの記事群との違い(対極にある2つの選択肢という位置づけ)

先行する記事群では、主に次のテーマを扱ってきました。

  • WMSリプレイス:自社スクラッチ維持か他社製品への乗り換えかというビルド・バイ判断
  • WMS刷新:経営インパクトの定量化と稟議承認のプロセス
  • WMSのリアーキテクチャ:マイクロサービス化という技術的な再設計
  • WMSのモダナイゼーション:リホスト、リプラットフォーム、リファクタリング、リビルド、リプレースという5つの技術的アプローチの使い分け

これらの記事群で語られる「リビルド」や「フルスクラッチ」は、既存WMSを土台にしつつ、ロケーションマスタや在庫データベースの構造も含めてクラウドネイティブに作り直す、最も大規模な選択肢です。

本記事で扱うのは、フルスクラッチか部分改修かを判断するための視点です。実務では、「特定のロケーションだけ改修したい」という相談が、要件を詰めるうちに「実はシステム全体に手を入れないと解決しない」と分かるケースも珍しくありません。この視点は、そうした見誤りを防ぎ、着手前に正しいスコープを見極める助けになります。

先行する6つの記事群は、いずれかの選択肢を前提に深掘りしてきました。これに対し、本記事は2つの選択肢を天秤にかけるための判断材料を提供する点で、独自の位置づけを持っています。

規模感・費用感の対比

基幹システム全体の再構築にあたるフルスクラッチ開発は、8,000万円〜数億円以上の費用と、1年以上という長期間を要します。これに対して、特定機能に絞った部分改修は500万〜2,000万円程度に収まりやすく、ごく軽微な画面修正だけなら、数十万円〜というさらに低い予算でも実施できる場合があります。

この費用差は10倍から100倍以上に及ぶこともあり、期間も約1〜3ヶ月と、フルスクラッチの1年以上に比べて数分の1から10分の1程度に短くなります。両者は規模の大小だけでなく、投資判断の重さそのものが異なります。フルスクラッチは経営層の稟議を要する大型投資で、部分改修は部門予算の範囲で決められることが多く、この重さの違いが期間の差にも表れています。

また、体制の面では、フルスクラッチはPM・現場リーダー・IT部門・外部ベンダーからなり、要件定義・設計・開発・移行の各フェーズに専任担当者を置くのが一般的です。一方、部分改修は物流部門の現場責任者と情報システム部門の担当者、依頼先の担当者数名という小さな体制で完結することが多く、この軽さが着手までのスピード感の差を生みます。

ポイント

部分改修とフルスクラッチは、規模・費用・期間・投資判断の重さが異なります。着手前に課題の広がりを見極めておくと、見積もりを同じ前提で比べやすくなります。

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

フルスクラッチと比べたうえで、部分改修が合理的になるのは、現行WMSの状態や課題の範囲が特定の条件を満たしているときです。ただし、その条件に当てはまらない場合は、部分改修という選択肢そのものを慎重に見直す必要があります。

現行WMSが安定稼働し、課題が局所化している場合

現在のWMSが安定して稼働し、業務プロセス全体を大きく変える予定がない場合には、部分改修が適しています。課題が局所化している例は、「特定ロケーションのピッキング動線だけが非効率」「ハンディターミナルの特定画面の入力が面倒」といったものです。部分改修が向いているかを判断する第一のチェックポイントは、システム全体ではなく特定の一部分に困りごとが集中しているかどうかです。

その課題を解決すれば当面の業務が回ると見通せるなら、フルスクラッチより部分改修でスピーディーに改善するほうが投資対効果は高くなります。一方で、困りごとが複数の機能や拠点にまたがって同時多発的に起きている場合は、部分改修を積み重ねてもいたちごっこになりやすく、次章で述べる判断指標も確認しておくべきです。

実務上の目安として、直近1年以内に大きなシステムトラブル(原因不明のエラー、データ不整合、長時間の業務停止など)が発生していないかも参考になります。安定稼働が続いている企業は基盤そのものが健全なケースが多く、そのため部分改修の前提条件を満たしていると考えられます。

低予算・短納期でスピーディーに改善したい場合の進め方

フルスクラッチのような大型投資に踏み切る予算的な余裕がない、あるいは繁忙期を控えて今すぐ現場の課題を解消したいという場合、部分改修は現実的な選択肢になります。部分改修であれば約1〜3ヶ月で完了し、既存のデータベースやインフラをそのまま流用できるため、要件定義・設計の期間も大幅に短縮できます。

ただし、この進め方が有効なのは、今ある課題を今あるシステムの枠内で解決できる場合に限られます。現状分析の段階で課題が本当に局所的かを丁寧に見極め、影響範囲がロケーション単位・画面単位にとどまることを確認してから着手することが、低予算・短納期のメリットを最大限に活かす条件になります。

部分改修を選ぶ企業の多くは、まず小さく試し、効果が見えたら次の改修に進むという段階的な投資のスタイルを取っています。1回の改修で得られた効果(作業時間の短縮、誤ピッキングの削減など)を数値で記録しておくと、次の改修を提案する際の説得材料になります。その結果、社内での改修活動そのものが続きやすくなるという副次的な効果も期待できます。

ポイント

部分改修が合うのは、現行WMSが安定し、困りごとが特定の機能や拠点に限られるときです。複数の機能や拠点にまたがるなら、後続の判断指標に照らして見直すべきです。

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

保守費用、システムの複雑度、ブラックボックス化の3指標を並べた図解。
3つの兆候を個別に点検すると、改修継続の前提を見直しやすくなります。

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

保守費用が開発費の20%超過・スパゲッティ化・ブラックボックス化

第一の指標は、保守費用が開発費(初期改修費)の年間15〜20%の相場を大幅に超えているかどうかです。改修を重ねるたびに保守外の追加費用が積み上がり、年間で数十万円〜数百万円に達しているなら、改修を続けるコストと作り直すコストを比べるタイミングです。月額保守費用5万円のシステムで保守外の追加費用が年間平均80万円かかっていた企業は、クラウドERPへの全面刷新を決断しました。

その結果、ランニングコストを40%削減できたと報告されており、この種の逆転現象は定期的に点検する価値があります。また、第二の指標は、システムの複雑度です。度重なる改修でプログラムが絡み合い、少しの改修でも想定外の不具合(デグレード)が多発するようになると、部分改修そのものがリスクの高い行為になります。

さらに、第三の指標は、ブラックボックス化の度合いです。構築時の担当者がすでに退職し、内部構造を誰も説明できないまま部分改修を繰り返すことは、深刻な事故を招くリスクを高めます。この3つの指標のどれかに強く当てはまる場合は、部分改修という選択肢の前提が崩れていると考えるべきです。

業務フローの抜本的見直し・大規模要件がある場合

もうひとつの判断材料は、要望の性質そのものです。倉庫の業務フローを抜本的に見直したい、複数拠点を統合管理したいといった要望は、そもそも部分改修の範囲を超えています。自動倉庫やAGV(無人搬送車)、ピッキングロボットなど高度なマテハン機器との独自連携を新たに構築する場合も、部分改修では対応しきれません。

既存の自社開発基幹システムと密結合な連携をゼロから再設計する場合も、フルスクラッチによる作り込みが要ります。判断で迷うのは、「最初は部分改修のつもりだったが、要件整理で複数の機能に影響が及ぶと分かった」ケースです。そのような場合は、部分改修の枠に無理に収めず、対象範囲を再定義してフルスクラッチも含めて費用対効果を比べ直すことが重要です。

また、要件整理の途中で「ついでにあの機能も直したい」という要望が次々と追加される状況も、部分改修の枠を超えつつある兆候として注意すべきです。要望が雪だるま式に膨らんだら、いったん立ち止まって全体像を俯瞰し、部分改修の積み重ねかフルスクラッチかを再検討するタイミングです。

ポイント

保守費用の膨らみ、スパゲッティ化、ブラックボックス化のどれかに強く当てはまるなら、部分改修の前提は崩れています。大規模な要件があるときも、作り直しを含めて比べ直します。

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

現行仕様の文書化、小さな部分改修、結果の確認、判断ラインの合意を示すチェックリスト。
記録と事前合意が、次の判断を支える材料になります。

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

現行仕様の「読める化」を先行させる重要性

ブラックボックス化が進んだWMSでも、まずは現行仕様を文書化する「読める化」から手をつけるべきです。仕様書が残っていない、あるいは古い仕様書が実態と乖離しているWMSでは、フルスクラッチに切り替えるにしても、既存ロジックを解析するリバースエンジニアリングの工数が別途かかります。

この読める化を部分改修の一環として小さく始めておくと、フルスクラッチに切り替える際の初期分析コストを事前に圧縮できます。さらに、読める化を進めるなかで「実はこの部分は部分改修でも対応できる」と分かることもあります。読める化と改修は、並行して進めることで、どちらの選択肢を取っても後工程の手戻りを減らせます。

具体的には、部分改修を1件依頼するたびに、対象範囲のデータフロー図や画面遷移図を依頼先から納品してもらう運用にします。そうすると、改修を重ねるうちに、システム全体のドキュメントが自然と蓄積されていきます。この積み重ねは、将来フルスクラッチを検討するときの初期分析コストを大きく圧縮します。

段階的な見極め方(小さく改修して様子を見る)

判断に迷う場合は、まず小さな部分改修を1件実施し、その結果を材料に次の判断を下すのも有効です。得られるのは、影響範囲の広さ、デグレードの有無、現場の反応、想定外の追加費用の有無などの情報です。この改修がスムーズに完了し、追加のトラブルもなければ、当面は部分改修を積み重ねても問題ないと判断できます。

逆に、1件の改修でも影響調査に想定以上の時間がかかる、デグレードが複数箇所で見つかるといった場合は、複雑度が想定より高いシグナルです。そのときは、フルスクラッチへの切り替えを早めに検討すべきです。あわせて、「保守費用が開発費の20%を超えたら見直す」「同じ画面に3回以上改修が出たら根本原因を調べる」といった判断ラインを、経営層や関係部門と事前に合意しておきます。

そうした判断ラインを、情報システム部門だけで抱え込まず、物流部門の責任者や経営層とも共有しておくと、感覚や声の大きさに左右されず、データに基づく意思決定ができます。また、いざフルスクラッチへの切替を提案する場面でも、唐突な大型投資と受け取られず、改修の延長線上にある自然な意思決定として合意を得やすくなります。

ポイント

判断に迷うときは、まず小さな部分改修を1件行い、その結果を材料に判断します。判断ラインを事前に社内で合意しておくと、感覚に左右されにくくなります。

まとめ

フルスクラッチは8,000万円〜数億円以上・1年以上を要するのに対し、部分改修は500万〜2,000万円程度・約1〜3ヶ月と、費用も期間も大きな開きがあります。

現行WMSが安定稼働し課題が局所化している場合は、部分改修が合理的です。一方で、保守費用が開発費の20%を超えている、スパゲッティ化・ブラックボックス化が進んでいる、業務フローの抜本的な見直しが必要といった場合は、フルスクラッチへの切り替えを検討すべきタイミングです。

課題の局所性、システムの健全度、投資できる予算と期間の3つを照らし合わせ、そのときどきで最適な選択を積み重ねることが、WMSと長く付き合ううえで現実的です。

まずは現行仕様の読める化を進めつつ、小さな部分改修を通じてシステムの複雑度を見極めることをお勧めします。判断に迷う場合は、改修とフルスクラッチの両方に精通したパートナーに相談するとよいでしょう。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。