WMSのリニューアルの発注/外注/依頼/委託方法について

WMSリニューアルの発注は、要件を整理し、発注先を選び、RFPと契約・役割分担を決める順に進めるのが基本です。この順番を守ると、現場に定着する刷新を実現しやすくなります。

発注前の準備から失敗の回避策まで、この順番に沿って確認していきます。

▼全体ガイドの記事
・WMSのリニューアルの完全ガイド

WMSのリニューアルを外注する前の整理事項

WMSのリニューアル前に整理する課題と目的、要件、社内体制と発注範囲の3項目を示す図。
3つの観点をそろえると、提案内容を比べる軸ができます。

相談前に自社の状況を言語化できているかで、発注の成否はほぼ決まります。要件を固めないまま相談すると、ベンダーの提案に流されやすくなるため、発注の前に自社の課題、要件、体制を整理しておきましょう。

現行WMSの課題と刷新の目的の言語化

現状と目標を整理するときは、課題を具体的な業務場面ごとに書き出し、刷新後のKPIも合わせて決めておきます。

  • 処理時間:ピーク時の出荷指示取込に30分かかる
  • 現行の課題:システムの老朽化、EC化による出荷増
  • 連携ミス:ERP在庫連携は1日2回の手動CSVで、転記ミスが月10件
  • KPI例:在庫精度98%から99.9%、誤出荷率0.3%から0.05%
  • 短縮目標:出荷リードタイムを20%短縮

数字と業務場面が具体的であれば、提案の良し悪しを判断しやすくなります。また、目標は投資対効果を経営層に説明する根拠にもなります。ただし、目的が曖昧なままだと不要な機能が増え、費用も膨らみます。

必須要件(Must)と希望要件(Want)の切り分け

必須要件と希望要件を分け、どこまでを実現するのかを決めておきます。

  • Must:アパレル業の色・サイズ別在庫管理
  • Must:食品業の賞味期限・ロット・温度帯管理
  • Want:画面の配色を自社カラーに合わせる

すべての要件を実現しようとすると、過剰なカスタマイズで費用が跳ね上がります。さらに、属人化やブラックボックス化を新システムへ引き継ぐ原因にもなります。

そこで、Fit to Standardを意識し、カスタマイズはMustの要件だけに絞ります。標準機能に業務を合わせれば、コストと保守性のバランスが取れます。

社内体制と発注範囲の決定

発注前に社内体制と委託範囲を決めておくと、役割の抜け漏れを防げます。決める際は、次の項目を押さえておきます。

  • 社内体制:物流部門・情シス・経営層の巻き込みと、責任者の明確化
  • 一括委託:要件定義から開発・データ移行・並行稼働支援まで、一式を委託
  • 一部委託:要件定義は自社で行い、開発以降を委託

情シスだけでは現場の例外処理が抜けやすく、現場マネージャーだけでは連携の設計が甘くなりがちです。そのため、物流部門と情シスの両方を巻き込んだ体制にしておく必要があります。

委託範囲によって発注先や契約形態が変わるため、先に線を引いておく必要があります。範囲が曖昧なままだと、後工程で「契約に含まれていない」という食い違いが必ず起きます。

ポイント

課題の数字やMust要件を、社内の担当者どうしで言い切れるかが目安です。言い切れない項目があれば、ベンダーに相談する前に整理し直します。

WMSリニューアルの発注先の種類と選定基準

発注先は、SaaS、パッケージ、スクラッチ開発会社に大別できます。そのうえで、得意領域と費用構造を比べ、自社業務と発注範囲に合う相手を選びます。

SaaS・パッケージ・スクラッチ開発会社の違い

各方式の初期費用、継続費用、適合性を並べて見ると、違いがはっきりします。

  • SaaS:標準機能が整い数ヶ月で導入。初期0円・月額20万円なら5年で1,200万円
  • パッケージ費用:初期100万円・月額10万円なら5年で700万円
  • パッケージの特徴:自社サーバー導入・カスタマイズが可能。業種特化型は業務に合い、標準機能も使える
  • パッケージ保守:年間保守費は初期構築費の15〜20%
  • スクラッチ:業務に100%合わせられるが、従来は半年から1年以上かかり高額

SaaSは月額の従量課金が積み上がるため、5年や7年のTCOで見ると割高になる場合があります。オンプレ型やパッケージ型より高くなるケースもあるので、Must要件とTCO、導入期間を並べて比べるとよいでしょう。

AI駆動開発によるスクラッチ復権という選択肢

AI駆動開発は、スクラッチ開発の工期とコストに新たな選択肢をもたらします。

  • 工期・コスト:生成AIで従来比30〜70%圧縮できる
  • 発注先:AI駆動開発の実績を持つ会社も比較の対象
  • 支援範囲:コンサルティングから開発まで一貫した支援の有無

自社業務に合わせたいが予算が足りない企業にも選択肢が生まれ、パッケージか高額なスクラッチかという二択は変わりつつあります。さらに、パッケージ並みの予算で業務に合わせたWMSを作れる可能性もあります。

riplaのようにコンサルティングから開発まで支援する企業であれば、要件整理から内製化に近い柔軟な構築まで相談しやすいでしょう。

物流ノウハウと開発力の両面を見抜く方法

導入、移行、稼働後それぞれの実績を、提案書とあわせて確かめます。

  • 物流と開発:同業種・同規模・同じマテハン構成の実績
  • 移行と連携:データ移行、並行稼働、ERP・OMSのAPI連携経験
  • 稼働後:導入企業への在庫精度や現場の定着状況の聞き取り

たとえば「アパレルEC、出荷1日5,000件、自動倉庫連携あり」に近い事例は、条件比較に役立ちます。一方で、移行の実務に弱い会社は本番直前に頓挫することもあります。そこで、リファレンスチェック(現場担当者への聞き取り)で実態を確かめます。

ポイント

発注先は、自社業務に近い導入実績があるかで絞ると判断しやすくなります。費用は5年のTCOで比べると、初期費用と月額の差が見えやすくなります。

丸投げを避けるRFP(提案依頼書)の書き方

RFPに記載する目的と現状、業務と要件、計画と連携、処理規模の4分類を示す図。
4分類を同じ形式で示すと、各社の提案を横並びで確認できます。

RFP(提案依頼書)は発注の質を左右します。内容が曖昧だと、各社が異なる前提で提案するため、比較しにくくなります。

一方で、作り込みすぎると現場の実態から離れた仕様になりかねません。比較に必要な情報をそろえ、適切な粒度で作成することが求められます。

RFPに盛り込むべき必須項目

提案の条件をそろえるため、RFPには、目的から処理規模までの4つの分類にわたる情報を記載しておきます。

  • 目的と現状:プロジェクトの目的、KPI、現行システム構成
  • 業務と要件:業務フロー、取扱品目、Must・Want要件
  • 計画と連携:予算、スケジュール、ERP・OMS・TMS・自動倉庫
  • 処理規模:出荷件数、SKU数、拠点数、ピーク時の処理量

処理規模の定量データは、ベンダーが工数を見積もる根拠になります。そのため、可能な限り数字で明記しておきましょう。

各社への提案フォーマットは統一し、機能と費用を同じ項目で回答してもらいます。期間と体制も同じ形式で示してもらうと、横並びで比較できます。

初期費用とランニング費用に加え、保守費と追加開発単価の内訳まで求めます。費用の内訳を先に確かめておくと、後からの追加請求を防げます。

自社特有の例外処理・連携要件の伝え方

在庫が合わなくなる最大の原因は、現場の例外処理が新システムに反映されないことです。そのため、現場の運用例をRFPに含められるよう、次のような事象を洗い出します。

  • 返品単位:2個1セットの商品が1個だけ返品される
  • 破損品:隔離後も論理ステータスが変わらず、引当可能在庫に残る
  • サンプル品:記録のない持ち出しが発生する

抜けがあると稼働後の在庫精度が下がるため、現場マネージャーに「イレギュラーなとき、どう処理しているか」を聞き、具体例を記載します。

ERPのリアルタイム連携やEDI連携は、データ項目と頻度まで明記しておくと、提案の前提をそろえやすくなります。

提案を正しく比較するための評価軸

提案は、次の5つの評価軸で点数化して比べます。

  • Must要件:充足度の確認
  • 自社業種の実績:同業種への導入の確認
  • 移行・並行稼働支援:支援の手厚さ
  • 保守体制:サポートの中身と継続性
  • 5年TCO:5年間の総保有コストの比較

安さだけで選ぶと、移行支援が不足して自社が疲弊したり、保守費が後から増えたりします。そのため、評価軸に重みを付けた採点表を用意しておくとよいでしょう。

採点表は社内の合意づくりにも役立ち、選定理由を経営層に客観的な根拠とともに説明できます。発注先の選定や費用相場の詳しい比較は、関連記事も参考にしてください。

ポイント

RFPは、比較に必要な項目を各社が同じ形式で回答できているかが判断の目安です。作り込みすぎず、処理規模や例外処理を具体的に書けているかを基準に見直してください。

契約・撤退で必ず確認すべき条項

契約では、旧システムからの撤退条件と、将来の乗り換え条件を確認しておきます。出口の条件は、隠れコストの大きさを左右します。

旧ベンダーからのデータ引き上げ(Exit戦略)

旧契約と新契約のデータ引き上げ条件を確認しておくと、移行時の追加費用を抑えられます。

  • 旧契約:自社によるDBへの直接アクセスの可否
  • 抽出費用:旧ベンダーへの依頼では、CSV抽出1回数十万円かかる場合がある
  • 解約・返還条件:旧契約の解約条件とデータ返還条件
  • 新契約:将来のエクスポート形式と費用の明記

移行リハーサルは複数回行うため、抽出費用が累計で数百万円になることもあります。そのため、Exit戦略を先に定めておくと、長期のコストも抑えやすくなります。

解約条件・DBアクセス権・知的財産権

将来の乗り換えに備えて、解約条件、権利、障害対応を契約で確かめておきます。

  • 解約条件:予告期間、最低利用期間、中途解約時の違約金
  • SaaSの契約:最低契約期間が設けられることが多く、短期解約では違約金が発生する
  • 権利帰属:スクラッチのソースコード・設計書の著作権と知的財産権
  • 保守移管:権利がベンダー側だと、保守を他社へ移せない場合がある
  • 開示・障害対応:ソースコードの開示範囲と、書面に明記するSLA・対応時間帯

権利関係を契約段階で明確にしておくと、将来の選択肢を確保できます。

隠れコストの契約段階での洗い出し

システム本体以外の費用も、契約と見積の段階で洗い出し、総額を把握しておきます。

  • 端末:ハンディ端末は1台5万〜30万円で、現場人数分が必要
  • 環境・支援:Wi-Fi増強や導入支援コンサル費用
  • 年間保守:オンプレ・スクラッチは初期構築費の15〜20%
  • 倉庫移転:出庫、早期解約、割増保管、棚卸などの費用

倉庫移転の手数料は、月額保管料の3〜6ヶ月分に相当する場合があります。そのため、金額を契約書や見積書に明示してもらいましょう。費用相場の詳細は、関連記事もご参照ください。

ポイント

契約では、将来の乗り換えやデータ引き上げの条件が書面で確認できるかが目安です。隠れコストは、端末や倉庫移転の費用まで含めて総額で把握します。

外注先と握っておくべき役割分担と責任範囲

データ整備、移行方式、UAT、並行稼働、切戻し判断を、自社とベンダーの役割分担として示す図。
複数の作業領域で担当と判断者をそろえる構成です。

WMS刷新は、外注先と自社が協働するプロジェクトです。役割が曖昧だと、移行や稼働の場面で責任の押し付け合いが起きます。

データ移行とマスタクレンジングの責任

移行の失敗は、約7割がデータに起因すると言われています。そのため、自社とベンダーで作業を分担しておくとよいでしょう。

  • データ整備:自社が商品・取引先のクレンジング、名寄せ、ロケーションマスタ整備を主導
  • 削除基準:「過去12ヶ月入出荷実績のないマスタや休止ロケーションは捨てる」
  • 移行方式:週末停止の一括移行か、差分を反映する差分移行か
  • 責任と時期:担当・期限、抽出投入のタイミング、差分の扱い

抽出から投入までの間も在庫は動き続けるため、担当と期限を明確にし、データの時点をそろえておけば、移行当日の混乱を防げます。

並行稼働とUATシナリオの分担

自社とベンダーの役割を事前に分け、受入テストと旧システム停止の条件をそろえておきます。

  • UAT:自社主導で通常業務と例外処理を含むシナリオを作り、現場が検証
  • 並行稼働:新旧システムを動かす期間と旧システムの終了条件(Exit Criteria)、判定者の合意
  • 終了基準:「エラー率0.5%未満」「API連携が4週間安定稼働」など

UATをベンダー任せにすると、現場特有の使いにくさが稼働後に表面化します。また、並行稼働(パラレルラン)は二重入力で工数が1.5〜2倍になるため、期間の長さも見込んでおく必要があります。

ロールバック判断とマテハン連携の責任分界点

本番稼働後の停止に備えて、判断者と機器連携時の責任を決め、一次対応窓口と障害の切り分けルールも事前に合意しておきます。判断権限が曖昧だと、トラブル時の決定が遅れ、被害が広がります。

  • 切戻し判断:エラー率や棚卸差異率を基準とした判断者の決定
  • 保持期間:旧システムと旧ハンディ端末を最低3ヶ月保持
  • 連携と窓口:責任分界点、一次対応窓口、障害切り分けの取り決め

自動倉庫やAGV・AMRなどのマテハン機器と連携する場合は、どこまでを誰の担当にするかを先に決めておく必要があります。また、WCS/WESとの連携開発は、500万〜3,000万円の追加費用になることもあります。

複数ベンダーが関わると、障害時に問題箇所を切り分けにくくなるため、早い段階で合意しておくことが欠かせません。

ポイント

データ移行、UAT、切戻し判断、マテハン連携のそれぞれに担当者と期限があるかで判断します。曖昧な項目が一つでも残るなら、契約前に決め直すのが目安です。

WMSリニューアルの発注でよくある失敗と回避策

発注では似た失敗が繰り返されるため、事前に起きやすい問題を把握し、対策を発注条件や移行計画に織り込んでおくとよいでしょう。

ベンダー丸投げと現場教育不足

最も多い失敗は、要件定義から運用までをベンダーに丸投げすることです。

  • 要件定義:現場マネージャーの参加と、例外処理や運用実態の反映
  • 教育と支援:操作研修、マニュアル、稼働後の問い合わせへの対応

丸投げすると物流業務の知見や例外処理が抜け、現場で使えないシステムになりかねません。たとえば、シミュレーション上で最適なフリーロケーションでも、フォークの旋回半径や作業者の慣れを無視すると、ピッキング速度が落ちます。作業者が使いこなせなければ、優れたWMSでも意味がありません。そのため、新システムが現場に定着するまでの伴走を、支援範囲に含めてもらいましょう。

繁忙期切替と並行稼働の指示系統二重化

切替時期と指示系統を決めておくと、繁忙期の出荷停滞や二重指示を避けられます。

  • 切替時期:繁忙期を物流カレンダーで共有したうえで、閑散期に移行
  • 指示の一本化:出力元は新システムのみとし、旧システムは参照用にする

繁忙期の切替は二重入力で工数を増やし、出荷を滞らせます。出荷指示書やピッキングリスト、送り状を新旧両方から出すと、重複ピッキングや誤出荷が起きます。

そこで、発注先と現場の双方で運用ルールを共有しておきましょう。

まとめ

発注前には、課題と目的、要件、社内体制を整理し、発注範囲も決めておきます。そのうえで発注先を選ぶ際は、各方式の特性と5年TCOを比べ、物流知見と開発力で判断します。

続いてRFPで例外処理や連携要件を伝え、契約ではデータ引き上げ、知的財産権、隠れコストを確認しておきます。移行と稼働の役割を文書に残せば、繁忙期の切替や指示系統の二重化も防ぎやすくなります。

▼全体ガイドの記事
・WMSのリニューアルの完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。