WMS（倉庫管理システム）の刷新は、現場の出荷を止めずに進めなければならない難易度の高いプロジェクトです。だからこそ「専門のベンダーに外注したい」と考える企業がほとんどですが、ここで安易に丸投げをしてしまうと、要件の食い違いやデータ移行の失敗、稼働後の在庫差異といったトラブルが一気に噴き出します。発注の入口を間違えると、数千万円規模の投資が「使えないシステム」に化けてしまうことも珍しくありません。
この記事では、WMS刷新を発注・外注・委託・依頼する際に押さえるべきポイントを、実際の移行現場で起きる泥臭い問題まで踏み込んで体系的に解説します。外注前の社内整理、発注先の種類と選び方、丸投げを避けるRFPの書き方、契約・撤退時に見落としがちな隠れコスト、そして外注先と握るべき役割分担まで、この1本で発注の全体像を掴めるように構成しました。WMS特有の在庫論点を軸に、失敗しない発注の進め方をお伝えします。
▼全体ガイドの記事
・WMS刷新の完全ガイド
WMS刷新の発注・外注とは｜「丸投げ」が失敗を生む構造
WMS刷新の外注がうまくいかない最大の理由は、システムそのものの良し悪しではなく「自社の業務をどこまで言語化して渡せたか」にあります。倉庫業務は現場ごとに例外処理やローカルルールが積み重なっており、それをベンダーが知らないまま開発が進むと、稼働後に「現場が回らない」という致命的な事態を招きます。発注とは、開発を任せることであると同時に、自社の業務を翻訳して渡す作業でもあるのです。
WMS刷新の外注で最初につまずく理由
多くの企業がつまずくのは、要件が固まらないうちにベンダー選定や見積もり依頼を始めてしまう点です。「とりあえず話を聞いてから決めよう」と進めると、各社の提案フォーマットがバラバラで比較ができず、結局は営業トークの上手さで選んでしまうという失敗に陥ります。WMSの場合、提案書はどれも機能が網羅されていて魅力的に見えるため、真の開発力や物流ノウハウを見抜く軸を自社が持っていないと、表面的な印象で発注先を決めることになりかねません。
もうひとつの落とし穴が、現場を巻き込まないまま情シスや経営層だけで発注を進めてしまうケースです。倉庫の現場担当者は、セット品のバラ返品やサンプルの持ち出し、破損品の隔離といった日々の例外処理を当たり前にこなしています。こうした暗黙のオペレーションがRFPに反映されないと、ベンダーは標準機能だけで設計を進め、稼働後に「在庫が合わない」「現場が手作業に戻る」という結果を招きます。発注の成否は、現場の知見をどれだけ早く吸い上げられるかで決まると言っても過言ではありません。
発注・外注・委託・依頼の違いと使い分け
WMS刷新の文脈では「発注」「外注」「委託」「依頼」がほぼ同じ意味で使われますが、契約形態として区別すると整理がしやすくなります。成果物の完成に責任を負ってもらう「請負契約」と、人員の稼働時間に対して費用を支払う「準委任契約」では、トラブル時の責任の所在がまったく異なります。要件が固まっている刷新なら請負、要件定義や移行支援のように手探りの工程なら準委任、というように工程ごとに使い分ける発想が重要です。
実務では、要件定義は準委任で伴走してもらい、開発・移行は請負で成果物責任を明確にする、というハイブリッドな組み方が増えています。一括で全工程を請負にすると、要件変更のたびに追加見積もりが発生して費用が膨らみやすく、逆にすべて準委任にすると成果物の品質責任が曖昧になります。発注の前段階で「どの工程をどの契約形態で任せるか」を設計しておくことが、後のコストとリスクをコントロールする第一歩です。
外注する前に社内で整理すべきこと
外注の品質は、発注前の社内整理でほぼ決まります。ベンダーに渡す前に「現状の業務」「実現したいこと」「測定したい成果」の3点を自社の言葉でまとめておくことで、提案の精度が上がり、見積もりのブレも小さくなります。ここを飛ばして外注すると、要件のヒアリングだけで数ヶ月かかり、しかも漏れが残るという二重の損失が生まれます。
現状業務（As-Is）と例外処理の棚卸し
まず取り組むべきは、入荷・格納・保管・ピッキング・出荷・棚卸という一連の業務フローを、正常系だけでなく例外系まで書き出すことです。WMS刷新で在庫が合わなくなる真因の多くは、現場が良かれと思って行っている例外処理にあります。2個1セットで出荷した商品が1個だけ返品される単位の食い違い、破損品を物理的に隔離したのに論理ステータスを変更し忘れて発生するゴースト在庫、サンプル品の無記録持ち出しなどは、いずれも標準機能の想定外で起こる現象です。
これらの例外処理を発注前に洗い出し、「新システムでどう扱うか」を方針として持っておくことが重要です。すべてをシステム化する必要はありませんが、少なくとも「どの例外が在庫差異を生むか」を把握していれば、RFPやヒアリングで漏れなく伝えられます。現場担当者へのインタビューやビデオ撮影によるオペレーション観察を1〜2週間かけて行うだけでも、後工程の手戻りを大幅に減らせます。
要件の「必須（Must）」と「希望（Want）」の切り分け
洗い出した要件は、業務が止まる「必須（Must）」と、あれば便利な「希望（Want）」に仕分けします。この切り分けが曖昧なまま発注すると、優先度の低い機能にカスタマイズ費用が膨らみ、本来注力すべき在庫精度や連携の品質に予算が回らなくなります。一般に、過度なカスタマイズは属人化とブラックボックス化を招き、次の刷新でまた同じ苦労を繰り返す原因になります。
判断の軸として有効なのが「Fit to Standard」、つまり標準機能に業務を寄せる考え方です。自社特有の競争力に直結する部分だけをカスタマイズし、それ以外は標準に合わせることで、コストと将来の保守負担を同時に抑えられます。発注の段階で「ここは標準に合わせる、ここは譲れない」という線引きを示せると、ベンダーも適切な提案を返しやすくなり、見積もりの透明性も高まります。
在庫精度・誤出荷率などKPIの設定
外注前にKPIを定義しておくことは、稼働後の評価基準を持つという意味で欠かせません。在庫精度（実在庫と帳簿在庫の一致率）、誤出荷率、ピッキング生産性、棚卸差異率といった指標は、現状値を測っておくことで刷新の効果を定量的に検証できます。たとえば「誤出荷率を現状の0.3%から0.05%へ」「在庫精度を98%から99.9%へ」といった具体的な目標を持てば、ベンダーへの要求も明確になります。
このKPIは、経営層への投資説明にも直結します。数千万円規模の刷新をなぜ今行うのかを問われたとき、誤出荷によるクレーム対応コストや在庫差異による機会損失、人件費削減効果をROIとして示せれば、稟議は格段に通りやすくなります。発注前の整理は、ベンダー対応のためだけでなく、社内合意形成のためにも価値ある作業なのです。
発注先（外注先）の種類と選び方
WMS刷新の発注先は、提供形態によって性格が大きく異なります。自社の出荷規模や業種特性、求めるフィット度に応じて、どのタイプに外注するかを見極めることが重要です。ここを誤ると、過剰投資や機能不足という形で後悔することになります。
SaaS・パッケージ・スクラッチ・AI駆動開発
クラウド型のSaaSベンダーは、初期費用を抑えて数ヶ月で導入できる手軽さが魅力です。一方で従量課金が積み上がり、5年・7年といった中長期で見るとオンプレやパッケージより割高になるケースもあるため、TCO比較が欠かせません。パッケージ型は業種特化の機能が充実しており、アパレルの色サイズ管理や食品の賞味期限・温度帯管理など、自社業種に合った製品を選べば高いフィット度が得られます。
フルスクラッチ開発は100%自社業務にフィットしますが、従来は費用と期間が大きな壁でした。ここに変化をもたらしているのがAI駆動開発です。AIを活用した開発手法により工期とコストを30〜70%圧縮できるようになり、「パッケージ並みの予算でスクラッチ開発」という新しい選択肢が現実味を帯びています。「SaaSかスクラッチか」という従来の二項対立にとらわれず、AI駆動開発によるスクラッチの復権も含めて発注先を検討する価値があります。
物流ノウハウと開発力の見抜き方
提案書はどの会社も洗練されているため、見るべきは「自社と似た業種・規模・出荷形態での実績」と「移行時のトラブル対応経験」です。具体的には、過去のWMS刷新で並行稼働をどう乗り切ったか、データ移行で何件のマスタをどう整理したか、稼働後に在庫差異が出たときにどう原因を特定したかを、事例ベースで質問すると実力が見えてきます。抽象的な機能説明ではなく、現場の固有名詞が出てくるかどうかが、物流ノウハウの有無を見抜く手がかりです。
開発力については、ERPやOMSとのAPI連携実績を契約前に確認することが重要です。「連携できます」という口頭の回答ではなく、実際の連携方式（リアルタイムAPIかCSVバッチか）、エラー時のリカバリ設計、過去の連携実績まで踏み込んで確認しましょう。コンサルティングから開発、稼働後の定着支援まで一気通貫で対応できる会社であれば、工程をまたぐ責任の押し付け合いを避けられ、プロジェクト全体の見通しが立てやすくなります。
マテハン（WCS/WES/AGV）連携の責任分界点
自動倉庫やAGV・AMRといったマテハン機器との連携は、WMS刷新の中でも特に難易度が高い領域です。WCS（倉庫制御システム）やWES（倉庫運用管理システム）を介した連携には、500万円から3,000万円規模の追加開発費が発生することもあり、見積もりの前提として連携範囲を明確にする必要があります。マテハン機器のメーカーとWMSベンダーが別会社になる場合、障害発生時に「どちらの責任か」が曖昧になりがちです。
そのため、発注前に責任分界点を文書で合意しておくことが不可欠です。どこまでをWMSベンダーが担当し、どこからがマテハンメーカーの領域か、障害時の一次切り分けは誰が行うか、といったルールを事前に握っておけば、稼働後のトラブルで現場が止まる時間を最小化できます。複数ベンダーが介在するプロジェクトほど、この切り分けルールの明文化がリスク管理の要になります。
丸投げを避けるRFP（提案依頼書）の書き方
RFP（提案依頼書）は、丸投げを避けるための最も強力なツールです。自社の要件を構造化して伝えることで、各社の提案を同じ土俵で比較でき、見積もりの妥当性も判断しやすくなります。RFPの質が、そのまま発注の成否を左右すると言っても過言ではありません。
RFPに必ず盛り込む項目
RFPには、プロジェクトの目的と背景、現状業務の概要、解決したい課題、必須要件と希望要件、想定スケジュール、予算規模、評価基準を盛り込みます。特に重要なのが、出荷件数や品目数、拠点数、ピーク時の処理量といった定量データです。これらの数字があることで、ベンダーは適切な規模感で提案でき、見積もりのブレが小さくなります。逆に数字が曖昧だと、各社が異なる前提で見積もるため比較が成立しません。
また、既存システムからの移行範囲や連携先システムの一覧、データ移行の対象期間も明記します。評価基準については、価格だけでなく、実績・技術力・移行支援体制・稼働後サポートをどの配分で評価するかを示しておくと、ベンダー側も注力ポイントを把握しやすくなります。RFPは一方的な要求書ではなく、良い提案を引き出すための対話の起点と捉えると、書くべき内容が見えてきます。
自社特有の例外処理・連携要件の伝え方
RFPで最も差がつくのが、自社特有の例外処理をどう伝えるかです。前述したセット品のバラ返品、破損品のステータス管理、サンプル持ち出しといった在庫差異を生む業務を、具体的なシナリオとして記述します。「通常はこう、しかしこういう場合はこう処理している」という形で書くことで、ベンダーは標準機能で対応できるか、カスタマイズが必要かを早期に判断でき、見積もりの精度が上がります。
連携要件についても、単に「ERPと連携したい」ではなく、連携するデータの種類、タイミング（リアルタイムかバッチか）、件数、エラー時の運用までを記述します。ここを曖昧にすると、稼働直前に「想定していた連携と違う」という事態が発生し、追加開発で費用とスケジュールが膨らみます。例外と連携という、後から問題化しやすい2点をRFPで先に潰しておくことが、丸投げを避ける核心です。
契約・撤退時に確認すべき条項（隠れコスト対策）
WMS刷新の発注で見落とされがちなのが、契約と撤退に関わる条項です。新しいシステムの機能ばかりに目が向きますが、旧システムからの撤退コストや、将来また乗り換える際の出口戦略まで考えておかないと、想定外の隠れコストに苦しむことになります。発注の段階でこそ、撤退の条件を確認しておくべきです。
旧DBアクセス権とデータ引き上げ費用
意外な落とし穴が、旧システムのデータベースへの直接アクセス権を自社が持っていないケースです。アクセス権がベンダー側にしかないと、移行テストやリハーサルでデータを抽出するたびに、旧ベンダーへ1回あたり数十万円のスポット費用を支払う羽目になります。刷新プロジェクトでは抽出を何度も繰り返すため、この費用が積み上がって数百万円規模に達することもあります。
こうした事態を防ぐには、新システムの発注時だけでなく、旧システムの契約内容を遡って確認することが必要です。データの所有権が自社にあるか、DBへのアクセス手段が確保されているか、解約時にデータをどの形式でいつまでに引き渡してもらえるかを契約書でチェックします。新しい発注先との契約でも、将来の乗り換えを見据えて、データの可搬性（エクスポート形式や引き渡し条件）を必ず盛り込んでおきましょう。
5年TCOと解約条件の確認
見積もりは初期費用だけで判断せず、5年から7年のTCO（総保有コスト）で比較することが鉄則です。たとえば初期費用0円・月額20万円のSaaSは5年で1,200万円、初期費用100万円・月額10万円のパッケージは5年で700万円となり、初期費用の安さが中長期で逆転する場合があります。ハンディ端末（1台5万〜30万円を人数分）、Wi-Fi環境整備、オンプレ・スクラッチの年間保守費（初期構築費の15〜20%）といった付帯コストも、TCOに含めて検討すべきです。
解約条件についても、最低契約期間や中途解約時の違約金、解約予告期間を事前に確認します。WMS刷新と倉庫移転を同時に進める場合は、旧倉庫からの出庫作業費や早期解約違約金、割増保管料、棚卸費などで月額の3〜6ヶ月分に相当する移動手数料が発生することもあります。発注時にこうした撤退・移転コストまで見積もりに織り込んでおくことで、予算超過の不意打ちを避けられます。
外注先と握るべき役割分担とリスク管理
発注後のプロジェクトを成功させるには、外注先と自社の役割分担を明確にしておくことが欠かせません。「ベンダーに任せたから安心」という丸投げの姿勢では、移行や並行稼働といった山場で必ずトラブルが起きます。誰が何に責任を持つかを工程ごとに握っておくことが、リスク管理の基本です。
データ移行・UATシナリオの責任分担
WMS刷新の失敗の7割はデータに起因すると言われるほど、データ移行は重要な工程です。マスタデータのクレンジングや名寄せ、在庫残高の時点整合性の確保は、ベンダーだけでは判断できない自社業務の知識を要します。「過去12ヶ月間に入出荷実績のないマスタや休止ロケーションは移行対象から外す」といった12ヶ月ルールのような捨てる基準は、自社が主体となって決め、ベンダーが技術的に実装するという分担が現実的です。
UAT（受入テスト）のシナリオ作成も、自社が責任を持つべき領域です。正常系だけでなく、例外処理やイレギュラーなケースを網羅したテストシナリオを用意することで、稼働後の「想定外」を大幅に減らせます。ベンダーが用意する標準テストに任せきりにせず、現場の知見を反映した自社シナリオを加えることが、品質を担保する鍵です。誰がどのテストを担当し、合否をどう判定するかを事前に取り決めておきましょう。
並行稼働とロールバックの責任範囲
新旧システムを同時に動かす並行稼働（パラレルラン）は、二重入力で現場の工数が1.5〜2倍になる負荷の高い期間です。最大の事故は、新旧両方のシステムから出荷指示書やピッキングリストを出してしまう指示系統の二重化で、これが誤出荷を連発させます。物理的な指示書は新システムのみから出す一本化を徹底し、終了条件（Exit Criteria）として「エラー率0.5%未満」「API連携が4週間安定」といった明確な基準を外注先と合意しておくことが重要です。
万一、本番稼働後に出荷が止まった場合のロールバック（切り戻し）についても、判断基準と権限を事前に決めておきます。どの数値（エラー率や棚卸差異率）がどの水準に達したら、誰の判断で旧システムに戻すのかを明文化します。注意すべきは、旧システム用のハンディ端末を破棄してしまうと再接続ができず業務が止まる点です。新システム稼働後も最低3ヶ月は旧端末とライセンスを保持し、切り戻せる状態を維持しておくことが、安全網になります。
WMS刷新の外注でよくある失敗と回避策
WMS刷新の外注では、似たような失敗が繰り返し起きています。先人のつまずきを知っておくだけで、回避できるリスクは少なくありません。ここでは特に頻度の高い失敗とその対策を紹介します。
例外処理ヒアリング漏れとゴースト在庫
最も多い失敗が、例外処理のヒアリング漏れによる在庫差異です。たとえば破損品を物理的に隔離したのに、システム上の在庫ステータスを変更し忘れると、実在しない在庫（ゴースト在庫）が引き当てに使われ、欠品クレームを引き起こします。「WMSを入れれば在庫が自動的に合う」というのは幻想であり、現場の例外処理をシステムにどう反映するかを設計しなければ、新システムでも在庫は合いません。
回避策は、発注前の業務棚卸しで例外処理を洗い出し、RFPと要件定義でベンダーに確実に伝えることです。在庫差異を生む業務パターンをリスト化し、それぞれを新システムでどう処理するかを設計段階で決めておきます。外注先に「在庫が合う仕組み」を任せるのではなく、自社の例外を共有して一緒に設計する姿勢が、ゴースト在庫を防ぐ唯一の方法です。
繁忙期切替・現場教育不足
切替のタイミングを誤る失敗も深刻です。並行稼働や本番切替を繁忙期に行うと、二重入力で1.5〜2倍に膨れた工数に出荷ピークが重なり、現場が崩壊します。切替は必ず閑散期に設定するという物流現場のカレンダー感覚を、発注時のスケジュール設計に反映することが大切です。外注先のスケジュール都合だけで切替日を決めず、自社の繁忙カレンダーを最優先に据えましょう。
もうひとつ見落とされがちなのが、現場教育の不足です。どれだけ優れたシステムを発注しても、現場担当者が使いこなせなければ効果は出ません。マニュアル整備、操作研修、稼働直後のサポート体制を外注先の支援範囲に含めるか、自社で手当てするかを役割分担として明確にしておきます。コンサルティングから定着支援まで一気通貫で対応できるパートナーを選べば、稼働後の立ち上がりがスムーズになり、投資効果を早期に回収できます。
まとめ
WMS刷新の発注・外注は、ベンダーに任せて終わりではなく、自社の業務をどこまで言語化して渡せるかが成否を分けます。外注前に現状業務と例外処理を棚卸しし、必須要件と希望要件を切り分け、KPIを設定しておくことが出発点です。そのうえで、SaaS・パッケージ・スクラッチ・AI駆動開発という選択肢から自社に合った発注先を選び、RFPで例外処理や連携要件を構造化して伝えることで、丸投げによる失敗を避けられます。
さらに、旧DBアクセス権やデータ引き上げ費用、5年TCO、倉庫移転の移動手数料といった隠れコストを契約段階で確認し、データ移行・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を創業。