2010年11月から受注案件でEC-CUBEを用いた案件に携わってきました。 そこで出た問題点や必要改善点に関して、簡単にまとめていきます。 基本的には受注側、ソリューションする側の視点で書いています。
・DBの選択 EC-CUBEに慣れた人材がいなければ、Mysqlを選ぶべきでは無いと思います。Postgresqlにすべきです。 前に書いたエントリーにも書きましたが、テーブルdtb_customerのbirthカラムがTimestamp型で設計されているため、ECサイトとして取得が必要な生年月日の保存に問題があります。 また、初期のindexなどが整備されていないため、Mysqlに聡い人でないと運用は難しいかもしれません。
大規模案件でMysqlのスペシャリストなどが入れば別ですが、立ち上げ時にそんな人材がアサインされているのは稀だと思います。
・課金方法の選定 これは案件規模によって要件は異なるでしょうが、クレジットカードやWEBMONEY、コンビニ決済などは代理店のモジュールなどを入れなければなりません。 事前に必要な課金方法については要件を詰める必要があります。 モジュールによって導入難易度が異なるので、見積にも工期にも大きく影響します。 また、一度サービスインしてから追加するのは一度サイトを停止しなければならず、非常に面倒だと思います。
・受注管理のメール配信について 自動メール通知のタイミングを案件によって重点的に確認すべきです。 注文確認メールなど、一部はEC-CUBEのシステムでデフォルトで出るようになっているのですが、出ないメール通知もあります。発送完了メール等は出ないです。 大きな範囲で言えば、クライアントがEC-CUBEのシステムによってワンストップでサービスを行おうとしているのか、そうでないのか事前に十分なヒアリングが必要です。
・会員規約他の入力制限 DB上の制約は別として、システム上のvalidateとして、入力制限が掛けられている箇所が幾つかあります。 具体的には会員規約の文字数が1000文字です。 今回の自分の案件では、クライアントが準備した会員規約文言が1000文字内に収まりませんでした。 事前に確認しないとサービスイン間近で余計な工数が発生します また、サイトで表示する項目の微妙な違いも事前に詰めて置く必要があります。
今回はこのへんで
