通販サイト/システムのリニューアルの開発期間・スケジュール・納期について

通販サイト/システムのリニューアルは、定期便管理なども標準搭載のASP・クラウドECをそのまま使えば約1〜2ヶ月、フルスクラッチなら約6ヶ月以上と幅があります。その差を生むのは、定期便管理や電話・FAX受注との連携をどこまで作り込むかです。

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

▼全体ガイドの記事
・通販サイト/システムのリニューアルの完全ガイド

  • 通販サイト/システムのリニューアルの位置づけと、関連記事との違い
  • 開発期間・スケジュールの全体像と、規模別の期間配分
  • 定期購入や通販特有の連携が納期を左右する要因

通販サイト/システムのリニューアルの位置づけ(通販特有のUX起点という論点)

通販サイト/システムのリニューアルとは何か(通販特有のUX起点という論点)

開発期間を見積もる前に、本記事が扱う論点の位置づけを押さえておく必要があります。同じ「通販サイト・通販システムを作り替える」取り組みでも、何がきっかけで動き出すかによって、スケジュールに効く要因がまったく変わるためです。

モダナイゼーション「HOW」・刷新「WHY/WHEN」・更改「期限管理」・ECリニューアル(総論)との違い

「通販サイト/システムのモダナイゼーション」は、EC-CUBEベースの独自カスタマイズや独自スクラッチ構築のOMSなど、自社が保有する通販システムを対象とします。5つの技術的アプローチの使い分けと、実装フェーズの工程別期間配分に重心を置きます。

「通販サイト/システム刷新」は、会員データや受注実績という資産価値を経営層にどう説明し、稟議承認と三者合意形成にどれだけの期間を要するかという意思決定プロセスに重心を置きます。「通販サイト/システム更改」は、保守サポート契約の満了やEOS/EOLといった、自社の意思とは無関係に訪れる期限から逆算してスケジュールを管理します。

「ECリニューアル」は、業態を問わない一般的なECサイトを対象に、デザイン規模別の期間感とUX/UI刷新特有の遅延要因を扱う総論です。これに対し本記事は、顧客からどう見えるかという体験・デザイン起点はECリニューアルと共通させつつ、対象を定期購入・カタログ通販・テレビ通販に絞ります。その業態固有の画面・導線をどう作り替えるかを、開発期間の見積もりとして扱う点が最大の違いです。

定期購入・カタログ/テレビ通販特有の顧客接点というリニューアルの起点

一般的なECサイトは「ユーザーが自ら検索し、比較検討して買う」検索・比較型のUXを重視します。一方、定期購入やカタログ・テレビ通販は「提案・LTV(顧客生涯価値)重視型」のビジネスモデルです。いかに継続してもらうか、つまり解約率(チャーンレート)を抑えられるかが事業の生命線になります。

商品を売ったあとも、毎月商品が届く理由を作り続ける中長期のコミュニケーションを前提にしたUX設計が求められます。この特性が、開発期間の見積もりに、一般的なECリニューアルにはない論点を持ち込みます。

マイページの定期便管理画面や申込番号のクイックオーダーなど、通販特有の画面・機能をどこまで作り込むかで、開発期間は大きく変わります。同梱物との連動やコールセンター連携も、期間を左右します。そのため、まず通販特有の顧客接点をリニューアルの対象範囲にどこまで含めるかを明確にすることが、現実的なスケジュールの出発点になります。

ポイント

同じ作り替えでも、何がきっかけかで見積もりの前提が変わります。通販特有の機能を対象に含めるかを先に決めておくと、期間の見積もりがぶれにくくなります。

開発期間・スケジュールの全体像(規模別の期間配分)

開発期間・スケジュールの全体像(規模別の期間配分)

通販サイト・通販システムのリニューアルの開発期間は、数ヶ月から1年以上と大きく変わります。その幅を決めるのは、デザインとシステムをどこまで作り込むかという規模と、定期便管理などの通販特有機能をどこまで対象に含めるかです。ECパッケージ等を使い、カスタマイズを含めてリニューアルする場合は、早くても3ヶ月以上を見込んでおく必要があります。

ASP・クラウドEC活用〜フルスクラッチまでの期間レンジ

ASP・クラウドECが提供するテーマ(デザインテンプレート)を使い、定期便管理機能も標準搭載のものをそのまま使う場合、期間の目安は約1〜2ヶ月です。パッケージやオープンソースをベースに、自社ブランドの世界観を反映したオリジナルUI設計や、カタログ通販特有の申込番号によるクイックオーダー機能まで踏み込む場合は、約3〜6ヶ月を見込みます。

標準機能では対応できない独自の定期便ロジックや、電話・FAX受注とコールセンターの深い連携を追求するフルスクラッチの場合は、約6ヶ月以上と最も長期化します。一般的なECサイトのリニューアルの平均的な所要期間は半年〜1年程度とされますが、通販では定期便管理やコールセンター連携の作り込み度合いが、この期間をさらに押し上げます。

目的設定〜公開までの標準的な工程別スケジュール

中規模の通販サイト・通販システムのリニューアル(4〜6ヶ月程度)を例にとると、最初に、解消したい顧客体験上の課題を抽出して目的を定めるのに約2〜3週間を要します。続く要件定義では、対象範囲に定期便管理・同梱連動・コールセンター連携を含めるかを切り分けます。制作会社の選定と合わせて、この工程には約3〜4週間を見込みます。

次に、購入導線・マイページ・定期便管理画面のレイアウトを決めるワイヤーフレームの作成とデザイン制作に、約1.5〜2.5ヶ月をかけます。この段階で、スマートフォンでの見え方や、定期便のスキップ・周期変更・解約といった操作の分かりやすさを丁寧に詰めます。

デザインが固まった後は、コーディングと会員データ・商品マスタ・注文履歴の移行準備を並行して約1.5〜2ヶ月進め、最後に最終テストとサイトの切り替え・公開に約2〜3週間を充てるのが一般的です。この工程配分を守るには、データ移行の仕様を早期に決め、基幹・物流・コールセンターシステムとの連携仕様の確認を後回しにしないことが前提になります。

ポイント

期間の目安は、標準機能なら1〜2ヶ月、フルスクラッチなら6ヶ月以上と幅があります。定期便管理やコールセンター連携を標準機能で足りるかどうかが、その分かれ目になります。

通販サイト特有の納期を左右する要因

通販サイト特有の納期を左右する要因

通販サイト・通販システムのリニューアルで納期が遅れる原因は、一般的なECリニューアルにはない、通販特有の業務や顧客接点にあることが少なくありません。特に見落とされがちな要因を、2つ取り上げます。

定期便管理・マイページ・会員データ移行の複雑さ

定期購入を扱う通販サイトの会員データには、保有ポイント残高、会員ランク、次回お届け予定日、周期変更履歴といった、通常のECサイトにはない項目が数多く紐づいています。これらを新システムのマイページや定期便管理画面に正しく移行しないと、稼働直後に「お届け予定日がずれた」「保有ポイントが消えた」といった深刻なクレームにつながります。

マイページで「スキップ・周期変更・解約」を、ユーザーが数タップで自己完結できる設計を追求するほど、画面設計とロジックの検証項目が増え、開発期間は伸びる傾向にあります。とくに解約導線は、分かりにくくすると一時的に解約を防げても、ブランドへの不信感を招きます。そのため、手続きの途中で周期変更や別商品への切り替えを提案するUIを、丁寧に設計する必要があります。

また、この検証工程を軽視したスケジュールを組むと、公開直前になって手戻りが発生しやすくなります。

コールセンター・電話FAX受注連携とカタログ配布・放送スケジュールとの兼ね合い

カタログ通販やテレビ通販では、現在でも電話やFAXによる受注が大きなウエイトを占めます。電話窓口とWebシステムが分断されたままリニューアルを進めると、オペレーターが顧客の最新のカート状況や定期便の設定を把握できず、リニューアル後にちぐはぐな対応が起きやすくなります。

顧客データと注文履歴を単一のシステムで統合すると、オペレーターがWeb上のカゴ落ち状況を見ながら電話対応できる、オムニチャネル連携が実現します。その実現には、コールセンターシステム側の改修スケジュールも合わせて調整する必要があります。これは自社の努力だけでは短縮できない、相手都合の遅延要因です。

カタログの配布直後やテレビ放送直後は、受注が集中する繁忙期にあたります。この時期に新システムの公開や大規模な画面変更が重なると、オペレーターも顧客も新しい操作に不慣れなまま繁忙対応に追われ、致命的な機会損失を招きかねません。このため、年間の販促カレンダーとカタログ・放送スケジュールを早めに洗い出し、コールセンター側の改修担当者を初期段階から巻き込んでおくことが、この遅延要因を抑える鍵になります。

ポイント

定期便の会員データ移行とコールセンター連携は、納期を延ばしやすい要因です。コールセンター側は相手都合で遅れやすいため、初期段階から関係者を巻き込んでおくことが大切です。

通販特有のUX検証を組み込んだ段階的リリース設計

通販特有のUX検証を組み込んだ段階的リリース設計

リニューアルの目的が顧客体験・CVR改善である以上、通販特有の画面・導線が実際に使いやすいかを確かめながら公開することが大切です。その進め方が、納期短縮と効果検証の両立につながります。

定期便解約導線・申込番号クイックオーダーのユーザビリティ検証

デザインが完成した後、全ページを一斉に公開する前に、定期便のスキップ・周期変更・解約導線と、カタログ・テレビ通販特有の申込番号によるクイックオーダー機能を検証しておくと有効です。その方法として、既存顧客のモニターにタスクを依頼するユーザビリティテストが効果的です。

高齢層を含む顧客層が多い通販サイトでは、若年層中心のユーザーテストでは見えない操作の迷いが数多く存在します。この検証工程は一見納期を延ばすように見えますが、公開後に「定期便の解約方法が分からない」という問い合わせがコールセンターに殺到する事態を防げます。トータルでは、リスクの低い進め方です。

閑散期カットオーバーの逆算スケジュール

年末商戦や大型セール、カタログ配布直後やテレビ放送直後の受注集中期に新システムを公開すると、新レイアウトに不慣れな顧客の離脱や問い合わせ増加が、通常業務の繁忙と重なって機会損失に直結します。

そのため、年間で最もアクセス・受注量が落ち着く閑散期に公開日を置き、そこから要件定義からテストまでの各工程を逆算して組み立てることが鉄則です。ユーザビリティテストや会員データ移行のリハーサルといった検証工程も、この逆算スケジュールにあらかじめ織り込んでおきます。そうすれば、公開直前になって検証時間が確保できないという事態を避けられます。

ポイント

公開前に解約導線や申込番号のクイックオーダーを既存顧客で検証すると、公開後の問い合わせを抑えられます。公開日は閑散期に置き、検証期間もあらかじめ組み込んでおきます。

発注前に確認すべき見積もりのポイント

発注前に確認すべき見積もりのポイント

現実的な納期でリニューアルするには、発注前に通販特有の対象範囲と現状の課題を発注先とすり合わせておくことが欠かせません。その準備に関わる要件概要書とベンダー選定の2点を、順に解説します。

要件概要書に盛り込むべき通販特有の項目

見積もりの精度は、発注時に通販特有の対象範囲をどれだけ明確にできているかで決まります。現状のデザイン・UIの課題は、直帰率が高いページや定期便解約前の離脱導線など、アクセス解析データとともに整理しておくことが大切です。

そのうえで、定期便管理と申込番号システムをどこまで対象に含めるかを明記した要件概要書を用意します。同梱物との連動やコールセンター連携についても、対象に含めるかどうかを書き添えます。

会員データや注文履歴などのデータ量と品質、ビジネスカレンダーから逆算した希望公開時期も、あわせて整理しておきます。これらがそろうと、複数の制作会社・開発会社から比較しやすい見積もりとスケジュール提案を得やすくなります。

UX/UIリニューアル実績を重視したベンダー選定

依頼先を選ぶ際は、通販システムの開発実績だけでなく、デザイン刷新によってCVR改善や離脱率改善を実現した実績があるかを重視します。さらに、定期購入やカタログ通販特有の画面設計に携わった経験があるかも、大切な判断材料になります。

システム構築の技術力が高くても、定期便管理のUX設計やユーザビリティテストの設計・分析に不慣れなベンダーでは、見た目を新しくしただけで数値が改善しないリニューアルに終わるおそれがあります。

プロジェクト開始後は、各分野の担当者を交えた週次の定例会議で、進捗と課題を共有します。また、全体工程には10〜20%程度のリスクバッファを組み込んでおくことが、想定外の事象が起きても公開時期を守る備えになります。

ポイント

要件概要書で対象範囲と現状の課題を明確にしておくと、見積もりを比べやすくなります。ベンダーは、CVR改善の実績と定期購入の画面設計の経験で選ぶのが目安になります。

まとめ

通販サイト/システムのリニューアルの開発期間まとめ

本記事では、通販サイト/システムのリニューアルにおける開発期間・スケジュール・納期を解説しました。モダナイゼーション・刷新・更改・ECリニューアルが扱う観点とは異なり、本記事の対象は業態特有の顧客接点です。

定期購入・カタログ通販・テレビ通販という、継続的な関係性を前提とした業態の顧客接点を、体験・デザイン起点で作り替えることが本質です。期間はASP・クラウドECの1〜2ヶ月からフルスクラッチの6ヶ月以上まで幅があり、定期便管理や申込番号システムをどこまで作り込むかで大きく変わります。

遅延の主因になるのは、定期便管理や会員データ移行の複雑さと、コールセンター連携およびカタログ配布・放送スケジュールとの兼ね合いです。定期便解約導線のユーザビリティ検証や閑散期の逆算スケジュールを組み込みつつ、通販特有のUX/UIリニューアルの実績があるパートナーに、早めに相談することをお勧めします。

▼全体ガイドの記事
・通販サイト/システムのリニューアルの完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。