WMSのリニューアルのPoC・プロトタイプ・モックアップ開発について

WMSのリニューアルにおけるPoC・プロトタイプ・モックアップと聞くと、「WMSのモダナイゼーション」や「WMS刷新」「WMS更改」で語られる検証と同じだと思われがちですが、本記事が扱う検証の目的はこれらとは異なります。モダナイゼーションにおけるPoCは、新旧システムが同じ処理結果（在庫数量・引当結果）を返すかという機能等価性の検証（技術HOW起点の回帰検証）が中心であり、刷新におけるPoCは、本開発への投資判断ゲート・ステークホルダー合意形成の場（経営層のWHY/WHEN判断材料）として位置づけられます。更改におけるPoCは、期限内に既存の出荷業務を止めずに代替できるかという確証を得るための、タイムボックス化された実地検証です。これらに対して本記事が扱う「リニューアル」のPoC・プロトタイプ・モックアップは、ハンディターミナル・タブレット画面のワイヤーフレームやデザインカンプを使い、現場スタッフが実際に迷わず操作できるかという「体験・デザインの検証」にフォーカスします。ゼロからWMSを構築する「WMS開発」とは異なり、既に稼働しているシステムの画面・操作体験を検証しながら作り替えるブラウンフィールドの文脈である点は他の3記事群と共通ですが、検証の対象が「処理ロジックの正しさ」ではなく「使いやすさ」である点が決定的に異なります。

本記事では、WMSのリニューアルにおけるPoC・プロトタイプ・モックアップ開発について、UI/UX検証の重要性と全体プロセス、ワイヤーフレーム・デザインカンプ・現場ユーザビリティテストの進め方、ハンディターミナル・タブレット・スマホの実機検証（UAT）で押さえるべきWMS特有のポイント、そしてPoCを成功させるための実務的なポイントまでを体系的に解説します。技術的な回帰検証の詳細はモダナイゼーションの記事に、投資判断ゲートとしての位置づけは刷新の記事に、タイムボックス化された実地検証は更改の記事に譲り、本記事では「現場が本当に使いやすいと感じるUIをどう検証するか」に焦点を当てます。

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

▼全体ガイドの記事
・WMSのリニューアルの完全ガイド

WMSのリニューアルにおけるPoCの位置づけ（体験検証という論点）

WMSのリニューアルにおけるPoC・プロトタイプ・モックアップを正しく設計するには、まず「何を検証するプロジェクトなのか」という前提を、隣接する3つの記事群と切り分けて理解しておく必要があります。同じ「WMSのPoC」というテーマでも、検証の目的がまったく異なるためです。検証の目的が異なれば、参加者の顔ぶれ、必要なドキュメントの精度、そして検証にかけるべき期間も自ずと変わってきます。技術的な妥当性を確認したいのか、経営層を説得する材料を集めたいのか、期限内に業務を止めずに移行できるかを確かめたいのか、それとも現場が迷わず使えるかを確かめたいのかによって、同じ「PoC」という言葉でも中身はまったく別物になるという前提を、プロジェクトの初期段階で関係者間に共有しておくことが欠かせません。PoC・プロトタイプ・モックアップは、開発全体の中では小さな一工程のように見えるかもしれませんが、倉庫という止められない現場を相手にするWMSのリニューアルにおいては、この工程の質がプロジェクト全体の成否を決めると言っても過言ではありません。限られた検証期間の中で何をどこまで確かめるべきかを見誤らないよう、以降の章で具体的な進め方を順に見ていきます。

「WMSのモダナイゼーション」におけるPoCは、リホスト・リプラットフォームであれば技術的な実現可能性の検証、リファクタリング・リビルドであれば新旧システムが同じ在庫数量・引当結果を返すかという機能等価性（回帰検証）が中心です。「WMS刷新」におけるPoCは、Go/No-Go判断基準をあらかじめ数値化し、本開発への投資判断ゲート・複数ベンダー比較の透明性確保の場として位置づけられ、経営層への上申材料としての性格が強くなります。「WMS更改」におけるPoCは、保守契約満了やEOS/EOLという期限が固定されている前提で、限られた期間の中で新WMSが既存の出荷業務を止めずに代替できるかという確証を得ることに特化した、タイムボックス化された実地検証です。これらに対して本記事が扱うリニューアルのPoC・プロトタイプ・モックアップは、ハンディターミナル・タブレット画面のデザインが現場スタッフにとって直感的で迷わないものになっているかという「体験の検証」が主目的であり、処理速度やデータ整合性といった技術的な正しさよりも、操作のしやすさ・分かりやすさという主観的な評価軸を重視する点が最大の違いです。同じ「PoC」という言葉を使っていても、モダナイゼーション記事のPoCは主にエンジニアとQA担当者の間で完結する検証であるのに対し、本記事が扱うPoCは倉庫現場のスタッフを主役に据え、デザイナー・PMがその声を拾い上げるという参加者の構成そのものが異なる点も押さえておく必要があります。

WMSのUI/UXデザインは、単なる「見た目の変更」ではなく、入力負荷の軽減や画面遷移の分かりやすさといった「業務設計」に深く踏み込む工程です。デザイナーが頭の中で描いた理想的な操作フローが、実際の倉庫現場でも同じように機能するとは限りません。倉庫の照明条件、作業用手袋の着用、片手での操作といった現場特有の制約は、オフィスでの机上検討だけでは見落とされがちです。だからこそ、本格的な開発に着手する前にプロトタイプ・モックアップの段階で現場検証を挟み、机上の想定と現場の実態とのギャップを洗い出しておくことが、WMSのリニューアルを成功させる大前提になります。検証を省略して本実装まで進めてしまうと、リリース後に現場から「使いにくい」という声が噴出し、稼働中のシステムを改修することになりますが、稼働後の改修は業務を止めない配慮や再教育のコストが上乗せされるため、開発前に行う検証よりもはるかに大きな負担を伴います。プロトタイプ段階での手戻りと、稼働後の手戻りとでは、コストの桁が違うという認識を関係者間で共有しておくことが重要です。

PoC・プロトタイプ検証の全体プロセス

WMSのリニューアルにおけるPoC・プロトタイプ検証は、大きく「デザイン段階の試作品による検証」と「実装済みシステムによる受入テスト（UAT）」という2つの段階に分かれます。それぞれの段階で検証すべき内容と精度が異なるため、順序立てて進めることが重要です。段階を踏まずにいきなり実装済みシステムでの検証から始めてしまうと、根本的なデザインの見直しが必要になった際に実装済みのコードごと作り直すことになり、開発コスト・期間の両面で大きな損失を招きます。試作品の精度が低い段階から高い段階へと徐々に引き上げながら、都度フィードバックを反映するという段階的なアプローチを徹底することが、手戻りを最小化する基本方針です。

開発の初期段階では、デザイナーが現場業務の理解に基づき、画面構成の整理、ワイヤーフレームの作成、UIデザイン、操作導線の最適化を行います。この段階で、入荷検品・ロケーション確認・ピッキング・棚卸・出荷梱包という一連の業務フローに沿って、現場作業員が迷わずに操作できるデザインルールを整備します。ワイヤーフレームは画面のレイアウトや情報の配置を確認する簡易的な試作品であり、デザインカンプはそこに実際の配色やアイコン、フォントを反映させた、より本番に近い見た目の試作品です。この段階でボタンの配置や表示項目の優先順位を固めておくことが、後続の実装フェーズでの手戻りを防ぐ最大のポイントになります。あわせて、拠点や部署によって呼び方の異なる用語（棚番なのかロケーションなのか、検品なのか検数なのか）を画面上でどう統一表記するかも、このデザインカンプ作成の段階で決めておくべき論点です。呼称のばらつきは些細に見えて、複数拠点展開時の教育コストや問い合わせ対応の負荷に直結します。

デザインカンプがある程度固まった段階で、実際のデータを用いたプロトタイプを構築し、現場作業者に実際にシステムを触ってもらうPoC（概念実証）を実施します。ここでは机上の検討だけでは見えなかった「操作性」や「画面の見やすさ」といったユーザビリティを評価し、要件とのギャップを洗い出して画面レイアウトなどの調整を行います。「特定のロケーションから商品をピッキングして数量を入力する」「棚卸結果を入力する」といった具体的なタスクを現場スタッフに依頼し、どこで操作が止まったか、どこで誤解が生じたかを観察・記録することで、開発者側の視点だけでは気づけない「生の迷い」を特定できます。この段階でのフィードバックをデザインへ反映するサイクルを1〜2回繰り返すことで、実装フェーズに進む前にデザインの完成度を高めておくことができます。テストに参加させる現場スタッフは、ベテランだけでなく入社間もない新人やパート・アルバイトも含めて複数のスキルレベルから選ぶことが望ましく、ベテランには気づけない「初見ならではの迷いポイント」を洗い出せる点が、多様な参加者を集める意義です。

ハンディターミナル・タブレット・スマホ実機検証（UAT）のWMS特有ポイント

デザインカンプ・プロトタイプでの検証を経て実装が進んだ段階では、実際の端末を使った受入テスト（UAT）を行います。WMSのUATには、他の業務システムにはない固有の検証ポイントがいくつか存在します。オフィス向けの業務システムであれば、社内のPC・ブラウザ環境という比較的均質な条件で検証を完結できますが、WMSの場合は倉庫という物理空間そのものが検証環境の一部になるため、机上のデザインレビューだけでは決して見えてこない要素を意識的に洗い出す必要があります。

受入テストでは、実際の業務フローに沿ったテストシナリオを作成し、実機を用いて検証します。正常系の操作だけでなく、バーコードが読み取れない、在庫数が想定と異なるといったエラー発生時の画面表示が現場作業者にどう伝わるかまで含めて検証することが重要です。UI刷新において見落とされがちなのが、正常時の操作画面は磨き込まれていても、エラー時のメッセージ表示や次のアクションの案内が分かりにくいままになっているケースです。異常系のシナリオを含めて十分にテストを行うことが、現場への定着化を左右します。特に、エラーメッセージの文言が開発者向けのシステム用語のまま表示されてしまうと、現場スタッフは何をすればよいか分からず作業が止まってしまいます。「在庫が不足しています。リーダーに確認してください」のように、次にとるべき行動まで案内する平易な文言に置き換えられているかを、UAT段階で必ず確認しておく必要があります。

WMSの実機検証では、他の業務システムには見られない現場特有の検証項目があります。たとえば、タブレットやスマートフォンと「リングスキャナ」を組み合わせたハンズフリー作業スタイルを導入する場合、端末を持ち替える手間（入力負荷）がどれだけ軽減されるかを実際の作業動線の中で確認する必要があります。また、倉庫内は場所によって照明条件やネットワーク電波状況が異なるため、机上のデモ環境だけでなく実際の倉庫Wi-Fi環境下でのスキャン速度や画面遷移のもたつきを検証することも欠かせません。こうしたWMS固有のハードウェア連携・現場環境を含めた実機検証を行って初めて、リリース後に「デモでは快適だったのに現場では使いにくい」というギャップを防ぐことができます。あわせて、従来型のハンディターミナルからAndroidベースのスマートフォン・タブレットへ端末を切り替える場合は、画面サイズや持ち方が変わることで指の動かし方そのものが変化するため、旧端末に慣れたベテランスタッフほど違和感を覚えやすい傾向があります。世代の異なる複数のスタッフに同一のタスクを実施してもらい、端末の違いによる習熟スピードの差も含めて記録しておくと、本稼働後の教育計画を立てるうえでも有用な材料になります。

PoCを成功させるための実務的なポイント

WMSのリニューアルにおけるPoC・プロトタイプ検証を実効性のあるものにするためには、検証範囲の絞り込みと現場の巻き込み方に工夫が必要です。

PoC・プロトタイプ検証は丁寧に行うほど効果が高まりますが、際限なく時間をかけられるものではありません。出荷業務に直結するピッキング・検品画面など、現場への影響が最も大きい画面から優先的に検証対象に据え、周辺的な画面の検証は後続フェーズに回すといった優先順位づけが重要です。検証項目をあらかじめ「必ず確認する項目」と「時間が許せば確認する項目」に仕分けておくことで、限られた検証期間の中でも重要な論点を取りこぼさずに進めることができます。あわせて、検証の終了条件（Exit Criteria）を事前に定義しておくことも実務上有効です。たとえば「代表的な5つのタスクを、初見の現場スタッフが平均〇分以内に完了できる」といった具体的な基準を設けておけば、検証をいつまで続けるべきかという判断に迷わず、開発フェーズへ進むタイミングを客観的に見極められます。

PoC・プロトタイプ検証は、開発担当者やデザイナーだけで完結させず、現場のリーダークラスや実際に日々ハンディターミナルを操作するスタッフを巻き込むことが成功の鍵です。現場のキーパーソンが検証の初期段階から関わることで、リリース後に「聞いていなかった」「使いにくい」という反発を防ぎ、新しいUIへの当事者意識を醸成できます。また、検証結果を「見た目の印象」だけで評価するのではなく、具体的な作業タスクを完了できたかどうか、完了までにかかった時間や操作ステップ数といった定量的な指標もあわせて記録しておくと、複数のデザイン案を比較する際の客観的な判断材料になります。検証で得られたフィードバックは、その場限りの口頭共有で終わらせず、画面ごとに指摘事項と対応方針を一覧化した記録として残しておくことも重要です。複数拠点で段階的にリニューアルを展開する場合、この記録が次の拠点での検証を効率化する資産になり、拠点をまたいでの「二度手間」を防ぐことにつながります。検証記録は、対応の要否だけでなく「今回は見送るが次フェーズで検討する」という保留の判断とその理由まで残しておくと、後日「なぜあの要望が反映されなかったのか」と現場から問われた際にも、経緯を説明できる材料として機能します。

まとめ

本記事では、WMSのリニューアルにおけるPoC・プロトタイプ・モックアップ開発について、UI/UX検証の重要性と全体プロセス、ワイヤーフレーム・デザインカンプ・現場ユーザビリティテストの進め方、ハンディターミナル・タブレット・スマホの実機検証（UAT）で押さえるべきWMS特有のポイント、そしてPoCを成功させるための実務的なポイントを体系的に解説しました。モダナイゼーション（機能等価性の回帰検証）・刷新（投資判断ゲート）・更改（期限内の代替確証）とは異なり、リニューアルにおけるPoCの本質は「現場スタッフが迷わず操作できるか」という体験の検証にあります。ワイヤーフレームからデザインカンプ、現場ユーザビリティテスト、実機でのUATへと段階的に精度を上げながら検証し、異常系のエラー表示やハンズフリー作業スタイルといったWMS固有の論点まで含めて確認することが、リリース後の「使いにくい」を防ぐ最も確実な方法です。検証範囲を絞り込みタイムボックス化しつつ、現場キーパーソンを検証の初期段階から巻き込む体制づくりが、WMSのリニューアルにおけるPoCを成功させる鍵となります。開発フェーズに進んでからの手戻りは、プロトタイプ段階での手戻りに比べてコストも期間もはるかに大きくなるという原則を関係者間で共有し、目先の検証コストを惜しまない姿勢が、結果的に最短のスケジュールと最も低いトータルコストでのリニューアル完了につながります。倉庫現場のUI/UX改善に伴走した実績が豊富なパートナーへ早めに相談し、自社だけでは気づきにくい検証の抜け漏れを補ってもらうことも、WMSのリニューアルを成功に導く現実的な選択肢の一つです。

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