大阪で働く社長の日記

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のマーケティング面での問題点を説明させて頂きます。

前回と同様に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の問題点をどのように解決するのか書いてみます。

まず、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に移るのが良いのか検討しております。

今日は、地元である神戸の三宮でmagento-jp meetingが開催されましたので、この手のコミュニティ会合は避けていたのですが、初めて参加させて頂きました。

３分ぐらい遅れて会場に到着しまして、自己紹介させて頂きました。

まずは、カスタマイズ方法に関してですが、プログラム作成を離れて２年少しのものにとっては、とても新鮮な香りで、懐かしいなぁと感慨深い内容でした。

しかし、magentoはディレクトリ構造が複雑な感じがしました。

それから、CMSであるtypo3との連携に関しての説明があり、最近、CMSの重要性を再認識している私にとって、非常に興味深い内容でした。

これで会合は終了したのですが、CMSの連携でmagentoとの連携で、私が気に入っているCMSで連携できるものはないかとAPIを調べてみると、Joomla!がありました。良いですね。

Drupalを何回か会社の仕事で導入しましたが、結局、アドオンやモジュールでは役に立たないというか、当時のメンバーでは、お客の要望を100％実現できなかった嫌な経験があるので、CMSを避けていたのですが、Joomla!＋magentoで販売主体の会社のホームページの開発は可能であり、魅力的なビジネスネタになるのではないかと思われます。

Joomal!＋EC-CUBEも工夫すれば、できるのでしょうが。

あっそうそう、今日は、私の誕生日だったので、自分で会合の帰りに家族が食べるケーキを買って帰りました。（泣）

2009年9月19日（土）にMagento-JP Meetingの関西が神戸で開催されるみたいです。

土曜日も最近は忙しくしておりますので、ちょっと息抜きに、どのような方々が日本でmagentoを広めようとしているのか、参加してきたいと思います。

第二回、Magento-JP meetingの詳細はこちらから

初めて利用したのですが、参加するのには、OpenIDを利用して参加申請しないといけないみたいです。私は、趣味のブログをYahoo!、メール送信だけGoogleのGMailを使用しておりましたが、今回は、Yahoo!のOpenIDを使うことにしました。

ところで、OpenIDは１つだけ保有するべきですよね。Google側にしようか悩みましたが、日本はYahoo!でしょ～。と考えてYahoo!JapanのOpenIDを初めて使用しました。

何がどう便利になっていくのか解りませんが、Magento-JP meetingの参加申請は出せました。

当日は楽しみですね。

なお、当日は、私の誕生日だったりします。何か良いことがあれば良いのですが。（笑）