新しい古典：Jamstack と MACH が従来の CMS の概念に向け進化する

Jamstack、MACH、また Drupal を始めとする従来の CMSが、お互いから学びながら進化すること、また Jamstack と MACH のマーケティングにおける一部の誤解を解消する方法について：

近年、MACH や Jamstack のような新しいアーキテクチャが、コンテンツ管理システム（CMS）やデジタルエクスペリエンスプラットフォーム（DXP）の世界で登場しています。

ある意味で、これらのアーキテクチャは従来のモデルに挑戦しています。そのため、私は時々 MACH や Jamstack についての意見を尋ねられることがあります。論争を避けるために、私はほとんど意見を述べるのを控えてきました。

しかし、多様な視点の価値を受け入れた上で、私はいくつかの考えを共有することを決意しました。以下に共有する考えが、今後これらの技術の進化にポジティブに貢献することを願っています。

Jamstack は CMS を内包している

Jamstack は 2015 年に生まれ、静的サイトを構築するためのアプローチとして始まりました。Jamstackという用語は JavaScript、API、および Markup を表します。Jamstack は、ウェブエクスペリエンス層をコンテンツとビジネスロジックから切り離すアーキテクチャのアプローチです。ウェブエクスペリエンス層は通常、静的ページ（マークアップ）として事前にレンダリングされ、コンテンツデリバリーネットワーク（CDN）を介して提供されます。

2023 年までに、Jamstack コミュニティは様々な変革を遂げてきました。ルーツから大きく進化し、ますます「コンテンツプレビュー」などの従来の CMS の機能を統合する方向に向かっています。この変化は、より複雑なウェブサイトを扱う必要性や、開発者だけでなくマーケターに対しても Jamstack をユーザーフレンドリーにする必要から生じています。

Jamstack コミュニティのリーダーである Netlify は、この変化を認識しています。それに伴い、彼らは「Jamstack」という用語から「コンポーザブル・ウェブプラットフォーム」（組み立て可能なウェブプラットフォーム）に向かうことを公然と宣言しています。

長い間、Drupal を含む多くの従来の CMS は、「コンポーザビリティ」の概念を採用してきました。たとえば、Drupal は 20 年にわたりコンポーザブルな CMS として認知されているだけでなく、Drupal が提供するコンポーザブルな機能は高度なものになっています。

Jamstack によるこの拡張は、ソフトウェアが時間とともにより複雑で多面的になる傾向を反映しており、これはしばしば複雑性増加の法則と呼ばれています。単純なものは、時間とともに複雑性を増していきます。

私は、今後 Jamstack がメニュー管理、翻訳ワークフロー、マーケティングテクノロジーの統合などの機能を追加し続け、従来の CMS に近づいていくと考えています。

注意喚起：現在の CMS はハイブリッド

Jamstack は、機能だけでなく、アーキテクチャにおいても、従来の CMS に似てきています。従来の CMS は、主に 2 つの方法で機能します。モデル・ビュー・コントローラ（MVC）と呼ばれるアプローチを使用して、プレゼンテーション層をビジネスロジックから分離する「結合 (coupled)」または「統合 (integrated)」、または Web サービス API を使用してフロントエンドとバックエンドを分割する「疎結合 (decoupled)」です。これは Jamstack が行う方法と似ています。

現代の CMS は、さまざまな JavaScript フレームワークと統合し、GraphQL バックエンドを持ち、静的ページをレンダリングすることができるなど、多くの機能を備えています。

この両方の方法の組み合わせは「ハイブリッド」として知られています。従来のCMS のほとんどは、このハイブリッドアプローチを採用しています。たとえば、Drupalは「Jamstack」と「Headless」という用語が存在するより前から、ヘッドレスアプローチを 10 年以上にわたり推進してきました。

従来の CMS は「モノリシック」で「時代遅れ」と主張することは、その進化を見落とした人々による視野の狭い意見です。実際には、今日の選択肢は純粋なヘッドレス CMS かハイブリッド CMS かのどちらかです。

「Jamstack」の再定義：誇大広告を超えて

Jamstack がより多様化するにつれて、元々の「Jamstack」という名前と定義は制約的に感じられます。かつてはより高速でセキュアなウェブサイトを簡単に展開することを中心にした Jamstack の本質が変わっています。

当初 Jamstack が掲げていた価値提案の幾つかは古くなってきました。それは Jamstack の進化のみがもたらしたものではなく、過去何年もの間、Jamstack の利点の多くは過大評価されてきたからです：

• Jamstack のデプロイメントが簡単だという考えには議論の余地があります。実際には、デプロイメントは開発者だけでなく、特にマーケターにとってもどかしい作業です
• 私は Jamstack のパフォーマンスに関する利点についても疑問を抱いています

要するに、最初は静的サイト生成とシンプルさで知られていた Jamstack は、より動的で複雑なものに成長しています。これは市場の需要に応じた肯定的な進化です。この進化により、Jamstack と従来の CMS の間の差が狭まっていますが、それらはまだいくつか異なります。Jamstack は純粋なヘッドレスアプローチを提供し、従来の CMS はヘッドレスと統合の両方のオプションを提供しています。

この変化により、Jamstack は MACH に似てきています。最後に、それについて私の意見を述べたいと思います。

MACHと従来のCMSの主要な違い

多くの読者、特に Drupal コミュニティのメンバーの中には、MACH について知らない人もいるかもしれません。MACH は、Microservices、API ファースト、Cloud ネイティブ SaaS、Headless の頭文字をとった略語です。これは、ビジネス機能ごとに異なるクラウドサービスとして構築され、通常は異なるベンダーによって開発・メンテナンスされ、エンドユーザーによって統合されるアーキテクチャのアプローチを指定しています。

MACH アーキテクチャーの理念に基づいたソリューションを使用してオンラインストアを構築すると想像してみてください：支払いを処理するために異なるクラウドサービスを使用し、製品カタログ用に別のサービスを使用し、その他も同様です。MACH の主要なアーキテクチャコンセプトの 1 つは、これらのサービスの各々が独立して開発、展開、管理できることです。

一見すると、Drupal や WordPress とあまり変わりがないように見えるかもしれません。WordPress や Drupal などのプラットフォームはすでに多くの統合機能を備えており、2023 年の時点では Drupal モジュールは 5 万以上を数えます。実際、これらのモジュールの一部は、Drupal を MACH サービスに統合する役割を果たしています。たとえば、Drupal や WordPress でオンラインストアを構築する場合、支払いサービス、SaaS ベースの製品カタログなどと連携するモジュールをインストールします。

一見すると、このモジュラーアプローチは MACH に似ているように思えます。しかし、明確な差違があります：Drupal や WordPress は、モジュールを「コアプラットフォーム」に追加して機能を拡張しますが、MACH は独立したサービスの集合体であり、基礎となるコアプラットフォームに依存せずに動作します。

「モノリシック」な機能が MACH に与えうる恩恵

MACH コミュニティの多くは、コアプラットフォームが存在しないことを評価し、しばしばコアプラットフォームをモノリシックであると批判します。技術的な観点から見れば、Drupal のコアプラットフォームは高度にモジュール化されており、すべてのコンポーネントを交換できるようになっています。

従来の CMS に「モノリシック」というレッテルを貼るのではなく、より正確に MACH と従来の CMS の違いを説明する方法は「コアプラットフォーム」の存在または不在に焦点を当てることです。

さらに重要なのは、コアプラットフォームが一貫性のあるユーザーエクスペリエンスの維持、集中型のアカウント管理、統合の互換性とアップグレードの処理、インテグレーション全体での翻訳とコンテンツワークフローの効率化などに果たす重要な役割がしばしば見落とされることです。コアプラットフォームは実質的に、エンドユーザーと開発者のエクスペリエンスを向上させるための「共有サービス」を提供します。コアプラットフォームがない場合、開発およびメンテナンスコストが増加し、断片化されたユーザーエクスペリエンスやコンポーザビリティーにおける重大な課題が生じる可能性があります。

これは私が「MACH 疲れ」と呼ぶ現象と一致しています。ますます多くの組織が、MACHベースのシステムの開発および保守費用について認識し始めています。さらに、エンドユーザーはしばしば断片化されたユーザーエクスペリエンスに直面します。統合されたインタフェースではなく、多くの分離されたシステム間を移動してタスクを完了する必要に迫られることが珍しくありません。

私にとって、理想的な解決策は「緩やかに結合されたアーキテクチャと高度に統合されたユーザーエクスペリエンス」と表現できるかもしれません。このようなアーキテクチャは、最適なシステム（好みの CMS、CRM、コマースプラットフォームなど）を組み合わせる柔軟性を提供します。同時に、高度に統合されたユーザーエクスペリエンスは、これらの組み合わせがエンドユーザーだけでなく、コンテンツクリエーターやエクスペリエンスビルダーにとってもシームレスであることを保証します。

現在、Drupal などの従来のプラットフォームは、MACH ソリューションと比較してこの理想に近いと言えます。私は今後、MACH コミュニティが MACH プラットフォームのコストパフォーマンスを向上させることに焦点を当てると予想しています。これには、依存関係を管理し、バージョンの互換性を確保するためのツールを作成する取り組みが含まれるでしょう。これは Drupal が Composer を採用しているプラクティスと似ています。

「デジタルエクスペリエンスコンポジション（DXC）ツール」と呼ばれるツールを使用して、MACHのユーザーエクスペリエンスを効率化する取り組みが既に進行中です。DXCはMACHアーキテクチャの上にあるレイヤーとして機能し、さまざまなMACH要素をモジュラーな「レゴブロック」に分解したユーザーインターフェースを提供します。これにより、開発者とマーケターの両方がこれらのブロックを組み立ててデジタルエクスペリエンスを構築できます。従来のCMSをよく知っているユーザーにとっては、多くのCMSプラットフォームがDXC要素をコアプラットフォーム内の重要な機能として組み込んでいることから、このコンセプトは馴染み深いものかもしれません。

Drupal のような従来の CMS は、特にウェブサービスへのアプローチに関して、Jamstack と MACH からヒントを得ることもできます。たとえば、Drupal はビジネスロジックを MVC パターンを使用して効果的にプレゼンテーション層から分離していますが、主に内部API に依存しています。よりオープンなウェブサービス API にシフトすることで、Drupal の柔軟性とイノベーションの潜在能力を向上させることができるでしょう。

まとめ

近年、CMS/DXP 分野では、MACH、Jamstack、疎結合、ヘッドレスアーキテクチャなど、さまざまな技術的アプローチが見られ、それぞれが自身の道を切り開いてきました。

最初はこれらのアプローチが枝分かれしていくように見えましたが、互いから学び、他のアプローチが持つ強みを取り込んでいく傾向が見られます。

Jamstack は、静的サイト生成に焦点を当てた初期のアプローチから、より動的で複雑なアプローチに進化しており、従来のCMSとの差を縮めつつあります。

同様に、従来の CMS との差を埋めるために、MACH は従来の CMS のコアプラットフォームに共通して見られる共有サービスをカバーしていく必要があるかもしれません。これにより、開発コスト、コンポーザビリティー、ユーザーの親和性が向上するでしょう。

プラットフォームの評価は、最終的にはアーキテクチャーとは無関係に、どれだけ効果的に良いユーザーエクスペリエンスとコストパフォーマンスを提供できるかによって判断されます。重要なのはアーキテクチャーについて考慮することではなく、エンドユーザーにとってより直感的で強力なプラットフォームをどのように作成できるかということにフォーカスしてテクノロジーを評価することです。