倉庫管理システムの更改は、現状と更改目的を整理するところから始まります。発注先を選んで契約し、要件定義と開発、データ移行と並行稼働を経て、本番稼働へ切り替えます。
目的と要件を固めてから発注先に相談すると、稼働後の在庫差異やコスト超過を防ぎやすくなります。
▼全体ガイドの記事
・倉庫管理システム更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
倉庫管理システム更改の発注・外注の全体像
倉庫管理システムを外注する際は、次の順に進めます。
- 現状と更改目的を整理する
- 発注先を選ぶ
- 契約する
- 要件定義と開発を進める
- データ移行と並行稼働を行う
- 本番稼働へ切り替える
発注で失敗する企業の多くは、最初の整理が曖昧なまま開発会社に相談してしまいます。その結果、相手の提案ペースに流されがちです。そのため、まずは発注の全体像と、自社が主体的に決める領域を押さえておきます。
発注前に押さえる更改の目的
発注を成功させるには、更改の目的を社内の言葉にしておくことが出発点になります。
- 老朽化対応：サポート終了（EOL/EOSL）に備える
- 処理能力の改善：EC化による出荷増に対応する
- 属人化の解消：過度なカスタマイズを見直す
目的によって、適切な発注先や投資規模は変わります。たとえば在庫精度を上げたい場合は、機能比較よりも現場の例外処理を業務設計に反映することが論点になります。
目的が曖昧なままだと、パッケージの標準機能に業務を合わせるだけになりかねません。その結果、課題を解決できないまま稼働を迎えるおそれがあります。
現場が限界を感じている兆候も、具体的に集めておきましょう。ピーク時の応答低下や、特定担当者しか操作できない画面がその例です。ERPとのCSV手動取込による二重入力や転記ミスも、更改の根拠になります。
兆候を数値で整理しておくと、経営層への投資稟議や発注先への説明に一貫性が生まれます。
発注先となる開発会社の主な4タイプ
WMSの発注先は、提供方式や開発方法によって大きく4タイプに分かれます。
- クラウド型（SaaS）：初期費用を抑え、短期に始めやすい
- パッケージ型（オンプレ）：業種特化機能を備える
- フルスクラッチ：自社業務への適合性を高められる
- AI駆動開発：AIが設計やコーディングの一部を支援する
SaaS型は数ヶ月で小さく始められますが、カスタマイズの自由度には制約があります。
オンプレ型は、導入に半年から1年以上かかるケースが一般的です。
フルスクラッチは自社業務に100%フィットさせられる一方、費用と期間がかさみやすい方式です。
AI駆動開発では、工期とコストを従来のスクラッチ開発より30〜70%圧縮できた事例もあります。パッケージ並みの予算で業務に合う仕組みを持つ選択肢として、注目されています。
更改の規模と必要な適合度を基準にして、検討するタイプを絞り込みましょう。
外注前に整理すべき要件と「必須・希望」の切り分け
発注先に任せきりにせず、要件は自社で整理しておく必要があります。要件が曖昧なままだと各社の提案を比べる基準がなくなり、どの提案も良く見えてしまいます。
まず現状の業務を洗い出し、そのあとで要件の優先順位を付けましょう。
As-Is/To-Be分析による現状業務の洗い出し
外注の精度は、現状業務（As-Is）をどこまで細かく洗い出せるかに左右されます。
- 主要フロー：入荷検品、格納、ピッキング、出荷検品、棚卸
- セット品の返品：2個1セットのうち1個だけ戻る場合の在庫単位
- 破損品：隔離後にシステム上の状態を変えない運用
- サンプル品：記録せずに持ち出す運用
こうした例外は、稼働後にゴースト在庫（実在しない引当可能在庫）を生みます。ゴースト在庫は、欠品クレームにつながるおそれがあります。
次に、更改後のあるべき姿（To-Be）を、KPIとあわせて描きます。たとえば、在庫精度を現状の95%から99.5%へ上げる、といった数値目標を設定できます。
誤出荷率を月10件から1件以下にする目標も、具体化の一例です。目標があれば、開発会社に伝える要件が明確になり、稼働後の効果検証にも使えます。
As-IsとTo-Beの差分が、今回の発注で実現したい範囲になります。
Must要件とWant要件の線引き(Fit to Standard)
洗い出した要件は、Must（必須）とWant（希望）に分けてください。
- Must：なければ業務が止まる、競争力に直結する要件
- Want：運用で吸収でき、標準機能でも代替しやすい要件
すべてを必須にすると、カスタマイズが増えて費用と期間が膨らみます。さらに、属人化という前システムの失敗を繰り返すおそれもあります。
標準機能で代替できる業務は、業務側をシステムに合わせるFit to Standardという考え方も有効です。
賞味期限管理や温度帯別ロケーションは、業種固有で欠かせないMustの例です。一方、画面の色や帳票の細かな配置は、運用で補えるWantの例になります。
優先順位を先に決めておけば、要件定義の途中で現場から出る要望にも、同じ基準で判断できます。
丸投げを防ぐRFP(提案依頼書)の書き方
RFP（提案依頼書）は、実現したいことを伝え、各社を同じ条件で比べるための文書です。完成度が低いと曖昧な提案が集まり、各社の違いが見えにくくなります。
RFPに必ず盛り込むべき項目
WMS更改のRFPには、提案と見積を比べるために、次の情報を記載します。
- 背景と範囲：目的、対象拠点、業務範囲
- 規模と機能：出荷件数、SKU数、Must/Want要件
- 連携と条件：外部連携、希望日程、予算帯
- 提案方法：提案と見積の指定様式
連携先には、ERP、OMS、TMSやマテハン機器を含めます。
規模情報は見積額に直結するため、ピーク日の出荷件数や拠点数を正確に書きましょう。
データ移行の範囲や並行稼働の想定期間も、RFPに記載しておきます。あわせて、繁忙期を避けたいなど、切替時期の制約も明らかにしておきます。
さらに、本番稼働後のサポート体制も確認対象になります。これらを問うと、物流現場を理解する会社は移行リスクへの対策も示します。一方、機能の説明に終始する提案との違いから、開発力や物流知識を見極められます。
例外処理・連携要件による「自社固有」の言語化
RFPでは、自社固有の例外処理と連携要件を具体的に示すことが欠かせません。
- 例外処理：ばら返品、破損品の状態、サンプル品の持ち出し
- システム連携：リアルタイムか日次か、APIかCSV/EDIか
- 機器連携：自動倉庫やAGV・AMRとWCS/WESの間で、どこまでを誰が受け持つか
こうした例外や連携は標準パッケージでは想定されておらず、記載がなければ提案や見積に反映されない場合があります。業務シナリオとして書いておけば、稼働後に深刻な在庫差異が起きるリスクを抑えられます。
連携の追加開発は500万〜3,000万円規模になることもあります。また、複数ベンダーが関わると障害時の責任が曖昧になりやすいため、RFPで確認しておきましょう。
契約・撤退時に確認すべき条項
新システムの契約だけでなく、利用中の旧システムから撤退する条件も確認しておく必要があります。旧システムを終える費用を見積もらないと、移行の段階で想定外の請求を受けるおそれがあります。
新旧双方の契約条件を見通しておくことが、トータルコストを左右します。
契約前に確認する旧システムの「データ引き上げ」コスト
特に見過ごされやすい費用の一つが、旧システムからデータを引き上げる費用です。
自社にデータベースへ直接アクセスする権限がない契約では、抽出を旧ベンダーに頼むことになります。
移行テストやリハーサルのたびに依頼が必要となり、1回あたり数十万円かかる場合があります。さらに、複数回のテストで、百万円単位の予備費が必要になる可能性もあります。
新システムの発注前に、旧ベンダーとの契約書を確認してください。
- データの所有権
- データベースへのアクセス権
- 解約時のデータ提供条件と費用
自社がデータを取り出す権利を持っていれば、抽出のたびに費用を請求されずに済みます。
撤退（Exit）条件も、発注の判断に組み込んでおく必要があります。
解約条件・保守費・知的財産権の取り決め
新たな発注契約では、稼働後に関わる条件も取り決めておく必要があります。たとえばオンプレ型やスクラッチ開発では、年間保守費が初期構築費の15〜20%程度になるのが一般的です。5年分の保守費が初期費用と同じ程度になることもあります。
- 保守範囲：障害対応、法改正対応、軽微な改修の対象
- 知的財産権：成果物の帰属、ソースコード、資料の引き渡し
- 移転費用：旧倉庫の出庫作業費、早期解約違約金、割増保管料、棚卸費
権利と資料の扱いは、将来の改修や乗り換えのしやすさに影響します。
倉庫の物理移転も同時に行う場合は、これらの費用が月額の3〜6ヶ月分に達することもあります。
外注先と握るべき役割分担とリスク管理
外注は任せきりにせず、自社と発注先の役割を明確にして進めます。
データ移行や並行稼働で責任が曖昧だと、現場の混乱や誤出荷、業務停止を招きます。そのため、発注前に工程ごとの担当者を決めておきましょう。
データ移行とUATの責任分界点
「WMS移行の失敗の7割はデータに起因する」と言われるほど、データ移行は重要かつ難しい工程です。
- 発注先：データのマッピングや投入ツールを用意できる
- 自社：移行元データを整え、正しさと対象を決める
- 自社：受け入れテスト（UAT）を主導する
たとえば、過去12ヶ月間に入出荷実績のないマスタや休止中のロケーションを移行対象から外す、といった基準があります。その採否は、現場を知る自社が決めます。
通常業務に加え、セット品のばら返品や破損品処理のシナリオも用意しておきます。これらのシナリオで想定どおりに動作するかを確認します。
移行中も在庫は動くため、抽出から投入までの差を埋める方法を決めます。差分を移行先に反映するか、週末に業務を止めて一括で切り替えるかを、発注先と合意してください。
並行稼働とロールバックの責任の明文化
新旧システムを同時に動かす並行稼働（パラレルラン）は、事故が起きやすい工程です。
新旧双方から指示書やピッキングリストを出すと、指示系統が二重になります。その結果、重複ピッキングや誤出荷が続くおそれがあります。
並行稼働の終了時期が曖昧なままだと、現場の負担が続きます。そこで、たとえば出荷エラー率0.5%未満や、ERPとのAPI連携が4週間連続で安定稼働することを、終了条件にします。
- 指示系統：現場に出す物理的な指示書は、新システムからのみ出す
- 要員計画：二重入力で工数が通常の1.5〜2倍になる前提で組む
- 終了条件：事前に数値基準を定め、基準を満たしたら新システムへ完全移行する
- 切り戻し：判断者と出荷エラー率・棚卸差異率の基準を決め、旧システムと旧ハンディ端末を新稼働後も最低3ヶ月保持する
倉庫管理システム更改の発注でよくある失敗と回避策
WMS更改には、繰り返し起きる典型的な失敗があります。つまずきやすい点を知っておけば、避けられるリスクも少なくありません。
代表的な失敗には、次の2つがあります。
ベンダー丸投げによる要件漏れ
要件整理を発注先に任せきりにするのは、よくある失敗です。現場の業務は発注先の目には入りにくく、そのまま要件から抜けやすくなります。
- 要件漏れ：開発会社は現場を把握しきれず、例外処理が抜ける
- 現場との不一致：繁忙期業務も抜け、Excelで二重管理するおそれがある
- 回避策（自社が主導）：要件を洗い出してRFPを作り、実現したいことを伝える
- 回避策（現場を巻き込む）：キーパーソンが要件定義に参加し、漏れと反発を抑える
見積もりに出てこない隠れコストの見落とし
見積金額だけで発注先を決めると、隠れた費用を見落とすことがあります。
- SaaS型：初期0円、月20万円なら5年間で1,200万円
- パッケージ型：初期100万円、月10万円なら5年間で700万円
- ハンディ端末：1台5万〜30万円で、現場の人数分が必要
- 周辺費用：旧ベンダーの抽出費、保守費、倉庫移転費も含める
初期費用が無料でも、従量課金でオンプレ型を上回る場合があるため、5年TCOで比べます。また、AI駆動開発の会社も比較対象に加えると、予算面で難しかったフルフィットを選べる場合があります。
まとめ
倉庫管理システム更改の発注は、発注先を選ぶ前の準備が成否を左右します。
発注先を選ぶ前に、自社で整えておく項目を、あらためて確かめておきます。
発注を成功させるための要点
発注前に整える項目は、実行順に並べると次の5つです。
- 更改の目的とKPIを言葉にする
- As-Is/To-Beを整理し、要件をMust/Wantに分ける
- 例外処理と連携要件を含むRFPを作る
- 旧システムのデータ取得条件や保守費、知的財産権を確認する
- データ移行からUAT、並行稼働、切り戻しまでの担当と終了条件を決める
自社が準備を主導すれば、開発会社の提案を適切に評価できます。さらに、在庫差異やコスト超過といった稼働後の問題も防ぎやすくなります。
更改を「投資」に変える視点
倉庫管理システムの更改を投資として成果につなげるには、効果と切替時期、費用をあわせて考える必要があります。
- 期待する効果：在庫精度向上、誤出荷削減、人件費の見直し
- 切替時期：閑散期を選び、繁忙期の現場混乱を避ける
- 費用判断：5年TCOで負担を捉え、投資効果を高める
- 発注準備：進め方が更改の成否と投資回収を左右する
この記事を、自社の発注準備にお役立てください。
▼全体ガイドの記事
・倉庫管理システム更改の完全ガイド
▼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を創業。