ヘッドレスコマース~多様で複雑な顧客動線に対応させる新常識~
ヘッドレスコマースというワードがEC界隈でトレンドになっています。今やECは自社サイトや各モールだけでなく、クローズドサイトやBtoBサイト、そのPCやスマホ、さらにはスマートスピーカーやVR・AR対応などもあり、多数かつ複雑化しています。それに対応するため、フロントシステムとバックシステムを分離して、柔軟性を持たせたECサイトのシステム構成のことを指しています。
増え続ける対応範囲と複雑化する顧客動線
2000年初頭は、ランディングページをつくってメルマガを配信すればある程度売上が立つ時代でしたが、だんだんとGoogleの検索対策やリスティング広告、ディスプレイ広告などに対応する必要が出てきて、FacebookやTwitter、YouTubeやInstagramなどのSNSが登場すると、それにも対応せざるを得なくなってきました。
テレビや動画配信を見ながらスマホで検索というのはもちろん、リアルのお店でもスマホで撮影してレビューを見る、LINEで相談するということも今や当たり前になりました。
システムとしてはこのようなリアルとネットのハイブリッド連携が必須になってきて、フロント側の拡張は広く深くなっていきます。当然、タッチポイントが増えれば増えるほどお客様のカスタマージャーニーは複雑化しますので、それに対応した仕組みづくり=システム化をしていかなければ生き残っていくことが難しくなっています。
ヘッドレスコマースの考え方で、ECサイトのフロントエンドをバックエンドから分離することで、フロント側のユーザーエクスペリエンスの改善がしやすいという大きなメリットが出てきます。これを実現するために、API(Application Programming Interface)を使ってフロントとバックを連携していきます。これがヘッドレスコマースを実現する大きな鍵になっています。API連携で受発注のECに必要な情報をフロントからバックに送ることで、フロントを自由に変更することができるようになります(01)。
マイクロサービスアーキテクチャ
API連携で徐々にシステムをつくっていくことは「マイクロサービスアーキテクチャ」という考えで、2011年頃から提唱されてきていました。小さなシステムモジュールを組み合わせて開発していくイメージで、つくったシステムは「柔軟性がある」という大きなメリットがあります。どんどん広がって深くなっていく、しかもスピードの速いEC業界にはぴったりな考え方と言えます。
しかし、マイクロサービスアーキテクチャの欠点の一つとして、システムの変更に伴うシステム間を結ぶAPIの仕様が変わってしまった場合に、大きな影響があることが多々あります。APIの仕様自体は通常は変わらないことが前提なのですが、実際には時代にあわせてAPIの仕様自体も変わってしまうのです。このため、仕様にあわせて変更しなければいけません。この変更によってシステム全体のスピードが落ちてしまったり、セキュリティが弱くなってしまうこともあるのです。API連携は通常1本や2本ではなく、受注や在庫連携、決済や配送など多い時には10本以上あることもあります。この仕様について書類化(ドキュメント化)を行っていないと、後から加わったスタッフにはまったくよくわからない状態になることも非常に多いのです。
ヘッドレスコマースのメリット・デメリット
とは言っても、ヘッドレスコマースの考えを持っていないと、とてもついていけない状態になっていることは間違いありません。テクノロジーが発展してお客様がそれに慣れてしまった場合には、そのテクノロジーについていくことは必須なのです。
ヘッドレスコマースはこの柔軟性にあったシステムになります。柔軟なUX改善施策をスピーディに実行できることや多様な流通チャネルを効率的に追加でき、OMOやオムニチャネルと相性がいいことが挙げられます。デメリットとしては、システム全体の再構築には時間と費用がかかってしまうことやAPI連携をはじめとした専門的な知識が不可欠でエンジニアだけでなく、リーダークラスにも知識が必要になっています。しかし、ヘッドレスコマースという考え方は、今後もどんどん進化するECの潮流や技術に柔軟に対応できるため、今後もこの方向になるのは間違いありません(02)。
ただし、ヘッドレスコマースでAPI連携を今後進めて行く上で、ひとつの大きな注意点があります。それはセキュリティです。APIはデータベースに穴をあけることになります。このため、API連携はセキュリティについて運用も含めて仕組みをつくる必要があります。また、API連携をメインとしながらも何かあった時のためにCSV連携をバックアップとして運用できるようにしておくとさらによいでしょう。
Text:川連一豊