OMSのリニューアルとは、既存OMSの受注処理画面と複数チャネルの統合ビュー画面について、デザインや操作性を刷新することです。開発期間は土台にするシステム基盤によって大きく変わり、UXリサーチや現場での検証が全体の期間を左右します。
工程ごとの期間の目安と納期を守る進め方は、全体ガイドにまとめています。
▼全体ガイドの記事
・OMSのリニューアルの完全ガイド
- OMSのリニューアルの位置づけと、UX/UI起点で期間を考える理由
- 工程ごとの期間の目安と、画面ごとの検証期間の違い
- スケジュールを狂わせる落とし穴と、納期を守るための管理のポイント
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
OMSのリニューアルとは何か（UX/UI・顧客体験起点の位置づけ）
リニューアルを考え始めるきっかけは、技術の老朽化そのものより、利用者の実感であることが少なくありません。「画面が古くさく感じる」「新しく入ったオペレーターがすぐに操作を覚えられない」「複数チャネルの注文状況が一目で把握しづらい」といった声がその例です。
機能面では最低限のことができていても、ボタンの配置がわかりにくい、入力項目が多く受注処理に時間がかかる、チャネルごとに画面のレイアウトが違って混乱を招くといった体験の古さがあります。こうした体験の古さは、コールセンターの生産性やブランドイメージに影響します。
そのため、リニューアルは「利用者からどう見えるか」「オペレーターがどう感じるか」を出発点にし、開発期間の考え方も他の切り口の刷新とは異なってきます。
モダナイゼーション・刷新・更改との違い
本記事は、すでに稼働している既存OMSの画面を土台にしたリニューアルを前提にします。ゼロからOMSを構築する「OMS開発」とは異なり、この前提は他の3記事群と共通です。
既存OMSの見直しでは、モダナイゼーション、OMS刷新、OMS更改の3つがよく比べられます。それぞれ、議論を始めるきっかけが異なります。
- モダナイゼーション：技術面から進め方を選ぶIT部門の議論
- OMS刷新：注文処理の遅延や在庫連携ミスによる機会損失を経営層にどう説明し、いつ稟議を通すかを決める経営判断（WHY/WHEN）
- OMS更改：保守契約の満了やベンダーのEOS/EOLという動かせない期限から逆算する、契約起点の判断
モダナイゼーションは、リホスト、リプラットフォーム、リファクタリング、リビルド、リプレースといった技術的アプローチ（HOW）のうち、どれを選ぶかというIT部門・エンジニア視点の議論です。
これに対してリニューアルは、契約期限や内部構造にかかわらず、「今の画面と操作性で現場に選ばれ続けられるか」という顧客体験の観点から、刷新の必要性を判断します。開発期間の見積もりでは、在庫引当ロジックの改修やベンダー選定の期間以上に、UXリサーチとデザイン制作、現場オペレーターによる検証の期間が全体を左右する点が特徴です。
コールセンター受注画面と複数チャネル統合画面、2つのUX刷新対象
OMSのリニューアルには、性質の異なる2種類の利用者体験があります。1つ目は、コールセンターやカスタマーサポートの担当者が電話対応をしながら顧客情報を検索し、受注内容を入力・修正する「受注処理画面」です。1日に何十件・何百件と向き合う業務ツールであるため、作業効率と学習コストの低さが問われます。
2つ目は、ECモールや実店舗などから届く注文状況をまとめて見渡し、在庫引当や出荷指示の進捗を確認する「複数チャネル統合ビュー画面」です。この画面では、複数チャネルの情報をどう整理して一覧性高く提示するかというダッシュボード設計の巧拙が問われます。
この2つは求められる体験の質が異なるため、リニューアルの開発期間を見積もるときは、両者を一体で扱わず、それぞれに必要な検証工程を個別に積み上げて考える必要があります。
開発期間・スケジュールの全体像（工程別の期間配分）
全体の期間は、採用するシステム基盤によって大きく変わります。クラウド型（SaaS）を土台にUIをカスタマイズする場合は1〜3ヶ月程度、パッケージ型（オンプレミス）を土台にする場合は3ヶ月〜1年以上が目安とされています。独自のブランド要件を反映したカスタマイズを伴うリニューアルでは、早くても3ヶ月以上を見込んでおく必要があります。
この期間の中には、在庫引当ロジックの改修やベンダー選定の工程に加えて、UXリサーチ、デザイン制作、現場検証というリニューアル特有の工程が上乗せされます。その点を押さえることが、現実的なスケジュールを描く出発点になります。
現状分析・UXリサーチに要する期間
リニューアルの上流工程では、まず現状分析に着手し、現行の受注処理画面と統合ビュー画面の何が使いにくいのかを明らかにします。コールセンター担当者へのヒアリングやアンケートを行い、可能であれば操作ログも分析します。これにより、受注処理完了までの離脱ポイントや操作の迷いどころ、複数チャネルの情報を見落としがちな箇所を洗い出せます。
BtoBや業務システムのUI改善では、入力フォームの自動補完、エラー表示のわかりやすさ、ダッシュボードの情報整理といった観点が特に重視されます。頻繁に使う操作をどう簡略化するかが、作業効率と満足度の向上に直結するとされています。
現状把握と要件定義には、対象チャネル数や画面数にもよりますが、4〜12週間（約1〜3ヶ月）程度を見込んでおくと、後続のデザインでの手戻りを防ぎやすくなります。
要件定義・PoC〜デザイン確定・実装までの期間
現状分析の後は、要件定義と並行して、本格開発に入る前にPoC（プロトタイピング・ユーザビリティ検証）を行います。このとき、実際に使うコールセンターの担当者を上流工程から参加させ、「直感的に操作できるか」「エラーが出たときに解決しやすいか」を実務の目線で確かめることが欠かせません。要件定義とPoCには、8〜16週間（約2〜4ヶ月）程度を見込みます。
その後、画面構成を示すワイヤーフレームと、完成形に近いデザインカンプを作ります。ここまでを1〜2ヶ月程度とするのが一般的な目安です。デザインが固まったら、実装に進みます。
受注処理画面と統合ビュー画面は、既存の在庫引当ロジックや周辺システムと連携して動くため、実装では見た目の変更だけでなく業務ロジックとの整合性も確かめる必要があります。実装には、対象画面数や連携範囲に応じて1〜3ヶ月程度を見込みます。開発完了後は、業務の代表者が参加するUAT（ユーザー受け入れテスト）に2〜6ヶ月程度を確保することも忘れてはいけません。
スケジュールを狂わせる落とし穴（リニューアル特有の論点）
OMSのリニューアルには、初期段階で計画しておかないと大幅な遅延を招く落とし穴がいくつかあります。画面の見た目だけを変えるつもりでも、思わぬところでスケジュールが圧迫されます。そのため、典型的なパターンを押さえておくことが、納期を守る第一歩になります。
顧客マスタ・注文履歴の移行仕様未確定によるストップ
新しい受注処理画面や統合ビュー画面に既存の顧客マスタや過去の注文履歴を引き継ぐ際は、日付形式、文字数の上限、全角と半角の違いといったフォーマットの差を、人の手で埋める作業が発生します。
「何ヶ月分の注文履歴を統合ビュー画面で見られるようにするか」「不完全なデータをどう扱うか」といった事業上の判断は、要件定義の段階で決めておく必要があります。決めないまま移行を進めると、作業の途中で判断が止まり、スケジュールが大幅に遅れます。
作業量によっては、エンジニア1日5万円×30日稼働で150万円規模の工数がかかることもあります。UIデザインの美しさに目が向きやすいリニューアルでは、こうした重い工程が見落とされやすい点に注意が必要です。
外部システム連携の仕様確認遅れとチャネル間表示崩れ
新しい受注処理画面や統合ビュー画面は、基幹システムやWMS、決済システムなどと連携して動くのが一般的です。コールセンターでは、CTI（電話システム）も連携先になります。「連携できるはず」と思い込んでいた部分が、公開直前になって追加開発が必要だと分かるケースは少なくありません。
デザインや操作性の議論に関心が集まりやすいリニューアルでは、こうした連携仕様の確認が後回しになりがちです。その結果、納期の遅れや予算超過の大きな要因になります。
あわせて、ECモールの注文情報、電話注文の入力データ、店舗POSのデータは、項目数や表示ルールがチャネルごとに異なります。これらを1つの統合ビュー画面にまとめると、想定していなかった表示崩れや情報の欠落が終盤になって見つかることがあります。そのため、この検証は早い段階から組み込んでおくことが、納期を守るうえで欠かせません。
コールセンター受注画面と複数チャネル統合画面、UI刷新工数の違い
2つの画面は同じOMSの一部ですが、リニューアルで重点を置く検証は異なります。そのため、それぞれに必要な期間の考え方を分けて整理しておくと、精度の高いスケジュールを組みやすくなります。
コールセンター受注処理画面：現場ヒアリングと定着支援に要する期間
コールセンターの受注処理画面は、1日に何十件・何百件と処理する業務ツールです。そのため、見た目の刷新よりも「これまでの操作の癖をどこまで踏襲するか」という現場適合性の検証に時間がかかります。
長年同じ画面を使ってきたベテランのオペレーターほど、新しい操作の流れへの抵抗が強くなりがちです。そこで、デザインレビューの段階から現場のキーパーソンを巻き込み、電話対応をしながら受注入力を行う実際の業務シナリオで触ってもらい、意見を吸い上げるプロセスが欠かせません。
あわせて、新画面への切り替え後は一定期間の定着支援（操作研修やヘルプデスク対応）を見込んでおく必要があります。この現場ヒアリングと定着支援の工程は、合わせて3〜6週間程度をスケジュールに織り込んでおくことが望まれます。
複数チャネル統合ビュー画面：一覧性・ダッシュボード設計の検証期間
一方、複数チャネル統合ビュー画面は、ダッシュボード設計の検証に時間がかかります。ECモールや実店舗など性質の異なるチャネルの情報を、どう整理して一覧性高く見せるかが問われるためです。
単に情報を並べるだけでは「結局どこを見ればいいのかわからない」画面になってしまいます。そこで、未処理の受注や在庫連携エラー、出荷遅延の兆候など優先度の高い情報を視覚的に強調するレイアウトを設計し、実際の運用データで検証する流れが必要です。
この検証には、対象チャネル数や表示項目の複雑さに応じて2〜4週間程度を、独立した工程として見込んでおくのが現実的です。複数の部門（EC事業部門、コールセンター、物流部門）が同じ画面を見る場合は、部門ごとに求める情報の優先度が異なることが多いため、代表者を集めて合意形成の場を設けておくと、後工程での手戻りを防げます。
納期を守るためのスケジュール管理のポイント
UX/UI起点のリニューアルは、「もっと良くしたい」という欲求が際限なく膨らみやすいプロジェクトです。納期を守りながら顧客体験を高めるには、実務上の工夫が必要になります。
Must/Wantの仕分けと要望肥大化の防止
EC事業部門、コールセンター、IT部門のそれぞれから「この機能も改善してほしい」という要望が出ると、開発工数やテスト項目が際限なく増え、スケジュールも延びていきます。
これを防ぐには、要望をすべて洗い出したうえで、「Must（今回のリニューアルで必須）」と「Want（できれば・次フェーズ以降）」に仕分けることが欠かせません。仕分けのルールは、要件定義の早い段階で決めておきます。
特にUXの改善は、「あれもこれも良くしたい」という声が出やすいテーマです。だからこそ、優先順位を決める責任者を明確にし、範囲が際限なく広がる（スコープクリープ）のを防ぐ体制を整えておくことが、納期を守るための基本になります。
移行テストを削らないための繁忙期回避
開発やデータ移行でスケジュールが押すと、真っ先に削られやすいのが移行テストの期間です。しかし、テストを省略したまま本番公開し、新しい受注処理画面や統合ビュー画面に不具合が出た場合の損害は計り知れません。
特にコールセンター業務は顧客対応のスピードに直結するため、公開直後のトラブルは応対品質を下げ、ブランドイメージも損ないかねません。
スケジュールに余裕がない場合は、予定日に無理に合わせる代わりに、「リニューアルの公開日をセール期・年末商戦などの繁忙期からずらす」という決断も選択肢に入れるべきです。公開日をあらかじめ閑散期に設定し、そこから逆算してUXリサーチから実装、テストまでの各工程に必要な期間を積み上げることが、納期と品質を両立させる最も確実な方法です。
まとめ
OMSのリニューアルの開発期間・スケジュール・納期について、位置づけや工程ごとの期間配分を整理し、スケジュールを狂わせる落とし穴と、2つの画面の工数の違い、納期を守るための管理のポイントまで解説しました。
技術手法、経営判断、契約期限とは異なり、リニューアルの開発期間は、UXリサーチ、デザイン制作、現場検証に多くの時間を要する点が最大の特徴です。受注処理画面では現場ヒアリングと定着支援を、統合ビュー画面ではダッシュボード設計と部門間の合意形成を、それぞれ別の検証工程として見込んでおく必要があります。
さらに、Must/Wantの仕分けと繁忙期を避けた公開日の設定が、納期を守りながら顧客体験を高めるうえで役立ちます。画面の古さや操作性の悪さに課題を感じている方は、UX/UI起点のリニューアルに強みを持つパートナーへ早めに相談することをお勧めします。
▼全体ガイドの記事
・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を創業。