コンポーザブルなデジタル体験

コンテンツ管理システム（CMS）とデジタル体験プラットフォーム（DXP）の市場に対する私の見解について、久しぶりに書いてみたいと思います。

2009年、2011年、2017年に行ったように、アクイアの製品ビジョンと戦略のアップデートをするのも久しぶりです。

今回は、その両方の最新情報をお伝えしたいと思います。 DXP市場に対する私の見解と、アクイアのビジョンと戦略について詳しくお話しします。

この記事を通して、Drupal（私が始めたオープンソースプロジェクト）とアクイア（私が始めた会社）がコンポーザブル・エンタープライズにどのようにフィットするか、実践例を挙げて説明します。

コンポーザブル・エンタープライズ

コンポーザブル・エンタープライズは、ソフトウェア業界において重要なトレンドの1つです。 アナリスト企業のガートナーがこの言葉を普及させました。彼らは、コンポーザブル・エンタープライズを次のように定義しています。

コンポーザブル・エンタープライズとは、パッケージ化されたビジネス機能の組み立てと組み合わせによって、変化するビジネスニーズに革新的に対応できる組織を指します。 ベンダーはよりモジュール化された機能を提供するようになります。コンポーザブル・エンタープライズを実現するために、企業はアプリケーションの調達と提供の方法を変更する必要があります。

コンポーザブル・エンタープライズの主な考え方は、組織が既存のパーツブロックからソリューションを構成したり組み立てたりすることで、より迅速に行動できるようになる、というものです。 また、ビジネスニーズの変化に対応する柔軟性も備えています。

ガートナー社のソート・リーダーシップによれば、アーキテクチャのモジュール化はコンポーザビリティの鍵となる重要な課題です。 しかし、コンポーザビリティはモジュール化以上のものでもあるのです。 コンポーザビリティは、ソフトウェア設計だけでなく、エンドツーエンドのアプローチを定義しています。 ビジネスのアジリティ、アーキテクチャ、ガバナンスの哲学です。

コンポーザブルDXP

本記事では、コンポーザブル・エンタープライズの考え方をDXP市場に当てはめて考えてみます。

具体的には、コンポーザブルDXPの鍵となる6つの基本的な考え方について展開します。

1. 原則1：ソフトウェア設計はモジュール化する必要がある
2. 原則2：コンポーネントは発見可能でオーケストレーション可能である必要がある
3. 原則3：全てのビジネスステークホルダーがローコード/ノーコードで力を発揮する必要がある
4. 原則4：データ活用のために、統合と自動化が必要
5. 原則5：マルチチャネルに活用したいコンテンツには、強力なコンテンツ管理が求められる
6. 原則6：プラットフォームアプローチには、多様なエクスペリエンスの構成と提供方法が必要

MACHとJamstack

6つの原則を解説する前に、DXP市場におけるコンポーザビリティが、MACHやJamstackのようなトレンドを生み出したことを共有したいと思います。

• MACHは、Microservices, API-first, Cloud-native SaaS, Headlessの頭文字をとったものです。 MACHアーキテクチャでは、ビジネス機能の一つ一つがクラウドサービスとなります。 クラウドサービスは独立したベンダーによって構築・管理され、それらを使用する顧客側で統合されます。 典型的なMACHサービスは、フロントエンドを持たない（ヘッドレスサービス）か、フロントエンドを切り離したバックエンドサービスです。 その結果、MACHのサービスでは、統合やフロントエンド開発のためのWebサービスAPIが提供されています。
   
• Jamstackは、JavaScript、API、Markupの頭文字をとったものです。 Jamstackは、Webエクスペリエンス層をデータやビジネスロジックから切り離す設計手法です。 Webエクスペリエンス層は、CDN経由で提供される静的ページ（マークアップ）として事前にレンダリングされることが多いです。
  

つまり、MACHとJamstackは、主に設計手法について述べています。 MACHは主にWebアプリケーションのバックエンド設計に関するものであり、Jamstackは主にWebアプリケーションのフロントエンド設計に関するものです。

MACHもJamstackも、コンポーザビリティという課題に対して、開発者中心のアプローチであることが表れています。 どちらもDXPの能力を定めるものではありません。 MACHもJamstackもコンポーザブルDXPの一部となることができます。

原則1：ソフトウェア設計はモジュール化する必要がある

Image

コンポーザブルDXPの核となるのは、モジュール化されたソフトウェアの設計原則です。 組織は、ソフトウェアをモノリシックにするのではなく、モジュール化することに焦点を当てるべきです。

モノリシック設計は柔軟性に欠けるからです。 モノリスは、チームの迅速な動きを妨げ、イノベーションを阻害し、デジタル製品やサービスを提供することを難しくします。

モジュール式ソフトウェアは、標準化されたインターフェースを持つ小さな部品に分解されます。 そして、再利用可能なコードを組み合わせてソリューションを作ることができます。

この考え方は新しいものではなく、1960年代から存在しています。しかし、多くのソフトウェアが、この基本的な設計原則に則っていないのが現状です。

原則2：コンポーネントは発見可能でオーケストレーション可能である必要がある

Image

コンポーザブルアーキテクチャとは、スタックの個々のコンポーネントを、システムの他の部分に影響を与えることなく交換することができる設計を指します。

これは、企業がニーズに合わせて最適なソリューションを選択し、組み立可能にするためのものです。

異なるプロバイダのコンポーネントを組み合わせることで、企業は多くの柔軟性を得ることができますが、同時にコストと複雑さが増します。

• 部品が発見しにくい場合がある：例えば、DXPで利用可能なすべてのコンポーネントは何なのか、それらは何をするのか、そしてどのように使うのか、などです。
   
• コンポーネントのオーケストレーションが困難な場合がある：例えば、あるコンポーネントは一緒に動作しないかもしれないし、コンポーネントには依存関係があるかもしれない、などです。
  

多くのコンポーネントで構成されるソフトウェアスタックは、構築や保守が困難な場合があります。 実際、コンポーザブルアーキテクチャは、発見、オーケストレーション、インテグレーション、およびテストの負担の多くがベンダーからエンドユーザーに移ります。

コンポーザビリティを実現するためには、部品の発見、インストール、組み立て、メンテナンスを簡略化する手法が必要です。 優れたコンポーザブルDXPは、多様なコンポーネントを管理するために、次のようなソリューションを提供します。

• Packaged business capabilities(PBCs)：コンポーネントとその構成をより高いレベルのビルディングブロックにまとめたものです。 これは、ソリューションの提供をより再現性の高いものにするために有効です。
   
• マーケットプレイス：部品とPBCの両方を検索し、発見できるようにするものです。
   
• コンポーネントマネージャ：異なるプロバイダからコンポーネントをインストールし、更新するための統一されたメカニズムを提供します。 コンポーネントマネージャは、コンポーネントの依存関係（コンポーネントAがコンポーネントBもインストールする必要があるなど）を解決し、コンポーネントの互換性（コンポーネントAがコンポーネントBのv2としか動作せず、v3とはまだ動作しないなど）を管理します。 また、コンポーネントマネージャは、コンポーネントの新しいバージョン（例えば、コンポーネントBにセキュリティリリースがあり、更新する必要がある）を知っており、その更新をオーケストレーションします。例えば、セキュリティ上の理由からコンポーネントBを更新すると、コンポーネントCも更新する必要がある、などです。
   
• コンポーネントカタログ：コンポーネントと、コンポーネントを管理するために必要なメタデータのレジストリまたはデータベースです。 これには、コンポーネントの場所、バージョン情報、依存関係チェーン、互換性の制限、リリースの詳細などが含まれます。マーケットプレイスとコンポーネントマネージャは、1つまたは複数のコンポーネントカタログの上で動作します。
   
• CI/CDパイプライン：コンポーネントの継続的な統合、管理、更新のために必要です。 独立したプロバイダから、日々新しいバージョンのコンポーネントがリリースされています。 コンポーザブルソフトウェアを確実かつ迅速に提供するためには、自動統合・自動テストが必要です。
   

原則3：全てのビジネスステークホルダーがローコード/ノーコードで力を発揮する必要がある

Image

最高の顧客体験を提供するためには、すべての部門（エンジニアリング、マーケティング、セールス、カスタマーサクセス、人事）がその創造に参画する必要があります。

モジュール化されコンポーネント駆動であることは、開発者にとっては素晴らしいことです。しかし開発以外のビジネスステークホルダーは手出しできません。

そこで、ローコードやノーコードのソリューションの出番です。 ローコードやノーコードの技術は、グラフィカルユーザーインターフェース（GUI）を使用して、体験の構築を高速化します。 ソフトウェア開発者の手を借りずに、すべてのビジネスステークホルダーが顧客体験を創造できるようになります。

ローコード/ノーコードのコンポーザブルDXPは、少なくとも3つの点で組織を支援します。

1. 社内外の開発チームに頼るのではなく、各事業部門が自分たちのテクノロジーを所有すれば、より迅速に行動することができます。
2. ローコード/ノーコードソリューションにより、社内の開発チームは、独自の差別化されたイノベーションに集中することができます。 ローコード/ノーコードの価値提案は、ビジネスユーザーだけのものではなく、開発チームのスピードアップにもつながります。
3. ローコード/ノーコードソリューションは、ソフトウェアエンジニアリングの能力とスキルに依存する組織を減らすことができます。
    

つまり、ローコード/ノーコードソリューションは、部門横断的なチームが優れた顧客体験をより迅速に提供することを可能にするのです。

原則4：データ活用のために、統合と自動化が必要

Image

企業は、パーソナライズされた顧客体験を実現するために、ますますデータを活用するようになっています。 目標はシンプルで、カスタマイズされた体験を通じて、顧客満足度、ロイヤルティ、支持を向上させることです。

将来のアプリケーションは、複数のソースからデータを取得し、各ユーザーのきめ細かいユーザープロファイルを作成するようになるでしょう。 そして、このユーザープロファイルはパーソナライズに利用されます。

第一の問題は、顧客データがCRMシステム、会計システム、ウェブサイト、マーケティングツール、コマースシステム、POSシステム、分析プラットフォーム、カスタマーサポートソフトウェア、モバイルアプリケーション、チャットボット、コールセンターソフトウェアなど、あらゆる場所に存在していることです。

すべてのデータソースを活用する必要があることは明らかですが、データはさまざまなデータベースや異なるフォーマットで保管されています。 パーソナライズされた体験を提供する上で、データのサイロ化は最大の障壁の1つです。

データを最大限に活用するためには、データを統一する必要があります。 このようなサイロから脱却する必要があるのです。

2つ目の問題は、拡張性です。 人間は、すべての顧客とすべての顧客とのインタラクションについて、手作業で体験を構成することはできないのです。

数百万人のユーザープロファイルと数百万回のインタラクションがある場合、自動化が重要な鍵を握ります。 組織は、人々の好みに合わせて体験を調整するために、機械学習アルゴリズムに頼らなければなりません。

最後になりますが、組織は顧客のデータプライバシーを尊重し、GDPRなどの規制や各国のデータプライバシー法を遵守する必要があります。 このため、ユーザーデータの管理・利用には第三の複雑な層が追加されることになります。

原則5：マルチチャネルに活用したいコンテンツには、強力なコンテンツ管理が求められる

Image

マルチエクスペリエンスとは、Webサイト、モバイルアプリケーション、チャットボット、音声アシスタント、ウェアラブル、拡張現実、メタバーズなど、さまざまなデジタルタッチポイントでユーザーが1つの組織でエンドツーエンドに体験することを指します。

優れたコンテンツは、優れた（マルチ）エクスペリエンスの核となるものです。 質の高いコンテンツは、組織を競合から際立たせるのに役立ちます。 そのため、お客様が関心を持つコンテンツを制作し、お客様が好むチャネルで配信することが期待されています。 コンポーザブルコンテンツが鍵です。

コンポーザブルDXPは、すべてのチャネルでコンテンツを管理するという課題に対処するために設計されたコンテンツプラットフォームを提供する必要があります。 これらの課題は以下の通りです。

• コンテンツのサイロ化を解消し、コンテンツ管理およびコンテンツ運用を効率化します。
• コンテンツモデルとヘッドレス配信機能を活用し、チャネルや顧客接点にまたがるコンテンツを提供します。
• コンテンツガバナンスと、すべての顧客接点におけるブランドの一貫性を向上させます。

これらの課題に対応するために、コンテンツプラットフォームには以下のようなコア機能が必要です。

• コンテンツモデリング：コンテンツを共通の要素に分解し、異なるチャネルで共有したり、リミックスできるようにします。 また、お客様一人ひとりの関心事をデータに基づいて把握し、コンテンツを素早く組み立て直すことも可能です。 記事、ブログ、ページなどのモデルや、細分化されたデジタルアセット、製品情報などが含まれます。
   
• コンテンツ運用：コンテンツの戦略、作成、配信、分析を担当するすべての人々とプロセスを組織化します。
   
• コンテンツ配信：さまざまなチャネルにコンテンツを配信します。 コンテンツプラットフォームは、Webサービス（ヘッドレス）や従来のプレゼンテーション層（カップルド）を使って、コンテンツをさまざまなチャネルで利用できるようにするコンテンツリポジトリとして機能します。
   
• コンテンツガバナンス：すべてのエンゲージメントチャネルでコンテンツが一貫していることを確認します。 エンゲージメントチャネルは、バラバラでもサイロでもいけません。
   
• コンテンツパーソナライズ：リアルタイムにコンテンツをパーソナライズします。 パーソナライゼーションは、匿名の行動履歴や顧客プロファイルの明確な嗜好に基づいて行うことができます。
   
• ジャーニーオーケストレーション：インバウンドからアウトバウンドタッチポイントまで、またネイティブチャネルから連携チャネルまでのカスタマージャーニーをシームレスにコーディネートします。 ジャーニーオーケストレーションは、リアルタイムイベント、推論されたインサイト、機械学習による意思決定、ビジネスルールに基づいて、一人ひとりに最適なアクションを瞬時に、かつ大規模に提供します。
   

コンポーザブルコンテンツは、必ずしもヘッドレスCMSがデファクトでベストなコンテンツプラットフォームであることを意味しない。 ヘッドレスソリューションには、他のアプローチと比較して、長所と短所があります。

• 従来のCMSは、コンテンツリポジトリと、それを使って体験を構築するためのノーコードツールの両方を提供しています。 従来のCMSは、マーケティング担当者や開発者がUIを使用してWebエクスペリエンスを構築するためのものでした。 従来のCMSは強力なWebサービスAPIを持っていないため、複数のチャネルにコンテンツをプッシュする能力に限界があります。
   
• ヘッドレスCMSは主にコンテンツリポジトリであり、一般的にデジタル体験を構築するためのノーコードツールが欠けています。 ヘッドレスCMSは、複数のチャンネルにコンテンツをプッシュすることに長けています。 フロントエンドに依存しないため、開発者は独自のフロントエンドを構築する必要があります。 ヘッドレスCMSは、マーケティング担当者には不利になりがちですが、開発者にとってはより柔軟性があります。
   
• ハイブリッドCMSはヘッドレス機能を提供しますが、オプションですぐに使えるフロントエンドも用意されています。 開発者には、チャネルをまたいだコンテンツ配信に必要なウェブサービスAPIを提供し、同時にマーケティング担当者には、デジタル体験を構築するためのノーコードツールを確保します。

従来のCMSのほぼすべてが、ハイブリッドCMSへと進化しています。 従来のCMSについて話すことはもはや関係ありません。 現在では、ヘッドレスかハイブリッドかの二者択一になっています。

原則6：プラットフォームアプローチには、多様なエクスペリエンスの構成と提供方法が必要

Image

多くの企業がそうであるように、デジタル体験のアプリケーションの数は減るどころか、増え続けています。

また、サイトによって、規模、機能、複雑さ、寿命が異なります。 継続的に開発される経験もあれば、数ヶ月しかない経験もあります。 あるものはITによって、あるものはマーケティングによって構築されます。 月に1000人の訪問者があるサイトもあれば、月に1億人の訪問者があるサイトもあります。

デジタル体験のポートフォリオを管理する場合、画一的なアプローチではうまくいきません。 組織は、開発アプローチと運用コストのバランスをとる必要があります。

あるWebサイトでは、マーケティング担当者が使いやすいページビルダーと静的サイトのホスティングを使用することができます。 別のウェブサイトでは、同じ組織がヘッドレスCMSとPaaSデリバリープラットフォームを必要とするかもしれません。

さらに、CIOとCMOは、コスト削減と加速化のプレッシャーに同時に直面することがよくあります。 彼らは常に、より少ない人数でより多くのことをこなす方法を考えなければならないのです。

では、どのようにしてデジタル体験アプリケーションの多様なポートフォリオを管理し、速度を最大化し、コストを最小化し、増大するセキュリティ要求に対応すればいいのでしょうか。すべて品質を犠牲にすることなくです。

これは、小規模から大規模まで、シンプルから複雑まで、ITからマーケティングまで拡張可能なプラットフォームやエコシステムを標準化することで実現します。 具体的には、体験の構成や配信方法を選択できるタイプのプラットフォームです。

• 経験構成オプション：APIとノーコードツールの両方を提供するプラットフォーム。WebサービスAPIからテンプレート、ページビルダー、フロントエンドJavaScriptフレームワークに至るまで、さまざまなツールを提供します。
   
• 体験配信オプション：静的サイトまたは動的サイトをSaaSまたはPaaSでデプロイできるプラットフォームです。

また、これらの異なる構成と配信モデルは、標準的な共有サービスのセットによって支えられる必要があります。

• コンテンツの共有を可能にするサービス。
• データの共有を可能にするサービス。
• Cloud-nativeな配信を効率化するサービス。
• リリース管理、デプロイ、セキュリティ、コンプライアンスのベストプラクティスなど、一貫した運用ワークフローを促進するサービス。
• コンポーネント、PBC、デザインシステムなどのグローバルカタログを管理するサービス。
• グローバルに展開するサイトやデジタル体験のポートフォリオを管理するサービス。

つまり、デジタル体験のポートフォリオを管理するには、特定のコアサービスを中心に構築された標準的なテクノロジーフットプリントが必要ですが、体験構築と体験提供のアプローチを変えるオプションも必要なのです。

まとめ

数十年にわたり、硬直した柔軟性に欠けるシステムと格闘してきた企業は、コンポーザビリティによってもたらされる敏捷性とスピードを切望しているのです。

これは、今日の経済において特に重要なことであり、組織はオーダーメイドのデジタルな顧客体験を持つことに基づいて競争上の優位性を獲得しています。

私は、今後10年以内に大多数の企業がコンポーザブルモデルに移行すると予測しています。

—

この元記事は A Composable Digital Experience Manifesto で掲載されています。 Drupalとアクイアの詳細は、こちらのページをご覧ください。