WMS改修は、現状業務と例外処理を把握したうえで、設計・開発、データ移行と並行稼働の順に進めるのが基本です。この順で進めると、現場の混乱を抑えながら本番稼働に移れます。
判断の軸、工程、データ移行、並行稼働、本番時のリスク管理を、順に説明します。
▼全体ガイドの記事
・WMS改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMS改修の全体像と着手前に押さえるべき判断軸
WMS改修には、既存システムに機能を足す改修から、システム全体を入れ替える刷新（リプレイス）まであります。
出発点になるのは、今の課題が改修で解決できるのか、刷新が必要なのかを見極めることです。
判断を曖昧にしたまま改修を進めると、根本の課題が残ります。その結果、数年後にフルリプレイスへ進み、二重に投資することになりがちです。
改修・刷新・リプレイスの違い
改修と刷新の違いは、既存システムの土台を残すか、基盤ごと入れ替えるかにあります。判断の軸になるのは、必要な変更の範囲と既存環境の状態です。
- 改修：既存WMSを土台に、出荷フロー、帳票、他システムとの連携など必要な箇所を手直しする
- 刷新（リプレイス）：システム基盤ごと新しいものへ入れ替える
- 改修を選ぶ目安：追加機能が既存の仕組みに無理なく載る場合
- 刷新を検討する目安：データ構造そのものを変える必要がある場合
- 刷新を検討する目安：ベンダーの保守が終了している場合
改修は必要な箇所だけを手直しするので、投資額は比較的小さく抑えられます。
数十万円から数百万円規模で収まることも多いです。
ただし、土台が老朽化している場合は、性能や保守性の根本問題が残ったままになります。
一部を直したときに別の機能まで連鎖的に壊れるなら、土台が限界に近いサインです。
刷新は基盤ごと入れ替える大規模プロジェクトです。
費用は数百万円から数千万円、期間は半年から1年以上に及びます。
改修・刷新に着手すべき5つのサイン
改修を本格的に検討するタイミングは、日々の運用に表れます。
- サポート終了：システムやOSのEOL／EOSLが近く、セキュリティ更新を受けられない
- 処理能力の不足：EC化や出荷件数の増加に処理が追いつかず、ピーク時に処理落ちする
- 手作業の連携：ERPやOMSとの連携がCSV取り込みのままで、二重入力や転記ミスが続く
- 改修の属人化：度重なるカスタマイズで仕様が不透明になり、担当者が一人に限られる
- 在庫精度の低迷：在庫精度が上がらず、誤出荷や欠品クレームが減らない
2つ以上当てはまるなら、改修プロジェクトを正式に立ち上げる価値があります。
特に、担当者が一人に限られている場合は、その担当者が退職すると障害時に復旧できないリスクもあります。
経営層に説明するときは、誤出荷1件あたりの再配送費や顧客離反による損失を示します。
二重入力に使う年間の工数も数字に換算すると、投資判断の材料になります。
WMS改修の進め方｜企画から稼働までの全体ステップ
WMS改修は3段階で進みます。第1段階は企画と要件定義です。第2段階は設計と開発です。第3段階はテスト・移行・リリースです。
期間は規模によって変わります。
目安としては、要件定義が1〜2か月、設計・開発が2〜4か月、テストと移行が1〜2か月です。
各工程の完了基準を最初に決めておくと、準備が足りないまま次へ進んで手戻りが起きるのを防げます。
要件定義・企画フェーズ（As-Is／To-BeとKPI設定）
企画では、まず現状業務（As-Is）の流れを整理します。入荷、格納、ピッキング、梱包、出荷、棚卸の流れを、現場の動きに沿って書き出しておきます。
そのうえで、システムで対応する作業と、紙やExcel、人の記憶で運用している作業を分けておきます。例外処理も、現場で在庫差異が起きないよう、あわせて洗い出します。
- セット品：商品をばらして出荷するケース
- 破損品：商品を隔離するケース
- サンプル：マニュアルに載っていない持ち出しのケース
次に、改修後のあるべき姿（To-Be）を描き、達成度を測るKPIを設定します。
目標を数値にしておけば、稼働後に改修の効果を検証できます。
目標の例として、誤出荷率を現状の0.5%から0.1%以下に下げることが挙げられます。また、ピッキング1行あたりの作業時間を20%短縮する目標や、月次棚卸の差異率を1%未満にする目標もあります。
KPIが曖昧だと、改修の結果が「なんとなく便利になった」で終わってしまいます。そのため、投資対効果を経営層へ報告できないおそれがあります。
設計・開発フェーズ（RFP作成とベンダー選定）
要件が固まったら、RFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。
改修機能は、「必須要件」と「希望要件」に分けて記載します。すべてを必須にすると見積もりが膨らみます。また、要件が曖昧だと各社の提案がばらつき、比較できなくなります。
RFPには、ベンダーが見積もりに必要な情報を具体的に盛り込みます。
- 例外処理：自社特有の対応内容を文書で伝える
- 出荷ピーク：繁忙期の出荷量を共有する
- 連携仕様：接続先システムの仕様を明記する
ベンダーは、物流業務への理解度と移行の実績で見極めます。同業種・同規模の改修実績があるか、データ移行と並行稼働の支援範囲はどこまでかを確認してください。
発注側は、契約を終えるときに自社でデータを引き上げられる条件になっているかも押さえておきます。
AI駆動開発により、工期とコストを3割から7割圧縮し、パッケージ並みの予算で自社業務に100%フィットしたシステムを構築する選択肢も現実的になっています。
「パッケージかスクラッチか」の二択で考えるより、各社の提案の幅を比べることが大切です。
テスト・移行・リリースフェーズ
開発後は、ベンダーが単体テストと結合テストを行い、そのあとに自社で受け入れテスト（UAT）を実施します。正常系だけでなく、例外シナリオも必ず網羅してください。
- 返品・キャンセル：通常と異なる受注処理の流れ
- 緊急出荷：急な出荷依頼に対応する流れ
- 障害時の代替運用：システム停止時にどう作業を続けるか
現場の実態に即したシナリオを用意できるかで、本番稼働後のトラブル発生率が大きく変わります。
テストで見つかった不具合は、リリース前に修正したうえで、再テストで解消を確かめます。
リリースでは、データ移行と並行稼働が大きな山場になります。WMS改修の成否を分ける工程なので、後半の章で詳しく見ていきます。
データ移行の実務｜失敗要因の7割を占めるデータの問題
WMS改修の失敗要因は、多くがデータに起因します。長年の運用を続けるうちに、使われなくなった商品マスタや重複した登録、休止中のロケーション情報が蓄積していきます。
不要なデータをそのまま移行すると、検索性が落ちたり引当ミスを招いたりします。
移行は単なるコピーではなく、過去の運用を見直して整理する作業です。
マスタクレンジングの基準（12か月ルールと名寄せ）
クレンジングでは、どのデータを移行対象から外すかを決めます。その判断の目安になるのが、いわゆる12か月ルールです。
- 商品マスタ：過去12か月間に入出荷実績がない商品は、原則として対象外
- 休止ロケーション：使われていないロケーション情報は、原則として対象外
移行するか迷うデータは、現場・営業・購買の各部門に確認して決めます。
名寄せも欠かせません。
同じ商品に表記のゆれがあったり、取引先コードが部署ごとに違っていたりすると、新システムでも在庫を正しく集計できなくなります。
商品コードや取引先マスタの統一ルールを決め、重複をひとつにまとめてから移行すると、改修後の在庫精度が上がります。
この整理作業は、改修効果を出すための前提になります。
在庫の時点整合性（差分移行と業務停止一括の選択）
WMS移行では、在庫の時点整合性が難所になります。抽出から投入までの間も入出荷は続くため、抽出時点の在庫と投入完了時の実在庫にずれが生じます。
この時間差を吸収する方法は、業務停止中の一括移行と差分移行の2つです。どちらを選ぶかは、出荷を止められる時間によって決まります。
- 業務停止一括：週末や連休に倉庫を止め、在庫が動かない状態で移す
- 差分移行：基準データを移した後、入出荷の差分を反映する
一括移行は在庫の整合性を取りやすい反面、出荷を止められる期間が限られる事業では実施が難しくなります。
差分移行は業務を止めずに済みます。ただし、取り込み漏れがあると在庫がずれるおそれがあります。
どちらの方法でも、移行リハーサルで十分に検証してください。
発注側は、自社の出荷カレンダーと停止できる時間を踏まえ、どちらが現実的かを早めにベンダーとすり合わせておきます。
並行稼働（パラレルラン）の正しい進め方と終わらせ方
並行稼働は、新旧のシステムを同時に動かし、新システムが旧システムと同じ結果を出すかを確かめる工程です。
並行稼働は安全策になる一方で、運用を誤ると現場が混乱します。
同じ作業を新旧の両方に入力するため、現場の工数は1.5倍から2倍に膨らみます。そのため、計画段階で必要な工数を見込んでおいてください。
指示系統の一本化（新システム側）
特に重大な事故につながるのが、新旧の両方からピッキングリストや送り状、出荷指示書を出してしまう二重化です。両方の指示で作業すると、同じ商品を二重に出荷したり、逆の指示が混ざったりして、誤出荷が続けて起きます。
- 指示書の出力：現場に渡す物理的な指示書は新システムだけから出す
- 旧システム：結果の照合用として裏で動かす
こうすると、現場の作業を1系統に保てます。新システムに不具合が出た場合も、旧システムの記録と照合して原因を切り分けられます。
Exit Criteria（終了条件）の決め方と切替時期
並行稼働は、終了条件（Exit Criteria）を数値で定めたうえで終えます。「なんとなく安定した」という感覚だけで判断しないためです。関係者でこの条件を合意し、満たしたことを確認してから、旧システムを停止します。
- 出荷エラー率：0.5%未満の状態を2週間続ける
- API連携：ERPなど他システムとのAPI連携が4週間以上安定して動く
- 棚卸差異率：基準値以内に収める
切替は、年末商戦やセールなどの繁忙期を必ず避け、出荷量が落ち着いた閑散期に設定してください。
並行稼働は工数が増えるため、繁忙期に重ねると現場の処理が追いつかなくなります。その結果、「使えないシステム」という不信感を招くおそれがあります。
物流現場のカレンダーに合わせてスケジュールを組むことが、定着の前提になります。
本番稼働とリスク管理｜停止時への備え
本番稼働（カットオーバー）はプロジェクトのゴールであり、最も緊張する場面です。出荷が止まれば、顧客への遅延や売上機会の損失に直結します。
そのため、成功した場合だけでなく停止した場合も想定し、撤退と復旧の手順をあらかじめ決めておきます。それが本番稼働への備えになります。
ロールバックの判断基準と権限の明確化
本番稼働後に旧システムへ戻すかどうかは、事前に定めた基準と権限に沿って判断します。
- 判断基準：出荷エラー率が一定値を超える、または午前中の出荷予定の半分も処理できない
- 判断権限：権限者を1人指名し、現場が迷わず動ける指揮系統を整える
- 事前共有：基準と権限者を文書化し、関係者全員で共有する
出荷停止が長引くほど損害は膨らむため、判断者を探す時間を減らすことが、停止時間の長期化を防ぐことにつながります。
リスク管理は、システムの性能とは別に、プロジェクトを運営する側で備えるべきものです。
旧システム・旧端末の保持期間と隠れコスト
新システムの稼働後も、切り戻しに備えて旧環境は保持しておく必要があります。見積もりには表れない撤退コストも、あわせて確かめておきます。
- 保持する環境：旧システムのライセンスと旧ハンディ端末を本番稼働後も最低3か月保つ
- 保持する理由：新稼働後に不具合が見つかった際、旧端末がないと再接続できず業務が止まるおそれがある
- データ抽出費：旧データベースに自社から直接アクセスできない場合、旧ベンダーへの依頼が必要になり、1回あたり数十万円のスポット費用がかかることもある
- 契約条件：データ引き上げ条件と解約違約金を、改修開始前に契約書で確認する
移行テストやリハーサルのたびにデータ抽出を依頼する可能性もあるため、撤退の出口を確保してから着手してください。
WMS改修でよくある失敗と回避策
WMS改修の失敗には、よく見られる共通のパターンがあります。いずれも、システムの性能よりも業務設計と進め方に起因します。代表的な失敗は2つで、それぞれに対策があります。
例外処理の反映漏れによるゴースト在庫
WMSを導入しても、在庫が必ず合うとは限りません。現場の例外処理がシステムに反映されないと、在庫差異が起きます。
- 返品の単位：2個1セットの商品が1個だけ返品される
- 破損品の隔離：物理的に隔離しても、システムの状態を変え忘れる
- サンプル持ち出し：記録されない運用が残る
なかでも、破損品の状態変更漏れはゴースト在庫を生みやすい例です。出荷できない商品が引当可能な在庫として残るため、受注後に欠品クレームを招きます。
対策としては、要件定義で例外処理を洗い出し、新システムのフローに組み込みます。マニュアルに載っていない運用も含めて、現場ヒアリングを行ってください。
ベンダー丸投げと現場教育不足
自社の業務理解や要件整理を手放してベンダー任せにすると、現場に合わないシステムができてしまい、稼働後に使えない事態に陥ります。
RFPや要件定義は自社が主体となって進め、ベンダーはパートナーとして巻き込んでいくことが大切です。
現場教育も欠かせません。作業者が操作に慣れていなければ、システムが優れていても、稼働初期の生産性は落ちてしまいます。
- 操作研修：本番前に実際の端末で練習する
- マニュアル：現場で使う手順を整備する
- 先行トレーニング：ベテラン作業者が事前に習熟しておく
現場が新システムを自分たちの道具として受け入れられるよう、時間を確保してください。
改修の成否は、最終的に現場への定着で決まります。
まとめ｜WMS改修の成否を分ける移行と運用の進め方
WMS改修は、企画・要件定義から本番稼働までの工程で捉えます。設計と開発を経たあと、データ移行に進みます。並行稼働を行ってから、本番稼働に至ります。製品選びよりも、現状業務と例外処理を把握することが重要です。
不要なデータを整理する作業、在庫の時点整合性の確保、指示系統を一本化した並行稼働も、成否を分ける要素です。
Exit Criteriaとロールバック基準を数値で定め、旧ベンダーのデータ抽出費や旧システムの保持コストも着手前に把握します。
切替は必ず閑散期に設定し、現場教育も計画に組み込むことが改修成功の鍵です。
工程と注意点を自社の予定に落とし込み、無理のない進め方で改修を実現してください。費用相場、発注方法、開発会社については、関連記事もあわせてご覧ください。
▼全体ガイドの記事
・WMS改修の完全ガイド
▼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を創業。