優れているのに普及していない。
理由は同じです。
10年以上CS-Cartを触ってきた立場から、正直に書きます。都合の悪い部分も含めて。
結論から
CS-Cartは、制約を製品ではなく人間に預けています。
だからほぼ何でも実装できるし、だから簡単に壊れます。長く使えるCS-Cartサイトと、手を入れられなくなったCS-Cartサイトを分けるのは、プラットフォームではありません。触った人間の規律です。
以下に挙げる長所も短所も、すべてこの1点から出てきます。
CS-Cartが優れている点
EC運営に必要な機能が、最初からほぼ揃っている
他のプラットフォームなら最初の1年をかけて足していくような機能が、標準で一通り入っています。最小限のコアに基本機能を買い足していく作り方ではありません。
要件を、回避策ではなくロジカルに実装できる
実務で一番効いてくる差はここです。Shopifyと比べると分かりやすくなります。
SaaSでは、変わった要件は大抵3つのどれかに着地します。やりたいことに近い動きをするアプリを入れるか、想定されていない使い方でハック的に無理やり通すか、「それはできません」とクライアントに伝えるか。
CS-Cartでは、要件は要件のまま実装できます。ロジックはあるべき場所に置かれ、依頼されたとおりに動き、「どの回避策で成り立っているか」を誰も覚えておく必要がありません。
価値は「CS-Cartのほうが多機能」ということではありません。プラットフォームと交渉する時間ではなく、ビジネスが求めたものを作る時間に使えるということです。
自分のものである
自社サーバーで動くオープンソースなので、ストアが何になれるかをプラットフォーム側が決めることはありません。これは次の章のとおり諸刃でもありますが、要件が本当に固有である場合、そもそもの実現可能性を左右します。
それでも普及していない理由
ここを濁すつもりはありません。理由は実在しますし、どれも製品の品質とは関係のないところにあります。
ドキュメントが薄い
プラットフォームの実力に対して、明らかに足りていません。実務上の帰結として、特にテーマ構築とカスタマイズの初手で、後になるまで誰も指摘してくれない間違いが起きます。その結果は日常的に目にします。
機能が多く、使いこなすのが難しい
網羅性の高さが、そのまま難しさになっています。機能は豊富にありますが、ある目的に対してどの仕組みを使うべきなのかは、管理画面を見ても分かりません。
利用者が少なく、検索で解決できない
WordPressやShopifyであれば、詰まったことは大抵誰かが書き残しています。CS-Cartでは、書かれていないことがよくあります。実装例やハックが本当に見つからないため、知識が記事ではなく人に溜まります。
インフラがついて回る
自社サーバーで動く以上、SaaSが黙って引き受けてくれていたものを自分で持つことになります。セキュリティ、環境構築、そしてバージョンアップという継続的な保守です。多くのチームにとって、プラットフォームの出来とは無関係に、ここでCS-Cartが選択肢から外れます。
いま挙げた4つを、もう一度見てください。
ドキュメントが薄い。使いこなしが難しい。検索しても出てこない。インフラを持つ必要がある。どれもソフトウェアの欠陥ではありません。全部が同じことを言っています。CS-Cartは、分かっている人がそこにいることを前提にしているということです。
Shopifyはその人を不要にすることで普及しました。CS-Cartはそうしませんでした。それだけの話で、これが本当に良い製品が普及しない理由です。
引き継いだCS-Cartサイトで、高確率で見つかるもの
他社が構築したCS-Cartサイトを引き継ぐとき、まず探すパターンがあります。現れ方は3通りです。
- コアファイルが直接書き換えられている。オープンソースなので、止めるものが何もありません。
- 親テーマが直接カスタマイズされている。アップデートに耐える形になっていない。
- 既存パーツをCSSだけで無理やり整えている。コードレベルで正しく実装せず、色やレイアウトを上から当てている。
3つとも同じ間違いです。拡張すべきところを、上書きしている。
厄介なのは、単に雑だからではありません。3つとも、やった日は完璧に動きます。見た目は整い、クライアントは満足し、請求も通り、数ヶ月は何も問題が起きません。
請求書が届くのはバージョンアップの時です。コアや親テーマに上書きされたカスタマイズは消え、本来なら定型作業であるはずのメンテナンスが、予定外の復旧作業に変わります。何がどう変更されていたのか、なぜそうしたのかを調べるところからです。CSSだけの対応は消えませんが、下のマークアップが動かない前提で書かれているため、別の壊れ方をします。
結果として、初期費用を抑えて作られたサイトが、安全にアップデートできないサイトになります。そして大抵、アップデートされないまま放置されます。自社で所有しているはずのプラットフォーム上で、何年も前のバージョンに取り残される。
これはプラットフォームのせいでも、構築した人が愚かだったからでもありません。ドキュメントの薄さのツケが、後から回収されているだけです。正しい拡張の口はちゃんと用意されています。ただ、それが分かりやすい場所になく、検索しても正解に導いてくれる記事がないというだけで。
引き継いだCS-Cartサイトが、このどれに当たるか分からない。そういう状態であれば、次のバージョンアップの最中ではなく、その前に確認しておく価値があります。ご相談ください。
それでも私がCS-Cartを選ぶ理由
ここまで書いてきたことは、要するにCS-Cartは難しい、という話です。実際そのとおりです。それでも10年以上使ってきましたし、ビジネスに何が許されるかを勝手に決めてくるプラットフォームで作業するよりは、こちらのほうがいいと思っています。
コストは実在しますが、そのすべてが同じもので支払えます。プラットフォームをきちんと理解している人間がいることです。知識がその場にあれば、ドキュメントの薄さは問題になりません。誰かが責任を持てば、インフラは怖いものではなくなります。カスタマイズが生き残る形で書かれていれば、バージョンアップは「事件」ではなくなります。
正直なところをまとめると、CS-Cartは非常に良い製品で、ただ一つ変わった条件がついている、ということです。人が要る。私は長いことその人でいることを選んできましたし、この仕事は代わりのものより面白いと思っています。
CS-Cartを使うべきか
正直に言えば、場合によります。これより速く答えが返ってきたら、その相手を疑ったほうがいいと思います。
おそらく向いていない場合
- 公開後、プラットフォームを継続的に見る人がいない
- 要件がSaaSの標準機能の範囲に収まっている
- サーバー、セキュリティ、バージョンアップを自分で持ちたくない
検討する価値がある場合
- 要件が、いまのプラットフォームで変更できない部分に何度もぶつかっている
- 本当にやりたかったことに近づけるため、アプリや回避策が積み上がっている
- 運用が固有で、「だいたい合っている」で済ませると実際に損失が出る
- プラットフォームを借りるのではなく、所有したい
* すでにCS-Cartをお使いの場合、問うべきは使うかどうかではありません。いま立っているものが、次のバージョンアップを越えられるかどうかです。
よくあるご質問
CS-CartとShopify、どちらが優れていますか？
一般論としてどちらが上ということはありません。Shopifyは変更できる範囲を限定することで開発者を不要にしました。CS-Cartは制限を設けない代わりに、分かっている人がいることを前提にしています。
プラットフォームを継続的に見る人がいないのであれば、Shopifyのほうが安全です。要件がSaaSの制約に何度もぶつかっているのであれば、CS-Cartなら回避策ではなく要件そのものを実装できます。
CS-Cartがあまり普及していないのはなぜですか？
理由は3つあり、いずれも製品の品質とは関係ありません。ドキュメントが薄いため初手で間違いが起きること。利用者が少なく、詰まったときに実装例が見つからないこと。そして自社サーバー運用ゆえに、セキュリティ・環境構築・バージョンアップの保守がついて回ること。
これらのコストは実在します。そして、サイトを保守する人が負担します。
CS-Cartサイトで最も多い間違いは何ですか？
拡張せずに上書きしてしまうことです。コアファイルの直接変更、親テーマの直接カスタマイズ、既存パーツをCSSだけで無理やり整えること。
3つとも作業した日は動きます。そして3つともバージョンアップで破綻します。
新規ECをCS-Cartで構築することを勧めていますか？
無条件には勧めません。適切なプラットフォームは、要件と、構築後に誰が保守するかによって変わります。このページは乗り換えを勧めるものではなく、CS-Cartの実像を書いたものです。
他社が構築したCS-Cartサイトでも対応できますか？
はい、それが仕事の大きな部分を占めています。引き継ぎ案件でまず行うのは、何がどう変更されているのか、どこまで安全に触れるのかを把握することです。
CS-Cartのことで、聞ける相手がいない
引き継いだサイトの状態が分からない、先延ばしにしているバージョンアップがある、「できません」と言われた要件がある。どれもお気軽にご相談ください。