WMS更改の発注/外注/依頼/委託方法について

WMS更改の発注・外注・委託は、現状業務と要件の整理、RFPによる提案依頼、委託先との責任分担の確認の順に進めると、出荷を止めない移行につなげられます。

外注先の選び方、RFPの書き方、契約と役割分担を順に取り上げます。全体像はWMS更改の完全ガイドもご覧ください。

▼全体ガイドの記事
・WMS更改の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

WMS更改の発注・外注・委託の基本

発注の前に、言葉の範囲と外部へ任せる役割をそろえておく必要があります。範囲が曖昧なまま見積もりを頼むと、各社の提案範囲がばらつき、比較できなくなります。

「発注」「外注」「委託」の違いと使い分け

実務では同じ意味で使われることが多いものの、契約形態の観点では区別できます。「発注」は、仕事を正式に依頼する行為全般を指します。

• 外注：社内でも担える作業を外へ切り出す、という意味合いが強い言葉です。
• 委託：成果物に責任を負う請負と、作業時間に対価を払う準委任の二つに分かれます。

WMS更改では、仕様が未確定の要件定義を準委任、成果物が明確な開発と移行を請負とする組み合わせが一般的です。

また、瑕疵担保責任や検収の考え方も、契約形態によって変わります。そのため、見積もりの段階で、フェーズごとの契約と責任の所在を相手と擦り合わせておきます。

内製と外注、それぞれが向くケース

倉庫管理には、引当ロジック、ロケーション設計、マテハン連携といった専門性が求められます。そのため、すべてを社内だけで作れる企業は多くありません。

設計から開発、移行まで社内で行うには、物流とシステムの両方に詳しい人材が複数名必要になります。

一方で、現場の例外処理や日々の運用ルールは社内にしか分かりません。外部へ丸投げすると、在庫差異の温床になります。

• ハイブリッド型：社内が要件定義と業務設計を主導し、開発・移行・テスト支援を外部に任せる形。
• 外部開発会社：出荷が1日数千件超、複数拠点、自動倉庫やAGV連携のいずれかに当てはまる場合は、発注するほうが安全です。
• 導入支援のみ：単一拠点で、SaaSの標準機能にほぼ収まる場合に選べます。

自社の業務の複雑さは、出荷件数や拠点数、自動倉庫やAGVとの連携の有無で見積もります。そのうえで、外注する範囲を決めます。

WMS更改の外注先の種類と特徴

発注先は、SaaS、パッケージ、受託開発の3タイプに大きく分けられます。ほかにコンサルティングファームもあります。3タイプは得意領域や費用構造がそれぞれ異なります。

SaaS・パッケージ・受託開発会社の違い

各方式の違いは、業務の合わせ方、得意領域、開発の自由度に表れます。

• SaaS：初期費用を抑えて短期間で導入できる一方、「Fit to Standard」の考え方で業務を標準機能に合わせます。
• パッケージ：アパレルの色・サイズ管理や、食品の賞味期限・温度帯管理に強みがあります。
• 受託開発：スクラッチで業務に合わせられるため、例外処理や複雑な連携が多い企業に向いています。

初期費用0円の月額提案もありますが、出荷件数やユーザー数に応じた従量課金が積み上がり、総額が大きくなる場合があります。

5年の期間で見ると、SaaSがオンプレ型より割高になるケースもあります。たとえば、初期0円・月額20万円なら5年で1,200万円です。一方、初期100万円・月額10万円のパッケージなら5年で700万円となり、費用が逆転します。

また、導入期間はSaaSが数ヶ月、パッケージやスクラッチは半年から1年以上が一般的です。このため、依頼先は、自社の業務を標準機能にどこまで寄せられるか（標準化余地）と、納期をどこまで待てるか（納期の許容度）で選びます。

AI駆動開発によるスクラッチ開発の復権

従来は、パッケージに業務を合わせるか、高額なスクラッチで業務に合わせるかの二択でした。一方で、AI活用により選択肢が広がっています。

• 工期とコスト：コード生成や設計支援により、30〜70%圧縮できた事例があります。
• 自社への適合：パッケージ並みの予算で、100%フィットする進め方が現実的です。
• 発注先の実績：AI駆動開発の経験を確かめ、スクラッチも改めて評価の対象にします。

WMSは企業ごとに運用ルールが異なります。

AI駆動開発によって、コストと自由度の差は和らいでいます。

依頼前の社内準備

依頼前の社内準備によって、発注の成否の8割が決まると言っても過言ではありません。

準備が足りないと、判断材料がないまま設計が進みます。その結果、「そんな業務は聞いていない」と手戻りが増えます。

依頼前は、現状業務を洗い出すことと、要件を必須と希望に分けることに取り組みます。

現状業務（As-Is）の棚卸しと課題の言語化

入荷から出荷までの倉庫業務を一つずつ書き出し、現状（As-Is）を洗い出します。マニュアルに載っていない例外処理も、あわせて拾い上げます。

• 返品：2個1セットの商品のうち1個だけが戻ってきたときの扱い。
• 破損品：物理的に隔離した後の、システム上のステータス変更。
• サンプル品：記録を残さずに持ち出されるもの。

例外処理がシステムに反映されないと、論理在庫と物理在庫がずれます。そして、引当できない「ゴースト在庫」が欠品クレームを招きます。

在庫精度に直結するのは、現場ヒアリングの精度です。

WMSを導入しても、在庫が自動的に合うとは限りません。そのため、ベテラン担当者に半日でも聞き取り、暗黙のルールを文書にしておくことは、発注前に欠かせない作業です。

必須要件（Must）と希望要件（Want）の切り分け

要件は、業務に不可欠なMustと、あると便利なWantに分けておきます。

標準機能で足りる部分まで個別化すると、費用と納期が膨らみます。また、カスタマイズは将来のバージョンアップを妨げ、属人化やブラックボックス化につながる場合があります。

• Must：欠けると出荷が止まってしまう要件です。
• Want：運用の工夫で補える要件です。

Wantについては、まず標準機能で代替できないかを確かめます。そのうえで、必要なものだけに優先順位を付けて依頼します。

MustとWantの一覧はRFPの中核になり、相見積もりの比較精度を高めます。

丸投げを防ぐRFP（提案依頼書）の書き方

RFP（提案依頼書）は、複数社に同じ条件で提案を求め、横並びで比べるための文書です。

記載の精度が低いと、提案がばらつきます。

要件と前提を丁寧に伝えると、提案の質が上がります。

要件を丁寧に伝えれば、価格だけで選ぶことや丸投げによる失敗も防げます。

RFPに必ず盛り込む項目

各社の提案を同じ条件で比べられるよう、RFPには目的、要件、規模をそろえて記載します。

• 目的と背景：更改の狙い、現状業務、解決したい課題を伝えます。
• 要件と計画：Must/Want一覧や想定日程を示し、予算レンジと評価基準も添えます。
• 規模の数値：出荷件数やSKU数、拠点数を数字で示し、ピーク時処理量も添えます。

定量データがないと、各社は安全側に寄せた過大な見積もりを出さざるを得なくなります。

ERP・OMS・TMSとの連携方式は、API・EDI・CSVのどれかを示したうえで、リアルタイム性が必要かも明記します。

移行の対象と並行稼働の期間、本番切替の希望時期も記載します。

切替時期は、必ず閑散期に置きます。

RFPは、ベンダーに考えてもらうための質問状です。

情報を具体的に書くほど、提案の質が上がります。

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

例外処理と連携要件は、具体的なシナリオや機器名を挙げて、RFPに記載します。

• 例外処理：セット品の個別返品などを挙げ、可能なら入出力のフロー図も添えます。
• 連携要件：接続する機器や方式、障害時の切り分け責任の所在を記します。

例外を伝えていないと、要件定義の段階で想定外とされ、あとから追加費用を請求されることがあります。

自動倉庫やAGV、AMRとの連携は、500万円から3,000万円規模の追加開発になることがあります。

WCSやWESを介すと複数のベンダーが関わるため、責任分界点が曖昧になりがちです。

委託先候補の見極め方と相見積もりの取り方

提案を受けたら候補を見極め、相見積もりを比べます。機能一覧や価格だけでは、現場理解の深さは判断できません。そのため、現場への理解度も確かめます。

物流ノウハウと開発力の見抜き方

実力は、提案書の内容に加えて、具体的な物流課題への回答や担当者の理解度で見極めます。

• 例外処理を質問：セット品のバラ返品や、在庫の時点整合性への対応。
• 導入実績を確認：類似規模・業種での移行や並行稼働の進め方。
• 技術者と面談：実際の担当予定者と話し、理解度を直接確かめます。

例外処理への回答が実装のイメージまで具体的なら、同種の課題の経験が期待できます。一方で、回答が一般論にとどまる場合は、物流の知識をさらに掘り下げて見極めます。

営業と技術者では理解度に差がある場合があるため、実績は件数より中身を掘り下げて確かめます。

相見積もりで比較すべき5つの観点

見積もりの金額だけでは、導入後に生じる費用や支援の差が見えません。そこで、次の5つの観点を各社に当てはめて比べます。

• 5年間のTCO：初期費用とランニング費用を合算した総額。
• 要件充足度：Must/Wantにどこまで応えられるか。
• 移行支援：データの受け渡しと並行稼働の範囲。
• 保守体制：障害時の対応やサポートの条件を比べます。
• 納期の現実性：切替時期を含めて、実現できる日程かを判断します。

見積もりには、移行や教育、保守など、あとから発生する費用が含まれないことがあります。そのため、前提条件もあわせて確認します。

オンプレやスクラッチの年間保守費は、初期構築費の15〜20%が相場です。

5年間の合計では、構築費とほぼ同額になる場合があります。

ハンディ端末は1台5万〜30万円で、必要な台数分の費用がかかります。こうした周辺費用も含めて、同じ条件で比べます。

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

新システムの契約を結ぶ時点で、旧システムからの撤退も考えておきます。これを怠ると、移行時のスポット費用や次回更改の制約につながります。

旧ベンダーのデータ引き上げ費用とDBアクセス権

旧ベンダーがDBを管理していて、自社に直接のアクセス権がない契約では注意が必要です。

• 現在の契約：新システムを発注する前に、自社がDBへ直接アクセスできるかを確かめます。
• 新しい契約：将来のデータ抽出権と、撤退（Exit）の条件を取り決めます。

CSVの抽出は、移行テストやリハーサルのたびに必要になります。そして、1回あたり数十万円の費用が繰り返し発生します。

データ移行は何度も試すため、スポット費用が積み上がります。契約の段階で確認しておけば、隠れたコストを防げます。

解約条件・違約金・知的財産権の取り扱い

解約費用、知的財産権、開発契約の基本条件は、法務と一緒に確かめます。

• 解約条件：違約金と最低利用期間を見たうえで、新旧契約の時期を合わせます。
• 知的財産権：納品プログラムの著作権が、どこに帰属するかの取り決め。
• 開発契約：準委任か請負か、検収条件、瑕疵対応期間。

倉庫を移転するときは、出庫作業費や早期解約違約金が重なる場合があります。割増保管料や棚卸費が加わることもあります。

移動手数料は、月額利用料の3〜6ヶ月分になることもあります。そこで、新旧契約に空白や重複が生じないよう、解約時期を逆算します。

特に、著作権がベンダーに残ると、将来の改修や他社への乗り換えが制限されるおそれがあります。契約書は、揉めたときにこそ効力を発揮します。

外注先と握るべき役割分担とリスク管理

外注先に任せる領域と自社が関わる領域を分けて、契約時に明確にしておきます。そうすれば、問題が起きたときに責任を押し付け合う事態を防げます。

データ移行・UATシナリオの責任分界点

WMS更改の失敗の約7割は、データに起因すると言われています。そこで、移行と受け入れテスト（UAT）の役割を分けておきます。

• データ移行：クレンジングの判断は自社、ツールの開発と実行はベンダーが担います。
• UAT：自社がシナリオを作り、正常系と例外処理を検証します。

マスタのクレンジングや名寄せ、在庫残高の時点整合性が、移行の成否を左右します。

過去12ヶ月間に入出荷実績がないマスタや休止中のロケーションを移行から外す「12ヶ月ルール」を、文書に書き残します。

不要なデータを移すと、新システムにも在庫差異が残ります。そのため、UATではセット品のバラ返品や破損品の処理も試します。

並行稼働とロールバック判断の責任設計

並行稼働（パラレルラン）では、新旧両方から指示書を出すと、重複ピッキングや誤出荷が起きてしまいます。そのため、条件を事前に決めておきます。

• 指示書：現場へは新システムからのみ出力し、二重化による誤出荷を防ぎます。
• 実施時期：二重入力で工数が1.5〜2倍になるため、閑散期を選びます。
• 切り戻し：誤出荷率の基準値を数値で定め、切り戻しを判断する権限者も決めておきます。
• 終了条件：エラー率0.5%未満や、API連携の4週間安定など。
• 旧環境：切り戻しに備えて、旧システムと旧ハンディ端末を最低3ヶ月は残しておきます。

まとめ

WMS更改では、依頼前の社内準備が要になります。

現状業務と例外処理を棚卸しし、MustとWantを分けたうえでRFPに記載します。

委託先は、価格だけでなく、5年間のTCOや物流ノウハウ、移行支援を比べて選びます。

旧システムのデータ引き上げ費用やDBアクセス権、解約条件も、新システムの発注時に設計しておきます。

移行とUATの責任分界や指示の一本化を外注先と決めておけば、出荷停止のリスクを抑えられます。

切り戻し基準と旧端末の3ヶ月保持も、あわせて決めます。

▼全体ガイドの記事
・WMS更改の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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