OMSのリニューアルは、ECモールや電話注文、実店舗などから届く注文を扱う受注処理画面と、複数チャネルの注文を見渡す統合ビュー画面の操作性を刷新する取り組みです。既存のOMSの画面をもとに、本開発の前にPoC・プロトタイプ・モックアップで、現場のオペレーターが本当に使いやすいかを確かめる工程です。
OMSの見直しには、モダナイゼーション・刷新・更改といった取り組みもあります。モダナイゼーションは、リホスト、リプラットフォーム、リファクタリング、リビルド、リプレースといった技術的な進め方に軸足を置きます。
刷新は、注文処理の遅延や在庫連携ミスによる機会損失を定量化し、経営判断につなげる取り組みです。更改は、保守契約の満了やベンダーのEOS/EOLといった外から迫る期限をきっかけに進みます。
本記事は、こうした進め方とは異なる視点で書いています。オペレーターが日々向き合う受注画面のUXと、複数チャネルの注文を横断的に確認する統合ビュー画面の見やすさ、つまり利用者が直接触れる操作体験を刷新する視点で、PoC・プロトタイプ・モックアップ開発を解説します。
本テーマの全体像は、次の完全ガイドをご覧ください。
▼全体ガイドの記事
・OMSのリニューアルの完全ガイド
- OMSのリニューアルの位置づけと、ほかのテーマとの違い
- ワイヤーフレームからクリッカブルプロトタイプまでの検証の流れ
- 現場オペレーターを巻き込んだユーザビリティテストの進め方
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
OMSのリニューアルの位置づけ（UX/UI・顧客体験起点）
同じ「OMSを作り替える」というテーマでも、検証すべき対象は記事によってまったく異なります。そのため、PoC・プロトタイプ・モックアップ開発の設計を正しく行うには、このテーマの範囲を、モダナイゼーションや刷新、更改などの隣接するテーマと切り分けて理解しておく必要があります。
ゼロからOMSを新規に構築する「OMS開発」とは異なり、リニューアルはすでに稼働している既存OMSの画面をもとにする前提で進みます。
モダナイゼーション・刷新・更改との違い（PoCで検証すべき対象の違い）
モダナイゼーションのPoCは、既存の注文データや在庫引当ロジックを新しい環境に移しても同じ処理結果が得られるかを確かめる、機能等価性の検証が中心です。刷新のPoCは、経営層のGo/No-Go判断を裏付けるROIやリスクの検証に、更改のPoCは、ベンダーの技術力や移行の致命的なリスクを見極める選定の検証に重心があります。
これに対し、リニューアルのPoCは「機能が同じように動くか」より「オペレーターや利用者にとって本当に使いやすいか」という体験そのものを検証する点に主眼があります。ゼロから作る「OMS開発」のPoCは、まだ存在しない業務フローの実現可能性を確かめます。一方、リニューアルでは既存の画面をもとに、新しいデザインが現場の作業効率を落とさず、むしろ高められるかを、実際のオペレーターの手で確かめます。
コールセンター受注画面と複数チャネル統合画面、2つの検証対象
PoCで検証する観点は、コールセンター・カスタマーサポート担当者が使う受注処理画面と、複数チャネルの注文状況を見渡す統合ビュー画面で異なります。受注処理画面では、電話対応をしながら入力するという実際の業務シナリオでの操作性、処理速度、エラー発生率が主な検証項目です。
統合ビュー画面では、複数チャネルの情報をどれだけ素早く正確に把握できるかという一覧性と視認性が主な検証項目です。この2つを1つのプロトタイプでまとめて検証すると論点がぼやけるため、それぞれ独立した検証シナリオを用意することが、PoCの精度を高める要点です。
ワイヤーフレームからクリッカブルプロトタイプまでの検証プロセス
UI/UX起点のリニューアルでは、本格的な開発に入る前に、段階を踏んで検証内容を具体的にしていくのが基本です。最初はワイヤーフレームで画面の骨組みを検証し、続いて実際に操作できるプロトタイプへと進みます。
ワイヤーフレームによる操作フローの洗い出し
UI/UX改善の第一歩は、現在の操作フローを見直すことです。オペレーターが「顧客を検索する」「複数チャネルの注文履歴を確認する」「新規受注を入力する」といった目的を果たすまでの手順を、画面の骨組みであるワイヤーフレームに描き出します。
実際の画面を作り込む前に、無駄な画面遷移や迷いやすい箇所を減らし、よく使う操作を簡単にできるかをこの段階で確かめておくと、後の開発コストや手戻りを最小限に抑えられます。統合ビュー画面でも、どの情報をどの順番で目に入れるかという情報設計を、ワイヤーフレームの段階で固めておくことが重要です。
デザインカンプとクリッカブルプロトタイプによる初期検証
ワイヤーフレームの検証を終えたら、本格的な開発に入る前に、実際のシステムのように画面遷移やボタンを操作できる「クリッカブルプロトタイプ」と、完成形に近いデザイン画像の「デザインカンプ」を作ります。業務システムでは、画面ごとにボタンの配置や色使いが変わるとオペレーターが迷いやすくなります。
そのため、共通のUIコンポーネント（デザインパターン）を適用し、学習コストを下げられる直感的な設計になっているかを、プロトタイプ上で確認します。また、開発の初期の段階で一部の現場責任者にプロトタイプを触ってもらい、システムに対する期待値のズレをなくしておくことも欠かせません。
現場オペレーターを巻き込んだユーザビリティテスト
実際のコールセンター担当者やCS担当者にプロトタイプを操作してもらい、使い勝手を評価するユーザビリティテストは、リニューアルのPoCの中でも最も重要な工程です。
タスクベースの検証と定性的評価
検証では、具体的な業務のタスクを依頼することが、実務に即した確かめ方になります。たとえば、「電話対応をしながら、新規顧客の注文データを登録する」「クレーム対応のため、過去のチャネル横断での購入履歴を検索する」といった依頼です。
担当者がどこで迷い、どの入力で手が止まったかという「利用者の生の迷い」を観察すると、開発者側では気づけない心理的な負担を特定できます。そのうえで、トライアル期間中に操作性のアンケートを行い、「画面が見やすくてやる気が出る」「これなら続けられそうだ」といった肯定的な意見を集めます。
操作性アンケートで集めた肯定的な意見を最終判断に組み込むと、導入後のシステム定着につながります。
定量的評価とフィードバックループの構築
業務システムでは、タスクの完了率、エラー（入力ミス）の発生回数、1件あたりの操作（処理）時間を計測し、旧画面と比べてどれだけ効率化されたかを客観的に評価することが欠かせません。「使いやすくなった気がする」といった感覚だけで判断せず、数値で改善効果を裏付けることは、開発会社や経営層への説明責任を果たすうえでも重要です。
開発会社がヒューリスティック評価（UX専門家がチェックリストに基づいて問題点を見つけ出す手法）を組み合わせると、利用者を集めるコストをかけずに、短期間で課題を網羅的に洗い出せます。
ユーザビリティテストで見つかったボトルネックは、業務システムならではの方法でUIを修正します。たとえば、入力フォームの自動補完機能の追加、エラー表示のわかりやすさの改善、複雑な情報を整理したダッシュボードの構築などです。そのうえで、テストと改善を繰り返すフィードバックループを組み立て、満足度や作業効率の向上を続けて実現できるUIに仕上げます。
コールセンター受注画面・統合画面それぞれのPoC検証ポイント
2つの画面は、PoCで重点的に検証すべきポイントも異なります。そのため、それぞれの特性に合わせた検証シナリオを設計することが、限られたPoC期間で成果を最大化するための要点です。
受注処理画面：入力フォーム自動補完・エラー表示のプロトタイプ検証
受注処理画面のPoCでは、入力フォームの自動補完機能が実際の受注パターンに沿って正しく候補を出せるか、エラーが起きたときにどこが間違っているかをすぐに理解できる表示になっているかを重点的に検証します。
特に、電話口で顧客と会話しながら入力するという実際の業務シナリオを再現します。そして、複数人が同時にログインしてもエラーが起きないか、入力途中で保留や中断が起きてもデータが失われないかといった細かな挙動も、プロトタイプの段階で確かめておくことが重要です。
この検証を怠ると、稼働開始後に現場から「使いにくい」という声が噴出し、結局は旧システムの操作感に近づける修正対応に追われかねません。
統合ビュー画面：ダッシュボード情報整理と複数チャネル同時閲覧のユーザビリティ検証
統合ビュー画面のPoCでは、複数チャネルの情報を同時に見たときに「今すぐ対応が必要な受注」がひと目でわかるかという、視認性の検証が中心になります。実際の運用データに近いボリュームをプロトタイプに入れ、情報量が増えても画面が煩雑にならないか、在庫連携エラーや出荷遅延の兆候といった優先度の高い情報が埋もれないかを確認します。
さらに、EC事業部門・コールセンター・物流部門など複数の部門が同じ画面を見る想定であれば、部門ごとに異なる視点でプロトタイプを操作してもらい、「自分の業務に必要な情報がすぐ見つかるか」を部門横断で検証します。これにより、公開後に「結局誰にとっても使いにくい画面」になる失敗を避けられます。
デザインレビューの失敗回避ポイント
「見た目がかっこいいシステム」と「現場で使われ続けるシステム」は、必ずしも一致しません。だからこそ、デザインレビューの進め方を誤ると、せっかくのPoCの成果が活かされないまま本開発に進んでしまいます。
見た目以外を含む評価基準
デザインやブランドイメージは、経営層や意思決定者の好みに左右されやすく、「見た目が洗練されているか」だけでレビューが進むことがあります。しかし、業務システムのリニューアルでは、表示速度や入力項目の多さによる離脱、複数人同時ログイン時の挙動といったUXの観点も、レビューの基準に必ず入れる必要があります。
レビューの参加者には、経営層やデザイナーに加えて、現場で実際に操作するオペレーターや、既存顧客モニターに近い視点を持つ社内担当者も入れます。そうすることで、見た目の評価に偏らないバランスの取れた判断ができます。
決裁者の「ちゃぶ台返し」を防ぐ段階承認
デザインやUIの方向性は、後から大幅な変更が入ると、工期が大きく延びてしまいます。そのため、「要件定義完了時」「ワイヤーフレーム完成時」「デザイン初稿完成時」といった節目で経営層や決裁者に中間報告を行い、段階的に合意を得ながら進めます。こうすれば、終盤での「ちゃぶ台返し」を防げます。
あわせて、レビューをPC画面だけで完結させず、業務で実際に使う端末（PCとタブレット、必要であればスマートフォン）で実機確認をしてから最終承認します。こうした確認を組み込むと、公開直前に「実機だと表示が崩れている」といった手戻りを防げます。
まとめ
本記事では、OMSのリニューアルにおけるPoC・プロトタイプ・モックアップ開発を、UX/UI起点の位置づけ、検証の流れ、ユーザビリティテスト、画面ごとの検証ポイント、デザインレビューの順に解説しました。
リニューアルのPoCは、機能の等価性を確かめるモダナイゼーションや、ROIとリスクを検証する刷新とは異なります。利用者にとって本当に使いやすいかという体験そのものを、タスクベースの検証と定量・定性の両面で確かめる点が最大の特徴です。
受注処理画面では実務シナリオでの操作性を、統合ビュー画面では複数チャネル同時閲覧時の視認性を、それぞれ意識して検証します。そのうえで、見た目だけに偏らないデザインレビューと段階承認を重ねることが、本番稼働後のトラブルを未然に防ぐ最も確実な方法です。本開発前の検証設計に悩んでいる方は、UI/UXのPoC支援実績が豊富な開発会社に相談することをお勧めします。
▼全体ガイドの記事
・OMSのリニューアルの完全ガイド
▼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を創業。