大阪で働く社長の日記

さて、現在バタバタの納品作業がありまして、なかなか定時に帰れないのですが、遅くに自宅に帰るとカーテンにセミがとまっていました。

それも、羽化寸前のセミです。

どうも息子が昼間に拾ってきたみたいでして、夜中に羽化しだしました。

さて、なぜこんなに忙しくなったのかというと、EC-CUBEでとあるサイトを構築しているのですが、売るために必要な対策が打てませんので、当社で売れるEC-CUBEに変えております。

そこで、標準のEC-CUBEからもっと売れるEC-CUBEに切り替える作業として「EC-CUBE補完計画」を実行しております。

完成しましたら、どのように売上が変わったのか公表させて頂きたいと思います。

そう。セミが羽化するように。。。

EC-CUBEでは、何も考慮せずにサイトを公開してしまいますと、URLはディレクトリ構造になりません。

例えば、商品一覧の場合は、
/products/list.php?category_id=1
になります。

また、商品詳細ページの場合は、
/products/detail.php?product_id=1
になります。

これは、phpの作り方でやむを得ませんが、SEO上好ましくありません。

?以降の部分が検索エンジンにインデックスされるかどうかということなのです。

一部のサイトでは?以降もインデックスされていますが、ほとんどのEC-CUBEのサイトでは、?以降のURL付きはなかなかインデックスされません。

そこで、対策としては色々とあるのですが、ディレクトリ構造にして対応する方法があります。

上記の例であれば、
/products/list.php?category_id=1
↓
/products/list/category/1/

/products/detail.php?product_id=1
↓
/products/detail/product/1/

とかにすることです。※本当は絶対パスが良いのですが。

これは、単純にApacheのmod_rewriteで対応することができますが、すべてのHTMLテンプレートも同様に見直す必要があります。

そこで、当社では、このディレクトリ構造ができるように独自のEC-CUBEのカスタマイズを実施しました。

現在、当社が考えているWSO（Webサイト最適化）手法を用いて、売れるECサイトを構築できるようにEC-CUBEの独自カスタマイズ作業を進めております。

一部のユーザ様には事前に、この独自カスタマイズを適用させて頂いておりますが、売れるECサイトを構築できるツールとしての完成度に自信が出来た時点でソースを公開したいと考えております。

まだ、多くに未実装部分が多いので、中途半端な状態で公開はしたくありませんので。

それと、現在のEC-CUBEのソースコードも順次見直しをしておりまして、PHPならではのお行儀の良いオブジェクト指向に再度見直しまして、無駄なソースコードを大幅に削減したいと考えております。

現在のコード量の1/4ぐらいまでの削減を目指しておりますが、最低でも1/2ぐらいまで削減を図り、プログラムのレスポンス改善も行いたいと考えております。

ちょっと骨の折れる作業ですが、限界を感じておりますので、エンジニア魂としてやってみる価値があると信じております。

EC-CUBEをそのままインストールして使うとIEでは「Web ページの有効期限が切れています」と公開側で表示されることがあります。

再現する方法は、簡単でして、

１．商品一覧で２ページ目を表示させる。
２．２ページ目の商品一覧から適当な商品をクリックして商品詳細を表示させる。
３．IEの戻るボタンをクリック

なお、IEではなく、Firefoxだと「このページを表示するにはフォームデータを再度送信する必要があります。フォームデータを再送信すると以前実行した検索、投稿や注文などの処理が繰り返されます。」

これは、折角商品を選択して、もう一度一覧に戻って別の商品を買おうと思っていたのに、このような画面が表示されてしまうと、買う気を無くしてしまうことになります。

最悪なユーザビリティの問題であります。

当社では、この問題を根本的に解決することができました。

根本的にというのは、小手先のテクニックではなく、クラスから見直すことで対応することが出来ましたので、今後、当社のユーザに順次適用していきたいと考えております。

先日セットアップしたEC-CUBEの専用サーバですが、PostgreSQL8.4未満で動作させておりましたが、商品点数が多いサイトですので、レスポンスが著しく悪かったです。

そこで、PostgreSQLを8.4にバージョンアップして試してみたところ、申し分のない速度で表示されるようになりました。

原因として考えられるのは、今回のPostgreSQL8.4で追加された「ディスク先読み」機能が効果を発揮しているのではないかと考えられます。

この「ディスク先読み」機能は、必要なデータがメモリに存在しない場合は、DISKからデータを読み込むのですが、１ブロックづつしか読み込まないのがこれまでのバージョンだったのですが、今回の8.4からは一気にある程度読み込むのだそうです。

EC-CUBEをカスタマイズして、SQL文を見直したいのですが、ちょっとMagentoに移行などで、時間が取られてしまい今回はバージョンアップで対応してみました。

しかし、ここまでレスポンスが改善されるとは思いませんでした。

EC-CUBEをPostgreSQL8.4にバージョンアップは効果大ですね！

＜追伸＞
サーバからのレスポンスもGoogleの評価になっておりますので、レスポンスが悪いEC-CUBEでPostgreSQL8.4にしていないサイトは、バージョンアップをオススメします。

EC-CUBEの技術的・マーケティング的な問題点を前回お話をさせて頂きました。

それはあくまでテクニックの話でして、カスタマイズするだけで終わりな状況であれば、お客様は喜んで頂けませんし、投資したカスタマイズ費用に対しての費用対効果が測定できません。

そこで、当社では、Magento、EC-CUBE、LiveCommerceなどのECサイト構築に関して、デザイン制作、システムカスタマイズに関しては無料で、お客様には、インフラ、カード決済、SSL費用の負担して頂き、商品の売上金額の何％かを頂くことにしております。

EC-CUBEはネットマーケティングに弱いECサイト構築ツールですが、当社のWebサイト最適化を組み合わすことで、ネットマーケティングに強いEC-CUBEになりますし、Magentoであれば、もっと少ないカスタマイズでWebサイト最適化を施すことができます。

EC-CUBEで売れるサイトを構築するには、SEO、SEM、LPOだけでないWebサイト最適化手法を採用して売れる仕組みは構築できます。

しかし、それだけでは売れるサイトは作れますが、月商1000万円以上のサイトを構築することはできないでしょう。

ECサイトで大儲けするためには、我々みたいなネットマーケッター、Webデザイナ、ITエンジニアのノウハウや技術力だけではなく、お客様の商品をどのように愛して、その購買されるお客様に伝えるのかが重要であります。

次世代のネットで販売するために必要なことは、すべて相乗効果です。

足し算ではなく、かけ算であるということです。

さて、これまで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して、リファクタリングをさせて頂きたい思います。