ヘッドレスコマースを知る

学習の目的

この単元を完了すると、次のことができるようになります。

• ヘッドレスコマースを定義する。
  
• ヘッドレスなアプローチと従来のアプローチの違いを説明する。
  
• ヘッドレスなアプローチを使用する利点を 3 つ挙げる。
  

はじめに

Vijay Lahiri は高級なカスタムスニーカーを扱う Cloud Kicks 社の上級開発者です。彼は、ヘッドレスコマースという新しいアーキテクチャ設計アプローチのことを耳にしました。これは、E コマースサイトのショッピング体験レイヤーをコマースサービスから切り離すものです。

急速に成長している彼の会社では、E コマースの変化やイノベーションの加速に対応するために多くの新しい開発者を採用しています。コネクテッドな世界がますます進む中で、チームが幅広いタッチポイントで Cloud Kicks の買い物客にパーソナライズされた体験を迅速に提供するためにヘッドレスなアプローチが役立つのではないかと彼は考えています。

従来のコマースアプローチ

Cloud Kicks のような多くの企業は従来のコマースプラットフォームとアプローチを使用していて、密結合された複雑なソフトウェアがモノリシックなシステム上に置かれています。機能を変更するには、データベースを編集し、システムコードを更新し、フロントエンドプラットフォームをカスタマイズする必要があります。1 つのカスタマイズを行うために、Vijay とチームはフロントエンドからバックエンドまで複数のレイヤーのコードを編集することがよくあります。変更が複数の領域に影響するため、テストとトラブルシューティングにも長い時間がかかります。変更の内容によっては、サポート契約の保証が無効になったり、それ以降のアップグレードができなくなったりすることもあります。

開発チームは日々の業務や変化し続ける優先事項に忙殺されて、イノベーションが忘れ去られがちです。開発チームの人数が増えているのは言うまでもなく、Cloud Kicks のストアフロントアプリケーションには多くのカスタマイズ機能があり、コードにも無制限でアクセスできますが、設計によってコンテンツは Web サイトまたはモバイルアプリケーションでしか提供できません。Cloud Kicks のマーケティングチームはできるだけ早く他のデバイスにもサービスを拡張することを望んでいます。

Salesforce B2C Commerce

Cloud Kicks はすでに B2C Commerce を使用しています。B2C Commerce は、完全にクラウドでホストされるサービスとしてのソフトウェア (SaaS) プラットフォームです。従来 Cloud Kicks のような企業が多くの時間、労力、費用を費やしてきたデータベースのメンテナンス、セキュリティのパッチ適用、その他のインフラストラクチャと運用に関する作業はすべて Salesforce が管理します。Salesforce は年に何度も B2C Commerce をシームレスに更新するため、Einstein 人工知能 (AI) や Page Designer (ドラッグアンドドロップの宣言型エディター) のようなイノベーションがすぐに利用可能になります。Salesforce は柔軟性の高いリファレンスアーキテクチャを提供していますが、それでも変更はバックエンドとフロントエンドに影響します。Cloud Kicks がヘッドレスアーキテクチャに移行すれば、柔軟性がさらに高まります。

Vijay のような開発者は B2C Commerce に含まれる開発者ツールを使用してさまざまなカスタマーエクスペリエンスを作成できます。Vijay は「Salesforce B2C Commerce の開発」トレイルでツールのことを詳しく学習しました。RESTful API などのツールによって、Vijay がヘッドレスアーキテクチャを使用して体験を開発するのに必要なすべてのものが揃います。ツールを詳しく見ていく前に、ヘッドレスコマースについて確認しておきましょう。

ヘッドレスコマースとは?

ヘッドレスコマースとは、コンテンツ (商品、価格、テキスト、グラフィック) が保存、配信される場所で、フロントエンドレイヤーがありません。フロントエンド (ヘッド) はバックエンドから切り離され、API が橋渡しをして、商品、ブログ記事、お客様レビューなどのコンテンツを任意の画面やデバイスに配信します。フロントエンドの開発者は各自のビジネス要件に最適なフレームワークを使用して、適切なコンテンツを表示します。

E コマースサイトのフロントエンドとはショッピング体験のことです。これには、商品の詳細、グラフィック、プロモーションコンテンツなど、ストアフロントに表示されるすべてのものが含まれます。バックエンドとはショッピング体験によって生じるビジネスプロセス、それを支えるコマースサービス、その基盤となるデータ (検索、プロモーション、価格設定、在庫、チェックアウトなど) のことです。

たとえば、ある買い物客が特定の商品を購入し、それによってプロモーションがトリガーされるとします。買い物客がサイズ、色、価格によって商品を選択すると (フロントエンド)、ビジネスプロセスが対象となるプロモーションを特定し (バックエンドと API)、その情報を買い物客のデバイスに表示します (フロントエンド)。

フロントエンドとバックエンドは独立して機能するため、一方に変更があっても、もう一方は変更する必要がありません。

ヘッドレスを使用する理由

ヘッドレスコマースアーキテクチャでは、API によってフロントエンドとバックエンドの橋渡しを行い、バックエンドデータモデルやクラウドベースのインフラストラクチャを利用します。このモデルを使用すれば、Vijay や Web 開発者は任意のフロントエンドツールを使用して、カスタマイズされたコンテンツ、商品、支払ゲートウェイをアプリケーション (スマートウォッチ、キオスク画面、Alexa スキルなど) に導入できます。

ヘッドレスコマースを実装するには多くの方法がありますが、Vijay がヘッドレスコマースを実装したいと思う理由もたくさんあります。

より迅速な影響

ヘッドレスを導入すると、ストアフロントのデザインの更新や買い物客のチェックアウトまたはアカウント管理の体験の改善といったフロントエンドの変更に要する時間を大幅に短縮できます。ヘッドレスアーキテクチャでは、Cloud Kicks が変更をフロントエンドに転送すると、更新がほぼ瞬時に反映されます。API インテグレーションのおかげで、フロントエンドのイノベーションはバックエンドとは無関係です。一方、従来のコマースアーキテクチャで構築されたサイトでは、変更は公開プロセスにゆっくりと波及してから、すべての買い物客が最新のデザインを使用できるようになります。レプリケーションとテストが何度も反復されることで、大幅なスピードダウンになります。

シームレスな表示

ヘッドレスの場合は、マーチャントは買い物客が操作する要素を簡単に管理でき、マーケティングチームは公開するコンテンツに関して創造性を発揮できます。また、ヘッドレスコマースには普遍的な互換性があるため、Web サイトはすべてのデバイスや表示形式でシームレスに意図したとおりに動作します。一方、従来の E コマース Web サイトのマネージャーは、さまざまなデバイスで要素が表示されなかったり正しく表示されなかったりするリスクを最小限に抑えるために、レスポンシブデザインなどの手法を使用する必要があります。そのために、従来のコマースアーキテクチャを使用する開発者のテスト作業がもう 1 つ増えることになります。

ショッピング体験をパーソナライズする

ヘッドレスコマースでは、Cloud Kicks のようなマーチャントはデータを取得してカスタマージャーニー全体を統合できます。買い物客がどのチャネルを使用しても、バックエンドシステムによってその人を認識することができます。このデータを完全に把握できることで、ストアフロントアプリケーションではストアフロントからサードパーティのフロントエンドアプリケーションまで広範囲に人工知能 (AI) 機能を使用してショッピング体験をパーソナライズできます。ヘッドレスコマースを使用することでマーチャントはさまざまなタッチポイントでデータを提示する別の方法を見つけることができます。

RESTful API とは?

ヘッドレスコマースでは RESTful API を使用してクラウドサービスに接続し、やり取りを行うことができます。RESTful API は Hypertext Transfer Protocol (HTTP) を使用して要求を実行し、応答を受信する機能セットです。HTTP では GET や POST などの標準化された要求メソッドが定義されています。

そのため、任意のプログラム言語が HTTP を使用できるという利点があります。さらに、REST テクノロジーで通信に使用する帯域幅は Simple Object Access Protocol (SOAP) テクノロジーよりも小さいため、インターネットにより適しています。RESTful API は Amazon、Google、LinkedIn、Twitter などのサイトですでに使用されています。

RESTful API はステートレスであるため、クライアントとサーバー (この場合はフロントエンドとバックエンド) は互いに独立している必要があります。どちらも任意の言語でコーディングできるため、メンテナンス性が高く、進化も容易です。RESTful API はヘッドレスコマースアーキテクチャの多くのオプションの 1 つです。

汎用性が高いですね。

Vijay はフロントエンドで複数のデバイス用のカスタムチェックアウトフローを実装し、同じ RESTful API を使用してバックエンドと通信できます。これは、ヘッドレスコマースアーキテクチャを使用しているかどうかには関係ありません。ヘッドレスコマースへの移行はすべて一度に行う必要はありません。チームと共にヘッドレスの世界へと移行を進めるときには、既存の本番システムの完全統合された開発アプローチを維持しつつ、ヘッドレスを使用して新しいストアフロント機能を開発することができます。

次のステップ

ここでは、ヘッドレスコマースのフロントエンド、バックエンド、RESTful API について学習しました。ヘッドレスコマースのメリットとデメリットや、ヘッドレスによってさまざまなタッチポイントでのショッピング体験をパーソナライズできることも確認しました。次は、ヘッドレスへの移行を誰がどのように行うかを詳しく見ていきましょう。

リソース

• Salesforce: ヘッドレスに関するブログ記事
• Trailhead: API の基本
• 外部リンク: What Is REST API Design? (REST API 設計とは?)
• Trailhead: Salesforce B2C Commerce の開発
• Trailhead: Commerce Cloud Einstein の導入
• Trailhead: Salesforce B2C Commerce Page Designer (デベロッパー向け)