エンジニアがいる組織でローコードECの実現を考える

これはなに？

私が所属する株式会社エイチームコマーステックでShopifyをバックエンドとしたヘッドレスコマースの実現を検討した際の顛末を記した記事です。

TL;DR

• 「Shopifyを使ったヘッドレスコマース化」 と 「Obremoで実現したいこと」 の両立が難しいと判断して辞める決断をしたのが事実です。
• Shopifyというツール自体は非常に優秀で、 シンプルな売り方をする前提において 爆速で高品質なストアを構築できます。
• Shopifyを利用する場合の注意点
  • Shopify自体が提供する機能は少なく、 Shopifyアプリを使うのが前提 になります。
    • また、2022年8月現在、ShopifyがShopifyアプリ自体や開発ベンダーに対して責任を持たない契約になっています。
    • 開発ベンダーとの個社ごとの契約に少なからずリスクがあることを承知で利用する必要があります。
  • ニッチな売り方ほどShopifyアプリも含め機能の提供が遅れるので、Shopifyアプリ内製の覚悟が必要です。

Shopifyとは？

端的に言うと ECサイトプラットフォーム です。

ECサイトに必要な最低限の機能をひと通り提供していて、エンジニアがいなくてもストアを簡単に構築できます。
サイトのデザインと商品、ストアポリシー(特定商取引法に基づく表記などの法的な文章)が揃っていれば、ノーコードでECサイトが立ち上がります。
日本ではBASEなどの競合にあたる、越境ECに強みを持つカナダ発のサービスです。

なぜShopifyを試したのか？

厳密には 「Shopifyの提供するGraphQL APIを使ったヘッドレスコマース化が実現できないか？」 を試しました。

エイチームコマーステックの社長とリードエンジニアが、技術の今後を話す会で以下のような話をしたのが、この取り組みのきっかけです。

• カート・チェックアウト・決済機能などECに最低限必要な機能には、ここ数年大きな進化が見られず、実装の難易度に対して得られるものが小さい。
• 一方で、エンジニアがいないお店がECサイトを構築して成功する事例も増えている。
• 我々は社内にエンジニアがいることで、 フルスクラッチで開発しなければならないという制約 を抱えてしまっているのではないか。
• デファクトスタンダードになりつつあるShopifyのようなECプラットフォームを利用してECサイトを構築できるようになれば、 社内のエンジニアがより生産的な活動に時間を割けるかもしれない！！
• ShopifyはGraphQLエンドポイントを提供しているので、ヘッドレスコマースが実現できそう！！

なぜ、数あるECプラットフォームからShopifyを選択したのか？

以下の3点が主な選定理由です。

• シェアの高さから多くの企業のニーズを満たしている可能性が高い
• Shopify自体がGraphQLエンドポイントを提供しており、ヘッドレスコマース化の実現可能性が高い
• ベンダーが提供するShopifyアプリの多さや、Shopifyアプリを内製できる点からカスタマイズ性が高い

検証結果

Shopifyの開発ストアで1ヵ月程度検証した結果を以下にまとめます。

選定理由に対する振り返り

• シェアの高さから多くの企業のニーズを満たしている可能性が高い
  • ただし、ニーズが低い機能の実装は優先度が低く、サブスクなど比較的新しい売り方への対応は十分でない傾向にあると感じました。
  • Shopifyアプリを内製できるので、不足している機能を内製で補う選択肢はもちろんあります。
• Shopify自体がGraphQLエンドポイントを提供しており、ヘッドレスコマース化の実現可能性が高い
  • 事前情報通りGraphQLエンドポイントは提供されていました
  • ただし、サブスクリプション関連のAPIは公開アプリの製作者にのみ提供されていて、小さく試すにはハードルが高い内容でした。
• ベンダーが提供するShopifyアプリの多さや、Shopifyアプリを内製できる点からカスタマイズ性が高い
  • Shopifyアプリは確かに多かったのですが、国産アプリの選択肢は少なく、海外製アプリは日本語対応していないものが多いのが実態でした。
  • Shopifyアプリは確かに内製できますが、Obremoで実現したい販売方法を実現するには、サブスクリプションを起点にかなり広範囲な機能を実装する必要がありました。
    • カスタマイズ性が高くて便利というよりはカスタマイズしないと使えないというイメージで、保守・運用に掛かるコストが大きく、フルスクラッチで開発するのと同等以上のコストがかかりそうと判断

Pros(長所)

• 最低限のストアを構成する要素がシンプルで、短時間でストア開設できる。
  • 少なくともデフォルトのテーマをそのまま使う前提であれば、エンジニアがいなくても1日程度でストア開設できる。
• カート・チェックアウト・決済・CRMの部分の実装が不要、あるいは少工数で実現可能。
  • 最低限の機能はShopifyの基本機能として実装されている。
  • 不足している機能についてもZendeskやSalesforceといった有名どころのツールと連携するShopifyアプリが存在する。
• ディスカウント機能もクーポンやタイムセールなど、柔軟に設定できる。
  • サブスクリプションの初回限定の割引や段階的な値引きもこの仕組みを使ってワンタイムクーポンを発行する仕組みになっている。
• インフラの管理が不要になる。
  • Shopify側でインフラを管理してくれるため、当社側にサーバリソースは発生しない。
    • Shopify Plusにしないとキャパシティが保証されない点は注意が必要。
• かご落ちのフォローが簡単に実現できる。
  • かご落ち後、10分後にメールで未購入の商品があることを連絡する等の設定が可能。
• お客様の名寄せが自動的に行われる。
  • メールアドレスや電話番号など、お客様のログインIDに相当する情報を利用した名寄せが自動的に行われる。
  • ノーカスタマイズでも、お客様単位で注文履歴を遡れるのもCS対応上助かる。
• 需要が高い機能のアプリは充実している。
  • 単純なサブスクリプション
  • アップセル＆クロスセル
  • 診断コンテンツ
• 管理画面が充実していて、商品管理・顧客管理に必要な機能を追加実装する必要がない。
• POSシステムと連携や、リアル店舗での取り置きなどに対応しており、オフライン販売との連携が容易である。

Cons(短所)

• 顧客体験の作り込みに注力できない。
  • 内製部分のデータとShopify側のデータのつなぎこみがコアな部分で発生すると、技術的に無理やり対応させることになる。
• 複数アプリを連携させる場合に、相性が悪いものが存在する。
  • つなぎこみが想定されていないアプリを利用した場合、片方のアップデートでもう片方が使えなくなるリスクも気にする必要がある。
• GraphQL APIの提供範囲に一部制約がある。
  • Subscription APIはShopifyアプリ提供ベンダーに限定して公開されている。
    • サブスクリプション用の公開アプリを内製する選択肢もあったが、最初から開発規模を大きくしてしまうと撤退のハードルも上がってしまう懸念があった。
    • また、内製したとして既存のアプリ相当か上回るアプリを実現するのは、このフェーズで払う開発コストとして大きすぎた。
  • 定期購買アプリ経由で使えるAPIもあるが、現時点では機能不足感が否めない。
  • Shopifyアプリのベンダーになる選択肢もあるがヘッドレスコマース化の要件に含まれる簡単に捨てるという選択肢が取りづらくなる。
    • 他社が利用を始めてしまうとそちらのサポートも増える可能性があり、予期しない工数が発生してしまう。
• セット品の在庫管理の実装がない。
  • Obremoでは1回の注文単位を2袋としており、1点購入されると2個在庫が減るといった仕組みを実現する必要がある。
  • これを実現するのがセット品の概念だが、Shopifyの標準機能にこれがない。
  • 厳密にはバンドル販売用のアプリで対応可能だが、サブスクリプションアプリとバンドル販売アプリの相性が悪い。
  • 在庫管理を外部システムの機能として切り出して、Shopify側では予約購入扱いとすればサブスクリプション×バンドル販売という組み合わせも実現できたが、欠品を起こすとObremoブランドの毀損につながるため、選択肢から除外した。
    • ペットフードのサブスクリプションなので、予定通りに届かないとペットのご飯がない状態が発生するので在庫切れでお届けできないことは絶対NG。
    • 既存のお客様には安定供給をする必要があるので、在庫の残量を考慮して在庫を切らさない販売を実現する必要がある。
• Shopifyアプリの提供者とは個別契約になる。
  • 取引審査や契約回覧の数が膨大になって、事業部だけでなく法務への負担も高かった。
• 多頭飼いの実現ハードルが高かった。
  • 近年、2頭以上を飼育する多頭飼いをされる飼い主が増えているため、多頭飼い対応が必須。
  • サブスクリプションアプリの機能に、○○ちゃんのフードのように注文とペットを対応付けられる機能がない。
    • Shopifyの他の通常の注文にはタグ付けが可能だが、サブスクリプションアプリにはタグを付与する機能がないので、多頭飼いを表現することが難しい。
• 標準的から外れた実装を追加するたびに特別なカスタマイズが必要になる。
  • 現状課題に挙がっているサブスクリプション×バンドル販売や多頭飼いの機能を実装だけを考えても、アプリで対応できず、オリジナルの機能実装が必要になる。
  • これを繰り返すと複雑な仕組みが出来上がってしまうので、ヘッドレスコマース化で実現したかったエンジニアの生産活動に充てる時間を増やすという目的が実現できなくなる。
• 発注管理の機能不足している。
  • 発注情報を管理する仕組みはあるが仕入額の設定ができないので、原価を管理できない。
    • 発注管理と在庫管理をセットでアウトソースするか、内製するかしないと棚卸資産を報告するときに困る。
  • 在庫管理用のSaaSを用意する等で対応は可能なのでインパクトは小さい。

どうなればShopifyは使えるか？

• シンプルなサブスクリプションモデルやサブスクリプション以外の販売方法で困るケースはさほど多くなさそうです。
• つまり、サブスクリプションと他の販売手法(×バンドル販売、×クロスセルなど)を実現するアプリが登場するか、Subscription APIが標準公開されるなどすれば、Shopifyで弊社のサービスを展開するといったことも可能になる可能性があります。

最後に

今回のプロジェクトを通して、世の中のECを席巻するShopifyの凄さを実感することができましたというのが正直な感想です。
エンジニアがいるから常にフルスクラッチで開発すべきという固定観念を捨てて取り組んだからこそ、競争相手になる企業の武器が知れたという点でとても有意義でした。
今のShopifyの苦手もしばらくすると苦手ではなくなる可能性があるので、Shopifyの成長を定期的にチェックしつつ、エンジニアを抱えるEC企業の強みをどう発揮していくか考えたいと思います。