WMS（倉庫管理システム）のリニューアルを検討し始めると、多くの担当者がまず「どこに、どうやって発注すればよいのか」という壁に突き当たります。現行システムの老朽化やEC化による出荷件数の増加、ERPとのCSV手動連携による二重入力など、刷新すべき理由は明確でも、いざ外注となると要件の整理から発注先の選定、契約条件の確認まで判断すべきことが山積みです。発注のやり方を間違えると、ベンダー丸投げによる現場崩壊や、想定外の追加費用に苦しむことになります。
この記事では、WMSのリニューアルを発注・外注・委託する具体的な方法を、発注前の要件整理から発注先の選び方、丸投げを避けるRFP（提案依頼書）の書き方、契約と撤退で確認すべき条項、外注先と握るべき役割分担、そしてよくある失敗の回避策まで体系的に解説します。物流現場のリアルな落とし穴と隠れコストの実態を踏まえ、発注を成功させるための実務的なポイントをお伝えしますので、ぜひ最後までご覧ください。
▼全体ガイドの記事
・WMSのリニューアルの完全ガイド
WMSのリニューアルを外注する前に整理すべきこと
WMSリニューアルの発注で失敗する企業の多くは、要件を固めないままベンダーに相談を始めてしまいます。発注の成否は、相談前にどれだけ自社の状況を言語化できているかでほぼ決まると言っても過言ではありません。ここでは外注に動き出す前に必ず整理しておくべき3つの論点を解説します。
現行WMSの課題と刷新の目的を言語化する
まず着手すべきは、現行WMSのどこに限界が来ているのかを具体的な事象として書き出すことです。「処理が遅い」といった漠然とした不満ではなく、「ピーク時に出荷指示の取り込みに30分かかる」「ERPへの在庫連携を1日2回の手動CSV取り込みで回しており転記ミスが月10件発生する」のように、数字と業務シーンで表現します。こうした課題が明確になっていれば、ベンダーは的確な解決策を提案できますし、提案内容の良し悪しも判断しやすくなります。
あわせて、刷新によって何を達成したいのかという目的（KPI）も定義しておきましょう。在庫精度を98%から99.9%へ、誤出荷率を0.3%から0.05%へ、出荷リードタイムを20%短縮、といった目標があれば、投資対効果を経営層に説明する根拠にもなります。目的が曖昧なまま発注すると、ベンダーの提案に流されて不要な機能まで盛り込み、費用が膨張する原因になります。
必須要件（Must）と希望要件（Want）を切り分ける
WMSリニューアルの要件は、絶対に外せない必須要件（Must）と、あれば望ましい希望要件（Want）に分けて整理することが極めて重要です。たとえばアパレル業なら色・サイズ別の在庫管理、食品なら賞味期限とロット・温度帯管理は外せないMust要件です。一方で「画面の配色を自社カラーに合わせたい」といった要望はWantに分類します。
この切り分けをせずに「すべて実現してほしい」と発注すると、過剰なカスタマイズで費用が跳ね上がり、属人化やブラックボックス化という今回刷新した原因をそのまま新システムに引き継いでしまいます。標準機能で対応できる業務は標準に合わせる「Fit to Standard」の発想を持ち、Mustだけをカスタマイズ対象とすることで、コストと保守性のバランスを取ることができます。
社内体制と発注範囲を決める
発注前には、プロジェクトを誰が主導するのかという社内体制も固めておく必要があります。情シス担当だけで進めると現場の例外処理が抜け落ち、現場マネージャーだけで進めるとシステム連携の設計が甘くなります。物流部門・情シス・経営層の三者を巻き込んだ体制を組み、責任者を明確にしておきましょう。
そのうえで、どこまでを外注し、どこからを自社で担うのかという発注範囲を線引きします。要件定義から開発・データ移行・並行稼働支援まで一括で委託するのか、要件定義は自社で行い開発以降を委託するのかによって、選ぶべき発注先も契約形態も変わります。この範囲設定が曖昧だと、後工程で「それは契約に含まれていない」という認識齟齬が必ず発生します。
WMSリニューアルの発注先の種類と選び方
WMSリニューアルの発注先は大きく分けて、SaaSベンダー、パッケージベンダー、スクラッチ開発会社の3種類があります。それぞれ得意領域とコスト構造が異なるため、自社の業務特性と発注範囲に合った相手を選ぶことが成功の鍵です。ここでは各タイプの違いと、開発力を見抜くポイントを解説します。
SaaS・パッケージ・スクラッチ開発会社の違い
SaaS型WMSは初期費用を抑えて数ヶ月で導入でき、標準機能が整っている点が魅力です。ただし月額の従量課金が積み上がり、5年・7年のTCO（総保有コスト）で見るとオンプレ型やパッケージ型より割高になるケースがあります。たとえば初期0円・月額20万円のSaaSは5年で1,200万円となり、初期100万円・月額10万円のパッケージの700万円を上回る逆転が起こり得ます。
パッケージ型は自社サーバーに導入してカスタマイズできる柔軟性があり、業種特化型を選べば自社業務にフィットしやすい反面、年間保守費として初期構築費の15〜20%が固定的に発生します。スクラッチ開発は自社業務に100%合わせられますが、半年から1年以上の期間と高額な費用がかかるのが従来の常識でした。どのタイプも一長一短があるため、Must要件とTCO、導入期間の3軸で比較することが欠かせません。
AI駆動開発によるスクラッチ復権という選択肢
近年注目すべき変化が、AI駆動開発による「スクラッチ開発の復権」です。生成AIを活用した開発手法により、従来は高額・長期だったスクラッチ開発の工期とコストを30〜70%圧縮できるようになりました。これにより「自社に100%フィットさせたいが予算が足りない」という発注企業の悩みに、新しい解が生まれています。
「パッケージで妥協するか、高額なスクラッチに踏み切るか」という従来の二項対立は崩れつつあります。パッケージ並みの予算で自社業務に完全に合わせたWMSを構築できる可能性が出てきたため、発注先を選ぶ際にはAI駆動開発の実績を持つ会社も比較対象に加える価値があります。riplaのようにコンサルティングから開発まで一気通貫で支援できる企業であれば、要件整理から内製化に近い柔軟な構築まで相談しやすいでしょう。
物流ノウハウと開発力の両面を見抜く方法
WMSの発注先選びでは、ITの開発力だけでなく物流現場のノウハウを持っているかを見極めることが重要です。提案書がどれも良く見える中で真の実力を見抜くには、自社と同じ業種・同じ規模・同じマテハン構成での導入実績を具体的に聞くのが有効です。「アパレルEC、出荷1日5,000件、自動倉庫連携あり」といった近い条件での実績があれば信頼度は高まります。
あわせて、データ移行や並行稼働の支援経験、ERPやOMSとのAPI連携の実績も確認します。開発はできても移行の泥臭い実務に弱い会社は、本番直前で頓挫しがちです。可能であれば導入企業へのリファレンスチェック（現場担当者への聞き取り）を依頼し、稼働後の在庫精度や現場の定着状況まで確認すると、提案書だけでは見えない実力が浮かび上がります。
丸投げを避けるRFP（提案依頼書）の書き方
RFP（提案依頼書）は、発注の質を左右する最重要ドキュメントです。RFPが曖昧だと各社の提案がバラバラの前提で作られ、比較も検討もできなくなります。逆に作り込みすぎると現場実態と乖離した机上の仕様になりがちです。ここでは丸投げを避けつつ、適切な粒度でRFPを書くポイントを解説します。
RFPに盛り込むべき必須項目
RFPには最低限、プロジェクトの目的とKPI、現行システムの構成、業務フローと取扱品目の特性、Must要件とWant要件、想定する予算とスケジュール、そして連携対象システム（ERP・OMS・TMS・自動倉庫など）を記載します。とくに出荷件数・SKU数・拠点数・ピーク時の処理量といった定量データは、ベンダーが工数を見積もる根拠になるため必ず明記しましょう。
提案フォーマットを統一することも重要です。各社に同じ項目立てで回答を求めれば、機能・費用・期間・体制を横並びで比較できます。費用も初期費用とランニング費用、保守費、追加開発の単価まで内訳を出すよう指定しておくと、後から発生する追加請求を防ぐことができます。
自社特有の例外処理・連携要件の伝え方
WMS刷新で在庫が合わなくなる最大の原因は、現場の例外処理がシステムに反映されないことです。2個1セットで出荷した商品が1個だけ返品される単位の食い違い、破損品を物理的に隔離しても論理ステータスを変更し忘れて引当可能在庫に残るゴースト在庫、サンプルの無記録持ち出しなど、現場の「良かれと思った運用」が在庫差異を生みます。
これらの例外処理をRFP段階で洗い出し、どう扱うかをベンダーに伝えておかないと、要件定義で漏れて稼働後に在庫精度が崩壊します。現場マネージャーへのヒアリングで「イレギュラーなとき、どう処理しているか」を徹底的に聞き出し、RFPに具体例として記載しましょう。ERPとのリアルタイム連携やEDI連携の要件も、データ項目と頻度まで明記して提案の前提を揃えることが大切です。
提案を正しく比較するための評価軸
提案が集まったら、価格だけで選ばないことが鉄則です。Must要件の充足度、自社業種での実績、データ移行・並行稼働支援の手厚さ、保守体制、そして5年TCOの5つを評価軸として点数化し、総合的に判断しましょう。安さに飛びつくと、移行支援が手薄で結局自社が疲弊したり、保守費が後から膨らんだりします。
評価軸ごとに重み付けをして採点表を作っておくと、社内の合意形成もスムーズです。経営層への説明でも「なぜこの会社を選んだか」を客観的な根拠で示せます。発注先選定や費用相場のより詳しい比較は、関連記事で体系的に解説していますので、あわせて参考にしてください。
契約・撤退で必ず確認すべき条項
発注先が決まったら契約に進みますが、ここで多くの企業が見落とすのが「旧システムからの撤退」と「将来また乗り換えるとき」の条項です。新システムの機能ばかりに目が行きがちですが、撤退と出口の条件こそが隠れコストを左右します。ここでは契約段階で必ず確認すべきポイントを解説します。
旧ベンダーからのデータ引き上げ（Exit戦略）
WMSリニューアルで最も見落とされがちな隠れコストが、旧システムからのデータ引き上げ費用です。旧システムのデータベースへの直接アクセス権が自社になく、旧ベンダーに依頼しないとデータを抽出できない契約になっていると、移行テストやリハーサルでCSVを抽出するたびに1回数十万円のスポット費用を請求されます。移行は通常複数回のリハーサルを行うため、累計で数百万円に膨らむこともあります。
これを防ぐには、新システムの選定前に旧システムの契約書を確認し、解約条件とデータの返還条件、DBアクセス権を把握しておくことが必要です。そして新たに発注する契約でも、将来また乗り換える際にスムーズにデータを引き上げられるよう、データのエクスポート形式と費用を明記しておきましょう。Exit戦略を最初に握っておくことが、長期的なコストを大きく左右します。
解約条件・DBアクセス権・知的財産権
契約書では、解約予告期間や最低利用期間、中途解約時の違約金を必ず確認します。SaaSでは最低契約期間が設定されていることが多く、短期で見切ると違約金が発生します。スクラッチ開発の場合は、納品物のソースコードや設計書の著作権・知的財産権が自社に帰属するのか、ベンダーに留保されるのかが重要です。
ソースコードの権利がベンダー側にあると、保守を他社に切り替えたいときに移管できず、結果的にそのベンダーに縛られ続けることになります。将来の選択肢を確保するためにも、知的財産権の帰属とソースコードの開示範囲は契約段階で明確にしておきましょう。あわせて、稼働後の障害対応のSLA（サービス品質保証）や対応時間帯も書面で確認しておくと安心です。
隠れコストを契約段階で潰す
WMS刷新には、システム本体以外にも見えにくい費用が多数発生します。ハンディ端末は1台5万〜30万円かかり、現場の人数分が必要です。Wi-Fi環境の増強、年間保守費（オンプレ・スクラッチは初期構築費の15〜20%）、導入支援コンサル費用なども積み上がります。これらをすべて契約・見積段階で洗い出し、総額を把握しておくことが重要です。
とくにWMS刷新と倉庫移転を同時に行う場合は要注意です。旧倉庫からの出庫作業費、早期解約違約金、割増保管料、棚卸費などで、月額保管料の3〜6ヶ月分に相当する移動手数料が発生することがあります。発注時にこれらの費用を契約書や見積書で明示してもらい、想定外の追加請求を防ぎましょう。費用相場の詳細は関連記事もご参照ください。
外注先と握っておくべき役割分担と責任範囲
WMSリニューアルは発注して終わりではなく、外注先と自社が協働して進めるプロジェクトです。どこまでをベンダーが担い、どこからを自社が責任を持つのかを曖昧にすると、移行や稼働の山場で「それはそちらの担当のはず」という押し付け合いが発生します。ここでは特に責任の所在を明確にすべき3つの領域を解説します。
データ移行とマスタクレンジングの責任
WMS移行の失敗の約7割はデータに起因すると言われます。商品マスタや取引先マスタのクレンジング、名寄せ、ロケーションマスタの整備は、業務を理解している自社が主体となるべき領域です。「過去12ヶ月入出荷実績のないマスタや休止ロケーションは捨てる」といった12ヶ月ルールのような明確な基準を決め、誰がいつまでにクレンジングするかを握っておきましょう。
もう一つの難所が在庫の時点整合性です。データを抽出してから新システムに投入する間にも在庫は動き続けます。週末に業務を停止して一括移行するのか、差分を後から反映する差分移行とするのか、どちらを取るかをベンダーと合意し、抽出・投入のタイミングと差分の扱いの責任分担を明文化することが、移行当日の混乱を防ぎます。
並行稼働とUATシナリオの分担
新システムが要件どおり動くかを検証するUAT（ユーザー受入テスト）は、自社が主体で行う領域です。通常業務だけでなく、先述した例外処理やイレギュラーなケースを網羅したテストシナリオを用意し、現場担当者が実際の業務手順で検証します。ここでベンダー任せにすると、現場特有の使い勝手の悪さが稼働後に噴出します。
並行稼働（パラレルラン）では、新旧両システムを一定期間並行して動かしますが、二重入力で工数が1.5〜2倍に膨らみます。並行稼働の期間と、いつ旧システムを止めるかの終了条件（Exit Criteria）を、発注先とあらかじめ決めておきましょう。「エラー率0.5%未満」「API連携が4週間安定稼働」といった定量的な基準を設定し、誰がその判定を行うかまで握っておくことが重要です。
ロールバック判断とマテハン連携の責任分界点
本番稼働後に出荷が止まる事態に備え、どの数値（エラー率や棚卸差異率）を基準に、誰がロールバック（旧システムへの切り戻し）を判断するのかを事前に決めておく必要があります。判断権限が曖昧だと、トラブル時に意思決定が遅れて被害が拡大します。切り戻しに備え、旧システムや旧ハンディ端末は新稼働後も最低3ヶ月は保持しておきましょう。
自動倉庫やAGV・AMRといったマテハン機器と連携する場合は、責任分界点の合意が特に重要です。WCS/WESとの連携開発は500万〜3,000万円の追加開発になることもあり、複数ベンダーが介在すると障害時にどこの問題か切り分けが曖昧になります。障害発生時の一次対応窓口と切り分けルールを発注先と事前に合意しておくことが、稼働後の安定運用につながります。
WMSリニューアルの発注でよくある失敗と回避策
WMSリニューアルの発注では、毎回同じパターンの失敗が繰り返されています。これらは事前に知っていれば回避できるものばかりです。ここでは特に発生頻度の高い失敗と、その具体的な回避策を解説します。先人の失敗から学ぶことが、自社のプロジェクトを守る最善の方法です。
ベンダー丸投げと現場教育不足
最も多い失敗が、要件定義から運用までベンダーに丸投げしてしまうことです。自社の業務を一番理解しているのは現場であり、ベンダーは物流業務の専門家ではありません。丸投げすると例外処理や現場の運用実態が反映されず、稼働後に「現場で使えないシステム」が出来上がります。要件定義には必ず現場マネージャーを巻き込み、自社が主体的に関与する姿勢が不可欠です。
もう一つが現場教育の不足です。どんなに優れたWMSでも、現場の作業者が使いこなせなければ意味がありません。発注時に操作研修やマニュアル整備、稼働後の問い合わせ対応を支援範囲に含めてもらい、現場が新システムに定着するまで伴走してもらうことが重要です。シミュレーション上最適なフリーロケーションでも、フォークの旋回半径や作業者の慣れを無視すると現場のピッキング速度が落ちる点にも注意しましょう。
繁忙期切替と並行稼働の指示系統二重化
切替時期の判断ミスも深刻な失敗を招きます。出荷が集中する繁忙期にシステムを切り替えると、二重入力で工数が膨らむ中で出荷が回らなくなり、現場が崩壊します。切替と並行稼働は必ず閑散期に設定することが鉄則です。発注時にスケジュールを協議する際は、自社の物流カレンダー上の繁忙期を必ず共有し、無理のない移行計画を組みましょう。
並行稼働中の最大の事故が、指示系統の二重化です。新旧両方のシステムから出荷指示書やピッキングリスト、送り状を出してしまうと、重複ピッキングや誤出荷が連発します。物理的な指示書は新システムのみから出力する「一本化」を徹底し、旧システムは参照用に限定するルールを発注先と現場の双方で共有しておくことが、混乱を防ぐ決め手になります。
まとめ
WMSのリニューアルを発注・外注・委託する際は、まず現行の課題と刷新の目的を言語化し、Must要件とWant要件を切り分け、社内体制と発注範囲を固めることが出発点になります。発注先はSaaS・パッケージ・スクラッチの特性と5年TCOを比較し、AI駆動開発による新しい選択肢も視野に入れて、物流ノウハウと開発力の両面で選定することが大切です。
そして丸投げを避けるRFPで例外処理や連携要件まで明確に伝え、契約段階では旧ベンダーからのデータ引き上げや知的財産権といった撤退・出口の条項を確認し、隠れコストを潰しておきましょう。外注先とはデータ移行・UAT・並行稼働・ロールバックの責任分担を明文化し、繁忙期切替や指示系統二重化といった典型的な失敗を避ければ、WMSリニューアルの発注は着実に成功へ近づきます。自社に最適な発注方法を見極め、現場が定着する刷新を実現してください。
▼全体ガイドの記事
・WMSのリニューアルの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。