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