見出し画像

オンラインショップをヘッドレスコマースでいい感じにした話

アメリカ発のD2CスタートアップRamen Heroが、どのようにしてオンラインショップをリニューアルしたのか、背景や経緯を含めて紹介します。


この記事について

以下のような方々にとって、少しはお役立ちできる内容になっているかと思います。

・D2Cサービス運営に関わる方
・オンラインショップ運営に関わる方
・Shopifyを利用している方
・(特に、スタートアップの)エンジニアの方


はじめに

こんにちは、Ramen Heroでリードソフトウェアエンジニアをやっているyuya(Twitter)です。

画像1

Ramen Heroは、サンフランシスコ ベイエリアを拠点とするフード系D2Cスタートアップです。

アメリカ全土(一部地域を除く)に本格的なラーメンを冷凍で配送しています。

Ramen Heroについての詳しい説明はこちらの記事を参照してください。

私達のオンラインショップは2020年の4月にブランドを刷新しリニューアルオープンしました。

それに際して、裏側の仕組みをモダンな構成で作り直しました。


Shopifyを使ったオンラインショップのメリット・デメリット

前提として、私達はShopifyをCMSとして利用してオンラインショップを構築しています。

まずリニューアルに当たり、今までのShopifyを利用したオンラインショップのメリット・デメリットを考えました。


👍 メリット1
CMSなのでオンラインショップに必要な機能がひと通り入っている

Shopifyには商品管理・顧客管理・注文管理といった機能に加えて、その他オンラインショップに必須の機能が含まれています。

一から全て作ろうとするとお金も労働力も相当必要になります。

🍜

👍  メリット2
様々な支払い方法に対応した、支払い画面が用意されている

セキュリティの観点から、支払い画面を自分たちで作ることは推奨されていません。

Shopifyの支払い画面のセキュリティが100%安全とは言い切れませんが、専門的な知識を持つ方々が作る画面を利用するべきです。

また、PayPalなどデバイスに合わせた他の決済手段も提供されていますので、顧客が住所やクレジットカード情報入力することなく購入することができます。

この機能は、情報入力の煩わしさを無くし、離脱を防ぐことができます。

画像2

🍜

😕 デメリット1
パフォーマンスの改善が難しい

Shopifyのシステムでレンダリングされたページは、顧客がページを訪れる度に、サーバーサイドでレンダリングして動的に公開されています。

そのためページの表示は、静的に用意されたページに比べて遅くなります。

さらに、プラグインの入れ過ぎによって読み込むファイルの数が増えて、ページの表示が遅くなります。

オンラインショップにとってページの読み込みスピードはとても重要です。有名な話だと、Amazonが100ミリ秒毎の遅延が売上の1%を犠牲にしているということを発見しています。

🍜

😕 デメリット2
一般的なウェブアプリケーション開発手法が通用しない

一般的に、ウェブアプリケーションのソースコードはGitHub(厳密にはGit)のようなバージョン管理システムによって管理されます。

そのことによって、変更箇所の差分を見つけたり、不具合があった場合に前のバージョンに戻すこともできます。

しかし、誰でもShopifyダッシュボード上でテンプレートを簡単に変更できてしまうので、変更箇所が見つけづらく、不具合も出やすいということになってしまいます。

また、プラグインをインストールした際に、勝手にコードを挿入されるのでソースコードを管理するのはほぼ不可能と言って良いでしょう。

*厳密に言うとShopifyはローカル上でテーマを編集することもできるTheme KitというCLIを公開しています。こちらを最初利用していたのですが、ダッシュボード上でソースコードを変更できてしまう以上、バージョン管理は、ほぼ不可能でした。

🍜

😕 デメリット3
プラグインのデザインを思うように変更できない

Shopifyに足りない機能はプラグインを導入する必要があります。

プラグインにデザインを柔軟に変更する設定があればいいのですが、多くのプラグインはデザインがロックされてしまいます。

このことはブランドのイメージにも大きく影響してきます。


Shopifyをヘッドレスコマースの一部として使う

前述したメリットを残しつつデメリットを取り除くために、Shopifyの強力なオンラインショップの機能をバックエンドとして利用しつつ、フロントエンドを独自に構築することを考えました。

つまりShopifyをヘッドレスコマースの一部のシステムとして利用するということです(ヘッドレスコマースについての詳しい説明はこちらの記事を参照してください)。

幸いなことにShopifyはShopify Storefront APIを提供しているので、このアーキテクチャを採用できることがわかりました。

画像5

上の図のように、フロントエンドを自分たちで作り、Shopify Storefront APIを利用することでShopifyのオンラインショップの機能を使います。

また、支払いページを自分たちで作るのはリスキーなので、Shopifyのページを利用します。


オンラインショップのフロントエンド

フロントエンドをShopifyから引き剥がすことによって、オンラインショップの表示速度を最大化させるフレームワークを採用することができます。

そこで、私達はSSG(Static Site Generation )をサポートしているNext.jsを選択しました。

Next.jsは最新のフロントエンドのベストプラクティスが詰まったフレームワークだと思います。

SSGによって全てのページが静的に公開されるので、前述したように表示速度が動的なページと比べて早くなります。

さらに、Next.js v9.5からISR(Incremental Static Regeneration)が正式にサポートされたので、静的でありながら、ほぼ動的に内容を更新することができます

これはオンラインショップの商品やブログの内容をコードのリリースなしに変更することを実現します。

そしてNext.jsを採用したもう一つの理由として、React.jsのコンポーネント指向を使いたかったということもあります。

なぜなら、オンラインショップの運用は、常に内容を変更して顧客のニーズに合わせる試みをする必要があります。

コンポーネント指向は、組み合わせや並び替えをするだけで、変更を素早く試すことができます。


オンラインショップのバックエンド

通常Shopifyにない機能は、プラグインをインストールして機能を追加します。

しかし、前述したようにデザインを思うように変更できなかったり、必要としている機能がない場合もあります。

そこで私達は、Shopifyがカバーしていない私達独自のビジネスロジックを対応するための機能を持ったバックエンドをAPIとして開発しました。

構成はServerlessフレームワークを利用したシンプルなものですが、プラグインのようにデザインをロックされることなく、柔軟に利用することができます。

例えば、私達は独自の郵便番号バリデーションロジックを持っているので、その機能のためのAPIのエンドポイントを作成しました。


最終的な構成

画像5

フロントエンドはNext.jsを使ってVercelによって配信されています。

VercelはGitHubと連携して変更のリリースもすることができます。

さらに、開発ブランチのプレビュー環境を自動的に作ってくれるなど、便利な機能が多数あります。

バックエンドは、Shopify StoreFront APIServerlessフレームワークを利用したAPIハイブリットな構成となっています。


まとめ

👉 ヘッドレスコマースを導入することによって、CMSの制限を取り払う可能性がある

オンラインショップを一から作ることは、莫大なお金や時間を必要とします。それ故に、CMSを使う必然性が出てきます。

しかし、CSMによって様々な制約を受けてしまうことも事実です。

パフォーマンス的な観点から、一つの選択肢としてヘッドレスコマースが解決策になる場合もあります。

🍜

👉 独自のビジネスロジックが絡む機能は、プラグインを使うのではなく、自前でAPIを作る

プラグインによって、様々な制約を受けてしまうこともあります。そして、多くのプラグインは有料です。

自前でAPIを作ることで、ビジネスロジックに最適な機能を作ることができます。

また、オンラインショップショップのリクエスト量は少ないので、AWS Lambdaのようなサーバレスアーキテクチャを用いることによって、ほぼ無料で使うことができる場合もあります。

さらにAPIとして実装することで、ウェブ上ではなく他の方法で商品を販売する時に、再利用できます。

例えば、モバイルアプリや、LINE上で注文できるチャットボットなどです。

🍜

👉 とにかく改善の効率性を考える

オンラインショップにおいて顧客のニーズに合わせて変更を試すことは重要です。

GitHub、Vercel、 Next.jsの様なモダンなテクノロジーを利用することは変更の効率性を高めることがあります。

その結果、オンラインショップを顧客に最適化し、コンバージョン率を高めることに繋がります。


さいごに

当初、私達はオンラインショップの全てをフルスクラッチで作ろうとしていました。

この方法は開発チームが小さいスタートアップには不向きでした。

なぜなら、スタートアップは何よりもスピードが求められ、時間もお金も人的リソースも足りませんでした。

エンジニアとして、全てを作りたいと思う気持ちはわかります。

しかし、会社やチームの状況からベストなシステムを構築することがスタートアップのエンジニアとしての必要な能力だと思います。

さらに、よくできている他のサービスをできるだけ利用してリソースを抑えることで、

変更のスピードが上がったことだけではなく、サービスの質を改善するという本質のことに集中することができました。

🍜

Ramen Heroでは、ヘッドレスコマースで作るオンラインショップに興味のあるエンジニアの方を募集しています。

また、個人的にヘッドレスコマースやオンラインショップ開発について相談を受け付けています。

上記の連絡は、個人のTwitterにダイレクトメッセージをお願いします。



この記事が気に入ったらサポートをしてみませんか?