EC 市場が年々拡大していく中、最近ではヘッドレスコマースというワードを技術畑以外でも目にしたり、耳にすることが多くなってきました。私の体感的には 2019 年頃から技術者の間でヘッドレスコマースのアーキテクチャが話題となり、2020〜2022 年にかけて技術以外のレイヤーにも徐々に広まってきたように感じています。
この記事では最近ホットなヘッドレスコマースを理解する上で必要な基本知識と今後どのような方向性でヘッドレスコマースが採用されていくのかを解説・予想していきたいと思います。
ヘッドレスコマースとは
ヘッドレスコマースとは顧客接点（サイトの構成や見た目など）を司どるフロントエンドと EC のコアシステム（商品、顧客、在庫、決済など）を処理するバックエンドを分離した構築設計を指します。
ただ、フロントエンドとバックエンドを分離すると言われてもいまいちピンとこない方もいるかと思うので、これまで主流とされてきた構成とヘッドレス構成が具体的にどう違うのかを見ていきましょう。
モノリシックとヘッドレス比較
ヘッドレスコマースの概念を理解する上で重要になってくるのはカートシステムの責務です。
上の図で青の枠線はカートシステムが担う責任範囲を表しています。
左側が従来の一般的な EC カートシステムの構成になります。「モノリシック（一枚岩）」と呼ばれ、サイトの見た目を表現するデザイン（フロントエンド）とシステム（バックエンド）がカートシステムの責務に丸め込まれています。
一方で右側のヘッドレス構成ではフロントエンドがカートシステムの責務から分離され、間に API 領域が追加されています。結果としてカートシステムの責務でデザインを担保しなくなり、より提供する範囲が限定的になっていることが分かります。
モノリシック（一枚岩）構成の課題
カートシステムを使う側の立場からするとデザインとシステムが CMS でマルっと管理できるモノリシック構成の方が便利な気もします。
ではなぜカートシステムの責務を狭めるヘッドレス構成が注目を集めるのでしょうか？
これには結合度の概念が関係します。
プログラムの世界にはシステム同士の依存度合いを表す結合度という指標があります。この結合度が低い状態、つまり簡単に分離できる構造を疎結合と言います。
疎結合な構造にするとシステム同士の責務が明確になり、変更やテストをしやすくなります。そのため、多くの開発現場においてプログラムは疎結合であることが好まれます。
話をカートシステムに戻すとデザインとシステムが一括管理されているということは、疎結合の反対（密結合）であると捉えることができます。これはつまり、デザインとシステムが強い依存関係にあり、デザインとシステムそれぞれで独立した変更をカートシステムが容認しづらい状況にあると言えます。
リソース面においてもデザインとシステムが密結合になっていると以下図のように担当者のアサインや分業が難しくなります。
従来のモノリシックな構成をとるカートシステムの経験がある方は「コンテンツをここに出したいだけなのにこんな大変なの？」という思いをしたことがあるのではないでしょうか？
リソースや予算を投下すれば解決するのはまだいい方で、ASP など元々デザインとシステムが密結合で制限の多いカートシステムでは仕様上実現できないなんてことも普通にあります。
ヘッドレス構成のメリット
ヘッドレスコマースはこれまでカートシステムが抱えてきた結合度の課題を、解消するソリューションになります。デザインとシステムが疎結合になるため、次のような恩恵を受けられます。
制作視点
- フロントエンドとバックエンドで分業がしやすい
- モダンな技術を導入しやすい
- 改修内容の反映をスピーディーに行える
運用者視点
- カートシステムの制約に縛られず、自由度の高い改修を行いやすい
- クリエイティブの内製化やスポットでのアウトソースがしやすい
- デザインのみ、システムのみといった対応のリプレイスがしやすい
- オムニチャネル対応がしやすい
- サイバー攻撃を受けにくい
ユーザーに提供できる価値
「制作視点」、「運用者視点」で得られるメリットを活用すると次のようなバリューをユーザーに提供できます。
- 安心で快適な購入体験
- 個々のライフスタイルに合った UI/UX
いくつかメリットを列挙しましたが、特筆すべきはやはり自由度の高さになるでしょう。
これまで自由度の高さを追求すると、どうしてもフルスクラッチやそれに近い形での構築が必要になっていました。
しかし、ヘッドレス構成の取れるカートシステムが出てきたことで、購入体験をフルスクラッチに近い形で提供しつつ、裏側のシステムは SaaS など既存のクラウドサービスをフル活用して構築することが可能になってきています。
ヘッドレス構成のデメリット
ヘッドレス構成の良さをこれまで語ってきましたが、もちろんメリットがあればデメリットもあります。
制作視点
- カートシステムがよしなにやってくれていた機能が使えない
- 高い技術力が求められる
運用者視点
- 初期構築コストがかなりかかる
- 内製体制が必要
ヘッドレス構成における最大の弱点はコストです。モノリシック構成は制限が多いものの、カートシステム側が開発コストを低減してくれていました。ヘッドレス構成ではそういったカートシステムがよしなにやってくれていた部分を別サービスで代替するか自作しなくてはなりません。
また、コードベースで管理する範囲が拡張されるため、少なくともフロントエンド領域の内製化はほぼ必須になるでしょう。
内製体制が取れない場合はモダンな技術を扱えるパートナー先と運用保守契約を結んで、柔軟な対応ができる環境を構築しておく必要があります。
逆にそういった環境を構築できないとヘッドレス構成を採用しているメリットが上手く得られません。その場合、今手を出すのはもう少し待った方がいいかもしれません。
ヘッドレスコマースがフィットするケース
これまでに述べたメリット・デメリットを読んで頂けた方は薄々気付いているかもしれませんが、ヘッドレスコマースは「銀の弾丸」ではありません。むしろ真価を発揮するシチュエーションをかなり選びます。
ヘッドレスコマースを採用する上で前提条件となるのは一定以上の構築予算とエンジニアリソースの確保です。初期コストは従来のモノリシック構成と比べ、どうしても高くなります。
以下いずれかで重要度の高い要求がある場合、採用の検討をしてみるといいでしょう。
- サイトの表示速度を圧倒的に良くしたい
- オムニチャネルでの販売を強化したい
- デザインや機能の改修を素早く行いたい
- UI/UX を自由に制御したい
- カートシステムやブログ CMS など用途に応じて裏側で利用するサービスを使い分けたい
逆にヘッドレス構成が合わないケースは上記要件の重要度が高くない場合です。
初期コストをできるだけ抑え、クイックに構築したいスタートアップや新規事業の立ち上げでは不向きと言えます。
ヘッドレスコマースが捉える未来
現時点（2022/10/28）においてヘッドレスコマースは EC の構築形態を覆すようなアーキテクチャではありません。大規模 EC における構築アプローチの 1 つといったイメージです。
ただ、もう少し先の未来をヘッドレスコマースの視点で捉えてみると見え方が変わってきます。
EC の顧客接点はチャット、音声、AR/VR といったように年々多様化しています。
今後はスマートグラスといったウェアラブル端末もリリースされていくでしょう。
そうなってくると EC のオムニチャネル化はより一層加速し、EC サイトを構築するだけのモノリシックな構成だけではいずれ限界を迎えます。私は遅かれ早かれヘッドレスがもたらした疎結合な構成はどこかのタイミングで主流になると考えています。
疎結合になったシステム同士をシームレスに繋ぐサービスや初期構築コストを軽減するソリューションはいずれ出てくると予想されます。
実際に Shopify からはヘッドレスコマースを想定した Hydrogen というストアフロント向けのフレームワークや Oxygen というコンテンツ配信のためのインフラ環境が発表されています。
Web アプリケーション開発で人気のフレームワーク Next.js からは Next.js Commerce というスターターテンプレートが公開されています。また、Vue Storefront といったヘッドレスコマースに特化したフロントエンドフレームワークも存在します。
さらに Instant Commerce といったヘッドレスコマースサイトをすばやく低コストでリリースするためのサードパーティサービスも出てきています。
以上のように現時点でもすでに前述の潜在的課題を解消しようという動きがあり、ヘッドレスコマースが EC アーキテクチャの本流に乗る前の過渡期にいるように感じます。
まとめ
では私たちはヘッドレスコマースがもたらす未来に対して、どういった準備をしておくといいでしょうか？
結論から言えば、ヘッドレスコマース対応を無理して急ぐ必要はないと思います。
実際、ヘッドレスコマースを採用すべきかどうかは前述したメリット・デメリットをしっかりと吟味した上で判断しましょう。
これから CMS やサービスを選定する場合は、あらかじめヘッドレス構成への対応有無をチェックしておくと将来的に身動きが取り易くなるかもしれません。無理のない範囲でリスクヘッジが取れる状況を作っておくのが良いでしょう。
今回の記事を通して、EC 構築に少しでも興味を持っていただれば幸いです。
Discussion