WMSのモダナイゼーションは、発注前に要件と例外処理を整理し、RFPで依頼して、契約で役割分担と撤退条件を決める流れで外注します。
発注先を選ぶ物流部門の責任者や情シス担当の方が、丸投げを避けて適切なパートナーへ過不足なく委託できるよう、各段階で決めることを順に説明します。
▼全体ガイドの記事
・WMSのモダナイゼーションの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
WMS刷新の外注前の整理
発注で失敗する企業の多くは、自社の要件が固まらないまま「とりあえず話を聞かせてほしい」とベンダーに声をかけてしまいます。発注前にどこまで整理できているかで、その後のRFPの精度と見積もりの妥当性が決まります。
必須要件と希望要件の切り分け
外注前にまず行うのは、新WMSに求める機能を「必須要件（Must）」と「希望要件（Want）」に切り分ける作業です。すべての要望を必須として伝えると、ベンダーは安全をみてカスタマイズ費用を積み上げるため、見積もりが膨らみます。
逆に切り分けが曖昧だと、後から「これも必要だった」と追加開発が発生し、当初予算を大きく超過します。
- 必須要件：業務を止めないために外せない機能で、標準機能で足りるかをまず見ます。
- 希望要件：あれば望ましい要望で、必須要件とは分けて扱う項目です。
Fit to Standardの観点では、標準機能で対応できる範囲と、個別に作り込む要件を分けて考えます。たとえば、アパレルの色・サイズ別在庫管理や食品の賞味期限・温度帯管理は必須要件に置き、画面レイアウトの細かな好みは希望要件に分類します。
この線引きができていると、ベンダー比較の際に「どこまで標準でカバーできるか」という同じ土俵で、各社を公平に評価できます。
自社の業務フローと例外処理の棚卸し
WMS刷新で在庫が合わなくなる最大の原因は、現場が「良かれと思って」行っている例外処理がシステムに反映されないことです。実際には、2個1セットで出荷した商品が1個だけ返品される、破損品を物理的に隔離したのに論理ステータスの変更を忘れる、サンプルを記録なしで持ち出す、といった作業が該当します。
現場の例外処理が積み重なると、引当可能な在庫が実在しない「ゴースト在庫」となり、欠品クレームにつながります。
- 例外処理の対象：正規フローから外れていても、現場では日常的に行われている作業。
- 文書化の範囲：棚卸しした例外処理を、ベンダーに伝えられる形で残す範囲。
発注前に、現場で日常的に発生している例外処理を棚卸しし、文書に残しておきます。この作業を怠ったままベンダーに丸投げすると、要件定義で例外処理のヒアリングが漏れ、稼働後に在庫差異が一気に膨らみます。
現場のベテラン担当者にヒアリングして「正規フローから外れる作業」を洗い出しておくと、外注先に自社特有のオペレーションを正確に伝えられます。これは後述するRFPの質を左右する準備でもあります。
発注先の種類と選び方
WMSの外注先には、提供形態によって大きく異なるタイプがあります。どの形態を選ぶかで、初期費用、カスタマイズの自由度、運用後のコスト構造がまったく変わるため、自社の要件と照らし合わせて選ぶ必要があります。
発注先のタイプを理解しないまま見積もりだけを比べると、安く見えた選択肢が中長期で割高になる、といった判断ミスを招きます。
SaaS・パッケージ・スクラッチ・AI駆動開発の選択肢
クラウド型（SaaS）は初期費用を抑えて数ヶ月で稼働でき、標準機能で運用したい企業に向きます。一方で従量課金が積み上がるため、出荷件数が多い大規模倉庫では中長期のコストに注意が必要です。
パッケージ型（オンプレ）は自社環境に構築し、ある程度のカスタマイズも可能です。ただし、年間保守費として初期構築費の15〜20%が固定的に発生します。
- SaaS・パッケージ型：初期費用と保守の負担を、自社の運用に照らして比べる形態です。
- スクラッチ・AI駆動開発：自社の業務に合わせて作り込む形態と、近年注目される開発手法です。
フルスクラッチ型は自社の業務に100%フィットさせられる反面、従来は開発期間が半年から1年以上、費用も高額になりやすいのが難点でした。近年は、この課題に対してAI駆動開発が注目されています。
AI駆動開発を含む開発手法に対応できるかどうかも、発注先を選ぶ際の評価軸に加えると、選択肢が広がります。
物流ノウハウと開発力の見抜き方
提案書は、どの会社のものも一見すると良く見えます。だからこそ、その会社が物流現場の実情を理解しているか、技術的な開発力を本当に持っているかを見抜く必要があります。
物流ノウハウの有無は、例外処理や在庫の時点整合性といった現場特有の論点について、こちらが聞く前に踏み込んだ質問をしてくるかどうかで判断できます。逆に、表面的な機能説明に終始するベンダーは、稼働後の運用で苦労する可能性が高いと言えます。
- 物流ノウハウ：提案の中身が現場の言葉で語られているかを見る観点です。
- 開発力：技術面の実力を、提案書の見栄えとは切り離して評価する観点です。
開発力については、同業種・同規模のWMS刷新実績を具体的に確認し、可能であれば導入企業へのヒアリングや稼働中の画面デモを依頼します。特に、ERPやOMS、TMSといった周辺システムとのAPI・EDI連携の実績は、重要な判断材料になります。
各社の比較や選定基準を詳しく知りたい場合は、おすすめの開発会社をまとめた記事も参考にしてください。
RFP（提案依頼書）の書き方と丸投げの回避
RFP（提案依頼書）は、自社の要件をベンダーに伝え、各社から比較できる提案を引き出すための文書です。RFPの質が低いと、各社が異なる前提で見積もりを出すため横並びで比べられず、「ベンダー丸投げ」の状態に陥ります。
逆に、RFPで要件と評価軸を明確に示せば、提案の質と見積もりの精度が格段に上がります。
丸投げを避けるRFPの構成
特にKPIは「在庫精度99.5%以上」「誤出荷率0.1%未満」のように数値で定めておくと、ベンダーが目標達成の手段を具体的に提案しやすくなります。
- RFPに記載する項目：As-Is、To-Be、0.5%、Exit Criteria、数十万円を示します。
- 役割分担の範囲：どこまでを自社が担い、どこからをベンダーに任せるかを、RFPの中で示す箇所。
丸投げを避ける鍵は、「やってほしいこと」だけでなく「なぜそれが必要か」という背景を伝えることです。背景を共有すると、ベンダーは自社の意図をくみ取り、より良い代替案を示せるようになります。
また、評価基準を事前に示しておくと、提案を受ける側も判断がぶれにくく、社内の合意形成もスムーズになります。RFPは一度作って終わりにせず、ベンダーからの質問を通じて精度を高めていく前提で運用するとよいでしょう。
自社特有要件と連携要件の伝え方
前段で棚卸しした例外処理や業種特有の要件は、RFPの中で具体例を添えて書きます。抽象的に「在庫管理を正確にしたい」とだけ書くと、各社の解釈がばらつき、後の追加開発の温床になります。
- 自社特有要件：業種や現場に固有の業務ルールを、ベンダーに正しく伝えるための要件。
- 連携要件：ERPなど周辺システムとのデータのやり取りに関する要件。
連携要件も、ERPとの在庫・出荷データのやり取りを、リアルタイムAPIで行うか、CSVのバッチ連携で許容するかによって、開発工数と障害時のリスクが大きく変わります。
自動倉庫やAGV・AMRといったマテハン機器を導入している場合は、WCS／WESとの連携が500万〜3,000万円規模の追加開発になることもあります。
連携対象と方式、データ項目、頻度をRFPで明示し、契約前に各社の連携実績を確かめておくことが、稼働後のトラブルを防ぐ近道です。
契約・撤退で確認すべき条項
発注時に見落とされがちなのが、契約内容と「撤退（Exit）」に関する条項です。発注の段階で撤退まで見据えて契約条件を確認しておくと、将来の自由度を守れます。
旧DBアクセス権とデータ引き上げ費用
WMS刷新で意外な落とし穴になるのが、旧システムからのデータ抽出です。移行テストやリハーサルで繰り返し抽出すると、その費用だけで百万円単位に膨らむこともあります。
- 旧DBアクセス権：旧システムのデータへのアクセス権限の取り決め。
- データ引き上げ費用：抽出の回数や範囲に応じて膨らむ費用で、上限を決めておく項目。
具体的には、データのエクスポート形式（CSVやデータベースダンプ）、提供範囲（マスタ・トランザクション・履歴）、対応費用の上限を確認します。
今まさに発注しようとしている新ベンダーにも同じ視点で「契約終了時のデータ返却条件」を確認しておくと、次の刷新で同じ苦労を繰り返さずに済みます。
解約条件と保守・SLAの取り決め
契約では、解約に関する条件も事前に確認します。SaaSの場合は最低契約期間や中途解約時の違約金を、オンプレやスクラッチの場合は保守契約の更新条件と解約予告期間を押さえておきます。
最低契約期間や解約金だけでなく、複数年の運用費も含めて確認します。
- 解約条件：最低契約期間、違約金、解約予告期間など、途中で抜ける場合に関わる条件。
- 保守・SLA：障害対応と保守の水準を、契約に残しておく取り決めです。
あわせて、SLA（サービス品質保証）の取り決めも欠かせません。障害発生時の復旧目標時間、サポートの対応時間帯、問い合わせへの初動応答時間などを、契約に盛り込みます。
WMSが止まると出荷も止まり、売上に直結します。そのため、繁忙期を含めた対応体制をどう確保するかは、発注前に必ず握っておくべき論点です。
費用の内訳や相場感を詳しく確認したい場合は、見積相場をまとめた記事も参考にすると、判断材料が増えます。
外注先と握るべき役割分担
WMS刷新では、外注先に任せきりにできる作業と、自社が主体的に担うべき作業が混在します。役割分担を曖昧にしたまま進めると、「ベンダーがやってくれると思っていた」「それは御社の作業範囲です」といった押し付け合いが起き、プロジェクトが停滞します。
契約の段階で作業分担表（RACIなど）を作り、誰が何に責任を持つかを明文化しておくと、トラブルの予防につながります。
データ移行とUATシナリオの責任分界
WMS刷新の失敗の約7割はデータに起因すると言われます。データ移行では、旧システムからの抽出、クレンジング、新システムへの投入という工程があり、工程ごとの責任を外注先と明確に分ける必要があります。
一般に、マスタデータのクレンジングや名寄せは自社の業務知識が不可欠なため自社主導とし、移行ツールの開発や投入処理はベンダーが担う分担が現実的です。
- データ移行：抽出から投入までの工程ごとに、担当を決める対象。
- UATシナリオ：受け入れテストの想定を、どちらが用意するかを決める項目。
UAT（ユーザー受け入れテスト）のシナリオ作成も、自社が主体的に担うべき領域です。ベンダーが用意するテストは正常系が中心になりがちなため、現場で頻発するイレギュラーケースが抜け落ちやすくなります。
並行稼働とロールバック責任の明確化
新旧システムを同時に動かす並行稼働（パラレルラン）では、二重入力によって現場の工数が1.5〜2倍に膨らみます。最大の事故は、新旧両方から出荷指示書やピッキングリストを出してしまう「指示系統の二重化」で、これが誤出荷を連発させます。
物理的な指示書は新システムからのみ出すという一本化ルールを、外注先と現場の双方に徹底することが鉄則です。並行稼働の終了条件や切替の判断基準も、外注先と事前に合意しておきます。
- 並行稼働：新旧二重で運用する期間を、どの条件で終えるかを決めておく段階。
- ロールバック：本番稼働後に旧システムへ切り戻す判断の仕組み。
本番稼働後に問題が起きた際のロールバック（切り戻し）についても、判断基準と権限を契約の段階で決めておきます。たとえば「棚卸差異率が何%を超えたら、誰の判断で旧システムに戻すか」を決めておかないと、現場が混乱したまま出荷が止まり続けます。
注意したいのは、旧システムのハンディ端末を早々に破棄すると、旧システムへ再接続できず切り戻しができなくなる点です。新システムの稼働後も最低3ヶ月は旧端末とライセンスを残す取り決めをしておくと、切り戻しの備えになります。
プロジェクト全体の進め方を体系的に把握したい場合は、進め方をまとめた記事も参照すると役立ちます。
WMS外注でよくある失敗と回避策
WMSの外注では、過去のプロジェクトで繰り返されてきた典型的な失敗パターンがあります。事前に知っておけば、同じ失敗を避けられます。
失敗の多くは、発注側の準備不足やコミュニケーション設計の甘さに起因しています。これが、技術的な問題より目立つ失敗の特徴です。
ベンダー丸投げと隠れコストの罠
最も多い失敗は、要件整理をせずにベンダーへ丸投げするパターンです。自社の業務を理解しているのは現場であり、ベンダーは物流の専門家であっても、その企業特有のオペレーションまでは知りません。
丸投げすると、要件定義で例外処理が漏れ、稼働後に在庫差異やオペレーションの混乱が噴出します。前段で述べた要件整理とRFP作成を丁寧に行うことが、最大の回避策です。
- 丸投げ：要件整理を飛ばして、発注先に任せきりにすること。
- 隠れコスト：本体価格には表れない周辺費用や、中長期で積み上がる支払い。
隠れコストの罠も見逃せません。「初期費用無料」をうたうSaaSでも、月額の従量課金が積み上がると、中長期ではオンプレやパッケージより割高になることがあります。
たとえば、初期0円＋月20万円なら5年で1,200万円、初期100万円＋月10万円なら5年で700万円となり、TCOで見ると逆転します。このほか、ハンディ端末は1台5万〜30万円で人数分が必要になり、Wi-Fi環境の整備や導入支援コンサル費用も発生します。
見積もりを比べる際は、本体価格だけでなくこうした周辺費用も含め、5年TCOで総合的に判断することが欠かせません。
現場教育不足と切替タイミングの誤り
システムが優れていても、それを使う現場の教育が不足していると、稼働後に混乱が起きます。新システムの操作研修は、稼働直前に駆け足で行うより、UATの段階から現場のキーパーソンを巻き込んで慣れてもらうほうが定着の近道です。
現場が新システムに納得していないと、旧来のやり方に戻ろうとする力が働き、データ入力の徹底が崩れて在庫精度が低下します。
- 現場の教育：稼働後に混乱しないよう、操作に慣れてもらうための準備。
- 切替の時期：並行稼働や本番切替を行う時期を、出荷量に合わせて選ぶ判断。
切替のタイミングも、失敗を分ける重要な要素です。並行稼働や本番切替を繁忙期に行うと、二重入力で増えた工数に出荷ピークが重なり、現場が回らなくなります。
切替は必ず出荷量の落ち着く閑散期を選ぶのが鉄則です。段階的な移転計画と、出荷停止期間のバックオーダー消化計画を外注先と綿密にすり合わせておくと、複合プロジェクトを成功させる鍵になります。
まとめ
WMSは在庫と出荷という事業の根幹を支えるため、発注の巧拙が現場の混乱や追加コストに直結します。発注前に要件と例外処理を整理し、契約時に役割分担と撤退条件を明確にしてください。
▼全体ガイドの記事
・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を創業。