https://zenn.dev/kazuki_tam/articles/3fac13ee435714
EC 市場が年々拡大していく中、最近ではヘッドレスコマースというワードを技術畑以外でも目にしたり、耳にすることが多くなってきました。私の体感的には 2019 年頃から技術者の間でヘッドレスコマースのアーキテクチャが話題となり、2020〜2022 年にかけて技術以外のレイヤーにも徐々に広まってきたように感じています。
この記事では最近ホットなヘッドレスコマースを理解する上で必要な基本知識と今後どのような方向性でヘッドレスコマースが採用されていくのかを解説・予想していきたいと思います。
できるだけファクトベースで語りたいと思っていますが、今後の展望など個人的な意見も含まれています。さまざまな主張があると思うので、「こういう見方もあるんじゃないか？」などあればぜひご教示ください。🙇🏻♂️
ヘッドレスコマースとは顧客接点（サイトの構成や見た目など）を司どるフロントエンドと EC のコアシステム（商品、顧客、在庫、決済など）を処理するバックエンドを分離した構築設計を指します。
ただ、フロントエンドとバックエンドを分離すると言われてもいまいちピンとこない方もいるかと思うので、これまで主流とされてきた構成とヘッドレス構成が具体的にどう違うのかを見ていきましょう。
モノリシックとヘッドレス比較
ヘッドレスコマースの概念を理解する上で重要になってくるのはカートシステムの責務です。 上の図で青の枠線はカートシステムが担う責任範囲を表しています。
左側が従来の一般的な EC カートシステムの構成になります。「モノリシック（一枚岩）」と呼ばれ、サイトの見た目を表現するデザイン（フロントエンド）とシステム（バックエンド）がカートシステムの責務に丸め込まれています。
一方で右側のヘッドレス構成ではフロントエンドがカートシステムの責務から分離され、間に API 領域が追加されています。結果としてカートシステムの責務でデザインを担保しなくなり、より提供する範囲が限定的になっていることが分かります。
カートシステムを使う側の立場からするとデザインとシステムが CMS でマルっと管理できるモノリシック構成の方が便利な気もします。
ではなぜカートシステムの責務を狭めるヘッドレス構成が注目を集めるのでしょうか？ これには結合度の概念が関係します。
プログラムの世界にはシステム同士の依存度合いを表す結合度という指標があります。この結合度が低い状態、つまり簡単に分離できる構造を疎結合と言います。 疎結合な構造にするとシステム同士の責務が明確になり、変更やテストをしやすくなります。そのため、多くの開発現場においてプログラムは疎結合であることが好まれます。
話をカートシステムに戻すとデザインとシステムが一括管理されているということは、疎結合の反対（密結合）であると捉えることができます。これはつまり、デザインとシステムが強い依存関係にあり、デザインとシステムそれぞれで独立した変更をカートシステムが容認しづらい状況にあると言えます。
リソース面においてもデザインとシステムが密結合になっていると以下図のように担当者のアサインや分業が難しくなります。
