WMS刷新は、企画から本番稼働・定着まで、5つの段階を順に進めます。企画の段階で目的とKPIを決めておくと、各工程の判断がぶれにくくなり、稼働後の手戻りや現場の混乱を抑えられます。
▼全体ガイドの記事
・WMS刷新の完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
WMS刷新の全体像とプロジェクトの5ステップ
製品選びから始めると、WMS刷新はほぼ確実に迷走します。逆に、先に刷新の理由と改善する数値を決めておくと、各工程の判断基準が明確になります。
WMS刷新が必要になる「限界のサイン」
刷新が必要かどうかは、使いにくさよりも、具体的な業務の症状で判断します。代表的なサインを把握しておけば、どの症状から手を付けるかという優先順位を決める材料になります。
- 保守終了：ベンダーのEOL/EOSLに該当し、OSやデータベースの保守対象外になっている
- 処理能力の限界：EC化で1日の出荷件数が数倍に増え、ピーク時に数秒単位の遅延が発生している
- 標準機能の不足：オムニチャネルや多品種少量出荷に、標準機能で対応しきれていない
- 保守・連携の難化：改修の影響が読めないカスタマイズや、CSVの手作業による二重入力が増えている
特に保守終了を放置すると、セキュリティリスクに加えて、障害時に復旧できないリスクも抱え込むことになります。さらに、ほかの症状も重なっている場合は、刷新を本格的に検討する段階です。
企画から本番稼働までの5ステップ
WMS刷新は、目的とKPIを起点に、段階を一つずつ進めていく取り組みです。各段階で主に何をするかは、流れに沿って見ていきます。
- 企画・構想：目的とKPI、概算予算、提供形態（クラウドSaaS／パッケージ／スクラッチ）の決定
- 要件定義：As-IsとTo-Beを整理したうえで、RFPを作成してベンダーを選定
- 設計・開発：業務設計、システム設定やカスタマイズ、周辺連携の実施
- データ移行・テスト・並行稼働：マスタと在庫の移行、UATと本番相当の運用による検証
- 本番稼働・定着：カットオーバー後の安定運用、KPI監視、継続改善の実施
期間の目安は、SaaS中心なら数ヶ月、パッケージやスクラッチを含む大規模刷新なら半年から1年以上です。また、各段階の判定基準を先に決めておくと、遅延の防止につながります。
要件定義とベンダー選定の進め方
現状業務を曖昧にしたまま要件定義を進めると、現場で使えず、稼働後に手戻りが起きます。そこで、まず業務の実態を一覧にし、改善目標を決めるところから始めます。
As-Is/To-Be分析とKPIの設定
現状業務（As-Is）は、基本フローに加えて、現場独自の例外処理まで洗い出しておく必要があります。ここを見落とすと、移行後の在庫差異の原因になります。
- 基本フロー：入荷から格納、ピッキング、梱包、出荷、棚卸まで
- 例外処理：セット品のバラ返品、不良品の隔離、サンプル品の持ち出し
To-Beは、KPIとして数値で表します。目標の例は、在庫精度99.5%以上、誤出荷率0.05%以下、ピッキング1件あたりの作業時間20%短縮などです。
KPIがあれば、本番後に効果を検証できるだけでなく、投資対効果（ROI）を経営層に説明できます。数千万円の投資で何がどう改善するかを定量で示せることが、予算決裁の材料になります。
RFP作成とベンダー選定のポイント
RFP（提案依頼書）では、どの要件を必須とし、どの要件を希望にとどめるかを線引きします。
- Must／Want：必須要件と希望要件の区別
- 自社固有の業務：温度帯、賞味期限、色・サイズ展開への対応の確認
- 標準機能に寄せる業務：Fit to Standardの範囲の決定
すべてを必須にすると見積もりが膨らみ、譲れない条件が埋もれてしまいます。そのため、コストと適合度のバランスを見ながら線引きすることが欠かせません。
ベンダーの物流ノウハウと開発力は、実績や支援内容で見極めます。選定では、同業種・同規模の移行実績や、ERPやOMSとのAPI・CSV実装経験を確認します。さらに、データ移行と並行稼働の支援方法、旧システムからのデータ引き上げ、契約終了時の提供条件まで確かめます。
AI駆動開発を行う会社なら、スクラッチの工期・コストを30〜70%圧縮し、自社業務に100%合わせるといった選択肢もあります。
データ移行を成功させる進め方（失敗の7割はデータ）
現場では「失敗の7割はデータに起因する」と言われるほどです。実際、商品・ロケーションマスタの不備や在庫数量のずれが、新システムの誤動作につながります。そこで、マスタの整備と在庫の時点整合性を、移行より先に設計します。
マスタクレンジングの基準（12ヶ月ルール）
古いマスタをそのまま移すと、検索性が下がり、誤引当や誤ピッキングを招くため、移行前に整理しておく必要があります。
- 12ヶ月ルール：過去1年間に入出荷実績のない商品は、原則として除外
- 休止ロケーション：使われていない場所は対象外とする
- 重複コード：同一商品の別コードを名寄せして統合
全件を残すと新システムでも混乱が続きます。そのため、移行対象は現場と合意して決め、不要なデータを除くことが刷新の効果につながります。
在庫の時点整合性（差分移行か一括切替か）
移行中も在庫は動いています。抽出後から新システムへ投入するまでに入出荷があると、稼働直後に在庫数が合わなくなります。これが時点整合性の問題です。
- 一括移行：週末などに倉庫を止め、在庫が動かない状態で一度に移す
- 差分移行：抽出後の入出荷だけを追跡し、新システムに反映する方式
一括移行は確実ですが、出荷を止める必要があります。差分移行は停止を避けられる分、設計と検証が難しくなります。
閑散期に出荷を止められるのか、稼働率が高くて止められないのかを、物流カレンダーで確かめてから方法を選びます。
並行稼働（パラレルラン）の進め方と終わらせ方
新旧システムを並行稼働させるとリスクを抑えられますが、運用方法と終了条件が曖昧だと、現場が混乱します。指示系統と終了基準は、あらかじめ定めておく必要があります。
指示系統を一本化するルール
新旧の両方から指示書が出ると、二重ピッキングや二重出荷につながります。そこで、現場に渡す物理的な指示書の出力元を一つに統一します。
- 新システム：ピッキングリストと送り状を出力する
- 旧システム：裏側で結果を照合する検算用
二重入力により、並行稼働中の作業工数は通常の1.5〜2倍になります。そのため、並行稼働と本番切替は繁忙期を避けて、閑散期に設定します。
Exit Criteria（終了条件）の決め方
安定してきたという感覚だけで並行稼働を終えるのは危険です。そこで、旧システムを切り離すための数値基準を、事前に定めておきます。
- 出荷エラー：エラー率0.5%未満の状態が2週間連続すること
- ERP連携：API連携が4週間、障害なく安定していること
- 在庫差異：棚卸差異率が許容範囲内に収まっている状態
この基準を決めておくと、二重入力の負荷から旧システムへ戻る事態や、旧環境を止められないまま費用が続く事態を防げます。そのうえで、条件を満たすまでの期間と、未達だった場合の追加対応も合意しておきます。
本番稼働とリスク管理の進め方
本番稼働では、問題が起きたときに元へ戻す方法まで決めておきます。特に、ロールバックの判断基準と旧環境の保持期間は、押さえておきたい点です。
ロールバックの判断基準と権限
出荷が止まりかけたときに判断が遅れないよう、旧システムへ戻す数値基準と、決定権限を事前に定めておきます。
- 出荷エラー：エラー率が一定値を超えたとき
- 棚卸差異：差異率が許容上限を超えたとき
- 主要連携：復旧できない障害が起きたとき
判断を下す人は、物流責任者か情シス責任者かを決めておきます。判断者が不在のときに備えて、代理も明確にしておきます。基準と権限をセットで定めておくと、計画を実際に機能させられます。
旧システム・旧端末の保持期間
旧環境の扱いは、切り戻しの可否だけでなく、データ抽出費用や契約終了時の負担にも直接関わります。そのため、稼働前に確かめておきたい条件を押さえておきます。
- 旧環境の保持：新システムが安定するまで一式を残すことを推奨（最低3ヶ月）
- 旧端末：廃棄すると切り戻し時に再接続できない場合があるため、保管しておく
- データ抽出費：旧DBのアクセス権が自社になく、テストごとに依頼すると1回あたり数十万円となる場合がある
- 契約条件：ベンダー選定の段階で、解約時のデータ提供条件を取り決め、撤退（Exit）までを見据えた計画にする
WMS刷新でよくある失敗と回避策
失敗を避けるには、在庫精度を損なう例外処理と、プロジェクト体制に起因する問題を、事前に把握しておくことが大切です。
例外処理漏れが生む「ゴースト在庫」
例外処理の記録が漏れると、在庫データと実物がずれてしまいます。特に現場で見落とされやすいのは、次のような場面です。
- セット品の返品：2個1セットの商品のうち1個だけが戻り、単位が食い違う
- 破損品の隔離：物理的に分けて置いても、システム上の状態を変えておくのを忘れる
- サンプル品：記録せずに持ち出す
たとえば、破損品が引当可能なままだと、注文後に商品が見つからず、欠品クレームにつながります。
そこで、要件定義の段階で例外を洗い出し、新しい業務フローに正式な手順として組み込みます。例外を現場任せにせず、システムで扱える形にすることが、在庫精度につながります。
ベンダー丸投げと隠れコストの見落とし
ベンダー任せにすると、現場の実態とずれたシステムになるおそれがあります。そのため、自社が要件定義とUAT（受け入れテスト）を主導します。
テストシナリオには例外ケースも含め、自社が主体となって検証する体制を組みます。費用についても、初期費用だけでなく長期の総額で比べます。
- SaaS：初期0円・月額20万円なら5年で1,200万円
- パッケージ：初期100万円・月額10万円なら5年で700万円
- ハンディ端末：1台あたり5万〜30万円
- 保守費：オンプレやスクラッチは初期構築費の年15〜20%程度
- 倉庫移転：出庫作業費や割増保管料など月額の3〜6ヶ月分の手数料
従量課金が積み重なると、SaaSがパッケージを上回る場合もあります。だからこそ、初期費用だけで判断せず、長期で比べることが大切です。
5〜7年のTCO（総保有コスト）で、見積もりにない費用も含めて比べると、判断の材料がそろいます。
まとめ
WMS刷新は、企画から本番稼働・定着まで5段階で進みます。要件定義と設計・開発を経て、データ移行と並行稼働を終えたあと、本番稼働に進みます。まず、製品を選ぶ前に目的とKPIを数字で明確にしておきます。
マスタ整理と在庫の時点整合性、指示系統と終了条件、ロールバック基準を具体化すると、稼働リスクを抑えられます。
例外処理は業務フローに組み込み、隠れコストは5〜7年のTCOで確かめます。また、現場とベンダーを巻き込みながら、物流カレンダーに沿って無理のない計画を立てます。
▼全体ガイドの記事
・WMS刷新の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。