ECプラットフォームが担う新しい事業のカタチとは?システムの特徴や選び方

ECプラットフォームとはEコマースをするための場所として活用されるソフトウェアの総称です。そのものをECプラットフォームと呼ぶこともありますし、そのシステムによって出来上がった環境を指す場合もあります。

2020年代に入り、ECを指して、この言い方が普及していきています。ECプラットフォームという言い方は今、どんどん広がっており、2022年以降はECサイト環境のことをECプラットフォームと呼ぶ流れは加速していきそうです。そして、ECプラットフォームの選択が事業に与える影響はとても大きなものがあります。

他の記事でも幾度となく触れていますが、改めてECプラットフォームをおさらいし、その事業との関わり、その未来をここで展望してみましょう。

Eコマースプラットフォームとは

Eコマースプラットフォームと呼ぶ場合、それは基本的に商品やサービスを販売するためのソフトウエアのことを指します。

つまり、電子商取引を示すECのためのシステムのことです。その体を成すためには「商品を顧客が探し出せる機能」「購入希望商品を管理する買い物カゴ（ショッピングカート）の機能」「購入するための決済機能」が絶対に必要です。

この3つの機能がなければECプラットフォームとしては成立しません。

またECプラットフォームは基本的にWEBサイトの形式で、ユーザーとの商取引を実現します。そのため、その構造としてWEBの持っているフロントエンドの機能とバックエンドの機能があるということになります。

フロントエンドとはWEBサイトの中でもユーザーが目にする部分のことを主に指します。クライアントサイドと呼ぶ場合もあります。文字入力フォームであったり、ボタンなどのクリッカブルな箇所などがフロントエンドの範囲としてはわかりやすい箇所ではないでしょうか。

これに対してバックエンドはユーザーからは見えない部分の処理を指します。データーベースであったり、検索結果を返すといった動作はバックエンドによるものです。ユーザーからは見えませんがこうした処理を施す機能があることでWEBサイトとしてしっかり機能する仕組みになっています。

ECプラットフォームにとっては特に、この2つの機能がなければ機能しないことになります。構築を一段深くすすめるにはフロントエンド、バックエンド、それぞれについて専門的な知識を持ったエンジニアの力が必要になります。

ECプラットフォームの場合、構造はフロントエンド、バックエンドからなる必要があります。そして機能としては最初にあげた「ショッピングカート」「決済」「商品検索」の3点を揃えていることが条件です。

ECプラットフォームという言い方はカナダ発のカートASPで、世界的に支持されているShopifyが特に好んでこの言い方を使っていましたが、最近では多くのECシステムが「ECプラットフォーム」という概念でサービスを提供するようになりました。

この概念の広がりが文字通りプラットフォームとして、さまざまな機能を追加したり、連携できるような状況を作っています。

ECプラットフォームの種類をおさらい

ECプラットフォームの種類をおさらいしておきましょう。もし自身の環境や用途と合わないプラットフォームを選択してしまうと、それ自体が企画の失敗を意味します。そうなることはまず避けなければなりません。ですのでこの情報は非常に重要です。一般的な規模の順番で紹介します。

ECモール

モールはAmazonや楽天市場などの大型ECサイトのことを指します。ショッピングモール型ECというわけです。クリエイティブな要素としては画像と文章のみになります。

同じフォーマットで同一の商品が並ぶため、個性を出しづらいというデメリットがあります。しかし、集客力は協力で、常にユーザーは買い物をしようと集まっています。また、モール運営側でのマーケティングアプローチは強力です。そのため市場内での影響力は非常に大きなものがあるのも特徴といっていいでしょう。

それぞれのモールで特徴が違います。たとえば楽天は独特のフォント配置があり、そのデザインは非常にインパクトがあります。日本のインターネット通販業界に大きな影響を与えたデザインですが、いわゆるWEBでのデザインの基本的なセオリーとはまた違ったノウハウがそこにあります。

また、自社でのECサイトと並行して運用できるのも特徴の一つです。

カートASP

カートASPはベンダーが用意したサーバー内にプログラムを使うスペースを与えられて使用するタイプのECプラットフォームです。基本的にはワンストップで必要なものが揃っており、自分だけのECサイトを持った形式で表示されます。可能なこと、不可能なことはベンダーが提供している仕様に依存することになります。

自社サイトとしてのECをはじめようと思った場合は多くの場合で最初の選択肢になります。ベンダーごとのサービスに幅があり、多機能なものや拡張性のあるものも増えてきました。多くの場合ははテンプレートが用意されており、そのテンプレートに沿った形で構築を完了することが可能です。

またbaseやStores.jpのような無料で利用可能で決済金額に対して分率を決めてその分を収益に加えるタイプのASPも人気です。

一方で、月額利用料がある程度高く設定されているASPもあります。こうしたASPではあらたな機能開発がハイスイードで進められており、要望が重なったものであれば最先端ではなくとも、ある程度時流に乗っかって取り入れることを可能にしているASPもあります。

導入の手軽さはメリットですが、構築や運用の柔軟性に欠ける部分があることを事前に認識しておきたいところです。

オープンソースとECパッケージ

オープンソースとはソースコード、つまりプログラムが公開され、カスタマイズ可能なもののことを指します。必ずしもECプラットフォームにだけ関わるものではありません。たとえばOSのLinuxやCMSとして非常にポピュラーなWordPressなどがこのオープンソースです。有志の技術者が集まって開発するため、高い発展性があります。一方でプログラムに脆弱性があるとそこを通してトラブルに発展するケースもあります。

そのプログラムをサーバーを用意して格納しWEBサイトとして使用可能にするものがECでのオープンソースの利用方法です。実際のところ、プログラムがオープンソースではないものもあり、それは一般的にECパッケージと呼ばれるものです。

実際のところ、格納されるプログラムがオープンソースであるかどうかの違いしかそこにはありません。ですのでオープンソースという場合は「オープンソースのECパッケージ」という意味合いが隠されています。

ただし、オープンソースでは基本的にサポートがありません。そのため、構築には技術力がいるだけでなく、自己責任の要素が強くなります。また、オープンソースとしての最大のメリットはライセンス使用料が発生しないこともその一つです。そのため、大掛かりな機能を無料で使用することが可能になります。

一方で、ECパッケージも含めてアップデートの作業などは管理者自身が行う必要があります。特にオープンソースの場合はセキュリティ的な問題が発覚した場合、早急に対処を要求されます。

どちらもメリットは柔軟な構築が可能なことです。その自由度は高く、拡張性も優れています。一方で、オープンソースは安全性という面では他のECプラットフォームと比較すると格段に落ちます。同じカテゴリにいながらオープンソースとECパッケージで分けて説明されるのは、こうした部分で差異が大きいからです。オープンソースは初期コストがかからないと言われますがそもそも技術力を内部に要している場合に限られることもしっかりと記憶しなければなりません。

ライセンスが有料のECパッケージでは、それぞれ特徴があり、サポートのレベルなども変わってきます。構築には技術が必要ですが、環境の安全面は格段に高くなります。また、サーバーを選択したり、オンプレミスで自前の構築も可能です。そのため、規模的な拡張性もASPを使用した場合とは比較になりません。

フルスクラッチ

フルスクラッチはすべてオーダーメイドで構築する方法です。そのため、工期と費用は他の方法と比較になりません。とはいえ、完全な0スタートはそう多くはありません。一部をオープンソースで流用したりといったことが行われており、非常に境界は曖昧です。

それでも最初の要件によっては完全にオリジナルで構築するというケースももちろんあります。とはいえ、最初期の選択肢としてフルスクラッチを考える必要はほとんどないといえます。

実施するには巨大なプロジェクトチームが必要になることはいうまでもありません。

ECプラットフォームの選択がビジネスの大きな分かれ道

ECプラットフォームを選択する時はどうしても手探りになりやすい傾向にあります。モールであれ、ASPであれ、ECパッケージであれ、機能についての解説はされますが、具体的にそれがどう動作するのかを理解することは難しいのが現状です。複数のECプラットフォームに直接触れる機会のないユーザーにとっては理解が追いつくことは難しいのが実情です。そして、実際に複数のプラットフォームに触れる機会は多くの人にとってはありません。

その中で選択要素として提示されており、理解しやすいのが「価格」と「実行までのスピード感」です。この項目は実際に選択する際の決め手として、初めての導入時には特に用いられやすいものです。

しかし、この時の選択はビジネスに対する影響は少なくありません。基本的にどの種類でもECプラットフォームであるため最低限の要素を満たします。それはWEBで販売するための機能、つまり最初にあげた機能は持っているということです。実際にそれさえあればECとして機能できます。ですので最初の段階で問題があることに気づくことは困難です。また、ある程度使い込んで行ったとしても比較対象がないので気づかないということも少なくありません。

その結果、事業としての伸びを欠いて発展性に乏しいということになることは少なくありません。実際にECに対してネガティブな検索ワードを追加してみると、多くの事例が語られています。

これは特に手弁当で自力で始めた場合にはよく起こります。その始め方は重要で、その後のEC事業全体の発展性に影響があることは少なくありません。

• 「思ったような決済を導入できない」
• 「集客が思うようにいかない」
• 「利用したい集客手段との連携が悪かった」
• 「SEO対策に問題のあるプラットフォームだった」

などいろんなことが起こり、実際に対処するのが難しい状況にあるということが少なくありません。それは初期の段階から実は回避できた問題だったりすることもあります。

初期の段階で事業全体の規模や展望を具体的に持つことで、ECプラットフォームの選択を適切に行うことができます。しかし、なかなか初心者がうまく判断するのは難しいことです。何事も最初はどの程度の事業規模になるのかを考慮するのは難しいかもしれません。

しかし、ECプラットフォームを活用することは事業の一つです。予算を組み、計画を持つことはとても重要なのはいうまでもありません。適切なECプラットフォームを選択することで、事業拡大の進度は大きく影響を受けます。

扱う商品や、ブランドの方向性によって選択すべきプラットフォームは変わってきます。ある事例では最高のマッチングを見せたECプラットフォームが別の事例でははまらないことも少なくないのです。

結局のところ、複数のECプラットフォームを並列に判断し、しっかりと要件を押さえて選択していくには、それなりに経験のある信頼できる専門家に相談することが重要です。

ECでの陥りやすい失敗

どのゆなECプラットフォームでもシチュエーションに合わないプラットフォームの選択が歓迎されないことは前項で述べました。その上で失敗しやすい事例としては以下のようなものがあります。

デザインに凝りすぎる

ECはもとより、WEB全体で最近よく言われるのが「UI/UX」です。この言葉はユーザーを置いてきぼりにすると悲惨な状況を生むことになります。

ありがちかつやってはいけないのは単純に「かっこよさ」「斬新」などを念頭においてデザインを施すことです。

結果的に何ができあがるかというと「見辛い」「使いづらい」というユーザーの評価を受けるサイトです。

ユーザーにとってのECでの主目的は商品を見ること、理解すること、そして購入することにあります。サイト閲覧での驚きではないことを決して忘れないでください。

ECプラットフォームとしてのUI/UXのポイントは「使いやすく、安心して購入できる」ということを前提にしています。

どうやったら安心感が高まるのかを考えてデザインをしていくことがまずは重要です。

とにかく開発コストを抑えたら実務に合わなくなった

これもよくあることですが、とにかく初期の開発コストを削って、機能も載せない、カスタマイズしないといった状態で構築を進めてしまうパターンです。

そうするとどういったことが起こるのかというと実務のコストが膨らみます。

開発予算を絞ったことでとにかく使い勝手が悪いサイトが完成します。その結果として業務効率を下げてしまうことで「受注を捌き切れない」「顧客対応や配送手配などにとにかく手間がかかる」といったことが発生します。

そもそも注文を増やしていきたいというヴィジョンはどのようなECプラットフォームでの構築であっても持っているものと思います。その上でこうした効率にかかわる部分であまりに予算を絞りすぎるのは良い結果を生みません。

開発を丸投げした

理解の範囲を超えるものに取り組む時、頼れる存在がいると依存してしまうことは少なくありません。頼ること自体は問題ありませんが、全てお任せにしてしまうのは非常に残念な結果を生む可能性があります。

ECの事業はWEB環境だけで完結しない部分が少なからず存在しています。そのため、現場での意見をしっかりと反映させることもECプラットフォームを開発するうえではとても重要です。これは前項の予算を絞り過ぎたというケースと似たことが発生するケースが多くなります。

また、発注先のベンダーが意見を聞いてくれないといったケースでも丸投げと近いことが起こります。

ECの構築と同様にベンダーとのしっかりとした関係を構築することは快適な運用に直結します。しっかりと現場の意見を反映させるには、現場の作業状況や環境を理解してもらわなければいけません。そのためにはお互いにオープンかつフラットに様々なことが相談できる関係を持てることがとても重要です。

技術力の足りないベンダーへの依頼

ECを開発している多くのベンダーは開発実績を持っています。しかし、中には残念ながら技術力が足りないケースもあります。プレゼンテーションの内容だけで決めてしまうとこうしたことが起こる可能性があります。

結局のところ、こうしたことが発生するケースとしてはエンジニアに対するステータスを十分に与えていないベンダーで多く見られます。その結果、ディレクターとコーダーの間でのコミュニケーションが悪かったり、常に大量の過剰な業務を抱えていることで十分に実力を発揮できないといったケースが少なくありません。

選択する時はコンペのプレゼンターだけでなく、エンジニアの反応などもしっかりと把握しておく必要があります。

このことは前項で述べたコミュニケーションの悪いベンダーとも通じるものがあります。しっかりと制作実績なども把握し、総合的に発注先を決めることでこうした問題を回避できます。

こうしたケースは予算をしっかりと確保しているにもかかわらず発生してしまうパターンです。それは大きな機会損失です。いずれにしてもECプラットフォームの開発については、しっかりと長く付き合える企業とマッチングしたいところです。

2023年以降ECプラットフォームはどう進化するのか？

最後はまとめとして、ECプラットフォームが今、どういった方向性に発展しているのかについてです。

現状どういったプラットフォームであってもいくつかの対応を常に求められています。例えばそれは以下のようなものです。

• 新規テクノロジーへの対応
• セキュリティ対策
• コスト効率の向上

この課題を持たないECプラットフォームはありません。その上で発展の方向性の一つとして、この課題を解決するにはどうするべきかという部分に向けてECプラットフォームは進化を続けています。

これはECプラットフォームの成り立ちに関わる発展ルートといえます。

もう一つは時代に合わせたニーズに対しての進化です。その一つはモバイルテクノロジーなど多様なデバイスとのシナジーを考慮した発展です。例えばスマートフォンへの対応は視覚的には当たり前になりましたが、あくまでサイトを閲覧するという域での話です。サイト閲覧自体はモバイルの１機能に過ぎません。

将来的なECはもっと柔軟な購入体験を要望しています。たとえば、音声による購入です。これはスマートスピーカーでは活用が始まっています。他にもO2O2やオムニチャネルなどを考慮する場合、モバイルの活用を念頭に入れることが必要です。必ずしもWEB閲覧を必須とせずに購入できる仕組み作りをECでは求められ始めています。

SNS内で完結できる決済や、IoT、仮想空間上でのショッピングの実現などWEBを本籍地にしながら、それぞれのユーザーが過ごす時間のなかに入り込める方法を模索しています。

こうした話はそう遠くはありませんが、まだ高度な技術を要します。そのため、多くのECプラットフォームが備えているという話になるには時間がかかります。しかし、これらは結局のところ、これらの展望はいかにユーザーに寄り添った開発ができるかということがECプラットフォームのポテンシャルとしても、開発の指針としても求められているということに他なりません。