WMS（倉庫管理システム）の改修を外部へ発注しようと考えたとき、多くの担当者がつまずくのは「何を、どこまで、どの会社に頼めばよいのか」という入口の部分です。WMS改修は単なるシステムの入れ替えではなく、入出庫やピッキング、在庫引当といった現場オペレーションそのものを作り直す作業に近く、発注の進め方を誤ると本番稼働後に誤出荷や在庫差異が多発し、現場が混乱します。発注先の選び方ひとつで、数百万円から数千万円の費用と数ヶ月の工期、そして移行後の在庫精度までが大きく左右されるのです。
この記事では、WMS改修を外注・委託する前に整理すべき要件の固め方から、丸投げを避けるためのRFP（提案依頼書）の書き方、ベンダーの実力の見抜き方、契約・撤退時に確認すべき条項、そして外注先と握るべき役割分担までを、物流現場の実務に即して体系的に解説します。特に、競合記事では語られにくい「旧ベンダーからのデータ引き上げ費用」や「並行稼働の責任分界点」といった発注時にこそ効いてくる論点まで踏み込みますので、発注準備の実務書としてご活用ください。
▼全体ガイドの記事
・WMS改修の完全ガイド
WMS改修の発注・外注とは｜まず押さえる全体像と発注先の選択肢
WMS改修の発注とは、自社の倉庫業務に合わせてシステムを新しく作り直す、あるいは既存システムを大きく作り替える作業を外部の専門会社へ委託することを指します。発注先には大きく分けて、クラウド型WMSを提供するSaaSベンダー、パッケージ製品をカスタマイズするパッケージベンダー、ゼロから設計するスクラッチ開発会社、複数システムをまとめて統括するSIerの4つのタイプがあります。それぞれ得意領域と費用構造が異なるため、自社が抱える課題に合った相手を選ぶことが発注成功の第一歩です。
発注先の4タイプとそれぞれの特徴
SaaSベンダーは月額課金で短期間に導入できる反面、自社固有の例外処理に合わせた作り込みには限界があります。パッケージベンダーは物流業務の標準機能を備えていますが、カスタマイズが膨らむと費用が一気に跳ね上がる傾向があります。スクラッチ開発会社は自社業務に100%フィットさせられる一方、要件定義の精度がそのまま品質に直結します。SIerは基幹システムやマテハン機器との連携を含む大規模案件に強い半面、下請け構造になりやすく、コミュニケーションの階層が増える点に注意が必要です。
近年は、AI駆動開発によってスクラッチ開発の工期とコストが30〜70%圧縮できるようになり、「パッケージ並みの予算で自社に100%フィットしたWMSを作る」という選択肢が現実的になってきました。これまで「カスタマイズが高いからパッケージで妥協する」という発想が一般的でしたが、その前提が崩れつつあります。発注先を検討する段階で、この新しい選択肢も視野に入れておくと、後悔のない判断につながります。
自社内製と外注の判断基準
WMS改修を自社の情報システム部門で内製すべきか、外部に外注すべきかは、社内の開発リソースと物流ドメイン知識の有無で判断します。倉庫業務の例外処理やマテハン機器の制御は専門性が高く、社内SEだけで完結させるのは現実的に困難なケースがほとんどです。一方で、業務要件の言語化や現場との調整は自社にしかできない領域であり、ここを外注先に丸投げすると失敗します。実務としては「業務要件の整理と意思決定は自社、設計・開発・連携の実装は外注」という役割分担が現実的な落としどころとなります。
WMS改修を外注する前に整理すべきこと
外注先に相談する前に自社で要件を整理しておくことが、見積精度とプロジェクト成功率を大きく左右します。要件が曖昧なまま発注すると、後から「これも必要だった」という追加要望が次々に発生し、当初見積の1.5倍から2倍に費用が膨らむことも珍しくありません。発注前の整理は手間がかかりますが、ここに時間をかけるほど後工程のトラブルが減るため、最も投資対効果の高い準備工程といえます。
現状業務の棚卸しと課題の言語化
まず取り組むべきは、現状業務（As-Is）の棚卸しです。入荷・検品・格納・ピッキング・出荷・棚卸といった一連の流れを、現場のベテラン担当者にヒアリングしながら洗い出します。このとき特に重要なのが、マニュアルに載っていない「例外処理」を漏らさず拾うことです。セット品をバラで返品する処理、破損品を物理的に隔離したあとの在庫ステータス変更、サンプル品の無記録持ち出しといった現場の慣習は、放置すると新システムで在庫差異やゴースト在庫を生む温床になります。
課題の言語化では、「なぜ今このシステムでは困るのか」を具体的な数字で表現します。たとえば「出荷件数がEC化で3年前の2倍になり、現行システムのレスポンスがピーク時に耐えられない」「ERPとの在庫連携がCSVの手動取り込みで、二重入力と転記ミスが月に十数件発生している」といった形です。課題を定量化しておくと、外注先も解決策を提案しやすくなり、経営層への予算承認の根拠にもなります。
必須要件（Must）と希望要件（Want）の切り分け
洗い出した要件は、必ず「Must（必須）」と「Want（希望）」に切り分けます。すべてを必須にしてしまうと、費用が青天井になり、納期も延びます。たとえば「ロット管理と賞味期限管理は必須だが、AIによる需要予測は将来的な希望」というように優先順位を明確にしておくと、外注先は予算内で実現可能な構成を提案しやすくなります。この切り分けは、後述するFit to Standard（標準機能への適合）の判断、すなわちどこまで標準機能で我慢しどこを作り込むかの線引きにも直結する、極めて重要な工程です。
丸投げを防ぐRFP（提案依頼書）の書き方
RFP（提案依頼書）は、外注先に何を作ってほしいかを伝えるための公式文書であり、複数社を同じ条件で比較するための土台になります。RFPがないまま口頭で発注すると、各社が異なる前提で見積を作るため、金額だけを横並びで比べても意味がない状態に陥ります。丸投げを避けるためにも、自社の要件をRFPという形で明文化することが、適正な発注の出発点です。
RFPに必ず盛り込むべき項目
RFPには、プロジェクトの背景と目的、現状業務の概要、解決したい課題、必須要件と希望要件、対象拠点と取扱品目数、想定する出荷件数や在庫SKU数といった規模情報を盛り込みます。さらに、連携が必要な周辺システム（ERP・OMS・TMS・自動倉庫など）の一覧、希望する稼働時期、想定予算レンジ、提案書の提出形式と評価基準も明記します。予算レンジを示すことをためらう企業もありますが、おおよその規模感を伝えたほうが、現実的でない過剰提案や過小提案を防げます。
評価基準を事前に決めておくことも大切です。「価格40%・物流業務理解30%・連携実績20%・サポート体制10%」のように配点を定めておけば、社内の評価がぶれず、提案各社にも公平に伝わります。RFPの完成度が高いほど提案の質も上がるため、ここに自社の本気度が表れると考えてよいでしょう。
自社特有の例外処理・連携要件の伝え方
WMS改修で見積が大きくぶれる原因は、自社特有の例外処理と外部連携の認識違いにあります。RFPには、先に棚卸しした例外処理を業務シナリオとして具体的に記述してください。たとえば「ピッキング時に欠品が出た場合の代替出荷ルール」「返品入荷時の良品・不良品の振り分けと在庫ステータス変更の流れ」などを、文章だけでなく業務フロー図で示すと誤解が減ります。
連携要件については、連携先システム名・連携方式（API/EDI/CSV）・連携頻度（リアルタイム/日次バッチ）・データ項目を一覧化します。特に在庫数のリアルタイム連携は実装難度が高く、後出しにすると追加費用の温床になります。自動倉庫やAGVといったマテハン機器との連携が必要な場合は、WCS/WESとの責任分界点を提案時点で確認する旨をRFPに明記しておくと、後のトラブルを未然に防げます。
発注前に見抜くべきベンダーの実力
提案書はどの会社のものも一見すると魅力的に見えるため、見た目の良さだけで発注先を決めると失敗します。WMS改修で問われるのは、システムを作る技術力だけでなく、倉庫現場の業務をどこまで理解しているかという物流ドメインの知見です。発注前の段階で、各社の本当の実力を見抜くための質問と確認を徹底することが、後悔しない発注につながります。
物流ノウハウと開発力の確認方法
物流ノウハウを確認する最も効果的な方法は、自社特有の例外処理をぶつけて、その場でどう設計するかを語ってもらうことです。たとえば「在庫が合わなくなる原因をどう設計で防ぐか」と問い、ゴースト在庫の発生メカニズムや論理ステータスの設計まで踏み込んで答えられる会社は、現場を理解しています。逆に「標準機能で対応可能です」と即答する会社は、現場の複雑さを軽視している可能性があるため注意が必要です。
開発力は、過去の改修・移行実績を具体的に確認します。同程度の出荷件数や拠点規模での導入実績、移行時のトラブル対応事例、稼働後の保守体制までを質問してください。可能であれば、実際にそのベンダーが手がけた現場の担当者にリファレンスとして話を聞けると、提案書では分からない実態が見えてきます。
連携実績とプロジェクト管理体制の確認
WMSは単独で動くシステムではなく、ERPやOMS、WCS/WESといった周辺システムと連携して初めて機能します。発注先には、希望する連携方式での実績を具体的に確認してください。自動倉庫やAGVとの連携は500万円から3,000万円規模の追加開発になることもあり、複数ベンダーが介在すると障害発生時の責任の所在が曖昧になりがちです。連携部分の障害切り分けルールを誰が主導するのかを、発注前に明確にしておく必要があります。
プロジェクト管理体制では、誰がプロジェクトマネージャーを務め、どのような頻度で進捗会議を行い、課題管理をどう運用するかを確認します。下請け構造になっている場合は、実際に手を動かす開発者との距離が問題になります。窓口担当と開発現場の間に何階層あるのかを把握しておくと、コミュニケーションの遅延リスクを事前に見積もれます。
契約・撤退時に確認すべき条項と隠れコスト
WMS改修の発注で見落とされやすいのが、契約条項と「旧システムからの撤退」にまつわる隠れコストです。新システムの導入費用ばかりに目が向きがちですが、実際には旧ベンダーとの契約条件や、見積書に出てこない費用が総額を大きく押し上げます。発注前に契約条項を精査しておくことが、予算超過を防ぐ最大の防衛策になります。
旧DBアクセス権とデータ引き上げ費用
WMS改修で最も盲点になりやすいのが、旧システムからのデータ引き上げにかかる費用です。旧システムのデータベースへの直接アクセス権が自社になく旧ベンダーが握っている契約だと、移行テストやリハーサルのたびにデータ抽出を依頼することになり、1回あたり数十万円のスポット費用を請求されるケースがあります。移行プロジェクトでは抽出を何度も繰り返すため、この積み重ねが数百万円規模に膨らむこともあります。
このリスクを避けるには、新しい発注先を決める前に、現行システムの契約書で解約条件とデータの返還条件、DBアクセス権の所在を必ず確認してください。発注の段階から「移行時に必要なデータをどのフォーマットで、いつまでに、いくらで提供してもらえるか」という出口（Exit）戦略を描いておくことが、後の高額請求を防ぐ鍵になります。
解約条件・保守範囲・知的財産権
新しい発注先との契約でも、保守範囲と知的財産権の取り扱いを明確にしておく必要があります。年間保守費は初期構築費の15〜20%が相場であり、5年使えば構築費とほぼ同額の保守費が発生します。保守に含まれる作業範囲（障害対応・軽微な修正・法令対応など）と、別途見積になる作業の線引きを契約書で確認してください。
スクラッチ開発では、完成したシステムのソースコードの著作権が自社に帰属するのか、ベンダーに帰属するのかも重要です。著作権がベンダー側にあると、将来別の会社に保守を移したくても移せず、特定ベンダーへの依存（ベンダーロックイン）が固定化します。倉庫の移転を伴う改修の場合は、旧倉庫からの移動手数料が出庫作業費・違約金・割増保管料などで月額保管料の3〜6ヶ月分に達することもあるため、こうした周辺費用まで含めて総額を見積もってください。
外注先と握るべき役割分担と進め方
WMS改修の成否は、発注後に外注先と自社がどう役割を分担するかで決まります。「外注したのだから全部やってくれるはず」という丸投げの姿勢は、要件抜けや現場との認識違いを招き、プロジェクトを頓挫させる最大の原因です。発注時点で、どの作業を誰が担うのかを契約書とプロジェクト計画書に明記しておくことが、トラブル回避の前提となります。
データ移行・UATシナリオの責任分担
WMS改修の失敗のおよそ7割はデータに起因するといわれます。データ移行では、旧データのクレンジングと名寄せ、マッピング、投入までの工程のどこを外注先が担い、どこを自社が担うのかを明確に分けます。「過去12ヶ月間に入出荷実績のないマスタや休止ロケーションは移行しない」といった12ヶ月ルールのような捨てる基準は、業務を知る自社が決め、技術的な変換作業は外注先が担うのが現実的です。
UAT（ユーザー受け入れテスト）のシナリオ作成も、自社の関与が欠かせません。正常系のテストはベンダーが用意できますが、現場特有のイレギュラーケースは自社しか知り得ません。先に洗い出した例外処理を必ずテストシナリオに組み込み、本番同様のデータ量で検証することで、稼働後の在庫差異を未然に防げます。
並行稼働とロールバックの責任範囲
新旧システムを一定期間同時に動かす並行稼働（パラレルラン）は、移行の安全装置である一方、運用を誤ると現場が崩壊します。最大の事故は、新旧両方のシステムから出荷指示書やピッキングリストが出る「指示系統の二重化」で、重複ピッキングや誤出荷を連発させます。物理的な作業指示書は新システムのみから出す一本化を鉄則とし、並行稼働中は二重入力で工数が1.5〜2倍に膨らむことを織り込んで、切替は必ず閑散期に設定してください。
並行稼働の終了条件（Exit Criteria）も、発注先と事前に握ります。「誤出荷エラー率0.5%未満が継続」「ERPとのAPI連携が4週間安定稼働」といった定量的な基準を定めておけば、いつまでも並行稼働が続く事態を防げます。あわせて、本番稼働後に問題が起きた際のロールバック判断基準と判断権限者を決め、旧システムと旧ハンディ端末は稼働後も最低3ヶ月は保持しておくことで、いざというときに業務を止めずに済みます。
WMS改修の発注・外注でよくある失敗と回避策
WMS改修の発注では、毎回似たような失敗が繰り返されています。これらは事前に知っておけば回避できるものばかりです。発注前に典型的な失敗パターンを押さえ、対策を発注プロセスに組み込んでおくことで、プロジェクトの成功率を大きく高められます。
ベンダー丸投げによる要件抜け
最も多い失敗が、ベンダーへの丸投げによる要件抜けです。「プロだから現場を見れば分かってくれるはず」と要件整理を怠ると、現場のベテランしか知らない例外処理が漏れ、稼働後に在庫が合わない、特定の出荷パターンが処理できないといった問題が噴出します。回避策は、発注前に自社で業務を棚卸しし、例外処理を含めてRFPに明文化すること、そして要件定義の打ち合わせに必ず現場担当者を参加させることです。
もうひとつ起きやすいのが、現場教育を外注任せにする失敗です。どれだけ優れたシステムを作っても、現場が使いこなせなければ意味がありません。操作研修やマニュアル整備の範囲を発注時に取り決め、自社側でも教育担当を立てておくと、稼働直後の混乱を最小限に抑えられます。
隠れコストの見落とし
もうひとつの典型は、初期費用だけを見て発注し、稼働後にコストが膨らむ失敗です。クラウド型WMSは「初期費用無料」をうたうことがありますが、従量課金が積み上がり、中長期では割高になる場合があります。たとえば初期0円・月額20万円のSaaSは5年で約1,200万円ですが、初期100万円・月額10万円のパッケージは5年で約700万円となり、5年スパンでは逆転します。発注判断は初期費用ではなく、5〜7年のTCO（総保有コスト）で比較してください。
ハードウェア費用も見落としがちです。ハンディ端末は1台5万円から30万円程度で、必要台数分が一括で発生します。さらに前述の旧ベンダーへのデータ抽出費用、年間保守費、倉庫移転費用なども加味すると、システム本体以外の費用が総額の3〜4割を占めることも珍しくありません。発注前に、これら周辺費用を一覧化して総額を把握しておくことが、予算超過を防ぐ確実な方法です。
まとめ｜WMS改修の発注は準備で9割が決まる
WMS改修の発注・外注は、システムを作る技術の話である以上に、発注前の準備と役割分担の設計の話です。現状業務を棚卸しして例外処理まで言語化し、必須要件と希望要件を切り分け、それをRFPに明文化したうえで、物流ノウハウと開発力を兼ね備えたベンダーを見抜く——この一連の準備が、プロジェクトの成否の大半を決めます。
あわせて、旧ベンダーからのデータ引き上げ費用や5年TCOの逆転、倉庫移転手数料といった見積に出てこない隠れコストを発注前に洗い出し、契約条項で旧DBアクセス権や保守範囲、知的財産権を押さえておくことが、後の高額請求やベンダーロックインを防ぎます。並行稼働は指示系統を一本化し、Exit Criteriaとロールバック基準を事前に握り、切替は必ず閑散期に行ってください。準備に手間をかけるほど、稼働後の在庫差異や誤出荷といったトラブルは確実に減っていきます。本記事を発注準備のチェックリストとして、自社に最適なパートナー選びにお役立てください。
▼全体ガイドの記事
・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を創業。