ヘッドレスコマースの解説を紐解くと、大抵の場合には「フロントエンドがECシステムのバックエンドと切り離されているため、 フロントエンドとバックエンドを個別に開発・利用することが出来る」等と書かれていることが多いかと思います。

今までのECサイトの基本構造

在来のECシステムは、バックエンドとUIを含むフロントエンドは、密接に連携、あるいは結合しており、原則として不可分のものとなっているケースが大半でした。

ECのフロント機能の大半は、専用のECのパックエンド機能で管理されることを前提としており、基本的にワンセットのものとして用意され、例えば有機的にECのフロントエンドを追加することはできない構造です。

ヘッドレスコマースで求められるECサイトの基本構造

一方ヘッドレスコマースを実現可能なシステムの場合には、このフロントエンドとバックエンドを1対1の関係とはせず、n対1の関係でも成立するように、分離したシステム構成となっています。

このような、ECとしてのシステム部分(例えば商品情報や購買などのコア的な処理機能)と、それらを表示するフロントエンドを切り離すことを前提としたシステム設計とし、実際にそれを実装することで初めてヘッドレスコマースは実現することが可能となります。

この特定のフロントエンドに依存せず、任意に複数のフロントエンドを用意し連携可能としていることこそが、ヘッドレスコマースで必要かつ必須の機能です。

ヘッドレスコマースを実現するためには、このようなシステム概念に基づき設計され、その仕組みに基づいて稼働することが担保されているシステムでなければなりません。

在来型のECパッケージではこの概念を実現しているものは少なく、見せかけだけのヘッドレスコマースを実施しているものなどもあります。 正しく、複数のフロントエンドに対して一つのバックエンドで管理を実現できるシステムを利用していかなければ、フロントエンドのバリエーションの数の分だけ、管理の手間が増える、という事にもつながりかねません。

なお、EC-ORANGEでは、2020年の大規模バージョンアップの際に、パッケージの基本構造、システム概念自体を一新し、ヘッドレスコマースに対応できるシステムとなっています。

開発・メンテナンスにも効果を生む

フロントエンドとバックエンドが分離した構造となることで、システムの維持メンテナンスにも大きな効果を生み出すことが出来るようになります。

在来型のシステム開発のプロセスであったとしても、開発工期を圧縮できる可能性が高く、パラレルで開発を行うことなども可能となります。

例えば、在来は

• ECシステムを開発した後にUIを実装

という順番を覆すことが難しかったのに対し、ヘッドレスコマースのようなフロントとバックエンドが分割された構造の場合には、

• フロントとバックエンドの並行開発

というアプローチも可能となります。

在来型のシステム開発のプロセスであったとしても、開発工期を圧縮できる可能性が高く、パラレルで開発を行うことなども可能となります。

そればかりか、例えばバックエンドは自社で開発し、フロントエンドはデザインに強い会社とタッグを組んで開発実行するなど、強みを生かしたチーム構成などにより、より専門性の高い、あるいは完成度の高いECシステムを作り上げることも可能となります。

また、これらのアプローチは初期開発だけではなく、保守運用管理においてもフロントとバックエンドを切り離すことにより多くのメリットを提供可能であり、最終的には保守コストの減少、必要スキルの最適化などを実現する事が可能となります。