自社ECを実現する手段として 「OSS」 「ASP・SaaS」 「パッケージ」 「フルスクラッチ」 「自称クラウド」 「Commerble」 の観点で分析します。
自社EC構築手段の比較表はこちら
OSS
OSS（open source sofutware）とは利用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称です。
参考：wikipedia
ECサイトを無償で配布されているソフトウェア、モジュール、ソースコードを利用して構築します。日本においては、2010年頃、主要な構築方法の方法の一つでした。
OSSのメリット
●初期費用が安い、自由度が高い
ソースを自分で改変したり、無償で配布されているモジュールをインストールして自分で改変すれば自由度が高いという点は大きな魅力です。
転職が頻繁にある欧米では、著名なOSSを採用する事によって、担当を確保しやすくするという考え方もあるようです。
OSSのデメリット
●自分たちでメンテナンスをしなければならない
稼働後に、OSS自体のアップデート情報に追従したり、OSSが動作するインフラのメンテナンス(セキュリティパッチの 適用をサーバーと利用ミドルウェア、ソフトウェア自体)が必要なので、自分達でちゃんとメンテナンスしていけるという体制が必要です。
●セキュリティトラブルのリスク
ECのトラブルのリスクはあまりにも大きいので、安易に無償で始められるからというだけで始めてはいけません。現に、セキュリティトラブルが頻発しているオープンソースもあります。
参考：経済産業省 株式会社イーシーキューブが提供するサイト構築パッケージ「EC-CUBE」の脆弱性等について（注意喚起）
●Magentoの例
2020年、MagentoはMagento 1のサポートを終了し、ユーザーはコストと時間のかかる再プラットフォーム化プロジェクトであるMagento 2へのアップグレードを余儀なくされました。
参考：eコマースプラットフォーム「Magento」に深刻な脆弱性
●プラグインがアップデートされるわけではない
オープンソースコミュニティがパッチを作成しても、第三者のプラグインも同様にサポートされるわけではないというリスクが改めて明らかになりました。️Magentで第三者が作ったプラグイン等を利用していると、Magentoがバージョンアップした際に、プラグイン側に追随するアップデートが無いなどの問題がおきます。
オープンソースの有効な使い方を知ろう
もちろん、オープンソースが悪いというのではなく、オープンソースを有効に使うには、ちゃんとオープンソースのアップデートなど動向を注意するとともに自分でシステムのインフラを管理して、(できれば)オープンソースのコミュニティに何らかのフィードバックが出来るような体制を持っていることが重要だと思われます。
Commerbleでもプロダクトの一部にオープンソースを利用しています。（例えばJSONを解析するようなプログラムなど）それらのアップデートを追いかけ、責任を持って安全に利用することが重要です。
OSSで継続的に改善していくためには
コミュニティや公式サイトから情報を収集し、アップデートの取り込み、機能の追加を行なわなければなりません。カスタマイズをしすぎると、アップデートが難しくなってしまう場合もあります。
ASP・SaaS
ASP・SaaSとは必要な機能を必要な分だけ、サービスとして利用できるようにしたソフトウェア（主にアプリケーションソフ トウェア）のことです。
参考：Wikipedia
クラウド上で利用できるサービスの一つであり、ソフトウェアをインストールせずにインターネット上で利用する仕組みを提供します。共通のプラットフォームを利用し、提供されている機能を利用できます。
SaaSの例として、Microsoft 365や、Google Workspaceがあります。 Microsoft 365は、Microsoft社からインターネット経由で提供されています。業務で必要なアプリケーションやサービスを選んで、サービスを利用できます。また、端末を選ばずにいつでもどこでもアクセスすることができます。
ASP・SaaSのメリット
●比較的簡単にECサイトを導入できる
初期費用が無料で利用できるASPカートもあるため、比較的簡単にECサイトをオープンすることが可能になります。また、自社でサーバーを用意したり運用保守を行う必要がありません。
●導入までの期間が短い
例えば、BASEはメールアドレスとパスワード、ショップURLを登録するだけで開設できます。
ASP・SaaSのデメリット
●カスタマイズが難しい
提供されている機能以外は、ほぼ実装できないため、カスタマイズは難しい事が大半です。例として、外部サービス連携があげられます。決済手法など外部連携可能なサービスが決まっているので、必要とする機能がどこまでカバーされているのか注意が必要です。
ASP、SaaSで継続的に改善していくためには
事業者から提供されている、アプリや拡張機能を活用します。 例えば、Shopifyではアプリストアで提供されているアプリをインストールし、機能の拡張を行うことができます。一か月あたり無料～900円程度のアプリが多いです。アプリストアでは、無料体験が可能なものもあり、決済、配送、マーケティング、在庫管理など何千個ものアプリが提供されています。予約販売・定期配送といった販売方法も実現できるようです。
Shopify アプリストアから、上部のコレクションを選択し、「日本向けの便利なアプリ」を見ると、日本向けにカスタマイズされたアプリが表示されます。例として、配送日時指定のアプリでは、土日だけでなく、日本の祝日を除いた営業日数でのお届け日の換算が可能となります。
このように、ASP・SaaSは事業者から提供されるアプリや拡張機能の中から必要なものをインストール・連携します。まず始めてみる、始めることによって体験して学んでみるという点では非常に有用な仕組みです。
ただし、提供されている拡張機能以外は利用できなかったり、少量しかカスタマイズできなかったりするので、自分たちのビジネス要件にマッチした機能、アプリがあるかというのは非常に重要です。
機能的に満たすものがあっても事業が成長すると利用しているアプリでは、質もしくは量が満たせなくなることが往々にしてあるので考慮に入れておきましょう。
また、拡張機能をインストールするたびに利用料金も必要になるので、最終的にいくらくらい必要になるかという観点も重要です。
パッケージ
パッケージとは、事業者が提供するECの基本機能をパッケージ化したシステムです。自社に必要なカスタマイズ・機能追加をして構築します。
パッケージのメリット
●自由なカスタマイズが可能
構築時に、柔軟なカスタマイズができます。インフラの構築先も自社データセンターなど自分達で望んだ場所を選ぶことが出来ます。
パッケージのデメリット
●高額
自分達で選べるということは、サーバー調達や管理を自分達で行う必要があります。そのコストは安くないケースが大半です。
●老朽化
構築後、ソースが派生するのでアップデートできなくなり、老朽化してしまいます。ECバージョンアップ・スケールアップ・セキュリティなどの運用は自社で管理する必要があります。
また、ソースが古い事業者が多いようです。OSS製品をベースにカスタマイズし、パッケージとして提供している事業者もあります。
パッケージ製品で継続的に改善していくためには
有償で提供される機能を追加し、カスタマイズします。ただし、カスタマイズをしすぎると事業者が提供するパッケージのアップデートができない可能性があります。その場合はリニューアルを検討しなければなりません。
フルスクラッチ
フルスクラッチとは、すべてのシステムをゼロから自社で開発することです。自社構築で有名なEC事業者だと、モノタロウ、ユニクロがあげられます。
自分達で仕様を決めることが出来るのでカスタマイズの柔軟性に優れた構築方法といえるでしょう。しかし、継続的に開発するには大規模な開発体制、インフラ等、セキュリティへの対応などコストが必要になります。自社構築での例のように大手ならではの選択肢と言えるでしょう。
ですが、クラウド型でも遜色ないカスタマイズができるようになってきています。コスト面・セキュリティ面を考慮すると、クラウド型ECで実現できないよほど凝った要件でない限り、フルスクラッチで構築する必要はないので、本当にフルスクラッチを行う目的は何なのかという点が重要になります
フルスクラッチのメリット
●自由なカスタマイズが可能
カスタマイズが自由であり、自社ユーザーが使いやすく、独自の商習慣に対応したシステムを構築できます。そのため、保守・運用や機能の拡張がしやすく、内製化が可能です。
●他の事業者に運用を左右されない
パッケージやOSSのように事業者がサービスを終えてしまったため、移行しなければならないといったことはありません。
フルスクラッチのデメリット
●コスト
開発に多くのコストと時間がかかります。
●老朽化
構築方法にもよりますが、構築後３～５年で、システムが老朽化してしまうことも少なくありません。技術トレンドの変更に追従していく必要もあります。そのため、強固な開発体制を内製する必要があります。優秀なエンジニアチームを運用し続けることが重要です。
フルスクラッチで継続改善を行うには
必要な機能を自社で追加し、インフラを含めた環境を自己管理していく開発体制が必要になります。 コストがかかることから、自分達だけで事業をコントロールしたい大手向きの選択肢と言えるでしょう。
自称クラウド
自称クラウドという呼称にしましたが、市場ではクラウド型の製品ということで販売されています。パッケージ製品の代替として利用されていることが多いです。
自称クラウドのメリット
インフラや機能がクラウド側から提供されるので、利用者はインフラを自分たちで保有する必要がありません。また、要望に応じたカスタマイズをすることが可能とされています。ですが、このクラウド形態には大きく違い(本物、偽物)の観点があるので後述します。
自称クラウドのデメリット
まずこの自称クラウドというくくりでは、本当にクラウドなのか？という点が重要です。
クラウドの定義はなにか？を簡単に振り返ります。
NIST クラウドコンピューティングの概要と推奨事項には、クラウドの定義が明記されています。クラウドの定義は、要約すると次の通りです。
- オンデマンドセルフサービス
- 幅広いネットワークアクセス
- リソースの共有
- 迅速な拡張性
- サービスが計測可能・従量課金
ユーザーがWeb画面（セルフサービスポータル）からシステムの調達や各種設定を行うという、人手を介することなく自動で実行してくれる仕組みを備えていること。
PCだけではない、さまざまなデバイスから利用できること。
複数のユーザーでシステム資源を共有し、融通し合える仕組みを備えていること。
ユーザーの要求に応じて、システムの拡張や縮小を即座に行えること。
サービスの利用量、例えばCPUやストレージをどれくらい使ったかを電気料金のように計測できる仕組みを持ち、それによって従量課金（使った分だけの支払い）が可能であること。
自称クラウドでは、これらの定義が満たされていない場合があります。例えば、定義の一つに「リソースの共有」というものがありますが、リソースを共有せずテナントごとにサーバーを立てている事業者があるとします。この場合、どのようなデメリットがあるでしょうか。
●サーバーの台数が増えるごとに利用コストと管理コストが値上がる
サーバーの台数が増えるごとに比例して、利用コスト、管理コストが上がります。これはクラウドサービスを提供する事業者の料金やコストを見るとよくわかります。共有していないテナントだと、明らかに共有しているテナントよりコストが上がります。
●テナント別にサーバーを立てると機能やセキュリティが共有されない
機能やソースコードがサーバー毎に分離していたとすると、新しい機能やパフォーマンス、セキュリティを共有することが出来ません。1テナント1台ずつ別にサーバーを立てたものをクラウドとして提供している自称クラウド業者か、機能やセキュリティといったリソースが共有されているかというのは目には見えにくいですが、重要な点になります。
●リソースを共有できていないとパフォーマンスにも問題が出る
サーバーをテナント毎に分けると、あらかじめサーバーの性能、スペックが決められてしまいます。アクセス集中時にパフォーマンスが発揮できなくなってしまいます。クラウドなのにアクセス集中時に難がある自称クラウド業者は、パフォーマンスの問題を多く起こします。
●迅速な拡張性を持てない
リソースが共有されていないと、プラットフォームとして共通の状態にはならず、テナント毎に上京を把握する必要が出ます。そうなると迅速な拡張性に問題が出ます。これは利用しているECクラウドの拡張スピードが遅いという問題に繋がります。
●価格帯が高額
一般的に価格帯が高い製品が多いようです。見積もりを依頼すると3000万円スタートという話をよく聞きます。また、AWS等のクラウド上で動作していると言うだけで、共通システムが随時アップデートされないという話も聞くことがあります。料金表は未公開です。一定量カスタマイズが必要だとパッケージに乗り換える事が必要な製品もあります。
●ECクラウドによるアップデートの強要
自社のデータセンターでホスティングしているケースと違って、ASPやECクラウドはECシステム事業者側がサーバー管理をしています。そのため、EC事業者によるアップデート作業の強要が発生することがあります。
2021年、ある事業社は利用ユーザーにサイトジェネシス プラットフォーム からストアフロントリファレンスアーキテクチャ (SFRA) への移行を強制しています。
AWSやAzure、GCPといったパブリッククラウドでも利用しているサービスが終了して、別のものへの乗り換えが必要になることはありますので、懸念事項として覚えておきましょう。(パブリックラウドの場合は通常1,2年前からサービス終了と移行の予告があるのが一般的です。)
まとめ
いずれにしてもクラウドと名乗る製品については、本当にクラウドの定義に当てはまっているのか、見積もりが適切なのかというのを確認する必要があるでしょう。 本物のクラウドではないサービスで構築したサイトでは、コストが高い、パフォーマンスが悪いなどといった理由から、数年ごとにリプレイスが必要になり、本来のクラウドの長所を発揮できないサービスもあるようです。
それでは、クラウドに求められること、検討する上で重要なこととは何でしょうか。
コマーブルが考える本物のクラウドとは？8つのポイント
