WMS開発の開発期間・スケジュール・納期について

WMS開発は、方式と倉庫規模を定め、設備と外部連携を設計し、テストと並行稼働を経て本番化する順に進みます。期間は提供形態と規模で変わり、設備連携の有無も大きく影響します。

規模と方式ごとの期間の目安を示し、納期を守るための考え方も合わせて取り上げます。全体像はWMS開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・WMS開発の完全ガイド

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

WMS開発の開発期間の全体像

WMSは、倉庫内のモノの動きと現場作業を指示する実行レイヤーです。モノの所在や担当者、動かす順序を扱い、入荷検品から出荷梱包までを管理します。

OMSはECモール、自社EC、実店舗POSなど複数チャネルの受注を集約し、在庫引当から出荷指示までの処理を担います。一方、TMSは倉庫から出荷した後の配車計画、ルート最適化、ドライバー管理を担います。倉庫内の現場作業に特化するWMSは、OMSやTMSとは異なる観点で期間を見積もる必要があります。

EC市場の拡大による出荷件数の増加や、物流の2024年問題に象徴される労働力不足を背景に、WMSの導入・刷新のニーズが高まっています。その主な目的は、現場作業の標準化と省人化です。

開発期間は、クラウド型SaaS、パッケージ型、フルスクラッチ型のどの提供形態を選ぶかで変わります。さらに、SKU数や、自動倉庫・コンベア・AGV（無人搬送車）との連携の有無も期間に影響します。

規模別の開発期間と費用の目安

ここでは、方式ごとの期間・費用と、倉庫の規模に応じた開発の違いを並べて示します。

• クラウド型：標準機能を使い、短期間で導入
• パッケージ型：自社要件に合わせたカスタマイズが可能
• フルスクラッチ型：倉庫規模や自動化に応じて個別開発

クラウド型（SaaS）は標準機能を使うぶん、契約からAPI接続や端末設定までが最短2週間〜3ヶ月程度です。初期費用は0〜100万円程度、月額は数万円〜20万円以上です。

クラウド型を5年間使う場合、総所有コスト（TCO）は約1,300万〜1,800万円になります。ただし、独自のロケーション体系や特殊なピッキングロジックには、原則として対応できません。

パッケージ型は、オンプレミスまたはクラウド基盤で稼働します。標準機能に自社要件を反映するカスタマイズが加わるため、期間は3ヶ月〜1年程度です。

パッケージ型の初期費用は500万〜数千万円です。月額・保守費用は、開発費の10%程度に数百万円が加算され、5年TCOは6,000万円以上が目安です。

小規模（1,000SKU以下）は基本機能が中心で、期間は3〜6ヶ月、初期費用は300万〜800万円です。中規模（10,000SKU以下）は倉庫管理全般を扱い、期間は6〜12ヶ月、費用は800万〜2,500万円です。

大規模は複数拠点やマテハン連携を伴うため、期間は12〜18ヶ月（最長3年以上）、初期費用は2,500万円〜数億円が目安です。さらに、5年TCOが1億3,000万円以上に上ることも珍しくありません。

期間を左右する主な要因は、画面数の多さよりも、SKU数、拠点数、マテハン機器との連携の有無です。

同じ中規模でも、条件によって期間は変わります。たとえば、単一倉庫でハンディ端末のみを使う場合と、複数拠点で自動倉庫やAGVと連携する場合では、期間が異なります。

開発期間に影響するWMS特有の要因

期間を左右する最大の要因は、自動化設備やマテハン機器との連携範囲です。外部連携、現場業務、データ移行も、期間に影響します。

• 設備：制御・通信の設計と実機検証が必要
• 外部システム：リアルタイム連携では例外処理の設計も必要
• 現場業務：例外処理の範囲が実装難易度を左右
• データ移行：マスタ差異の調整と在庫差分の反映が必要

バーコードスキャナやハンディターミナルとの連携費用は、50万〜500万円程度です。一方、自動倉庫、コンベア、AGV、ピッキングロボットでは、WCS（倉庫制御システム）やWES（倉庫運用管理システム）を介して連携します。

設備連携には複雑な制御・通信の設計が必要です。そのため、開発費は1,000万〜3,000万円以上になり、期間も大幅に延びることがあります。

ERPや上位のOMS、下位のTMSとの連携の難しさも、期間に影響します。特にAPIによるリアルタイム連携では、通信エラー時の例外処理とデータ競合の制御が必要です。

サーバー間のタイムゾーン（時刻同期方式）が異なると、在庫の二重引当につながる深刻なバグが起きるおそれがあります。さらに、連携インターフェースの調整工数も膨らみます。

先入先出（FIFO）を厳密に行うアルゴリズムや、賞味期限・ロット単位の引当も、実装の難しさに影響します。また、セット品のバラ返品や予定外のサンプル持ち出しを、どこまで扱うかも検討が必要です。

商品コードの桁数やロケーションマスタの体系が新旧で異なる場合、複雑なマッピング設計が必要です。物流を止めずに移行するなら、移行中に変動した在庫の差分を反映するプログラムも欠かせません。

標準的な開発工程とスケジュール例

中規模WMSの工程は、各工程の工数配分と並行稼働まで含めて見積もる必要があります。

• 要件定義：全体の10%前後
• 設計・プロトタイプ検証：全体の10〜20%前後
• 開発実装：全体の40〜60%前後
• テスト・UAT・教育：全体の10〜20%前後
• 並行稼働：本番前に別途期間を確保

中規模の総期間はおよそ6〜9ヶ月です。工程は、要件定義・設計、開発実装・ハンディ連携、テスト・並行稼働の三つの山場に分けられます。

最上流のシステムデザインは全体の約2割を占めます。その精度が、納期を守れるかどうかを左右します。

要件定義・設計フェーズ（全体の20〜30%）

要件定義・設計には、プロジェクト全体の20〜30%程度を割り当てます。まず、現場の作業のどこまでをシステム化するかを洗い出し、設計へ落とし込みます。

• 業務範囲：入荷検品から出荷梱包までの対象を定義
• 倉庫内の方式：ロケーション管理と引当の方法を決定
• 連携範囲：基幹システム、OMS、TMSとの接続を整理

具体的には、ロケーションをフリーにするか固定にするか、引当を先入先出にするかロット・賞味期限単位にするかを、ここで決めます。

画面やDBを設計する前に、PoC（概念実証）で現場の動線や作業実態とのずれを検証するケースも増えています。

ロケーション設計や引当方式は後工程への影響が大きいため、途中で変えると設計・開発のやり直しが発生し、全体日程に響きます。そこで、要件定義書、ロケーション設計書、引当ロジック設計書を文書にまとめておくと、後続工程の手戻りを防げます。

開発実装・ハンディ連携フェーズ（全体の40〜60%）

設計が確定したら、開発に進みます。この工程は全体の40〜60%程度を占め、機能と各種連携を実装します。

• 実装：画面、バックエンド、在庫計算、引当ロジック
• 接続：ハンディ端末、OMS、ERP、TMSとの連携
• 設備制御：対象に応じWCS・WESとの通信を開発

自動倉庫、AGV、ピッキングロボットを連携する場合は、制御や通信の作り込みが加わるため、期間と工数が大幅に増えます。

期間を縮めるには、ハンディ端末の機種や設備の通信仕様を早く確定させ、共通化する部分と個別対応する部分を分けておくことが大切です。

社内テストでは、基幹システムやOMS・TMSとの連携を確かめます。先に不具合を解消しておくと、次の現場テストを進めやすくなります。

テスト・UAT・並行稼働フェーズ（全体の20〜30%）

テスト・UAT・並行稼働には、全体の20〜30%程度を割り当てます。単体・結合テストのあとは、現場スタッフが端末を操作して業務を検証します。

• 受入テスト：ギフト包装や返品などの例外業務を確認
• 並行稼働：新旧システムを同時稼働して結果を照合

UAT（受入テスト）では、イレギュラー業務も含めて、テスト完了率100%を目指します。

パラレルラン（並行稼働）は、通常2〜4週間が目安です。ただし、大規模倉庫では月次棚卸まで検証するため、3ヶ月程度を確保するケースもあります。

システムの完成日と、現場が新システムで正しく稼働する日は同じではありません。そのため、並行稼働の期間も含めて計画することが、納期を守ることにつながります。

マテハン機器連携・外部システム連携が納期に与える影響

OMSは販売チャネル数や在庫の同期方式、TMSは取引先ごとの通信手順によって期間が変わります。一方、WMSでは倉庫に置かれた物理設備との連携範囲が、期間に大きく影響します。

ハンディターミナルなどの入出力デバイスであれば、追加の工数は数週間〜1ヶ月程度です。これに対し、自動設備では、指示が実際の動きに反映されるかを実機で繰り返し検証する必要があります。

実機テストは天候や機器の稼働状況にも左右されます。そのため、ソフトウェア単体テストとは異なる日程管理が必要です。

ハンディターミナル連携と自動化設備連携の違い

接続方式によって、費用と期間は大きく異なります。加えて、通信規格やメーカー仕様も確認が必要です。

• ハンディ・スキャナ：標準規格を使う場合が多い
• 自動化設備：中間システムを介して個別制御

ハンディターミナルやバーコードスキャナの場合、追加費用は50万〜500万円程度、期間は数週間〜1ヶ月程度です。

一方、自動倉庫、コンベア、AGV（無人搬送車）、ピッキングロボットには、WCSやWESを介した独自のリアルタイム制御・通信が必要です。そのため、開発費は1,000万〜3,000万円以上になり、期間は数ヶ月単位で延びます。

設備メーカーごとに通信プロトコルや制御仕様が異なります。複数メーカーの設備が混在すると、個別対応が増えて開発が複雑になります。

設備連携では、要件定義の初期に対象の設備メーカーと通信仕様を確定します。あわせて、開発会社に設備連携の実績があるかも確かめます。

上位システム（OMS）・下位システム（TMS）との連携設計

WMSは多くの場合、受注情報を渡す上位のOMSと、出荷後の配送を担う下位のTMSの間で稼働します。また、連携方式によって工数と期間が変わります。

• OMSからWMS：出荷指示データを受け取る
• WMSからTMS：出荷実績データを渡す
• 接続方式：バッチ連携かAPIのリアルタイム連携かを選ぶ

この連携が正しく機能して初めて、受注から配送までの全体の流れが成り立ちます。

特に注意が必要なのは、サーバー間のタイムゾーン（時刻同期方式）の不一致です。不一致があると更新がずれ、在庫の二重引当を招くおそれがあります。

一定間隔のCSV連携で足りるか、APIによるリアルタイム連携が必要かを決めます。即日出荷や在庫のリアルタイムな把握を重視するなら、三者をAPIでつなぐ設計が求められます。

リアルタイム連携では、通信エラー時の例外処理とデータ競合の制御も実装します。そのため、その分の期間を確保しておく必要があります。

納期を短縮する具体的な方法

実稼働までの期間を左右するのは、マスタ整備の進み具合と、検証を1拠点・1業務に絞る範囲です。開発チームを増やすことが、そのまま納期短縮につながるとは限りません。

品質と現場への適合性を保ちながら期間を縮める方法は、データ整備の前倒しと、MVPによる段階導入です。

マスタデータクレンジングの前倒し着手

商品・ロケーションマスタのクレンジングは、要件定義の前に社内で始めます。コードや登録状態の不整合を、開発前に整理しておくことがポイントです。

• 商品コード：桁数の違いや重複登録を整理
• ロケーション：未使用コードを確認
• 実績データ：過去12ヶ月入出荷のない商品を確認

不整合を残したまま開発を進めると、テストで紐付けエラーが多発し、納期遅延の致命的な原因になります。さらに、廃止済みのコードやゴミデータは、ロケーション管理も混乱させます。

品目数が多い場合は、クレンジングだけで数ヶ月かかることもあります。そのため、開発会社への発注前か、要件定義と並行して始めると、後工程を圧縮できます。

1拠点・1業務に絞ったMVPによるスモールスタート

全拠点・全業務を一度に作るビッグバン方式を避け、課題の大きい1拠点・1業務に絞ったMVP（最小限の機能セット）を、先行してリリースします。

1. 2〜3ヶ月程度でMVPをリリース
2. 3〜6ヶ月程度の現場トライアルで、使い勝手と追加要件を洗い出し
3. 費用対効果の高い機能をアジャイルに追加し、安定稼働後に他拠点・業務へ拡大

追加機能には、自動倉庫との連携や、ピッキング動線を最適化する機能などがあります。一方、コア機能は数ヶ月程度で立ち上げられるため、投資対効果を早い段階で確認できます。

全拠点を一斉に導入すると、不具合発生時の影響範囲が大きく、全体納期に響くリスクがあるため避けるべきです。

納期遅延の典型要因と対策

遅延リスクは、綿密に計画しても完全にはなくせません。そこで、典型要因を把握し、契約や進捗管理に対策を組み込むことが大切です。

主な要因は、現場の例外業務の洗い出し不足と、並行稼働の終了条件（Exit Criteria）が未定義であることです。

現場イレギュラー業務の洗い出し不足

もっとも多い遅延要因は、現場に根付いた例外業務の洗い出し不足です。結合テストの終盤やUATで要件が表面化しないよう、標準作業だけで捉えないことが欠かせません。

• 返品・破損：セット品のバラ返品、保留エリアへの移動
• 予定外作業：サンプル持ち出し、ギフト包装、同梱処理

後から出てくる要件は、追加開発を招き、スコープクリープとして納期を圧迫します。例外を網羅するには、入荷検品、格納、ピッキング、出荷梱包の標準の作業の流れに加えて、現場の例外を一つずつ洗い出す必要があります。

要件定義では、作業員への聞き取りを徹底します。そのうえで、開発会社任せにせず、ユーザー企業が全業務フローを洗い出してUATシナリオを作成します。

例外業務シナリオのテスト完了率100%を受入基準にすると、例外パターンの漏れを確認できます。

並行稼働の終了条件（Exit Criteria）未定義によるトラブル長期化

もう一つの遅延要因は、並行稼働をいつ終えて一本化するかを決める、定量的な終了条件が未定義なことです。基準が曖昧だと、二重入力で現場が疲弊し、エラーが収束せずに停滞するおそれがあります。

• 在庫差異：差異率が〇%以下の状態が〇日継続
• 受入テスト：全例外シナリオの完了率が100%に到達
• 切り戻し：旧システムへ戻す計画と決断基準を設定

開発会社と終了条件を事前に合意し、文書に残します。在庫差異率の数値や継続日数は、案件ごとに決める条件です。

稼働後の重大な問題に備えて、旧システムへのロールバック計画と判断基準を決めておきます。さらに、全体工数の10〜20%程度をバッファとして確保しておくことも、現実的な対策です。

まとめ

ここまで、WMS開発の期間・スケジュール・納期を、期間の目安、工程配分、連携の影響、短縮策と遅延対策の観点から見てきました。

WMSの開発期間は、クラウド型で最短2週間〜3ヶ月、パッケージ型で3ヶ月〜1年です。フルスクラッチ型は、小規模3〜6ヶ月、中規模6〜12ヶ月、大規模12〜18ヶ月（最長3年以上）が目安です。

5年TCOは、クラウド型で1,300万〜1,800万円程度、パッケージ型で6,000万円以上、フルスクラッチ型で1億3,000万円以上が目安です。規模と方式によって費用も変わります。

OMSは販売チャネル、TMSは取引先ごとの通信手順が期間を左右します。一方、WMSでは設備連携と例外業務の範囲が納期に響き、見誤ると開発後も本稼働まで長引きます。

遅延の主な要因は、例外業務の洗い出し不足と、並行稼働の終了条件の未定義です。そのため、上流で要件を詰めておき、全体工数の10〜20%をバッファとして持つことが対策になります。

まずSKU数、拠点数、マテハン機器の有無を整理します。そのうえで、複数の開発会社にWMS構築の実績を確かめ、見積もりを依頼します。

▼全体ガイドの記事
・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を創業。