ECサイトのリニューアル時のプラットフォームの種類と選び方〜その比較と乗り換えの手順を解説

トレンドや技術の更新、セキュリティに関するアップデートの対応などECサイトはどうしてもどこかが古くなっていきます。それだけでなく「もっと売り上げを上げたい」「効率をあげたい」などポジティブな理由で検討しているケースもあるでしょう。

このように効率化や拡張性、あらたな可能性もリニューアルに向けた大きな理由になります。

今、使用しているECプラットフォーム内で変更していく、あるいは全面的に乗り換えて行うという選択肢も含め、どういった手順で行うのが良いのかをここで解説していきます。

デザインのみか全面リニューアルかを決めるポイント

ECサイトのリニューアルをしたい時、その要因は何であるのかによって方向性は大きく変わってきます。つまり自分たちが抱えているニーズに合わせて考える必要があるということです。

それはデザインの更新で完了できることもあれば、ECプラットフォームそのものを変更し、全面的に変更する必要があるケースもあります。

まずは全面的に変更する場合のフローを見てみてください。

部分変更で良いのか、全面リニューアルすべきか
↓
改変に必要な箇所、項目、機能のピックアップ
↓
課題解決に近いECプラットフォームの選択、および見積もり、要件定義
↓
作業発注
↓
作業開始

大まかにはこう言った流れで取り組むことになります。事業発注者としては前半の作業が重くなります。

ただし、必ずしも全面的にリニューアルが必要かについてはしっかりと検討してください。例えば、以下のようなケースではリニューアルで肩透かしを喰らうことも少なくありません。

• 集客を改善したい
• ブランドのイメージを変更したい

この２つはリニューアル要望として高いものですが、必ずしもECプラットフォームの変更と結びつかないことがあります。部分的にカスタマイズを行うことで十分に違ったイメージを打ち出すことが可能なケースがあります。

施策をしっかり行い、ピラーコンテンツなどに集客ができている場合、それはコンバージョンの問題になってきます。ただし、集客構造として多くのECプラットフォームはSEO的な部分では問題を抱えていることが少なくありません。

階層やフォルダ構造などの問題を考えた場合にさらにステップアップしたいと考えるのであれば、その場合はECプラットフォーム選択からの全面的リニューアルを考える必要があります。

2点目の見た目の改変、イメージの変更などの場合は多くの場合、全面的なリニューアルは必要ないと言えます。トップページとヘッダーやフッター、画像のリニューアルなどで十分に対応できるケースがほとんどです。また、そのほうが予算も変更の期間も少なく済むはずです。

新たなサイトへの全面的な更新は気分が良いものです。しかし、必ずしもそれが必要ではないかもしれないことを認識しておきましょう。

ドメインの変更はしない

また、今まで使っていたドメインがある場合は、基本的にそれを引き継いで使っていくことが重要です。全くの新規というケース出ない場合は今までのものを捨てることはWEBでは非常に無駄の多い行為です。このドメインの継続はどのようなパターンでも同様です。

乗り換えを必要とするパターン

では明確にECプラットフォームの乗り換えを検討するケースはどんな場合でしょうか。

• 運用効率が著しく低い
• 使用可能なWEB技術があまりない。基本的に安全性に課題がある
• ユーザビリティが低下し、現状で技術的な解決策がシステム変更以外にない
• 規模的なスペック不足

どれもシステムに関わる部分です。こうした部分ではどうしてもECプラットフォームそのものに対する変更でメンテナンスしていくことになり、その変更を受け付ける受け皿がないということが限界点となります。

こうなると完全にECプラットフォームを新たに選択し、全面的なリニューアルをするという対象になります。もはや全面リニューアルは必須です。

グレーゾーンとして要検討なケースとしては、現状にリニューアルの必然性はないけれど、ECサイトをスケールアップしたい時です。こうした場合も現状で活用しているECプラットフォームでは実現できないことがあることでリニューアルに向かう場合があります。こうしたポジティヴな要因でのリニューアルもリニューアル効果を感じやすいことは少なくありません。

このようなニーズによるリニューアルでは計画にも余裕が出てくるため、追い立てられるように厳しい工期で作業をしなくてもよいということもメリットです。機能を吟味しながらプラットフォームを選択することが可能になります。

最初に行うのは課題のリストアップ

いずれにしても、もしリニューアルが頭をよぎった場合、まず何より最初に行うべきは課題の洗い出しをしてみることです。

つまり、この作業では現状のECサイトの状況を把握すること、また、伸ばしたい場所、補修したい場所を整理することという意味があります。

どれもなんとなくではなく、明確にしておくことです。「どこが、どのように、どうすると、どうなるか」を整理してください。箇条書きで十分ですのでまとめておくことで、不必要なリニューアルを排除できますし、次のステップにも進みやすくなるはずです。

また、社外に協力を仰ぐ場合もこうした情報が整理されていることは非常に重要です。質の高い開発会社であれば、丁寧にヒヤリングを行い、対処できるケースもありません。

しかし、コミュニケーションは一方的なものを期待するとうまくいきません。ただリニューアルしたいというだけであればそれでも構わないかもしれませんが、成果に結びつかないことで、その投資は無駄になってしまう可能性も十分にあります。

特に現場からの意見は十分に吸い上げて整理しておくことは次のプロセスにとってとても貴重な材料になります。こうした作業を経て次のECプラットフォームを選択する、あるいは継続して利用するというプロセスへ移ってください。

また、ポジティブな理由でのリニューアルであれば実現の優先順位をつけておくことも重要です。この段階では実際にECサイト構築に関わるスタッフや外部の開発会社などとも相談しておくとスムーズに展開できるはずです。

一番状況に合うECプラットフォームを選択する

ここまで来てついにECプラットフォームを選択するという段階になります。

カートASPだけでもいくつかの選択肢が存在します。他にもECパッケージ、そしてフルスクラッチなどECプラットフォームには種類があり、それによって得意不得意が変わってきます。カートASPはその7でも比較的安価に導入できますが制限が多いという点でリニューアルには向かないことも少なくありません。

モール型ECの扱い

レアケースかと思いますが、モール型ECに絞るということもあるいはあるかもしれません。ただし、自社ECサイトで運営を継続していくうえでの根本的なデメリットがいくつか重なっており、商品やブランドに対するイメージが固まっており市場が安定しているケースに限られるでしょう。実際のところ、本当にレアケースではないかと思います。

ECモールへの出店はEC事業の初期においては広告などの費用を圧縮することができるなどメリットの多い方法です。一方で販売に対する手数料が問題になることがあります。

Amazonや楽天市場などのモール型ECもECプラットフォームといえますが、自社ECサイトとスタンスが違います。また、自社ECサイトと併用した運用ができるので、ここで語られるニュアンスとは大きく異なるものです。

もし、ECモールと自社ECの運用で工数が伸びている場合はモールとの運用を効率化できる自社システムのリニューアルを考えてください。連携を強化できる機能などもあるので、そうした機能をECプラットフォームに持たせることで効率化が進みます。

逆にECモールでの手数料などが負担になっている場合は撤退し自社ECに絞るという選択肢もあります。

それぞれのECプラットフォームに一長一短あり

実現可能なことと、予算帯、工期、ランニングコストなどを並べるとどれも「帯に短しタスキに長し」という状況になることは少なくありません。

実際のところ、実現可能なことが多い場合は、予算と工期が多くなります。

例えば実現したいことをすべて実現するというのであればフルスクラッチでの構築ということになります。しかし、その内容を吟味することによって実際にはもっと低予算で既存のサービスを活用しながら実現できる可能性も十分にあります。

そのため、事前に課題を整理し、優先順位を決めておくと、このプロセスを的確にこなすことができるようになります。

ECプラットフォームの種類は他の記事でも何度か解説しています。

【参考】2020年代に生き残るためのECプラットフォームの選び方とは？

こちらの記事ではECプラットフォームをケースごとに選択することについて解説しています。

どのような選択も一長一短あります。しかし、状況をしっかり把握し、目指す方向が定まっていれば自ずと適切な選択肢を見出せるはずです。

一つ考えなくてはいけないのは、あまりシステムのスペックだけで考えないことです。人間が利用するためのシステムとしてECサイトはあります。ですのでECプラットフォーム選びではそういった部分を忘れないことです。

まずユーザー視点、お客様視点、さらに、運営の効率などを考えて、問題のあった箇所をフォローできるECプラットフォームを選んでください。

ハイスペックなカートASPやECパッケージを選択する場合は、ほぼ自己完結で構築するのが難しくなります。開発会社などと相談しながら理想のECサイトを構築するためのプランを組んでいきます。

ハイエンドなものほど、機能は充実していて様々なことができますが、コンセプトや強みが目的と一致したものを選択するとその後の作業はスムースになっていきます。そうした部分も技術協力を受ける企業の担当者と相談しながら選択できるのがよいでしょう。

データの移行は可能か

アップグレードしていくというケースでは基本的にあまり問題になることはありませんが、まれにデータの移行がうまくいかないケースがあります。ですのでこれは事前に確認が必要です。こうしたことが後になってからわかると非常に面倒なことになります。

今までの顧客情報などは、EC事業全体の資産といえます。こうした情報が活用できないことはその後の運営を後退させる可能性すらあります。

ですので、事前にそうした移行に問題がないか、また早い段階で一部をテストして確認するといったことで対策していくことでトラブルを小さく、手間も抑え、余計な費用の発生を防ぐことが重要です。

またサイト移行はまれにでも発生するものと考えてプラットフォームを選ぶことも重要です。データの書き出しができないようなプラットフォームもまた問題があります。もし、そうしたプランがサービスを終了した場合、そのデータを再利用できなくなるリスクも考えておきましょう。

信頼できる開発会社と歩調を合わせる

このことは見落としがちですが、開発会社とのコミュニケーションは非常に重要です。

ここ、かいなでは依頼を受注する側になりますが、私個人としてはECの事業者として、ECサイトの構築を発注する側を経験したことも何度かあります。ECサイトのような販売と管理、マーケティング施策、決済など複数の項目が絡んでいるものはデジタル上であれアナログ上であれ、しっかりとコミュニケーションを取らなければうまくいきせん。

こうした複雑なシステムを構築する場合は、単純に発注者と受注者の関係だけで進行するとデティールの部分を詰め切らないまま進んでしまい、結果的に物足りないものになることが少なくありません。

発注者と受注者がいかに一つのチームになれるかでその結果は大きく変わります。とはいえ、これは発注者側だけでなく受注を受ける開発会社にももちろんいえます。ただ、受注内容をこなすのではなく、しっかりと案件だけでなく、発注者側の事情に寄り添いながら作業を進めてくれる会社が求められます。

提案内容、技術力と並んで、そうしたホスピタリティがあったり、一緒に作るという姿勢を持つ開発会社を可能な限り選んでください。案件を相談する中でそうした関係を築いていけそうな開発会社を探します。

また、メンテナンスなども継続してお願いできるような企業のほうが、その後の発展ビジョンも共有しやすい部分が多くあります。もちろん開発だけで完了するケースもありますが、何かWEBの技術面でスポット的であってもサポートがある企業のほうが安心感は高いでしょう。

特にリニューアルという段階になるとそれなりの規模のECサイト運営を求められることも少なくありません。そうした場面で頼れる存在は必須ともいえるでしょう。