WMS刷新を外注するときは、社内課題の整理、発注先の選定、契約と役割分担の確認の順に進めます。この順で進めると、丸投げや準備不足による失敗を防げます。
外注前の準備、発注先とRFP、契約・撤退と役割分担、よくある失敗と回避策の順に、確認すべき点を追っていきます。
▼全体ガイドの記事
・倉庫管理システムのモダナイゼーションの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
モダナイゼーションを外注する前の社内整理
外注の成否は、依頼前の社内整理で大きく変わります。要件が曖昧だと、標準機能だけの見積もりや過剰なカスタマイズの提案が届き、課題の解決から外れるおそれがあります。
現状課題の棚卸しと刷新目的の明確化
まず、発注側が現行WMSの限界を業務への影響と結び付けて書き出します。「古いから」という理由で済ませず、どの事象が起きているかを具体的に捉えることが大切です。
- 連携の手作業：ERPとのCSV取り込みで、二重入力や転記ミスが常態化している
- 仕様のブラックボックス化：過度なカスタマイズのため、改修のたびに高額な見積もりが出る
- 処理能力の不足：EC化で出荷件数が3年で2倍になり、ピーク時に遅延が起きる
達成したいKPIは数値で決めておきます。たとえば、在庫精度99.5パーセント以上、誤出荷率0.1パーセント未満、出荷リードタイム30パーセント短縮といった数値が挙げられます。
目的とKPIは、ベンダーを選ぶ基準にも、受け入れテストの合格基準にもなります。さらに、ROIの数値があると、経営層に投資を説明するときの説得力が増します。
必須要件（Must）と希望要件（Want）の切り分け
要望をすべて必須にすると、パッケージの利点が薄れ、スクラッチ並みの費用と期間になります。そのため、発注側が要望に優先度を付けて分けておきます。
- Must：欠けると業務が止まる要件
- Want：あると便利だが、標準機能で代替を検討できる要件
- 例外処理：在庫差異を招かないよう、個別に丁寧に確認する業務
判断軸はFit to Standard（標準機能に業務を合わせる）とします。そのうえで、アパレルの色サイズ管理や食品の賞味期限・温度帯管理のように、業種特有で外せない要件はMustに入れます。
セット品のバラ返品、破損品の論理ステータス変更、サンプルの無記録持ち出しも、確認が必要な例外です。こうした例外をシステムに反映しないと、ゴースト在庫や在庫差異につながります。
発注先の種類と選び方
発注先は提供形態によって、得意な領域も費用の構造も異なります。そのため、発注側が自社の課題、要件、予算に照らして選びます。
提供形態別の発注先タイプと向き不向き
4つのタイプは、倉庫の規模や要件への適合度、導入期間、長期費用の面で、それぞれ違いがあります。
- SaaS：標準業務に近い中小規模の倉庫向け
- パッケージ：業種特化のテンプレートで自社要件を一部吸収
- フルスクラッチ：大規模・複雑な倉庫の個別業務向け
- AI駆動開発：AIで設計・実装を効率化するスクラッチ開発
SaaSは初期費用を抑えて、数ヶ月で導入できるのが特徴です。一方で、従量課金が積み重なるため、5年・7年のTCO（総保有コスト）ではオンプレやパッケージより割高になることもあります。
パッケージは半年程度で導入でき、年間の保守費は初期構築費の15〜20パーセント程度が一般的です。これに対してスクラッチは、従来、半年から1年以上かかり、高額な費用が課題でした。
AI駆動開発は、工期とコストを3割から7割圧縮できるケースがあります。また、パッケージ並みの予算でスクラッチの自由度を得られる選択肢として、注目されています。
物流ノウハウと開発力の見抜き方
発注側は、提案会社の実力を物流現場の知識とシステム開発力の両面から確かめます。機能の表面的な比較は、その判断材料としては不十分です。
- 移行実務：過去の倉庫刷新での移行の進め方
- システム連携：ERP・OMSとのAPI・EDI、マテハン連携の実績
- 障害時の責任：複数社が関わると責任分界が曖昧になりやすいため、切り分けのルール
カタログ説明に終始し、移行実務の説明が浅い会社には注意が必要です。そこで、在庫の時点整合性をどう扱ったか、並行稼働をどう終えたかを、過去の事例で尋ねてみます。
自動倉庫やAGV・AMRなどの機器との連携経験も、あわせて確かめておきます。特に、WCS/WES連携は500万円から3,000万円規模の追加開発になることがあります。詳しい選定の観点は、関連記事もご覧ください。
丸投げを避けるRFP（提案依頼書）の書き方
RFP（提案依頼書）は、自社の要件を伝え、各社の提案を同じ条件で比べるための文書です。内容が曖昧だと提案や見積もりを比べられず、細かく決めすぎるとベンダーの知見を活かせません。
実現したいことは明確に書き、実現方法はベンダーの提案に委ねます。この線引きが大切です。
RFPに必ず盛り込む項目
各社の見積もりと提案を比べられるよう、RFPには業務の前提、要件、評価方法を揃えて書きます。
- 背景と目標：目的、KPI、現行構成と課題
- 対象範囲：業務範囲、Must・Want、連携先システム
- 提案条件：日程、予算感、提案書に記載する項目
- 評価基準：移行支援、実績、保守、撤退時のデータ引き上げ
連携先には、ERP・OMS・TMS・マテハン機器を含めます。あわせて、1日の出荷件数、SKU数、ロケーション数、ピーク時の処理量を示しておくと、見積もりやインフラ設計の精度が上がります。
提案の評価は、価格の比較だけで決めないようにします。移行支援体制や物流業界の実績、保守・運用サポートも、あわせて判断の材料に含めます。説明会で出た質問をもとに補足資料を出し、RFPの精度を双方向で高めていきます。
自社特有の例外処理要件の伝え方
例外業務はベテラン担当者の頭の中にあり、通常業務に比べてRFPから漏れやすい項目です。稼働後の在庫差異や追加改修を避けるため、発注側が早い段階で共有します。
- セット品：構成品に分けて出荷するケース
- 返品・破損品：返品時の状態区分や隔離方法
- 持ち出し・緊急対応：サンプル品や緊急出荷の扱い
例外業務の一覧は、別紙として添付します。一覧が完璧でなくても、存在を早く伝えておけば、要件定義の段階で深掘りでき、丸投げによる手戻りを防げます。
発注前の整理には、現場のキーパーソンを巻き込みます。こうした準備が、結果としてコスト削減につながります。
契約・撤退で確認すべき条項
契約では、新システムの導入条件に加えて、旧システムからの撤退や将来の移行に関する出口戦略も確認します。想定外の費用は、数十万円から数百万円規模になることがあります。
旧DBアクセス権とデータ引き上げ費用
旧システムの契約によっては、自社でDBにアクセスできません。そのため、抽出を旧ベンダーに頼むたびに費用が発生します。
- 新システム：データを標準形式でいつでも取り出せるか確認
- 旧システム：解約条件とデータ引き上げ費用を把握
- 移行予算：抽出費用を計画に織り込む
旧DBからの抽出は、移行テストやリハーサルで何度も必要になります。契約によっては1回あたり数十万円のスポット費用が、そのたびに積み重なります。
発注側は、CSVやAPIで自社がデータを取り出せる条件と、旧システムの解約条件を事前に確認します。Exit戦略を描いておけば、ベンダーロックインによる将来の高コスト化を防げます。
解約条件・保守・SLAの確認ポイント
月額料金だけで判断せず、契約期間や解約条件、障害時の対応、機器保守まで含めた総額で見ます。
- 解約条件：予告期間、最低契約期間、違約金
- 保守・SLA：対応時間、復旧目標、受付時間
- 機器保守：ハンディ端末やWi-Fi環境の対象範囲
たとえば、初期0円で月20万円の場合は、5年で1,200万円になります。一方、初期100万円で月10万円なら5年で700万円となり、総額が逆転することもあります。
倉庫の停止は出荷遅延に直結するため、発注側はSLAの復旧目標と、24時間365日か平日日中のみかを明記しておきます。また、端末は1台あたり5万円から30万円程度、年間保守は構築費の15〜20パーセントが目安です。
比較には、最低契約期間と保守費を含めた5年から7年のTCOを使います。初期費用に加えて、ランニング費用も契約条件の評価に入れます。
外注先と握るべき役割分担とリスク管理
WMS刷新は、発注側とベンダーの共同プロジェクトです。役割が曖昧なままだと、移行や稼働の場面で責任の押し付け合いが起きやすくなります。
データ移行・UATシナリオの責任分担
データ移行と受け入れテストは、業務知識が要る判断を発注側が担い、ツールや環境の準備をベンダーが担う形が現実的です。
- 発注側：データの整理基準、テストシナリオ、合否判定
- ベンダー：抽出・変換・投入ツールの開発と実行、テスト環境とデータの準備
- 共同確認：例外業務を含む確認範囲と合格基準
失敗の7割はデータに起因するといわれています。そのため、マスタのクレンジングや名寄せは業務知識が欠かせず、ベンダーに任せきりにはできません。
たとえば、過去12ヶ月に入出荷実績のないマスタや休止ロケーションを除く「12ヶ月ルール」は、自社で決めておきます。
UATシナリオには、通常業務に加えて例外業務も含めます。誰がいつ何を確認し、どの基準で合格とするかも、文書にまとめます。
また、役割分担表（RACIチャート）を作り、双方で合意しておきます。
並行稼働とロールバックの責任境界
並行稼働では、指示系統と切り戻しの条件を先に決めておきます。二重の出荷指示や判断の遅れを避けるためです。
- 出荷指示：物理指示書は新システムからだけ出す
- 切替時期：現場工数を考慮して閑散期に設定
- ロールバック：判断指標と決定権限を事前に定める
- 旧環境：新稼働後も最低3ヶ月は旧システム・端末を保持
新旧両方から出荷指示書やピッキングリストを出すと、重複ピッキングや誤出荷が起きてしまいます。並行稼働では現場工数が1.5倍から2倍に増えるため、繁忙期の切替は避けます。
エラー率や棚卸差異率がどの数値を超えたら、誰が旧システムへ戻すかを決めておきます。完全移行の条件（Exit Criteria）も、書き出しておきます。
完全移行の条件には、たとえば誤出荷率0.5パーセント未満や、API連携が4週間連続で安定することが挙げられます。一方、旧端末を早く破棄してしまうと旧環境へ再接続できず、業務が止まるおそれがあります。
発注でよくある失敗と回避策
発注の失敗は、技術の問題より準備不足やコミュニケーション不足から起きることがあります。よくある事例と、その回避方法を順に見ていきます。
ベンダー丸投げと現場教育不足
要件定義を業務知識のない情シスやベンダーだけで進めると、現場の運用から外れたシステムになりやすくなります。
- 現場参加：要件定義に現場のキーパーソンを加える
- 教育計画：稼働前の訓練とマニュアル整備を含める
- 手順書：自社業務に即した内容をベンダーと作る
フォークリフトの旋回半径や重量物の配置、作業者の熟練度を考慮しない設計では、ピッキングの動線が非効率になり、速度が落ちるおそれがあります。
現場が使いこなせなければ、システムの効果は出ません。そのため、操作に習熟した現場リーダーを育てておくことが、定着にもつながります。
繁忙期切替と隠れコストの見落とし
切替時期や見積もり外の費用を見落とすと、現場の混乱や予算不足を招きます。判断は、物流カレンダーと総額を基準に行います。
- 切替時期：閑散期を選び、十分な余裕を持たせる
- 費用確認：倉庫移転や旧契約の費用も含めて見積もる
- 発注判断：隠れコストを含めた総額で比較する
繁忙期は、並行稼働の二重入力と習熟不足が重なるため、現場が混乱しやすくなります。切替日は、ベンダー都合に合わせず、自社の物流カレンダーから決めます。
WMS刷新と倉庫移転を同時に行うと、出庫作業費や早期解約違約金、割増保管料、棚卸費が発生することがあります。
移動手数料が月額保管料の3〜6ヶ月分相当になる場合もあります。予算に織り込まないと、後半に資金が逼迫します。詳しい費用構造や進め方は、全体ガイドや関連記事もあわせてご覧ください。
まとめ
発注前に現状の課題とKPIを整理し、MustとWant、例外業務を切り分けておきます。発注先は、SaaS、パッケージ、スクラッチ、AI駆動開発の4つを比べて選びます。
RFPでは目的を伝え、実現方法は提案に委ねます。契約では、データ引き上げや解約、保守・SLAを確認し、移行やUAT、切替の役割についても合意します。
閑散期の切替、旧環境の保持、隠れコストの予算化まで決めておくことが、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を創業。