WMSのリニューアルの開発期間は、既存のWMSにどこまで手を入れるかで変わります。WMS全体では、小規模で3〜6ヶ月、中規模で6〜12ヶ月が目安です。
本記事は、UI/UXや現場の使い勝手を起点とするリニューアルに絞って解説します。詳しくは、以下の全体ガイドをご覧ください。
▼全体ガイドの記事
・WMSのリニューアルの完全ガイド
- WMSのリニューアルの位置づけと、ほかの記事群との違い
- 開発期間・スケジュールの全体像と、UI/UXデザイン工程の期間配分
- ハンディターミナル・タブレット画面のUI刷新が納期に与える影響
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMSのリニューアルの位置づけ（UX/UI・現場体験起点という論点）
開発期間を検討する前に、まず論点の位置づけを押さえておく必要があります。WMSという同じテーマでも、技術手法・経営判断・契約期限に重心を置く記事と、現場のUX/UI体験に重心を置く本記事とでは、期間を左右する変動要因が大きく異なります。そのため、期間の見込みも論点ごとに分けて考えることが欠かせません。
WMS開発（新規導入）・WMSのモダナイゼーション（技術HOW）との違い
WMS開発は、ゼロからWMSを新たに構築するグリーンフィールドの取り組みです。本記事のリニューアルは、すでに稼働しているWMSの画面と操作体験を作り替えるブラウンフィールドの取り組みで、この点はモダナイゼーションとも共通しています。
一方、モダナイゼーションは、システムの中身を作り替える技術手法です。ロケーションマスタや在庫データベースの構造、既存システムとの互換性を、5つの技術的アプローチでどう扱うかが中心になります。これに対して本記事は、現場スタッフがハンディターミナルやタブレットの画面で、どれだけ迷わずピッキングや検品を終えられるかに焦点を当てます。
技術の刷新を伴わず、ハンディターミナルの画面デザインとタブレット対応だけを変えるケースもあります。逆に、技術移行とUI/UXの刷新を同時に行う場合もあります。両者は独立した論点ですが、実務では連動することも多いという関係にあります。
WMS刷新（経営判断WHY/WHEN）・WMS更改（契約起点）との違い
WMS刷新は、誤出荷率の悪化やピッキング作業の生産性低下による損失を金額に換算し、経営層の稟議承認と、物流・IT部門の合意形成をどう進めるかに重心を置きます。経営層やプロジェクトマネージャーが判断する意思決定プロセスが中心です。
WMS更改は、保守サポート契約の満了、ハンディターミナルのリース満了、ベンダーのEOS/EOLといった、自社の都合とは無関係に外部から決まる期限から逆算してスケジュールを組むプロジェクトです。契約やライフサイクルが起点になります。
本記事のリニューアルは、体験やデザインの問題を直接の起点とします。たとえば、ハンディターミナルの画面が古く新人教育に時間がかかる、操作導線が分かりにくくミスが多い、他社と比べて見劣りするといった課題が該当します。刷新は経営判断の期間、更改は期限からの逆算を主に扱うのに対し、本記事はUI/UXの検証と現場定着の期間を中心に扱います。
開発期間・スケジュールの全体像（UI/UXデザイン工程を含む期間配分）
WMSのリニューアルは、現場ヒアリングからデザインコンセプトの決定、プロトタイピング、実装、現場テストまでを含む一連の工程として計画します。既存のハンディターミナル画面を差し替えるだけの作業とは、性格が異なるためです。
WMS全体の開発期間は、小規模で3〜6ヶ月、中規模で6〜12ヶ月が目安です。そのうち、画面設計やUX設計、ワイヤーフレーム作成、操作導線を整える「設計フェーズ」は全体の約10〜20%を占めるとされています。リニューアルでは、この設計フェーズが工程全体の成否を左右する中核になります。
パッケージシステムをベースに、ハンディターミナルやタブレットのUIをカスタマイズしてリニューアルする場合は、要件定義から開発・テストまでを含めて、早くても3ヶ月以上を見込む必要があります。なお、フルスクラッチで独自のUXを追求する場合は、さらに期間が延びる傾向があります。
現状分析・現場ヒアリング〜デザインコンセプト決定までの上流工程
上流工程では、まず現行のハンディターミナル・タブレット画面が現場でどう使われているかを観察します。ピッキング担当者や検品担当者へのヒアリングを通じて、どの操作でつまずくか、どの画面が古く感じられるかを洗い出します。並行して、競合他社や業界の先進的なWMSの画面デザインを比べ、自社が目指すブランドイメージの方向性を定めます。
ここで得た課題とゴールをもとに、共通のデザインパターンやUIコンポーネントをどう定義するかを決め、デザインコンセプトを固めていきます。WMSは入荷検品・ピッキング・棚卸・出荷梱包という反復業務を支えるツールです。そのため、見た目の刷新だけでなく「現場が迷わず操作できる一貫性」をコンセプトの中心に据えることが重要です。
この現状分析からデザインコンセプト決定までは、対象拠点数や現場ヒアリングの規模によって幅があります。単一拠点の中規模倉庫であれば、1〜2ヶ月程度を見込むのが一般的です。
プロトタイピング・実装〜ハンディターミナル実機テストまでの期間
デザインコンセプトが固まったら、ワイヤーフレーム、デザインカンプ、操作可能なプロトタイプの順に、段階的に精度を上げていきます。プロトタイプが固まると、ハンディターミナルとタブレットそれぞれの画面を実装し、既存のバックエンドや在庫データベースとの接続も確認します。
実装が終わったら、現場スタッフを交えた受入テスト（UAT）の期間を必ず確保します。実際のピッキング・検品の流れに沿って実機で操作してもらい、エラー発生時の画面表示が現場に正しく伝わるかまで確かめてから、本番リリースへ進みます。
この工程の期間は、既存のWMSに手を入れる範囲によって、数ヶ月から半年以上と幅があります。いずれの場合も、「デザインが固まってからコーディングに入る」という順序を崩さないことが、後述する納期遅延を防ぐ原則です。
ハンディターミナル・タブレット画面のUI刷新が納期に与える影響
WMSのリニューアルでは、ハンディターミナル・タブレット画面のプロトタイプ検証と現場ユーザーテストが、開発全体の納期を左右します。業務の進め方そのものに関わる工程だからです。
WMSのUI/UXデザインは見た目の変更にとどまらず、入力負荷の軽減や画面遷移の分かりやすさといった業務設計に深く踏み込みます。そのため、これらを開発の初期に組み込むことが、結果としてスケジュール全体の遅延を防ぎます。
ワイヤーフレーム・デザインカンプによるピッキング動線の手戻り防止
本格的なコーディングに入る前に、ワイヤーフレームやデザインカンプを使ってピッキングや検品の操作フローを確かめ、現場ユーザーからフィードバックを得ます。これにより、開発後の手戻り、つまり実装済みの画面を作り直す修正コストと期間を、最小限に抑えられます。
WMSのように入荷検品・ロケーション確認・ピッキング・棚卸といった定型業務を繰り返す画面では、ボタンの配置ひとつ、スキャン結果の表示位置ひとつが日々の作業効率に直結します。コーディング後に「やっぱり使いにくい」という声が出てから作り直すのは、期間にもコストにも最も避けたい事態です。
デザインカンプの段階で、できる限り具体的な操作イメージを固めておくことが、実装フェーズをスムーズに進める土台になります。
現場スタッフによるユーザビリティテストで「生の迷い」を特定する重要性
実際のピッキング担当者や検品担当者に試作品を操作してもらい、「特定のロケーションから商品をピッキングして数量を入力する」「検品完了後に出荷ラベルを発行する」といった具体的なタスクを依頼します。どこで操作が止まったか、どこで誤解が生じたかを観察して記録します。
この工程は、開発者の視点だけでは気づけない「生の迷い」を特定できる、効果の高いユーザーテストです。テストを省いてリリースまで進めると、公開後に「画面が分かりにくくミスが増えた」という声が現場から寄せられます。リリース前に潰せた修正を、稼働後の限られたリソースで対応することになります。
その結果、表面上の開発期間は短く見えても、リリース後の緊急改修に長い時間がかかる、本末転倒な事態になりかねません。現場ユーザーテストの期間をあらかじめスケジュールに組み込んでおくことが、トータルでの納期短縮につながります。
現場体験起点ならではの納期遅延要因
UI/UXや現場体験を起点とするリニューアルには、技術移行や経営判断とは異なる、デザイン起点ならではの納期遅延の要因があります。代表的な2つの要因と、その対策を順に見ていきます。
ハンディターミナル実機検証の甘さによる後戻り
近年、従来型のハンディターミナルに代えて、Androidベースのスマートフォンやタブレットを現場端末として使うケースが増えています。しかし、デザインの確認をPCの大きな画面の上だけで済ませるのは危険です。
PCとハンディターミナル・タブレットでは、画面サイズだけでなく、マウスクリックとタッチ操作、片手での操作といった利用シーンそのものが異なります。そのため、端末ごとのレスポンシブデザインや、グローブ着用時にも押しやすいボタンサイズの設計が必要です。
実機での検証を後回しにして実装を進めると、終盤になって「倉庫の照明下では画面が見づらい」「作業用手袋をしたままではボタンが押しにくい」といった現場特有の課題が一気に噴出します。その修正で手戻りが生じます。プロトタイプの段階から実機検証を組み込むことが、後戻りを防ぐ最も確実な対策です。
現場の「あれもこれも使いやすく」という要望肥大化
現場ヒアリングやユーザーテストを丁寧に行うほど、「入庫の画面もついでに直してほしい」「棚卸の画面もタブレットで使えるようにしてほしい」といった要望が次々と寄せられることがあります。現場の声を取り上げること自体は大切です。
ただし、それをすべてオーダーメイドで取り込むと、要件が際限なく膨らみ、当初のスケジュールを大きく超えるリスクが高まります。そこで有効なのが、対象範囲を「まず刷新する画面（ピッキング・検品など出荷業務に直結する画面）」と「次フェーズ以降で検討する画面」に切り分け、優先順位を明確にすることです。その内容を現場に説明し、合意を取っておきます。
ヒアリングで出た要望をすべて一度に実現しようとせず、段階的な改善計画として位置づけることが、現場の納得感を保ちながら納期を守る鍵になります。
納期を守るための実務的な進め方
ここまでの期間の目安と遅延要因を踏まえると、WMSのリニューアルで納期を守るには、デザインの土台づくりと発注前の準備の両方を固めておくことが欠かせません。
デザインシステム・UIコンポーネントの先行定義
画面ごとにボタンの配置や色使いがばらばらだと、現場スタッフは操作のたびに迷います。一連の業務すべてに共通するデザインパターンやUIコンポーネントを先に定め、全画面で統一しておきます。
共通のパターンを先に決めておくと、現場の学習コストを下げられ、直感的な操作につながります。また、開発側も画面ごとにデザインを一から作り直す手間が省け、実装のスピードが上がります。
デザインシステムの整備は一見遠回りに見えますが、リニューアル対象の画面数が多いプロジェクトほど、先行投資として大きな効果を発揮します。初期段階でこの土台を固めておくことが、後工程全体の期間短縮につながります。
発注前の準備と依頼先選定のポイント
発注前に要件概要書をまとめておくと、複数のベンダーから比較しやすい見積もりとスケジュール提案を得られます。要件概要書には、対象の画面一覧、対応が必要な端末、現場ヒアリングで得た優先要望を書きます。既存の在庫データベースとの接続要件も、あわせて記載しておきます。
依頼先を選ぶ際は、画面デザインを作れるかどうかだけでは判断しきれません。倉庫・物流現場のUI/UX改善の実績があるか、現場ユーザーテストの設計・実施に伴走できるか、ハンディターミナルやタブレットを含むマルチデバイス対応の経験が豊富かを確かめることが重要です。
プロジェクトが始まったら、週次などの定例会議で、デザインの進捗と現場からのフィードバックを見える形にします。仕様変更の申し出は口頭で済ませず、変更要求として起票するルールを徹底します。全体工程に10〜20%程度のリスクバッファを組み込んでおけば、想定外の事象が起きても稼働時期を守る備えになります。
まとめ
WMS全体の開発期間は、小規模で3〜6ヶ月、中規模で6〜12ヶ月が目安です。そのうち設計フェーズは全体の約10〜20%を占めるとされています。カスタマイズを伴うリニューアルは、要件定義から開発・テストまでで早くても3ヶ月以上を見込み、フルスクラッチで独自UXを追求する場合はさらに長くなる傾向があります。
モダナイゼーション（技術手法）、刷新（経営判断）、更改（契約起点）とは異なり、リニューアルで最大の変動要因は、デザインと体験の検証プロセスに潜んでいます。具体的には、ハンディターミナル・タブレットの実機検証をどこまで丁寧に行うか、現場の要望をどう優先順位づけして段階的に取り込むかが問われます。
デザインシステムを先に整えることと、倉庫・物流現場のUI/UX改善の実績が豊富なパートナーに早めに相談することが、WMSのリニューアルを納期内で成功させる鍵となります。
▼全体ガイドの記事
・WMSのリニューアルの完全ガイド
▼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を創業。