WMS更改のPoCは、保守サポート契約の満了やEOS/EOLといった動かせない期限が決まっているなかで、既存の入荷・保管・出荷業務を新WMSで代替できるかを確かめる検証です。
モダナイゼーションや刷新のPoCとは前提が違い、ベンダー選定全体の中で3〜6週間というタイムボックスに収める必要があります。
モダナイゼーションのPoCは、リホスト、リプラットフォーム、リファクタリング、リビルド、リプレースという5つの技術的アプローチの妥当性を検証する手法です。一方で刷新のPoCは、経営層への説得材料として現場に効果を実感してもらい、内発的な合意形成を進めるための手段です。
技術的な検証手法の詳細はモダナイゼーションの記事に、経営層への説得材料としての位置づけは刷新の記事に譲ります。更改特有の実務として問われるのは、限られた期間の中で実効性のあるPoCをどう実施するかです。
- 検証の目的：新WMSで現場業務を代替できるかの確認
- 期間の配分：ベンダー選定全体の中で決めるPoC期間
- 省略の判断：PoCを簡略化した場合のリスクの確認
本テーマの全体像は、以下の記事で確認できます。
▼全体ガイドの記事
・WMS更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMS更改におけるPoCの位置づけ
WMS更改のPoCを検討する前に、なぜ更改のPoCがモダナイゼーションや刷新のPoCと性質が違うのかを押さえておきます。
PoCにかけられる時間の長さは、この違いに直結する重要な前提です。
同じ「PoC」という言葉でも、何のために実施するのかという前提が違えば、検証する項目も、かけられる時間も、失敗したときの立て直しの手段も変わります。
着手前にこの位置づけを関係者全員で共有しておくことが欠かせません。
モダナイゼーション・刷新のPoCとの違い（時間制約という論点）
3つのPoCは、目的も使える時間も違います。中でも更改のPoCは、保守契約満了などの固定の期限から逆算して時間が決まります。
- モダナイゼーションのPoC：5つの技術的アプローチのどれが妥当かを検証する。初期段階なので、スケジュールを比較的柔軟に組める。
- 刷新のPoC：経営層や現場に効果を実感してもらい、稟議承認や合意形成を後押しする材料。実施時期を稟議に合わせられる余地もある。
- 更改のPoC：保守契約満了・ハンディターミナル等のリース満了・EOS/EOLという固定の期限から逆算したスケジュールの一工程。
ベンダー選定プロセス全体で約1.5〜2.5ヶ月しか確保できない更改案件では、PoCに数ヶ月単位の時間をかけることは物理的に不可能です。そのため、目安の3〜6週間というタイムボックス（期間の上限）の中で、確実に完了させる必要があります。この時間的制約こそ、更改のPoCを検討するうえで最初に押さえるべき最大の前提です。
加えて、更改のPoCは、デッドラインに向けた計画にあらかじめ組み込んでおくべき固定の工程として扱う必要があります。この位置づけを物流部門と情報システム部門の双方が事前に共有しておかないと、後工程で認識が食い違うおそれがあります。
「新機能の模索」から「代替可否の確証」へという目的の転換
更改のPoCは、通常のPoCとは確かめる内容そのものが変わります。
- 一般的なシステム開発のPoC：新しい技術やアイデアが実現できるかを探る「新機能の探索」が主眼
- 更改のPoC：新WMSが既存の入荷検品・ピッキング・出荷梱包業務を止めずに、確実に代替できるかの確証を得ること
すでに稼働しているWMSがEOS/EOLという理由だけで使えなくなる以上、新システムに求められるのは、目新しさより既存業務を過不足なく引き継げる確実性です。
この目的の違いは、検証項目の優先順位にも影響します。斬新な新機能のデモよりも、既存のロケーション体系や引当ロジックが正しく再現されるか、ハンディターミナルが現場で問題なく使えるか、既存データを取り込めるかを確かめます。これらは「地味だが業務継続に直結する項目」で、優先して検証することが求められます。
現場のピッキング担当者から見れば、更改によってWMSが多少便利になることより、これまで当たり前にできていた入出荷業務が変わらずできることのほうが重要度は高いといえます。PoCの評価基準も、この現場の感覚に合わせて設計する必要があります。
逆に言えば、更改のPoCで華やかな新機能のデモに時間を割きすぎると、限られたタイムボックスを浪費し、本来確かめるべき業務継続性がおろそかになります。本末転倒な結果を招きかねません。
期限制約下でPoCに割ける期間の目安
更改案件のPoCは、単独で存在するのではなく、ベンダー選定プロセス全体の中の一工程です。そのため、全体のスケジュールを理解したうえで、PoCに割ける具体的な期間を見積もる必要があります。
この期間感覚を関係者間で共有できていないと、現場と管理側の考えがぶつかります。「PoCなのだから念入りに時間をかけて検証したい」という現場の要望と、「デッドラインが決まっているので延ばせない」という管理側の制約が重なり、無用な調整コストが生じてしまいます。
ベンダー選定プロセス全体（約1.5〜2.5ヶ月）の中でのPoCの位置づけ
更改先のベンダー・製品を選定するプロセスは、大きく3つのステップで構成されます。
- Step1：技術適合評価とRFI（情報提供依頼）の送付で、候補を数社に絞り込む（1〜2週間）
- Step2：本記事の主題であるPoC等の実地検証（3〜6週間）
- Step3：セキュリティ監査や契約条件の交渉といったコンプライアンス・契約精査（1〜2週間）
これらを合算すると、選定プロセス全体で約1.5〜2.5ヶ月が必要になり、その半分近くをPoCが占める計算です。更改のPoCは、プロジェクト全体の中でも比較的大きな時間の比重を占める重要な工程です。それでも、数ヶ月単位の余裕はまったくないという厳しい制約下に置かれています。
Step1で候補を2〜3社程度まで絞り込んでおくことが、限られたPoC期間を有効に使うための前提条件になります。
さらに、Step3の契約精査に入ってから重大な不適合が発覚すると、候補を差し替える時間はほぼ残りません。そのため、PoCの段階で、データの保存場所、SLA、解約条件といった契約・セキュリティ要件の論点について、ある程度の目星をつけておくと、後工程の手戻りを防ぎやすくなります。
候補ベンダーを2〜3社に絞り込む重要性
3〜6週間という限られたPoC期間の中で、多数のベンダー候補すべてを丁寧に検証するのは現実的ではありません。
RFI回答や製品資料をもとに一次評価をし、自社の倉庫規模・SKU数・出荷特性に見合った候補を2〜3社程度まで絞り込んでおきます。これが、その後のPoCを実効性のあるものにするための前提です。
絞り込みでは、価格や機能一覧に加えて、次の3点を早い段階で確認しておきます。そうしておくと、その後のPoCで無駄な時間を使わずに済みます。
- 導入の実績：自社と近い業種・規模での稼働事例
- データ移行：既存WMSからの移行を支援した実績
- EOS/EOLへの対応：期限付きの更改案件を扱った経験
この絞り込みが不十分なまま多くのベンダーを並行してPoCにかけると、1社あたりの検証の深さが浅くなり、表面的な機能比較に終始するリスクが高まります。
特にWMSは、ロケーション体系や引当ロジック、ハンディターミナルの操作性といった現場密着の要素が製品ごとに大きく異なります。少数の候補に絞って深く検証するほうが、期限内に確度の高い判断材料を得られます。
WMS更改のPoCで検証すべき項目
更改のPoCは、画面の動作を見るだけでなく、既存WMSを代替できるかを多角的に評価する明確な役割を担っています。そのため、周辺システムとの連携や在庫引当、現場での実機の使い勝手まで確かめる必要があります。検証の観点は大きく2つで、連携や在庫引当といった技術面と、ハンディターミナル実機による現場の使い勝手です。
基幹システム・OMS・WCSとの連携確認と在庫引当ロジックの整合性
WMSは、基幹システム（ERP）や受注管理システム（OMS）、自動倉庫やAGVを制御する倉庫制御システム（WCS）などと複雑につながって動くシステムです。
更改のPoCでは、次の点を技術面で最優先に検証する必要があります。
- 周辺システムとの連携：API連携が新WMSでも正常に通じるか
- 在庫引当ロジック：既存の運用と矛盾なく機能することの確認
- 標準機能（Fit to Standard）への適合：SaaS・パッケージ製品では、入出庫業務をどこまで標準機能に適合させられるかの評価
検証では、実際のロケーションマスタや過去の入出荷データをプロトタイプ環境に投入し、棚卸処理も含めて実業務に耐えるかを短期間で確かめます。
標準機能への適合度が低く大幅なカスタマイズが必要だと分かった場合は、その製品がEOS/EOLという限られた期限内の更改先として現実的かどうかを、早い段階で再検討する材料になります。
ハンディターミナル実機を使った現場検証（WMS特有の論点）
WMS更改のPoCで見落としてはならないのが、机上の画面確認だけでなく、実際の倉庫Wi-Fi環境でハンディターミナルの実機を使った現場検証を行うことです。
見積管理システムや会計システムのような情報系システムであれば、PCのブラウザ上でのデモ確認が中心になります。一方でWMSは現場オペレーションと密接に結びついているため、実際の作業員がハンディターミナルを持って操作導線を検証することが不可欠です。検証するのは主に次の3点です。
- スキャン速度：ハンディターミナルで読み取りを行う速さ
- 画面遷移の分かりやすさ：作業の流れに沿って、画面の移動に迷わないか
- 入力負荷：作業者が入力する手間の大きさ
EOS/EOLを契機に更改する場合は、WMS本体とハンディターミナルの機種を同時に入れ替えるケースも多くあります。そのため、新しい端末の重さやバッテリーの持続時間、グリップ感といった物理的な使用感も、現場の受容性を左右する重要な検証項目になります。
更改先のWMSが新しいバーコード体系を採用している場合は、既存のラベルとの互換性や読み取り精度も、PoCの段階で確かめておく必要があります。
デモ環境の画面だけで判断し、現場実機の検証を省いてしまうと、本番稼働後に実際の倉庫環境ならではの問題が噴出するリスクが高まります。たとえば「電波が届きにくい場所でスキャンが不安定になる」「手袋をした状態でボタンが押しにくい」といった問題です。
期限直前でのPoC省略・簡略化のリスク
更改プロジェクトの着手が遅れ、EOS/EOLの期限が目前に迫った状態では、「もうPoCをやっている時間がない」という理由でPoC自体を省略・簡略化する判断が下されることがあります。しかし、これは更改案件において最も避けるべき選択のひとつです。
着手の遅れは、すでに起きてしまった過去の事実であり取り戻せません。ただし、そこから先の判断次第で、期限内に倉庫業務を止めずに乗り切れるかどうかは大きく変わります。プロジェクト関係者は、この点を強く意識しておく必要があります。
机上の提案書・デモ画面だけで判断することの危険性
PoCを省略し、机上の提案書やデモ画面の印象だけで代替WMSを決めると、実データや実機を通さないと見つからない仕様の不適合を見逃したまま、本番プロジェクトに進むことになります。
WMSには、ロケーションコードの階層構造、複雑化した引当ロジック、他システムとのデータ連携形式といった、企業・倉庫ごとに固有の細部が数多く存在します。
テスト設計の曖昧さや業務フローの未検証、例外処理の考慮不足が原因で、本番運用後に問題が見つかることがあります。たとえば「ピッキング指示が正しく出ない」「在庫が合わない」といった不具合です。手戻りが重なると、次のような事態を招きます。
- 追加開発と再テスト：重なると導入が遅れ、コストも増大した失敗事例が報告されている
- 期限超過：EOS/EOLという動かせない期限を超え、致命的な事態に直結しかねない
- 現場の混乱：期限を守ろうと不完全な状態で稼働すると、「ハンディターミナルの反応が悪い」などに直面する
- 二度手間：旧システムへの一時的な切り戻しや手作業での応急対応が発生し、更改で減らせたはずの運用負荷が一時的に増える
手戻りが重なると、更改で減らせたはずの運用負荷を一時的にせよ増やしてしまい、本末転倒な結果につながります。
期限に間に合わせることは重要な目標です。ただし、それ自体が目的になると、業務が回らない状態で稼働開始日を迎えてしまいます。そのため、PoCの段階で「最低限これだけは動くこと」というラインを、関係者間で明確に握っておくことが求められます。
コア部分に絞り込んだ短期集中検証という現実的な対応
どれほど期限が迫っていても、PoCは省かず、検証範囲をリスクが最も高いコア部分に絞って実施します。これが、期限付きの更改案件を成功させる鉄則です。
WMSであれば、業務が止まると致命的な影響が出る次の領域を、優先して検証します。
- ピッキングロジック：最も出荷頻度の高いカテゴリの処理
- 外部システムとの連携：基幹システム・OMS・WCSなど
- 入出荷の主要フロー：日々発生する入出荷業務の流れ
利用頻度の低い特殊な梱包パターンや、優先度の低い付随機能は、本番稼働後に段階的に検証・調整していくという割り切りも必要です。
検証範囲を絞り込むことで、3〜6週間という限られた期間の中でも、業務継続に直結する最重要リスクだけは確実に解消したうえで、次のステップに進めます。
検証範囲は、物流部門・情報システム部門・ハンディターミナルを実際に操作する作業リーダーの三者で、「何を検証し、何を稼働後に回すか」を明文化したチェックリストとして事前に合意しておくのが望ましいです。口頭の申し合わせだけに頼ると、検証漏れが起きたときに責任の所在があいまいになり、期限直前の混乱を招くおそれがあります。
まとめ
WMS更改のPoC・プロトタイプ・モックアップ開発について、モダナイゼーション・刷新のPoCとの位置づけの違い、期限制約下で割けるPoC期間の目安、検証すべき項目、期限直前での省略のリスクを解説しました。
更改のPoCは、ベンダー選定プロセス全体（約1.5〜2.5ヶ月）の中の3〜6週間というタイムボックスに収める必要があります。その目的は、新機能の模索ではなく、既存の入出荷業務を止めずに代替できるかの確証を得ることです。
基幹システム・OMS・WCSとの連携確認や在庫引当ロジックの整合性に加えて、ハンディターミナル実機を使った倉庫現場での検証が欠かせません。この点が、他の情報系システムの更改にはないWMS特有の論点です。
どれほど期限が迫っていても、PoCを飛ばさず、リスクが最も高いコア部分に検証範囲を絞って確実に実施します。これが、EOS/EOLという動かせない期限の中でWMS更改を成功させる鍵です。
保守サポート契約の満了やリース満了、EOS/EOLといった期限は、到来時期が事前に分かっています。だからこそ、時間切れに追い込まれてからPoCの重要性に気づくのではなく、逆算スケジュールの初期段階からPoCの実施計画を組み込んでおくことが、最終的に倉庫業務を止めない更改を実現する最短ルートになります。
▼全体ガイドの記事
・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を創業。