WMS開発のPoC・プロトタイプ・モックアップ開発について

WMS（Warehouse Management System：倉庫管理システム）は、入荷検品、ロケーション管理、ピッキング、棚卸、出荷梱包といった「現場の物理的なモノの動きと作業員の行動」を直接管理・指示する実行レイヤーのシステムです。受注処理を担うOMS（受注管理システム）や、倉庫の外側で配車・輸配送を最適化するTMS（輸配送管理システム）は、どちらかといえばデータとロジックの世界で完結する部分が大きいのに対し、WMSはシステム上のロジックがどれほど優れていても、現場の物理的な制約や作業員の感覚に合わなければ機能不全に陥ってしまうという特殊性を持っています。この特性ゆえに、WMS開発ではPoC（概念実証）やプロトタイプ、モックアップを使った早期の現場検証が、他のシステム開発以上に重視されます。

本記事では、WMS開発におけるPoC・プロトタイプ・モックアップ開発に焦点を当て、この領域でPoCが重視される理由、PoCの一般的な進め方と期間・費用感、モックアップ・PoCで検証すべき具体的なポイント、そしてPoCから本開発へ移行する際の注意点や失敗しやすいポイントまでを、具体的な数値とともに体系的に解説します。これから倉庫内オペレーションを効率化するWMSの導入を検討している方はもちろん、すでにPoCの実施を計画している担当者にとっても、実践的な判断軸が身に付く内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

WMS領域でPoC・プロトタイプ開発が重視される理由

WMSにおいてPoCやプロトタイプが重視されるのは、「机上の空論」が現場で致命的なトラブルを引き起こすリスクが非常に高いためです。OMSであれば在庫引当ロジックの正しさをシステムテストで検証できますし、TMSであれば配車計算のシミュレーションで一定程度の妥当性を確認できますが、WMSの場合はシステムが指示する内容が「現実の倉庫の中でどう機能するか」を、実際の現場と実機を使って確かめない限り、本当の意味での検証は完了しません。

長年使い慣れた紙のリストや旧システムのオペレーションから変更になるため、WMSの導入は現場の反発が起きやすい領域です。画面のボタン配置やタップ回数がわずかに増えただけでも、1日に何千回とバーコードをスキャンする現場にとっては大きなストレスとなり、作業効率が著しく低下します。机上の検討だけでは見えない「使いにくさ」を、開発着手前の早い段階で発見する必要があります。

システム上で「最短距離」と計算されたピッキング動線であっても、現場のフォークリフトの旋回半径、通路の幅、重量物の配置ルール、作業者のスキルレベルなどを無視していると、かえって時間がかかったり、通路上で作業者同士の渋滞が発生したりします。加えて、セット商品のバラ返品、破損品の保留エリアへの移動、営業担当によるサンプルの予定外の持ち出しといった「現場の例外処理」は必ず存在し、これらがシステムにどう反映されるかを事前に実証しなければ、稼働後に在庫差異が爆発的に増える事態を招きます。

OMSの在庫引当ロジックにバグがあれば、複数チャネル間での売り越し（二重販売）という形で問題が顕在化しますが、WMSの現場オペレーションに設計不備があると、システム上の在庫数と実際の棚にある数量が食い違う「在庫差異」という、より発見しづらい問題として蓄積していきます。在庫差異は日々の出荷業務では見過ごされがちですが、月次・年次の棚卸のタイミングで一気に表面化し、欠品による販売機会の損失や、逆に過剰在庫による保管コストの増加という形で経営に直接的な打撃を与えます。だからこそ、稼働してから問題に気づくのではなく、PoCの段階で現場のオペレーションとシステムのロジックがかみ合っているかを丁寧に検証しておくことが、WMSにおいては他のシステム以上に重要な意味を持ちます。

PoCの一般的な進め方と期間・費用感

WMSのPoCは、要件定義の後に、あるいは並行して行われ、フィット＆ギャップ検証というステップを踏んで進行するのが一般的です。ここでは、その具体的な進め方と、期間・費用の目安を解説します。

実際の現場データ（商品マスタや入出荷データ）を用いて最小限のシステム（MVP：Minimum Viable Product）やプロトタイプを構築し、現場の作業者に実際にハンディ端末などを触ってもらいながら、日々の業務フローに沿ってテストを行うことで、要件とのギャップを洗い出します。近年では、AI駆動開発（ローコード・ノーコードなど）を活用して、数日〜数週間で実際に動く画面を作り、高速で検証を回す手法も登場しています。設計・プロトタイプ検証フェーズは、WMS開発プロジェクト全体の10〜20%前後の期間を占めるのが一般的な目安です。

基本機能（在庫管理、簡易的な入出荷管理、基本ロケーション管理など）に絞った小規模なプロトタイプ（MVP）開発の費用相場は、300万〜800万円程度が一つの目安です。進め方としては、まず最も困っている1拠点・1業務に絞った最小機能のMVPを約2〜3ヶ月でリリースし、続く3〜6ヶ月程度の期間で現場でのトライアル運用を行いながら既存業務フローと並行稼働させ、使い勝手や追加要件を洗い出します。そのうえで、優先度の高い機能（自動倉庫連携やピッキング動線最適化など）をアジャイルに順次追加し、安定稼働を確認してから他拠点へ展開していく段階的な進め方が、失敗リスクを最小化する現実的なアプローチです。

従来のWMS開発では、要件をまとめてからプロトタイプの画面が動くようになるまでに数週間〜1ヶ月程度を要するのが一般的でしたが、近年はAIによるコード生成やノーコード・ローコードツールを組み合わせることで、この期間を大幅に短縮する動きが広がっています。実データ（サンプルの商品マスタや入出荷実績）を投入した簡易的な画面を数日〜1週間程度で用意し、現場担当者に触ってもらいながら細かい調整を繰り返す「高速イテレーション」型のPoCであれば、現場の生の反応を早い段階で吸い上げられるというメリットがあります。ただし、AI駆動開発によって「画面が動く」ところまでは早く到達できても、マテハン機器との実機連携やロケーション設計の物理的な妥当性検証には相応の期間が必要であることに変わりはなく、スピードと品質のバランスを見極めた計画が求められます。

モックアップ・PoCで検証すべきポイント

現場でのPoCにおいては、以下のようなポイントを実データと実機を使って具体的に検証していく必要があります。単に画面が動くかどうかではなく、実際の現場でストレスなく使えるかという視点での検証が欠かせません。

画面の見やすさや、手袋をしたままでの操作性に加えて、「通信のレスポンスタイム」が非常に重要な検証項目です。大量のデータ処理が走った際に、ハンディターミナルでバーコードを読み取ってから結果が反映されるまでに数十秒かかるような状態になると、現場作業が完全に停止してしまいます。ネットワーク環境が不安定になりやすい倉庫の奥まったエリアや金属棚が密集するエリアでも安定した通信ができるかを、PoC段階で実機を用いて確認しておくべきです。

フリーロケーション（空きスペースへの自由配置）や固定ロケーションなど、設計したロケーション管理の粒度が現場運用に即しているかを確認します。システムが指示するピッキング順序が、実際の倉庫内の通路や設備の配置と矛盾していないか、複数の作業者が同時に稼働した際に動線が交錯しないかを、実際の倉庫レイアウト上で検証することが重要です。あわせて、予定外の入荷（試供品やテスター等）や、一部商品の破損によるステータス変更など、現場で日常的に発生するイレギュラー処理を、作業者がハンディ上で迷わず処理できるかも検証すべきポイントです。

WMSは単独で稼働することが稀なシステムです。上位のOMSから出荷指示データを受け取り、出荷完了後には下位のTMSへ実績データを渡すという連携が正しく機能するかどうかを、PoC段階から検証しておく必要があります。PoCの多くはWMS単体の画面操作性に注目が集まりがちですが、データフォーマットの整合性やAPI連携のタイミングにズレがあると、本稼働後に受注情報が正しく反映されない、出荷実績が配送側に伝わらないといった重大なトラブルにつながります。PoCの段階で、少なくとも一つの外部システムとの間でサンプルデータを使った疎通テストを実施し、連携の実現可能性を確かめておくことが望ましい対応です。

PoCから本開発へ移行する際の注意点・失敗要因

PoCを実施したことで安心してしまい、本開発や本番稼働で失敗するという「落とし穴」がWMSには存在します。ここでは、代表的な失敗パターンとその対策を解説します。

PoCで現場にシステムを触らせると、「今の業務のやり方（旧システムの画面）」に近づけてほしいという要望が大量に出てきます。これをすべて受け入れて例外処理をシステムに組み込もうとすると、カスタマイズが際限なく膨らみ、当初予算の1.5〜2倍に費用が跳ね上がるケースが珍しくありません。必須（Must）と希望（Should/Want）を明確に峻別し、パッケージの標準機能に業務を合わせる「Fit to Standard」の姿勢を貫くことが重要です。また、PoC段階で発覚した要件漏れや変更要求は、その時点で吸収しなければなりません。設計・開発の後工程や本番直前になってから仕様を変更しようとすると、要件定義段階で対応した場合の最大200倍の手戻りコストが発生すると言われています。

PoC環境では少量の綺麗なダミーデータでテストが成功しても、本番環境のデータを流し込んだ途端にエラーが連発することがあります。過去12ヶ月間に入出荷実績がない商品や、廃止されたロケーションコードなどの「ゴミデータ」が残っていると、新システムのロケーション管理が混乱します。PoCと並行して、過酷なデータクレンジング（マスタ整備）を進めておくことが、本開発移行の絶対条件です。あわせて、システム連携を後回しにするとトライアルでWMS単体の操作性のみを確認して連携検証を後回しにしてしまい、本稼働時にOMSやTMSとの間で二重入力が発生し業務負荷が増大するという失敗パターンも典型的です。PoC段階から上位・下位システムとの連携方法を具体的に定義・検証しておくことが欠かせません。

まとめ

本記事では、WMS開発におけるPoC・プロトタイプ・モックアップ開発について、PoCが重視される理由、進め方と期間・費用感、検証すべきポイント、そして本開発移行時の注意点までを体系的に解説しました。WMSは、受注処理を担うOMSや倉庫外の輸配送を担うTMSとは異なり、「現場の物理的なモノの動きと作業員の行動」を直接管理・指示する実行レイヤーであるため、机上の設計だけでは検証しきれないユーザビリティやピッキング動線の妥当性を、実データ・実機を使ったPoCで早期に確認することが不可欠です。費用相場は基本機能に絞った小規模MVPで300万〜800万円程度、期間は設計・プロトタイプ検証フェーズ全体で開発期間の10〜20%程度が目安です。PoCから本開発への移行では、現場要望の全受容によるカスタマイズ肥大化と、マスタデータの品質不良という二つの落とし穴に注意し、Fit to Standardの徹底とデータクレンジングの並行実施を心がけることが、失敗しないWMS導入の鍵となります。まずは自社の倉庫で最も課題の大きい1拠点・1業務を特定し、小さく始めて検証しながら拡張していくアプローチから着手することをお勧めします。

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

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。