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

OMSのリニューアルとは、ECモール・自社EC・電話注文・実店舗といった複数の販売チャネルから届く注文をコールセンターやカスタマーサポート担当者が処理するための受注処理画面や、複数チャネルの注文を一元的に見渡す統合ビュー画面のデザイン・操作性を刷新する取り組みを指します。同じ「OMSを作り替える」というテーマでも、参照すべき記事によって重心はまったく異なります。「OMSのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという技術的アプローチ（HOW）に軸足を置き、「OMS刷新」が注文処理遅延や在庫連携ミスによる機会損失の定量化という経営判断（WHY/WHEN）に、「OMS更改」が保守契約満了やベンダーのEOS/EOLという外部から迫る期限（外圧型トリガー）に軸足を置くのに対し、本記事はそのどれとも異なり、オペレーターが日々向き合う受注画面のUXと、複数チャネルの注文を横断的に確認する統合ビュー画面の見やすさという「利用者が直接触れる操作体験」を刷新する視点でPoC・プロトタイプ・モックアップ開発を解説します。なお、ゼロからOMSを新規に構築する「OMS開発」とは異なり、本記事はすでに稼働している既存OMSの画面を土台にした刷新という前提に立ちます。

本記事では、OMSのリニューアルにおけるPoC・プロトタイプ・モックアップ開発に焦点を当て、ワイヤーフレームからクリッカブルプロトタイプまでの検証プロセス、現場オペレーターを巻き込んだユーザビリティテストの進め方、コールセンター受注処理画面と複数チャネル統合ビュー画面それぞれのPoC検証ポイント、そしてデザインレビューで失敗しないための実務的なポイントまでを体系的に解説します。本開発に入る前にどこまで検証すべきか悩んでいる情報システム部門・カスタマーサポート部門の方が、失敗しないPoC設計の判断軸を得られる内容です。

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

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

OMSのリニューアルとは何か（UX/UI・顧客体験起点の位置づけ）

PoC・プロトタイプ・モックアップ開発の設計を正しく行うには、まず本記事が扱う対象範囲を、隣接する記事群と切り分けて理解しておく必要があります。同じ「OMSを作り替える」というテーマでも、検証すべき対象がまったく異なるためです。

モダナイゼーション記事群のPoCは、既存の注文データ・在庫引当ロジックを新環境に移行しても同じ処理結果が得られるかという機能等価性の検証が中心であり、刷新記事群のPoCは経営層のGo/No-Go判断を裏付けるためのROI・リスク検証、更改記事群のPoCはベンダーの技術力や移行の致命的リスクを見極める選定検証に重心が置かれます。これらに対しリニューアルのPoCは、「機能が同じように動くか」ではなく「オペレーターや利用者にとって本当に使いやすいか」という体験そのものの検証に主眼が置かれる点が根本的に異なります。ゼロからOMSを構築する「OMS開発」のPoCがまだ存在しない業務フローの実現可能性を検証するのに対し、本記事が扱うリニューアルのPoCは、すでに稼働している既存の受注処理画面・統合ビュー画面を前提に、「新しいデザインが現場の作業効率を落とさず、むしろ高められるか」を実際のオペレーターの手で確かめる検証である点が特徴です。

OMSのリニューアルにおけるPoCは、コールセンター・カスタマーサポート担当者が使う「受注処理画面」と、複数チャネルの注文状況を見渡す「複数チャネル統合ビュー画面」とで、検証すべき観点が異なります。受注処理画面のPoCでは、電話対応をしながら入力するという実際の業務シナリオでの操作性・処理速度・エラー発生率が主な検証項目になり、統合ビュー画面のPoCでは、複数チャネルの情報をどれだけ素早く正確に把握できるかという一覧性・視認性が主な検証項目になります。この2つを1つのプロトタイプでまとめて検証しようとすると論点がぼやけてしまうため、それぞれ独立した検証シナリオを用意することが、PoCの精度を高めるコツです。

ワイヤーフレームからクリッカブルプロトタイプまでの検証プロセス

UI/UX起点のリニューアルにおけるPoCは、本格的な開発に入る前に、段階を踏んで検証の解像度を上げていくのが基本の進め方です。ここでは、上流のワイヤーフレームから、実際に操作できるプロトタイプまでの流れを見ていきます。

UI/UX改善の第一歩は、現在の操作フローの見直しです。オペレーターが「顧客を検索する」「複数チャネルの注文履歴を確認する」「新規受注を入力する」といった目的を達成するまでの手順を、画面の骨組みであるワイヤーフレームで可視化します。実際の画面を作り込む前に、無駄な画面遷移や迷いやすい箇所を削減し、頻繁に利用される操作を簡略化できるかをこの段階で検証することが、後の開発コストや手戻りを最小限に抑えることに直結します。統合ビュー画面についても同様に、どの情報をどの順番で目に入れるべきかという情報設計をワイヤーフレームの段階で固めておくことが重要です。

ワイヤーフレームの検証を終えたら、本格的な開発に入る前に、実際のシステムのように画面遷移やボタンのタップができる「クリッカブルプロトタイプ」や、完成形に近いデザイン画像である「デザインカンプ」を作成します。業務システムでは画面ごとにボタンの配置や色使いが変わるとオペレーターが迷いやすくなるため、共通のUIコンポーネント（デザインパターン）を適用し、学習コストを下げられる直感的な設計になっているかをプロトタイプ上で確認します。あわせて、開発初期の段階で一部の現場責任者にプロトタイプを触ってもらい、システムに対する期待値のズレをなくしておくことも欠かせません。

現場オペレーターを巻き込んだユーザビリティテスト

実際のコールセンター担当者やCS担当者にプロトタイプを操作してもらい、使い勝手を評価するユーザビリティテストは、OMSのリニューアルにおけるPoCの中でも最も重要なプロセスです。

単に画面を見せるだけでなく、「電話対応をしながら、新規顧客の注文データを登録する」「クレーム対応のため、過去のチャネル横断での購入履歴を検索する」といった具体的なタスクを依頼することが、実務に即した検証のポイントです。担当者がどこで操作に迷ったか、入力に戸惑って手が止まった箇所はどこかという「利用者の生の迷い」を観察・記録することで、開発者側では気づけない心理的な負担を特定できます。トライアル期間中に現場のオペレーターへ操作性のアンケートを行い、「画面が見やすくてやる気が出る」「これなら続けられそうだ」といったポジティブな意見を集め、それを最終判断に組み込むことが、導入後のシステム定着の鍵となります。

業務システムにおいては、「タスクの完了率」「エラー（入力ミス）の発生回数」「1件あたりの操作（処理）時間」といった数値を計測し、旧画面と比較してどれだけ効率化されたかを客観的に評価することが欠かせません。感覚的な「使いやすくなった気がする」という評価だけで判断せず、数値で改善効果を裏付けることが、開発会社や経営層への説明責任を果たすうえでも重要です。あわせて、ヒューリスティック評価（UX専門家がチェックリストに基づいて問題点を洗い出す手法）を組み合わせると、ユーザーを集めるコストをかけずに短期間で網羅的な課題抽出が可能になります。ユーザビリティテストで見つかったボトルネックに対しては、入力フォームの自動補完機能の追加、エラー表示のわかりやすさの改善、複雑な情報が整理されたダッシュボードの構築といった業務システムならではのアプローチでUIを修正し、テストと改善を繰り返すフィードバックループを構築することで、オペレーターの満足度や作業効率の向上を持続的に実現できるUIへと磨き上げていきます。

コールセンター受注画面・統合画面それぞれのPoC検証ポイント

2つの画面は、PoCで重点的に検証すべきポイントも異なります。それぞれの特性を踏まえた検証シナリオを設計することが、限られたPoC期間で成果を最大化するコツです。

受注処理画面のPoCでは、入力フォームの自動補完機能が実際の受注パターンに沿って正しく候補を提示できるか、エラーが発生した際にどこが間違っているかを瞬時に理解できる表示になっているかを重点的に検証します。特に、電話口で顧客と会話しながら入力するという実際の業務シナリオを再現し、複数人が同時にログインしてもエラーが起きないか、入力途中で保留や中断が発生した場合にデータが失われないかといった、実運用に即した細かな挙動までプロトタイプ段階で確認しておくことが重要です。これらの検証を怠ると、稼働開始後に現場から「使いにくい」という声が噴出し、結局旧システムの操作感に近づける修正対応に追われることになりかねません。

統合ビュー画面のPoCでは、複数チャネルの情報を同時に見た際に「今すぐ対応が必要な受注」がひと目でわかるかという視認性の検証が中心になります。実際の運用データに近いボリュームをプロトタイプに投入し、情報量が増えても画面が煩雑にならないか、優先度の高い情報（在庫連携エラーや出荷遅延の兆候など）が埋もれてしまわないかを確認します。あわせて、EC事業部門・コールセンター・物流部門など複数の部門が同じ画面を見る想定であれば、部門ごとに異なる視点でプロトタイプを操作してもらい、「自分の業務に必要な情報がすぐ見つかるか」を部門横断で検証しておくことが、公開後の「結局誰にとっても使いにくい画面」という失敗を避けるポイントです。

デザインレビューの失敗回避ポイント

「見た目がかっこいいシステム」と「現場で使われ続けるシステム」は必ずしも一致しません。デザインレビューの進め方を誤ると、せっかくのPoCの成果が活かされないまま本開発に進んでしまいます。

デザインやブランドイメージは経営層や意思決定者の好みに左右されやすく、「見た目が洗練されているか」だけでレビューが進んでしまうことがあります。しかし業務システムのリニューアルにおいては、表示速度や入力項目の過多による離脱、複数人同時ログイン時の挙動といったUXの観点をレビュー基準に必ず組み込む必要があります。レビューの参加者には経営層やデザイナーだけでなく、実際に現場で操作するオペレーターや、既存顧客モニターに近い視点を持つ社内担当者を加えることで、見た目の評価に偏らないバランスの取れた判断が可能になります。

デザインやUIの方向性について、後から大幅な変更が発生すると工期が大きく延びてしまいます。「要件定義完了時」「ワイヤーフレーム完成時」「デザイン初稿完成時」といった適切なタイミングで経営層や決裁者に中間報告を行い、段階的に合意を得ながら進めることが、終盤での「ちゃぶ台返し」を防ぐコツです。あわせて、レビューをPC画面のみで完結させず、実際に業務で使用する端末（PCとタブレット、必要であればスマートフォン）での実機確認を経てから最終承認するプロセスを組み込むことで、公開直前になって「実機だと表示が崩れている」といった手戻りを防ぐことができます。

まとめ

本記事では、OMSのリニューアルにおけるPoC・プロトタイプ・モックアップ開発について、UX/UI起点ならではの位置づけ、ワイヤーフレームからクリッカブルプロトタイプまでの検証プロセス、現場オペレーターを巻き込んだユーザビリティテスト、コールセンター受注処理画面と複数チャネル統合ビュー画面それぞれのPoC検証ポイント、そしてデザインレビューの失敗回避ポイントまでを体系的に解説しました。機能等価性の検証（モダナイゼーション）やGo/No-Go判断のためのROI検証（刷新）とは異なり、リニューアルのPoCは「利用者にとって本当に使いやすいか」という体験そのものを、タスクベースの検証と定量・定性の両評価で確かめる点が最大の特徴です。受注処理画面では実務シナリオでの操作性、統合ビュー画面では複数チャネル同時閲覧時の視認性という異なる観点を意識しながら、見た目だけに偏らないデザインレビューと段階承認を積み重ねることが、本番稼働後のトラブルを未然に防ぐ最も確実な方法です。本開発前の検証設計に悩んでいる方は、UI/UXのPoC支援実績が豊富な開発会社に相談することをお勧めします。

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

株式会社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を創業。