「なぜ世の中のEC構築は非効率に行われているのか？」という疑問をもとにCommerbleはスタートしています。 この記事では、Commerbleが解決しようとしている「非効率なEC構築」と「仮説や解決方法」についてまとめます。
EC構築においては非効率的な方法が展開されています。例えば、
- 高コスト＝技術は発展したのに、高い費用(インフラ,パッケージ、カスタマイズ)が掛かるのはなぜ？
- 陳腐化問題＝改善や変更が全然進まない、環境をアップデートできないのはなぜ？
- 都度の乗り捨て＝何年かおきにリプレイスして、ベンダーやシステムを乗り捨てるのはなぜ？
- パフォーマンス問題＝動作が重く、買い物しにくいサイトが多いのはなぜ？
自社ECサイトを構築されている方には、思い当たる点も多いかもしれません。
これらの課題を技術や考え方で解決できるのでは！という思いでCommerbleは始まりました。
また個人的に、こういった非効率な仕事を15年後に自分の子供がECの仕事に就いた時、経験して欲しくないし、21世紀もだいぶ経過したんだからコンピューターをカッコよく使おうぜ、という思いが強くあります。コンピュータは人を幸福にするもので、高いコストを強いる搾取の道具ではないはず。
自社でECを構築する場合にありがちな、非効率な部分を掘り下げます。
◆高コスト
高額なパッケージ費用
ECパッケージを数百万円など、クローズドな金額で購入します。さらにパッケージは提供会社しかカスタマイズできないケースが多くあります。初期コストが高いだけではなく、導入後、ベンダーロックインの独占的な改修価格になるのではという懸念もあります。
高額なSI費用
フルスクラッチの場合やパッケージ(有償無償を問わず)をカスタマイズする場合、SI費用は非常に高額になりがちです。 会員登録し、カートに入れ、決済するという基本は変わらず、カスタマイズも似た要望が多いのにどうしてコストがかかるのでしょうか。
高額なホスティング費用
データセンターの費用で月数十万から100万円強かかることもあります。CDNに月100万円支払うなど。 加えて運用監視という人的コストも発生します。
このように初期費用から高コストで、運用も安くありません。アップグレードや移行なども高コストになります。 そして、規模が大きくなるほど高コストな事業になります。これっておかしくないでしょうか？
◆都度の乗り捨て
高コストであるにもかかわらず、構築しては数年に一度リプレースされ、破棄されます。 会員登録して、閲覧して、買い物する基本の仕組みは変わらないはずなのに、どうして都度破棄されなくてはいけないのでしょうか？
構築パートナーも破棄されます。
なぜ都度システムを捨てるのでしょう？アップデートできず陳腐化してしまうから？ なぜ構築パートナーをリセットしたいのでしょうか？なぜ数年来の不満が溜まるような関係性になってしまうのでしょうか？
◆陳腐化問題
リリース直後から、システムは古くなっていきます。 パッケージはカスタマイズした場合、簡単にバージョンを上げられなくなります。 そのため、陳腐化を受け入れて、数年おきに捨てる という手法がとられがちです。
また、EC構築のビジネスの大半が初期コストに費やされるため、更新には優秀なエンジニアが当たりにくい事情もあります。
いつでも最新の環境にアップデート可能な仕組みが必要ですが、自前でデータセンターを持った場合はインフラの運用や更新が必要でパッチ当て等にも労力がかかります。その上に乗るパッケージではカスタマイズ内容によってはアップデートできないケースも多いです。技術的な対応方法はないものでしょうか？
◆パフォーマンス問題
パフォーマンスを維持するのに相当なコストがかかったり、サイトが重く使い勝手が悪いと機会損失が発生してしまいます。ですが、このパフォーマンスを重視するベンダーが少ないです。
そもそも高パフォーマンスにする知見や技術がなく、パフォーマンスを考えずにカスタマイズしてしまい、結果システムの速度が重くなるケースがあります。
正常に動作すればOKで、パフォーマンスに対するメリットがシステム構築事業者にはないのでしょうか？ 高パフォーマンスを出す知見やノウハウが業界に不足しているのではないでしょうか？
このようにEC構築手法は、非効率な手法のオンパレードなのに課題は置き去りで、業界は毎年非常に大きく成長しています。 それなら非効率なEC構築手法の課題を解決すると、世の中にとってメリットは大きいはずです。ワクワクしてきませんか？ Commerbleはワクワクする世界を目指して、これらの問題を考えます。
Q.なぜ高コストになるのか
カスタマイズが高コストになるのは、あらかじめカスタマイズを予期した製品になっていないからでは？ ユーザーのカスタマイズに対するニーズは年々高まっているのに、追従できないパッケージとして古いアーキテクチャのままなのでは？
それならEC業務に特化したアーキテクチャを考え、あらかじめカスタマイズ可能な領域(CMS、API、バッチなど)を設けておけばよいのでは？
インフラが高コストになるのは、自社で所有するからで、AWS,Azureのようなパブリッククラウド形態のEC開発プラットフォームとして提供し、EC事業者はサービスとして利用すればよいのではないか。
高コストになるのは、EC構築のビジネスは、初期費用で稼ぐようなSI型のビジネスになっているからではないか。 プラットフォームを提供し、売れた分で課金していくようなビジネスモデルであれば、共存共栄で、プラットフォームのアップデートを行うことによって、売上があがり、その分プラットフォームを提供している側の実入りが増える。というようなゴールの一致も可能なのではないか。
Q.なぜ陳腐化するのか
陳腐化(アップデートできない)になるのは、パッケージや自社システムのインフラ構成が悪いからでは？
沢山機能がある、裏を返すと沢山アップデートしなくてはならない機能が出来てしまい、機能表の○は沢山あっても実際には陳腐化してしまっているのでは？機能表では○でも、中身がどのようにできているかはわからない、それをいいことに手を加えるとアップデートできない、数年以上使い続けられないパッケージが作られ、改善されないまま売られているのでは？ WEBサーバーやシステム基盤、セキュリティは年々アップデートされるという常識に対応していないからでは？
クラウド形態で提供すれば、ユーザーが個別にアップデートできないようなインフラ環境を作ることはない。プラットフォームをサービスとして提供し、プラットフォーム提供側が都度アップデートする事ができるようにしたら良いのではないか。
Q.なぜパフォーマンスが問題になるのか
非機能要件の重要性は、認識されにくい。EC構築の業界では無償のパッケージでも始めることができるので、初心者がパフォーマンスを考慮しないものを提供してしまう。
パフォーマンス問題はECの非機能要件に詳しい技術者がプラットフォームを作れば良く、パフォーマンスを意識したくないEC事業者はその部分をプラットフォームに任せてしまえばよいのではないか。
Q.なぜ乗り捨てなくてはいけないか
構築パートナーが都度リセットされるのは、SIパートナー(初期費用が大きく、作業に応じてコスト)とEC事業者(リリース後の売上が目的)でゴールに違いがあるからではないか？とすると、利用料金は売れた分の従量にすれば良いのではないか？
考え出すと、さらに多くの解決手法を思いつかりそうです。
こうしてCommerble EC PaaSというプロダクトを作っています。そんな物語を皆さんと共有したいと思います。
