東京と大阪で働く社長の日記

さて、これまでEC-CUBEの問題点を列記させて頂きました。

アクセスされた情報を見るとEC-CUBEでの検索が増えてきております（笑）

さて、問題点ばかり書いてしまうと、単なるクレーマーになってしまいますし、日本で一番最初にEC-CUBEの実績を公開した会社であり、以前はシルバーパートナーで、現在はブロンズにランクダウンしてしまいました（泣）が、EC-CUBEのカスタマイズできる会社である当社として利点を説明したいと思います。

EC-CUBEの利点は、それはオープンソースであり、コミュニティサイトが充実している点です。

また、書籍も２冊発売されており、情報が多いのが良い点であります。

他のオープンソースのECサイト構築ツールでは、ここまで充実した情報が手に入るものは無いです。

オープンソースとして、ここまで大きくなった国産のオープンソースアプリは無いではないでしょうか？

それだけ、多くの方が利用しますので、問題点も出てきますが、ソースを公開して頂いたことに深く感謝しなければなりません。

スクラッチから開発することを考えると、導入費用のコスト削減ができるので、助かっている方は多いと思います。

当社が日本で一番にEC-CUBEの導入事例を発表した時に開発元の会社様から取材を受けたのですが、その時が懐かしく思います。

すぐに採用した理由は、PHPで作られており、デザインはSmartyを利用しているところも大きな採用利用だったのですが、一番気に入っているのは、管理画面の使い勝手です。

EC-CUBE以前は、osCommerceやZenCartを利用していたのですが、管理画面の使いにくさにイライラしていたのですが、EC-CUBEが公開された時は、非常にビックリしました。

すばらしい！の一言でした。

Magentoも使いやすい管理画面なのですが、EC-CUBEの方が使い易いですし、エンドユーザに特別なマニュアルが無くても利用できる点が非常に良いです。

EC-CUBEの問題点は今回で最後にさせて貰います。

さて、マーケティングの問題点としては、LPOがあります。

EC-CUBEは非常に良いツールなのですが、マーケティング部分が弱く、PPC広告からのリンク先としてのランディングページの構築がしづらいという点が上げられます。

ランディングページとは、Yahoo!、GoogleなどのPPC広告からリンクされたページを集客ページの基点と考えて、そこからコンバージョン率をあげるための対策をすることをLPOと言います。

このランディングページの制作をEC-CUBEでするには、user_dataという領域を利用しますが、URLにuser_dataが表示されてしまいます。

これは、mod_rewriteで対応できるのですが、そもそも、エンドユーザは簡単にランディングページを作成することは困難であります。

EC-CUBEをカスタマイズしてくれる会社に依頼しても費用が発生してしまいますので、いくら投資してもコストに見合うかどうか疑問が出てきます。

これを対応するためには、WordPressを前面にして、EC-CUBEを後ろに持ってきて、構築する方法で対応することが一番効率が良いということになりますが、EC-CUBEとWordPressの２つのシステムを利用しなければなりませんので、エンドユーザは勉強するのに時間が掛かってしまいます。

EC-CUBEにCMSの機能があれば良いのですが、実装されておりません。

Magentoであれば、LPOとしてランディングページを作成する機能がキャンペーンとして存在しますので問題はありませんが、EC-CUBEのキャンペーンページ作成も使い勝手良いものでもありませんので問題があります。

他には、EC-CUBEにはサイト内検索はありますが、そのキーワードを集める機能がありません。

サイト内検索では、目的の商品を探しだせなかった訪問者が利用する機能ですが、このサイト内検索を利用することは、お客様の要望であり、ユーザビリティが悪いのか、商品のカテゴリ分けの仕方が間違っているので、コンバージョンを上げるためには、非常に重要であります。

もう少しサイト内検索機能を充実しなければならないのは、サイト内検索のキーワードを集約して、その結果を表示する機能が必要であります。

これもカスタマイズすればすぐに対応できますが、やはりカスタマイズ費用が掛かってしまう問題があります。

これまで、EC-CUBEの問題点を技術面、マーケティング面で説明させて頂きました。

他にも細かい問題点はありますが、問題がないシステムなどはこの世にはありません。
EC-CUBEがここまで導入されていることを考えると、国産のECサイトのオープンソースである点と、インターフェイスが良いところがあります。

ここまで立派に作られた国内向けのECサイト構築がなかったのですから、これがオープンソースで提供され、誰でも利用できることは非常にすばらしいことです。

もっともっと、使い勝手の良いツールになることが出来るので、当社としてもこれからも応援させて頂きたいと思いますし、Fork版を開発して、マーケティング面、レスポンス面、ソースコードの美しさを追求したEC-CUBEを提供させて頂きたいと考えております。

今回もEC-CUBEのマーケティング面での問題点を説明させて頂きます。

前回と同様にSEO対策で重要なのは、検索エンジンに対してどのようにサイトを巡回してもらい、インデックスしてもらうのかが重要であります。

そこで、重要なのが、ディレクトリ構造とsitemap.xmlの準備です。

ディレクトリ構造とは、URLの最後が/(スラッシュ)で終わっていることになります。
こうすることで、余分なdetail.php?product_id=70を無くし、detail/70/などのようにすることで、検索エンジンに良い評価を与えることができます。

しかし、EC-CUBEでこれをやろうとした場合は、Apacheのmod_rewriteを使う方法しか現在はありません。

これは、エンジニアであればできるレベルなのですが、一般ユーザにはちんぷんかんぷんでしょうし、そもそも、mod_rewriteの存在自体知らない方が多いと思います。

例えば、弊社でよく利用するconcrete5では、この機能が内蔵されておりませんが、mod_rewriteするためのテキスト情報を提供されており、.htaccessにそれを投入することで対応することができます。

同じく、Magentoにも同様にこの機能はあります。

エンジニアからするとすごく単純な仕組みなのですが、EC-CUBEでなぜそれを提供されないのか不思議であります。

次に、sitemap.xmlですが、これはGoogle、Yahoo!に対して自サイトはこれだけのページがありますよと言うファイルです。

中身は、XMLのテキスト形式でページ構成を記述します。

これも同様にconcrete5では自動的に生成できますし、cronを設定することで定期的にsitemap.xmlを生成します。

そのファイルを設置し、Google、Yahoo!に設置しましたと登録することで、インデックスされる量、すなわち、巡回の回数を増やすことができると言われております。
※注意、必ず巡回されるとは限りません。

同様に、Magentoにもsitemapを作成する機能がありますので、マーケティングが重要な時代で、このような機能がないEC-CUBEは問題があると判断しております。

もちろん、カスタマイズできる会社がカスタマイズすれば良いのですが、EC-CUBEのカスタマイズを依頼すると、当たり前ですが、彼れはそれで稼いでいますので、かならず費用が発生します。

バグは本家に還元しますが、カスタマイズで儲けることができる部分は、本家に還元しておりません。

やはり、EC-CUBEのFork版を開発して、オープンソースで公開して、エンドユーザのためのオープンソースにしないといけないと思います。

また、Magentoへの移行ができる方法も同時に提供することで、エンドユーザに選択できるものを複数提供することが当社の役目だと考えております。

これまでのEC-CUBEの問題点に関して多くの方から賛同する意見や、批判的な意見も頂きました。

特にEC-CUBEのカスタマイズで飯を食っている方からは辛辣な意見を頂きました。ありがとうございました。

さて、EC-CUBEの問題点として技術的な問題点を列記させて頂きましたが、今回からはマーケティング面で説明したいと思います。

EC-CUBEでいうマーケティングと言えば、ネットマーケティングになります。

このネットマーケティングで一番皆さんがご存じなのは、SEO対策だと思います。

SEO対策とは、正式には検索エンジン最適化のことであり、「検索エンジン最適化」対策というおかしな日本語になってしまいますが、一般的にSEO対策と言いますので、このまま使いたいと思います。

このSEO対策で重要であるのが、キーワードです。それもキーワードの出現率は重要であるばかりか、読みやすい文書にしないと折角検索エンジンの検索結果の上位に表示されていてもコンバージョンされにくいと考えているのが、当社が考えるSEO対策です。

しかし、残念なことにEC-CUBEはネットマーケティングで重要なSEO対策をほんの一部しか対応できないです。

トップページ、商品一覧ページ、商品詳細ページでそれぞれにメタタグなどの設定はできるのですが、商品一覧ページ、商品詳細ページでは共通のタグしか出力できません。

これでは、折角ECサイトを構築しても、SEO対策の手前で失敗していると言わざるを得ません。

そこで、当社では、以前からご紹介しております「Webサイト最適化」手法を用いてSEO対策と同時にコンバージョン率を上げるビジネスを開始しており、利用されているお客様からコンバージョン率が上がったと言われております。

EC-CUBEに独自のカスタマイズとして。この「Webサイト最適化」を施すことは出来るのですが、実は「Webサイト最適化」の全部を対応するには、EC-CUBEでは出来ないところがあります。

それは、レスポンスの悪さです。

先のタグに関しては、どこのEC-CUBEのカスタマイズできる会社であれば対応できます。
※ただし全てのEC-CUBEのカスタマイズ会社ができる訳ではありませんが。

根本的なレスポンスの悪さ、および、カスタマイズのしにくさを考えると、他のECサイト構築ツールに軍配があがるでしょう。

であれば、EC-CUBEを導入して利益が得られるぐらいの商品力があれば、問題ありませんが、競合が多い商品であればSEO対策だけではなく、コンバージョン率を上げるための「Webサイト最適化」が使えるECサイト構築を選択しないといけないでしょう。

そこで、当社が現在オススメするのは、やはりMagentoです。

レスポンスも良いですし、SEO対策がEC-CUBEよりもやりやすいところが良いです。

しかし、100%「Webサイト最適化」が使えるかというと、Magentoも及第点してかつけられません。

当社では、EC-CUBEのFork版を開発するのと同時にMagentoも「Webサイト最適化」手法で独自にカスタマイズする予定であります。

同時にEC-CUBE→Magentoへのマイグレーションツールの開発も実施する予定です。

何故かというと、これまで多くのユーザにEC-CUBEの導入を行ってきました。

その責任がありますので、Magentoへの移行ツールも同時に開発しなければ、普通のEC-CUBEをカスタマイズできる会社と同じレベルになってしまうからです。

EC-CUBEからMagentoへのマイグレーションに関して当社のお客様以外からもお問い合せ頂けましたら、ご協力させて頂きますので、EC-CUBEのサイト構築したが、売上が上がらない方は遠慮無くお問い合せください。

EC-CUBEの問題点としてデータベースのパフォーマンスが悪いところがあります。

データベースがあまり正規化がされていない部分と、プログラムから発行されるSQLに大きな問題があると思います。

例えば、PostgreSQLであっても、商品一覧の表示する部分では商品件数が増えると異常に遅くなります。また、トップページも相当遅く表示されることが多々見受けられます。

サーバのスペックとしてメモリを増設して、PostgreSQLの使用できる領域を改善したり、バージョンをPostgreSQLの8.4系にすると改善しますが、根本的な原因はデータベースではなく、正規化されていないデータ構造とSQL文に問題があります。

MySQLの方がPostgreSQLより高速に動作するはずなのに、EC-CUBEでは逆にPostgreSQLの方が速く動作する場合があります。

この点からも、データベースに問題があるのではなく、プログラムから発行されるSQL文に問題があると思います。

Oracleのデータベースが流行りだした1995年ぐらいずっと言われていることですが、データベースのレスポンスを改善するのに、データベースのパフォーマンスを改善するのではなく、SQLを改善した方がより効果があるのです。

しかし、正規化がされていない場合は、SQL文を見直せません。

EC-CUBEは、このSQL文を見直しても少ししかレスポンス改善の効果が見込めませんし、MySQLやPostgreSQLのサーバ側で改善してもあまり効果がなく、根幹部分を改善しないといけないです。

このような問題点の多いEC-CUBEですが、ここまで立派に作られており、オープンソースで提供されているものとしては、多くの実績がありますので非常に残念だと思います。

EC-CUBEをカリカリにチューニングして、Forkして、リファクタリングをさせて頂きたい思います。

引き続きEC-CUBEの問題点をご紹介させて頂きます。

今回はEC-CUBEはオープンソースですので、ソースをダウンロードできるのですが、そのダウンロードされたファイルを確認すると、改行コードが一致していないものがあります。

おそらく、Windowsパソコンで編集されている方と、Linuxなどでソースコードを編集されている方がいると思いますが、そこで何も意識せずにSubversionなどに放り込んでいるので、改行コードが一致しないのかと思います。

確かSubversionでは改行コードを統一する機能があったと思いますが、テキストファイルの改行コードは合わせておかないと、CRLFとLFが混在して状態であれば、いろいろな問題点が発生すると思います。

表面上はあまりたいした問題ではありませんが、カスタマイズしたりするプログラマからすると「うへ～」と感じる部分であります。

前回に引き続きEC-CUBEの問題点として、HTMLがXHTMLになっていない点が上げられます。

あまりたいしたことはないのですが、当社では独自にXHTML化しておりますので、公開側は問題ないのですが、管理画面側は悲惨な状況だと思います。

公開側はXHTML/CSSでカスタマイズするのは当たり前ですので、こちらはデザイン制作会社では対応ができると思いますが、管理画面までは手が回らないのでしょうか？

厳格にXHTML化する必要はありませんが、少なくとも、FireFoxのアドオンで提供されている「Html Validator」でのチェックぐらいはされていないと恥ずかしいと判断しております。

EC-CUBEをカスタマイズする場合は、公開側よりも管理画面側をカスタマイズする量が多いのですが、HTMLがおかしな状態ですので、プログラム開発する時に要らない余分な作業が発生してまうことが多々あります。

このようにHTMLの問題が多いEC-CUBEですが、後、かなり気になっている部分として、キャッシュを更新している部分があります。

キャッシュを消す処理量とレスポンスを速くするための比較になってしまうので、あまり表面上の問題はありませんが、個人的にはかなり問題視しております。

また、ブラウザの戻るボタンを押した時に、特定のタイミングでEC-CUBEから「有効期限切れ」のメッセージが表示されることがあります。

初歩的なことですが、対応できていない部分も問題視しております。

このように問題点が多い状況ですし、かなり前から指摘されている状況なのですが、一向に改善されていないところを見ると、解決できないのかなと思います。

はやり、ここは、当社でEC-CUBEをForkして、リファクタリングするしか無さそうな気がします。

前回に引き続きEC-CUBEの問題点をどのように解決するのか書いてみます。

まず、EC-CUBEはPHP4から対応ということですので、完全なオブジェクト指向言語になったPHP5からのみのサポートではありません。

PHP4は重大なセキュリティ上の問題が起こってもサポートは切れておりますので、PHP5で動作させないと非常に不味いですので、PHP4をサポートする必要はないです。

そこで、PHP4もサポートされているEC-CUBEなのですが、オブジェクト指向を理解して作られているのか非常に疑問があります。

_Ex 付きのクラスにカスタマイズした内容を書き込めってことだと思いますが、もともとのクラス自体が継承されることをまったく考えてない作りなので、もともとのクラスをどうしても書き換えたくなる気持を抑えるのが大変です。

これは開発するエンジニアとって正直なところ苦痛です。（笑）

これを解決するには、EC-CUBEをリファクタリングするしか方法がないかなと思っております。

なお、当社はEC-CUBEのブロンズパートナーであり、EC-CUBEが公開されて一番最初にサイトを公開させて頂いた会社です。

EC-CUBEを非難している訳ではなく、なんとかEC-CUBEを良いツールにしたいと考えておりますが、こうも問題が多いとなると、Magentoに移行する方が良いか、独自にリファクタリングするのが良いか検討する時期に来ているのではないかと考えております。

EC-CUBEは非常によく出来たECサイト構築ツールなので、利用者も多いのですが、エンジニア泣かせな部分が非常に多いのも事実です。

そこで、EC-CUBEの問題点を整理して、当社でEC-CUBEのリファクタリングを実施して、ちゃんとしたオブジェクト指向で作り直し、データベースも正規化し、初歩的なバグは速やかに直せる体制を築きたいと考えております。

まず、EC-CUBEの問題点として、ファイアウォール内で管理画面にログインできない問題点があります。

管理画面にログインしたら直ぐに更新情報が表示されるのですが、Proxyサーバ経由の場合に内部からのアクセスがあった場合は拒否されることがあります。

プログラム上はJSONライブラリを利用しておりますので、これがエラーになって管理画面にログインできない場合が想定されます。

企業内はセキュリティを考慮しておりますので、中の人は管理画面にログインできない時点で評価できないということになります。

カスタマイズできる会社であれば、すぐに修正できるのですが、評価する側からすると問題であります。

今後もEC-CUBEの問題点をご紹介させて頂きまして、リファクタリングした方が良いのか、皆さんのご意見をお聞きしたいと思います。

また、リファクタリングするのではなく、EC-CUBEではなく、Magentoに移行するのも１つの方法だと思います。

選択肢が多いECサイト構築ツール分野ですので、EC-CUBEをリファクタリングせずにMagentoなどの他のECサイト構築ツールに移るのも一考かなと思います。

なぜ、Magentoなのかというと、まず、データベースの構造が美しいです。
元々、データベースエンジニアであったので、このあたりに直ぐにチェックしてしまうのですが、本当に美しいデータベース構造になっていると思います。

次に、ECサイトを構築するのがお客様の目的ではなく、ECサイトを構築してから利益を得ることがお客様の目的であって、EC-CUBEをカスタマイズしてくれる会社にサイト構築をお願いするだけでは、目的は達成できないです。

EC-CUBEは正直なところマーケティングに弱いというか、考慮されていないと考えております。

その点からカスタマイズする会社が多いということでしょうが、Magentoにはネットマーケティングを強化する機能が搭載されておりますので、儲かるECサイトを構築するには、本当はこちらを採用するべきなのかもしれません。

ここまで育ったEC-CUBEを更に発展させる（リファクタリングする）方が良いのか、Magentoに移るのが良いのか検討しております。

全然知りませんでしたが、concrete5では管理画面から自動的にsitemap.xmlを作成する機能がありました。

これまで、外部の無料ツールでsitemap.xmlを作成しておりましたが、管理画面から容易にsitemap.xmlを作成できるので、非常に重宝します。

sitemap.xmlは、SEO対策では必須のファイルです。

このファイルを設置することで、検索エンジンに自サイトにはこれだけファイルがありますよ～と伝えることができますので、非常に重要です。

また、CMSとしてこの機能があることで、日々更新しているサイトであれば、サーバ側で定期的にcronで指定したURLを実行するだけでsitemap.xmlを作成する専用URLも用意されているところが非常に良い機能です。

EC-CUBEにもこのようなsitemap.xmlを自動的に作成してくれる機能があれば良いのですが。

しかし、高速なCMSとしてconcrete5は非常に優秀なので、Googleのレスポンスをページランキングの評価にすることへの対応もすんなりできるところが良いですね。

concrete5のモジュールをドンドン作成したいと考えております。