WMS改修の外注は、現状業務と要件の整理、RFPでの依頼内容の明確化、契約と役割分担の確認の順に進めます。この順で進めると、要件の抜けや認識違いといったトラブルを防ぎやすくなります。
▼全体ガイドの記事
・WMS改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMS改修の発注・外注とは|まず押さえる全体像と発注先の選択肢
WMS改修の発注とは、自社の倉庫業務に合わせてシステムを新たに作る、または既存システムを大きく作り替える作業を、専門会社に委託することです。発注先は、SaaS、パッケージ、スクラッチ開発会社、SIerの4タイプです。
発注先ごとに得意領域と費用の構造が異なります。そのため、候補ごとの違いをつかみ、自社の課題に合う相手を選ぶことが発注成功の第一歩です。
発注先の4タイプとそれぞれの特徴
4タイプを比べるときは、費用、業務への適合性、連携力の3点を基準にします。自社に必要な条件に照らすと、どのタイプが合うかを絞り込めます。
- SaaS:クラウド型WMSを月額課金で提供し、短期間で導入できます。
- パッケージ:製品をカスタマイズし、物流の標準機能を提供します。
- スクラッチ:自社業務に100%フィットさせて設計できます。
- SIer:複数システムを統括し、基幹やマテハンとの連携に強みがあります。
SaaSは自社固有の例外処理を作り込むことに限界があります。一方、パッケージはカスタマイズが増えると費用が上がりやすい傾向があります。
スクラッチは要件定義の精度が品質に直結します。SIerは大規模案件に強いものの、下請け構造で連絡階層が増える場合があります。
近年はAI駆動開発によって、スクラッチ開発の工期とコストを30〜70%圧縮できるようになりました。そのため、「パッケージ並みの予算で自社に100%フィットしたWMSを作る」選択肢も現実的になり、「カスタマイズが高いからパッケージで妥協する」という前提が崩れつつあります。
発注先を検討する段階で、この選択肢も視野に入れておくと、後悔のない判断につながります。
自社内製と外注の判断基準
内製か外注かは、社内の開発リソースと物流ドメイン知識の有無で判断します。
- 内製の判断:社内の開発力と物流知識が揃っているかを確かめます。
- 外注の判断:例外処理やマテハン制御の専門性が必要かを見ます。
- 現実的な分担:要件整理と意思決定は自社が担います。
例外処理やマテハン制御には専門性があるため、社内SEだけで完結させるのは難しいケースがほとんどです。
業務要件の言語化と現場との調整は自社にしかできず、外注先への丸投げは失敗につながります。一方、設計・開発・連携の実装は外注する形が現実的です。
WMS改修を外注する前の整理事項

相談の前に要件を整理しておくと、見積もりの精度とプロジェクトの成功率が高まります。要件が曖昧なままだと、追加要望を招きます。
追加要望が出ると、当初見積の1.5倍から2倍に費用が膨らむこともあります。そのため、事前の整理に時間をかけるほど、後工程のトラブルを減らせます。
現状業務の棚卸しと課題の言語化
現状業務(As-Is)では、倉庫の通常業務と例外処理の両方を確かめます。
- 通常業務:入荷、検品、格納、ピッキング、出荷、棚卸の流れを洗い出します。
- 例外処理:マニュアルに載っていない現場の慣習も拾います。
現場の業務の流れと例外処理は、ベテラン担当者へのヒアリングを通じて集めます。
例外には、セット品のばら返品、破損品を隔離した後の在庫ステータス変更、サンプル品の無記録持ち出しがあります。これらを放置すると、新システムで在庫差異やゴースト在庫が生じる恐れがあります。
「なぜ今のシステムでは困るのか」は、具体的な数字で表します。たとえば、EC化で出荷件数が3年前の2倍になり、現行システムがピーク時のレスポンスに耐えられない例があります。また、ERPとの在庫連携がCSVの手動取り込みで、二重入力と転記ミスが月に十数件発生する例もあります。
課題を数値で示すと、経営層への予算承認の根拠にもなります。
必須要件(Must)と希望要件(Want)の切り分け
洗い出した要件は、必ずMust(必須)とWant(希望)に分けます。
- Must(必須):ロット管理と賞味期限管理を含めます。
- Want(希望):AIによる需要予測は将来的な希望として扱います。
- Fit to Standard:標準機能で対応する範囲と作り込む範囲を決めます。
すべてを必須にすると、費用が青天井になり、納期も延びます。一方、優先順位が明確であれば、外注先は予算内で実現できる構成を提案しやすくなります。
丸投げを防ぐRFP(提案依頼書)の書き方

RFP(提案依頼書)は、依頼内容を外注先に伝え、複数社を同じ条件で比べるための公式文書です。自社要件をRFPに明文化することが、丸投げを避け、適正に発注する出発点になります。
RFPなしで口頭発注すると、各社が異なる前提で見積もります。そのため、金額だけを横並びで比べても意味がありません。
RFPに必ず盛り込むべき項目
RFPには、提案条件と規模、選定方法を含めます。各社が共通の前提で提案できるよう、必要な情報をそろえて記載します。
- 背景と要件:目的と現状業務、課題、MustとWantを記載します。
- 規模と連携:拠点、取扱品目、出荷件数、在庫SKU数、周辺システムを示します。
- 提案条件:稼働時期、予算、提出形式、評価基準を明記します。
周辺システムにはERP・OMS・TMS・自動倉庫などを含めます。予算レンジを示せば、過剰提案や過小提案が出にくくなります。
価格40%・物流業務理解30%・連携実績20%・サポート体制10%のように配点を決めておくと、社内の評価がぶれにくく、各社に公平に伝わります。RFPの完成度が高いほど、提案の質も上がり、内容には自社の本気度が表れます。
自社特有の例外処理・連携要件の伝え方
見積額が大きくぶれる原因は、例外処理や外部連携についての認識違いです。そのため、RFPには次の情報を示します。
- 業務シナリオ:欠品時の代替出荷、返品時の良品・不良品の振り分けを示します。
- 業務フロー:返品後の在庫ステータス変更も図に含めます。
- 連携仕様:連携先、方式、頻度、データ項目を記載します。
文章だけでなく業務フロー図にすると、認識違いを減らせます。連携方式にはAPI、EDI、CSVがあり、頻度にはリアルタイムや日次バッチなどがあります。
在庫数のリアルタイム連携は実装の難度が高く、後から追加すると追加費用につながります。また、自動倉庫やAGVとの連携が必要な場合は、WCS/WESとの間でどこまでを誰が受け持つかを提案の時点で確かめ、RFPに明記します。
発注前に見抜くべきベンダーの実力

提案書は、どの会社のものも一見魅力的に見えます。だからこそ、見た目だけで発注先を決めると失敗につながります。
ベンダーに問われるのは、開発技術に加えて、倉庫現場をどこまで理解しているかです。そのため、発注前に質問と確認を徹底し、各社の本当の実力を見抜くことが、後悔しない発注につながります。
物流ノウハウと開発力の確認方法
ベンダーの物流ノウハウと開発力は、例外対応と実績の両面から確認します。
- 物流ノウハウ:自社特有の例外処理への設計方法を聞きます。
- 開発力:過去の改修・移行実績を確かめます。
その際は、在庫が合わなくなる原因を具体的に示し、設計でどう防ぐかを質問します。
ゴースト在庫の発生メカニズムや論理ステータスの設計まで答えられる会社は、現場を理解しています。一方、「標準機能で対応可能」と即答する会社は、現場の複雑さを軽視している可能性があります。
同程度の出荷件数や拠点規模での導入例を挙げてもらい、移行時のトラブル対応と稼働後の保守体制も確かめます。可能であれば、ベンダーが手がけた現場の担当者に話を聞きます。そうすると、提案書では分からない実態が見えてきます。
連携実績とプロジェクト管理体制の確認
連携実績とプロジェクト管理体制について、発注前に次の2点を確かめます。
- システム連携:希望方式の実績と、障害時の責任分担を見ます。
- 管理体制:PM、会議頻度、課題管理、開発階層を確かめます。
連携先にはERP・OMS・WCS/WESなどがあります。自動倉庫やAGVとの連携は、500万円から3,000万円規模の追加開発になる場合があります。
複数のベンダーが関わると、障害時の責任が曖昧になりがちです。そこで、連携部分の障害の切り分けを誰が主導するかを、発注前に明確にしておきます。下請け構造では、開発者との距離がコミュニケーションの遅れにつながる場合があります。
契約・撤退時に確認すべき条項と隠れコスト
契約条項と旧システムからの撤退には、見落としやすいコストがあります。これらは新システムの導入費以外でも総額を押し上げる要因になります。
旧ベンダーとの契約条件や見積書に出てこない費用を確かめておくことが、予算超過を防ぐ備えになります。
旧DBアクセス権とデータ引き上げ費用
旧DBの権限とデータ抽出費用について、移行の前に次の2点を確かめます。
- 契約と権限:解約・返還条件とDBアクセス権の所在を確かめます。
- 抽出費用:テストやリハーサルごとの費用を確認します。
DBへの直接アクセス権が自社になく、旧ベンダーが握る契約の場合があります。その場合、移行テストやリハーサルのたびにデータ抽出を依頼します。
1回あたり数十万円のスポット費用を請求されるケースがあります。移行では抽出を何度も繰り返すため、その積み重ねが数百万円規模に膨らむこともあります。
必要なデータを、どの形式で、いつまでに、いくらで提供してもらうかを、あらかじめ決めておきます。後の高額請求を防ぐには、発注の段階から出口(Exit)戦略を描いておくことが欠かせません。
解約条件・保守範囲・知的財産権
新しい発注先との契約と旧倉庫からの撤退では、保守範囲、知的財産権、移転費用の3点を確かめます。
- 保守範囲:保守に含む作業と、別途見積もる作業を分けます。
- 知的財産権:ソースコードの著作権の帰属を決めます。
- 倉庫移転:旧倉庫からの移動に伴う費用を確認します。
年間保守費は初期構築費の15〜20%が相場で、5年使うと構築費とほぼ同額になります。障害対応、軽微な修正、法令対応など、どこまでが保守に含まれるかを契約書で確かめます。
著作権がベンダー側にあると、別の会社へ保守を移したくても移せません。その結果、特定ベンダーへの依存(ベンダーロックイン)が固定化します。
移動手数料は月額保管料の3〜6ヶ月分に達する場合があります。出庫作業費、違約金、割増保管料なども含めて、総額を見積もっておきます。
外注先と握るべき役割分担と進め方
WMS改修の成否は、発注後に自社と外注先がどう役割を分けるかで決まります。外注先への丸投げは要件の抜けや認識違いを招くため、担当作業を契約書とプロジェクト計画書に明記しておきます。それがトラブル回避の前提です。
データ移行・UATシナリオの責任分担
WMS改修の失敗のおよそ7割はデータに起因するといわれます。
- データ移行:基準の決定と技術的な変換を分担します。
- UAT:現場の例外をテストシナリオに含めます。
旧データの工程は、クレンジング・名寄せ・マッピング・投入に分かれます。「過去12ヶ月間に入出荷実績のないマスタや休止ロケーションは移行しない」という基準を設ける例もあり、基準を決めるには業務への理解が欠かせません。
正常系のテストはベンダーが用意できますが、現場の例外は自社にしか知り得ません。そのうえで、本番同様のデータ量で検証し、稼働後の在庫差異を未然に防ぎます。
並行稼働とロールバックの責任範囲
並行稼働(パラレルラン)は移行の安全装置ですが、運用を誤ると現場が崩壊します。
- 指示系統:物理的な作業指示書は新システムに一本化します。
- 終了条件:並行稼働を終える定量基準を発注先と決めます。
- 復旧準備:ロールバック基準と判断権限者を定めます。
最大の事故は、新旧両方から出荷指示書やピッキングリストが出ることです。指示系統が二重になると、重複ピッキングや誤出荷が続けて起きます。
並行稼働中は二重入力になるため、工数が1.5〜2倍に膨らむ前提で計画に織り込みます。切替は必ず閑散期に設定します。
たとえば、終了条件(Exit Criteria)としては、誤出荷エラー率が0.5%未満で続くことや、ERPとのAPI連携が4週間安定して稼働することが挙げられます。旧システムと旧ハンディ端末は、稼働後も最低3ヶ月保持します。そうしておけば、いざというときも業務を止めずに済みます。
WMS改修の発注・外注でよくある失敗と回避策
発注で繰り返される失敗の多くは、事前に知っておけば避けられます。典型例を押さえたうえで、対策を進め方の中に組み込みます。
ベンダー丸投げによる要件抜け
最も多い失敗は、ベンダーへの丸投げによる要件の抜けです。「現場を見れば分かる」と考えて要件整理を怠ると、現場のベテランしか知らない例外が漏れます。
- 要件抜けの防止:例外処理をRFPに記載し、現場担当者も要件定義に参加します。
- 教育の準備:研修・マニュアルの範囲を決め、自社に教育担当を置きます。
要件が抜けたまま稼働すると、在庫が合わない、特定の出荷パターンを処理できないといった問題が起きます。さらに、どれだけ優れたシステムでも、現場が使いこなせなければ意味がありません。
隠れコストの見落とし
初期費用だけで発注先を決めると、稼働後にコストが膨らむことがあります。
- 5年の費用例:初期0円・月額20万円のSaaSは約1,200万円です。
- パッケージ費用:初期100万円・月額10万円なら約700万円です。
- 端末費:ハンディ端末は1台5万円から30万円程度です。
- 周辺費用:本体以外が総額の3〜4割を占めることも珍しくありません。
クラウド型WMSは初期費用が無料でも、従量課金が積み上がる場合があります。中長期では割高になることもあるため、費用を比較します。この例の条件では、5年スパンで費用の優劣が逆転します。
発注を判断する際は、初期費用よりも5〜7年のTCO(総保有コスト)で比べます。ハンディ端末は、必要な台数分の費用が一括で発生します。また、データ抽出費、年間保守費、倉庫移転費も含めて周辺費用を一覧にし、総額を把握すると、予算超過を防げます。
まとめ|準備で9割が決まるWMS改修の発注
WMS改修の発注では、技術だけでなく準備と役割分担が大切です。まず業務と例外を洗い出し、MustとWantを整理します。
要件はRFPにまとめ、物流知識と開発力を持つベンダーから選びます。この準備が、プロジェクトの成否を左右します。
データ引き上げ費、5年TCOの逆転、倉庫移転手数料などの隠れコストも、発注前に確かめておきます。契約では、旧DBアクセス権、保守範囲、知的財産権を押さえておくと、高額請求やベンダーロックインを防ぐことにつながります。
並行稼働では、指示系統を一本化し、Exit Criteriaとロールバック基準を決めておきます。切替は必ず閑散期に行います。
準備に手間をかけるほど、稼働後の在庫差異や誤出荷などのトラブルを減らせます。本記事を発注準備のチェックリストとして、最適なパートナー選びにお役立てください。
▼全体ガイドの記事
・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を創業。
