国産でオープンソースなECサイト向けのカートツールであるEC-CUBEですが、いろいろと触っていて思うことが多いので、愚痴を書き連ねてみたいと思うのです。まぁ愚痴というくらいですからあまりポジティブな話ではないんですけどね...。
バグは結構多い
公式でも謳っているとおり『国内シェアNo.1』だそうですが、その割には随分とバグが多いなぁ、というのがカスタマイズ業務を行っていて思うことだったりします。特に私の場合は、レンタルサーバーに独自導入するスタイルが多いので、どうしても旧版(2・3系)のメンテナンスが主になり、現行版(4系)に比べると微妙にバグが放置されている感が否めません。
例えば消費税周り。今(2020～2021年)は軽減税率の適用がされていて、商品によって消費税が8%だったり10%だったりと選択をしなくてはいけないケースもあり、ユーザ(ECサイト運営側)からすればただでさえややこしいのに、切り上げだの切り捨てだのの設定もうまくいっておらず*1、税の実務上の問題も絡んでいたりして開発側もややこしいなぁ、と思いながら対応をしていたりします。
救いなのはEC-CUBEというプラットフォーム自体が『オープンソース』であること。コレ、大事なので2度言いました(1回目は1行目に言っていますよ)。フレームワークの違いはありますが、一貫してMVCモデルで作られているので、「理解していれば*2」メンテナンスも非常に簡単。基本的にはPHP(Model・Controller層)とHTMLやCSSの知識(View層)があれば大丈夫なので、最悪リリースまでに手処理でゴリゴリと直せますし、オープンソースだからこそ充実している開発コミュニティの存在も大きいです。なおしたければ知識のある人に聞けるしすでにノウハウも公開されていたりします。
「パートナー」の存在がUZAI...
EC-CUBEの日本国内におけるシェア拡大の大きな要因は「純国産であるからだ」、と結論付ける人たちは大変多いのですが、私はむしろ国産であるかどうかではなく*3、国内の「パートナー」と呼ばれる企業がこぞって参加をしているからではないかな、と思っています。本体の開発だけではなく、プラグインの開発も盛んで、(私の嫌いな)自社向けカスタマイズをプラグインで実装していく方法も考えられるほどプラグインの機能は多岐にわたります。
だから「パートナー」はEC-CUBEの陰の功労者くらいなイメージですし、彼ら無しでは技術的な知見も(簡単には)得られないわけですが、当然彼らもボランティアでやっているわけではなく、特にプラグイン等の開発を積極的に行っている「パートナー」だと、カスタマイズをさせるよりも自社で作ったプラグインの導入をさせて収益を得る方がよい、と考えている節もあったりはします。
詳細については触れませんが、とある機能のカスタマイズを考えていて開発者フォーラムを読み進めていくと、結局本体コードのカスタマイズをするとエラーになってしまい、よくよくカスタマイズをしている人に聞けば作りたい機能はプラグインで実装できるから自社のプラグインを導入すべきだ、と結論付けていました*4。そういう「パートナー」が、いかにも善意の第三者的な風で質問に答えていて、最後に売り込みかよ、という感じになってしまっているのはちょっといただけないかな、とは思っています*5。
バージョン間の差が大きい
これは今の私の現状ですが、2系と3系の2系統を並行してメンテナンスする必要があります。複数サイトを1企業が運営しているわけではなく、複数の企業のサイトメンテナンスをする関係でどうしても運用している系統が異なってしまうことに伴う問題点です。
2系は独自フレームワークを採用していて、View層ではSmartyというPHPテンプレートを使用しています*6。独自フレームワークもよくできていて、デフォルトで提供している機能(View/Controller)とは別に、カスタマイズ用の継承クラスもあらかじめ用意してあって、そこでゴリゴリ機能拡張をする、という「お膳立て」ができています*7。
3系以降になると、Symfonyフレームワークを採用していて、更にマイクロフレームワークとしてSilexを使い、ViewについてもSymfonyが提供しているTwig形式のテンプレートを使っており、2系とは異なる書き方にはなっているものの、これはこれで慣れてくるとメンテナンス楽だなぁ、と思っています。4系ではSilexがEOLとなったことからSymfonyオンリーとなっている、らしいのですがまともに触っていないのであまりよくわからないですごめんなさい。
おそらく3→4への移行は難しくないと思うのですが、2→3/4の移行は大変だろうな、と私自身考えています。ベースになっている技術の変更って、クライアントにとっては全く無関係なのでそのあたりの変更にびっくりするほど費用が掛かるということを「理解してもらえない*8」わけです。実際にはベースとなる機能が提供されているので機能追加されていた部分を移植する必要があり、更にView層であるテンプレートの書き方も変わるので移植にもそれなりの時間を要しますし、そう考えるとベースだけの変更、と言っても相当な負担になるので、サイト自体の大幅なリニューアルのタイミングでもない限りはベース変更の提案は難しいわけです。
今後のEC-CUBE「開発」に関して
時間がどれほど取れるのかわからないのですが、オープンソース開発に少し手を出そうかな、と思っています。パートナープログラムにも興味はあるのですが、むしろ本体の開発に対してコミットをしてみたいな、という、昔から考えていた「OSSへの貢献」をここで進めてみてもいいのかもしれないな、とは考えています。
また、プラグイン開発についても、今回スケジュールの都合もあってあまりいじっていないのですが、それでもプラグインの改造をしていたりするので、ノウハウも貯めつつチマチマと開発をしてみたいな、と考えています。
EC-CUBEと「マーケティング」
実は開発者としてだけではなく、『マーケオタク』という立場で考えてもEC-CUBEに関わっていくことはメリットがあるのかな、と思っています。いわゆるECサイトの構築は今後需要が増えていくことはオタクでなくとも想像ができますし、特に小規模のD2C系のECサイトの構築と販促の提案を合わせてできるという意味では、セルフマーケティングという目線で見てもなかなかいい売りにはなるはずですし*9、ECサイトの構築を看板に掲げるのはまさに今なのかな、と感じているわけです。
*1:3系ではこの件はバグとして認識はされていますが決定的な解決には至っていない模様です。
*2:MVCがなんであるか、ということの理解が少なくともできていれば、と言い換えてもいいでしょう。私自身もMVCの本質とかきちんと理解できているわけではないですし。
*3:実際には国産であることはきっかけに過ぎません。
*4:しかもそのプラグインが自社開発であることを触れていないので、世が世なら「ステマ」とでも言われていたのではないかと思われるほど自然に「あ、その機能だったらこのプラグインが必須ですよ」みたいな書き方でした。
*5:いや、実際に善意の第三者による回答なので問題もないですし、営業活動も必要ですのでやるべきではあるのですが。
*7:結局メインクラスに手を加えるケースも多いと思いますし、事実2系のメンテナンス業務は他社からの引継ぎ案件なのでかなりそのあたりがごちゃごちゃとしています。MVCが、というよりはオブジェクト指向の理解の問題なんですがまぁ難しいですよね(笑)。
*8:仮に理解をしたとしてもそれが利用する立場で負担すべきことではないと通常は認識をするはずなんです。導入時に「これがいいよね」とおススメされて買ったのに、「古くなっちゃったから新しいのでやらせてよ」とおねだりされた親がホイホイと新しいモノを買ってくれるとは思えないですわね。それと同じ。
*9:ただし、実際にはASP系の簡単ECサイト、例えばBASEやShopifyというところが競合になるので、ツールカスタマイズ要件が多いことをメリットとする必要はあるんですが...。
