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

WMS改修とは、既存WMS（倉庫管理システム）を全面的に作り替えるのではなく、「特定ロケーションのピッキング動線だけを見直したい」「ハンディターミナルの特定画面を軽微に修正したい」といった、特定機能・特定モジュールに絞った小規模な修正を指します。これまで解説してきた「WMSのモダナイゼーション」「WMS刷新」「WMS更改」「WMSのリニューアル」「WMSのリアーキテクチャ」「WMSリプレイス」の6記事群では、PoC（概念実証）は「新しい技術的アプローチが実現可能か」「既存のロケーションマスタ・在庫データを正確に移せるか」「倉庫稼働を止めずに新旧システムを並行稼働させられるか」といった、全面刷新に伴う技術的な不確実性を検証する重要な工程として位置づけられていました。これに対して本記事が扱うWMS改修では、PoC・プロトタイプ・モックアップの位置づけがまったく異なります。同じ略語・同じ試作品という言葉を使っていても、目的も規模も別物であると捉え直すことが理解の出発点になります。既存WMSの枠組みの中で行う画面修正や動線変更は技術的な不確実性が低いため、多くの場合PoCそのものは不要であり、代わりに「現場の作業員が見やすいか、使いやすいか」を素早く合意するための軽量な検証手法が中心になります。この違いを見誤ると、不要な検証コストをかけすぎたり、逆に必要な検証を省いてしまったりと、どちらの方向にも失敗しかねません。

本記事では、WMS改修におけるPoC・プロトタイプ・モックアップ開発にフォーカスして解説します。低予算・短納期という部分改修の強みを活かしながら、検証不足による失敗を避けるためのバランスの取り方を中心にお伝えします。モックアップ・プロトタイプ・PoCという3つの検証手法の使い分け、それぞれの進め方と費用感、WMS改修においてPoCが例外的に必要になるケース、そして検証を簡略化する際に注意すべきWMS特有の落とし穴までを体系的にお伝えします。「全面刷新のような大がかりな検証プロセスは組めないが、現場に受け入れられない改修を作ってしまうリスクは避けたい」という物流部門・情報システム部門の方にとって、身の丈に合った検証の進め方が身に付く内容です。限られた予算・期間の中でも「何を確認すれば安心して着手できるか」を見極める判断軸として活用してください。

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

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

WMS改修におけるPoC・プロトタイプ・モックアップの位置づけ

WMS改修における検証手法を理解するには、まず「何のために検証するのか」という目的を、隣接する6つの記事群と切り分けて整理する必要があります。同じ「試作品を作って確認する」という行為でも、確認すべき対象がまったく異なるためです。この違いを理解しないまま全面刷新と同じ重さの検証プロセスをそのまま部分改修に当てはめてしまうと、検証だけで改修全体の予算・期間を圧迫してしまう本末転倒な事態を招きかねません。

「WMSのモダナイゼーション」のPoCは、選定した技術的アプローチ（リホスト〜リプレースの5R）が技術的に実現可能か、既存のロケーションマスタ・在庫データを正確に新環境へ移せるかという「移行の正確性」を検証するものでした。「WMS更改」のPoCは、EOS/EOLという動かせない期限の中で新システムが既存の出荷業務を代替できるかという実現可能性の確証を得るためのものであり、「WMSのリアーキテクチャ」に至っては、ドメイン境界設計やマテハン連携基盤の技術的な妥当性そのものを検証する高度な技術検証でした。これらはいずれも「新しい技術・新しい構造が本当に機能するか」という技術的な不確実性を解消するための工程です。これに対して本記事が扱うWMS改修は、既存WMSという実績のある技術基盤の上で、画面のレイアウトや操作フローだけを変更するケースがほとんどであり、技術的な不確実性そのものが低いという前提があります。したがって本記事のPoC・プロトタイプ・モックアップは、技術が動くかどうかではなく、「現場の作業員がその変更を受け入れ、使いこなせるか」という、人と業務に関わる不確実性を解消するための軽量な検証として位置づけられます。全面刷新の記事群が「本当に動くシステムを、正しいデータで、止まらずに移行できるか」という技術リスクの排除を目的とするのに対し、WMS改修は「作ったものが、明日から現場で違和感なく使われるか」という受容リスクの排除を目的とする、という対比で理解すると分かりやすいでしょう。

WMS改修において基本的にPoCは不要・省略可能ですが、すべてのケースで不要というわけではありません。たとえば、既存のハンディターミナルとは異なる新しい機種の端末を部分的に導入する場合、その端末が既存WMSと問題なく通信できるか、倉庫内の電波環境で安定して動作するかは、技術的な不確実性が残るポイントです。このように、改修の範囲内に「これまで自社WMSで実績のない新しい技術要素」が含まれる場合は、その部分に絞った小規模なPoCを実施すべきです。予算と期間が限られる小規模改修においては、対象範囲全体にPoCをかけるのではなく、不確実性が残る部分だけを切り出して検証するという「絞り込み」の発想が重要になります。新端末の通信検証、新しいバーコード規格への対応検証、外部の在庫連携APIとの疎通確認といった、既存WMSの実績が及ばない領域が改修に含まれていないかを、着手前に必ずチェックしておくべきです。判断に迷う場合の簡易的な基準として、「今回の改修に使う技術要素は、すでに自社のどこかの拠点・どこかの業務で実際に稼働している実績があるか」を自問してみるとよいでしょう。実績があれば技術的な不確実性は低くPoCは不要、実績がなければ規模を絞ったPoCを検討する、という一次的な切り分けの目安になります。

モックアップ・プロトタイプの進め方（現場合意形成のプロセス）

WMS改修における検証の主役は、PoCではなくモックアップとプロトタイプです。現場作業員の「使い勝手」が作業効率に直結するWMSだからこそ、この2つの検証手法を正しく使い分けることが、改修を成功させる鍵になります。

モックアップは、実際の機能は動かさず、ハンディターミナル上のボタン配置や文字の大きさ、画面の色使いといったビジュアルを静的な画像として確認するための試作品です。開発コストがほとんどかからないため、WMS改修においてはほぼ必須の工程と位置づけるべきです。改修設計の初期段階でモックアップを作成し、実際にハンディターミナルを日々操作している現場のピッキング担当者・検品担当者に見てもらうことで、「文字が小さくて読みにくくないか」「ボタンの配置が今までと違いすぎて戸惑わないか」といった意見を、コーディングに着手する前の段階で吸い上げられます。特にWMS改修では、システムを発注する情報システム部門の担当者と、実際に画面を操作する倉庫現場の担当者が異なることが多く、両者の間で「見やすさ」の感覚にズレが生じがちです。モックアップという低コストな手段を挟むことで、このズレを早期に埋め、開発着手後の手戻りを防ぐことができます。モックアップの作成には専用のデザインツールを使う必要はなく、既存の画面キャプチャに修正案を重ねて示す簡易的な資料でも十分に機能します。重要なのは精緻さではなく、現場担当者と「これで進めてよいか」を短時間で合意できるスピード感であり、モックアップに時間をかけすぎることは、短納期というWMS改修の利点を損なう本末転倒な結果につながります。

プロトタイプは、画面遷移やボタンのタップといった一部の機能を実際に動かせる試作品で、モックアップより一段階踏み込んだ検証手段です。ピッキング動線の変更に伴う画面操作など、ユーザーのインタラクションが多い改修では、プロトタイプの作成を強く推奨します。現場担当者に実際にプロトタイプを操作してもらい、「次にどのボタンを押せばよいか迷わないか」「スキャンした後の画面遷移が想定通りか」を検証・改善するプロセスを繰り返すことで、本番実装後の手戻りを大幅に減らせます。WMS改修の予算・期間は限られているため、プロトタイプの作成範囲は改修対象の画面フローに絞り込み、あくまで操作性の確認に必要な最小限の機能だけを動かす形にとどめるのが実務上のコツです。全機能を精緻に作り込んだプロトタイプを目指すと、それ自体が本開発と変わらない工数になってしまい、短納期というWMS改修の利点を損なってしまいます。プロトタイプによるユーザーテストは、可能であれば実際に業務で使うハンディターミナルの実機、あるいはそれに近い画面サイズの端末上で行うことが望ましく、PCの大きな画面上だけで確認して「問題なさそうだ」と判断してしまうと、実機ならではの操作性の課題（文字の潰れ、タップ範囲の狭さ、片手操作のしにくさなど）を見落とすリスクがあります。改修規模が小さいプロジェクトほど実機検証が省略されがちですが、ここを省くと本番リリース後に現場から不満の声が上がりやすくなる点には注意が必要です。

PoCが必要になるケースと進め方

前章で例外として触れた、PoCが必要になるケースについて、より具体的な進め方を見ていきます。WMS改修であっても、技術的な不確実性が残る部分については、規模を絞ったPoCで確実に実現可能性を確かめておくべきです。ここを曖昧にしたまま本開発に進んでしまうと、着手後に技術的な問題が発覚し、結果的に短納期という部分改修の最大の利点を失うことになります。

新しいハンディ端末の導入や、既存WMSにはない外部システムとの新規連携を伴う改修では、対象を「通信部分のみ」「連携インターフェース部分のみ」というように限定した絞り込みPoCを実施します。改修の要件整理シートに「新しい技術要素を含むか」というチェック欄を設けておく運用にすれば、発注元・依頼先の双方でPoCの要否を見落とさずに済みます。たとえば、倉庫の奥まったエリアや金属棚が密集するエリアでも新端末が安定して通信できるかを、実際の倉庫環境で検証する、あるいは新しく連携する外部システムとのデータ授受が想定どおりのタイミング・フォーマットで行われるかを、実データに近いサンプルを使って確認するといった検証がこれに該当します。全面刷新のPoCが数週間〜数ヶ月規模で行われるのに対し、WMS改修における絞り込みPoCは、検証対象を最小限に絞り込んでいる分、数日〜2週間程度の短期間で完了させることを目指すべきです。検証項目を広げすぎると、それだけで改修全体のスケジュールを圧迫してしまうため、「何が分かれば着手してよいと判断できるか」を事前に明確にしたうえで、必要最小限の範囲でPoCを設計することが重要です。

WMS改修における絞り込みPoCは、全面刷新のPoCのように専用のテスト環境を大規模に構築する必要がなく、対象の端末やインターフェースを用いた最小限の検証で済むため、費用感も数十万円程度に収まるケースがほとんどです。検証の結果、技術的に問題がないと確認できれば、そのままプロトタイプ・本開発へと進みます。一方、検証の結果「想定していた新端末では倉庫内の電波が安定しない」「外部連携のデータフォーマットに互換性がない」といった問題が見つかった場合は、改修の前提そのものを見直す必要があります。この見直しにかかる時間を後工程で吸収しようとすると納期に大きくしわ寄せが来るため、技術的な不確実性が残る要素があると分かった時点で、できるだけ早い段階でPoCに着手し、着手判断のボトルネックにしないことが実務上のポイントです。

検証を省略・簡略化する際の注意点（WMS改修特有の落とし穴）

PoCを省略し、モックアップ・プロトタイプに重心を置くというWMS改修の進め方は、短納期・低予算を実現するうえで合理的である一方、検証全体を簡略化しすぎると別のリスクを招きます。ここでは代表的な2つの注意点を解説します。

PoCが不要だからといって、テスト工程まで簡略化してよいわけではありません。モックアップ・プロトタイプでの検証はあくまで「見た目」と「操作性」を確認するものであり、改修した機能が既存の他の機能に悪影響を及ぼしていないかというデグレード（機能低下）の検証とは別物です。特定のピッキング画面だけを修正したつもりが、データの保存処理や別画面の機能に悪影響を及ぼし、現場の作業が停止してしまうというトラブルは、モックアップ・プロトタイプの段階では見つけられません。改修の影響範囲を洗い出したうえで、本番相当のデータを用いたデグレードテストを、規模が小さい改修であっても省略せずに実施することが、検証プロセス全体を簡略化する中でも最後まで残しておくべき最低限のラインです。言い換えれば、WMS改修における検証の優先順位は「PoC＜デグレードテスト」であり、限られた予算を配分する際には、まず影響範囲調査とデグレードテストの工数を確保したうえで、余力があればモックアップ・プロトタイプの精度を高めるという順番で考えるのが実務上のバランスと言えます。

もうひとつの注意点が、モックアップ・プロトタイプの検証を、情報システム部門や依頼先だけで完結させてしまうことです。実際にハンディターミナルを日々操作する現場のキーパーソンをモックアップ・プロトタイプの検証段階から巻き込むことで、システム上は問題なく見えても実際の運用実態とはずれているといった、机上の検証だけでは気づけない問題を早期に発見できます。現場の意見を聞かずに情報システム部門の判断だけで改修を進めてしまうと、本番リリース後に「これでは現場で使えない」という声が噴出し、結果的に緊急の再改修が必要になり、短納期・低予算というWMS改修の利点が失われてしまいます。また、モックアップ・プロトタイプの検証と並行して、リリース後の現場教育・周知の計画も早めに立てておくことが重要です。検証段階で現場担当者に触れてもらった経験は、そのまま本番リリース後の操作教育の下地にもなるため、検証プロセスと教育プロセスを分断せず、一連の流れとして設計することが、WMS改修を現場に根付かせるための実務的なポイントです。巻き込むべき現場キーパーソンは、必ずしも管理職である必要はなく、むしろ日々の作業を最もこなしている現場のベテラン担当者や、逆に新人教育を担当している担当者を選ぶことで、幅広い習熟度の視点から意見を集められます。改修の規模が小さいからといって声かけを1人だけにとどめてしまうと、その1人の感覚だけに基づいた改修になり、他の作業員には使いにくいという結果を招くリスクがあるため、少なくともシフトの異なる複数名から意見を聞く体制を整えておくことが望ましいでしょう。

まとめ

本記事では、WMS改修におけるPoC・プロトタイプ・モックアップ開発について、全面刷新を扱う6記事群との位置づけの違い、モックアップ・プロトタイプの進め方、PoCが例外的に必要になるケースとその進め方、そして検証を簡略化する際の注意点を体系的に解説しました。WMS改修では、技術的な不確実性が低いためPoCは基本的に不要・省略可能であり、代わりにモックアップ（必須）とプロトタイプ（推奨）という軽量な検証手法で、現場の「使いやすさ」を素早く合意することが検証の中心になります。ただし、新しいハンディ端末の導入など技術的な不確実性が残る要素がある場合は、対象を絞り込んだPoCを実施すべきであり、いずれの場合もデグレードテストと現場キーパーソンの巻き込みは省略してはならない最低限のラインです。全面刷新のような重厚な検証プロセスを組めないことは、決して検証を疎かにしてよい理由にはなりません。むしろ限られた予算と期間だからこそ、何を検証し、何を省略してよいかという優先順位を明確にする判断力が問われます。まずは自社の改修内容に技術的な不確実性が残っていないかを確認し、モックアップから着手して現場との認識合わせを早めに始めることをお勧めします。

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