コンテンツガバナンスプレイブックは、新たに AEM as a Cloud Service の管理者や開発者を担当する際に役立ちます。このプレイブックはダウンロード可能で、実装時に強力なコンテンツガバナンス戦略を開発するために従う必要があるガイドラインとプロセスについて説明します。
役割、ワークフロー、実装について
組織は、あらゆるコンテンツが作成、ラベル付け、使用、メンテナンスに関する社内標準に準拠していることを確認する必要があります。公共向けの資料にこれらの標準を維持することは、ブランドアイデンティティを保つのに役立ちます。ワークフローをスムーズにするには、デジタルアセットをオーサリングするための明確な内部ガイドラインが必要です。コンテンツのレビューと更新のプロセスを実施すると、すべてが最新の状態に保たれます。
デジタルアセット管理のガイドラインとプロセスは、コンテンツガバナンスの範疇に含まれます。このプレイブックでは次の内容を説明します。
- コンテンツガバナンスの概要と開発への影響
- Adobe Experience Manager Sites と Assets の実装
- メタデータと、それが重要な理由
- コアコンポーネントの使用方法
- コンテンツガバナンス、ワークフロー、共同作業に関連付けられた役割
- コンテンツガバナンスを実装後も最新の状態に保つ方法

コンテンツガバナンスとは何かを理解したい
コンテンツガバナンスは、会社のコンテンツサプライチェーンを管理する一連のポリシーとプロセスです。チームが使用できるフレームワークを確立し、コンテンツのライフサイクル全体を通してガイドライン、配布、標準が満たされることを保証するのに役立ちます。
コンテンツガバナンスが重要な理由
コンテンツガバナンスは、組織にとって不可欠であり、コンテンツサプライチェーンの全体的な成功、および組織の評判とブランドに影響します。ブランドの戦略と品質に合わせてコンテンツの正確性と一貫性を保護できます。Adobe Experience Manager Sites と Assets には、コンテンツガバナンスが組み込まれており、コンテンツの管理方法を効率化し、コンテンツサプライチェーンを管理するために必要なツールを提供できます。
コンテンツガバナンス、システムガバナンス、法務およびコーポレートガバナンスの関係
コンテンツガバナンスは、常に法的および技術的な設定によって形成されます。Experience Manager コンテンツガバナンスは、文書化された法務およびコーポレートガバナンスと、システムアーキテクチャに対して定義された全体的なシステムガバナンスに基づいています。以下に例を示します。
- すべてのマーケティング資料を 7 年間保持するための法的および規制要件は、コンテンツのライフサイクルと、作成されたコンテンツのワークフローに情報を提供します。
- ユーザーグループの作成とアクセス制御のシステムガバナンス基準は、Experience Manager フォルダー構造に関連付けられており、コンテンツの戦略とガバナンスに影響を与えます。システムガバナンスとアセットガバナンスが連携して、セキュリティとユーザビリティを実現する必要があります。
- 機械学習(ML)や人工知能(AI)の使用を禁止する内部コーポレートガバナンスは、特定の Experience Manager 機能のアクティベーションに影響を与えます。
実装時にコンテンツガバナンスが重要な理由
Experience Manager チームは、Sites や Assets では標準で提供されないカスタムワークフローや機能など、開発に必要な保護機能を設定するために、初期ディスカッション中および実装フェーズを通じてコンテンツガバナンス戦略に関与する必要があります。さらに、サイト管理者は、プロセス全体の継続性を確保するための適切なグループ、権限、ポリシーの設定を支援します。
Sites と Assets を実装する際に、開発者が取るべき 5 つの重要なアクションについて理解したい
- 新しいコンテンツを接続して設定: 新しいコンテンツの Experience Manager へのシームレスなワークフローを実装するには、アドビのアセットリンクなどのコネクタをセットアップして設定する必要があります。これにより、新しいコンテンツが制御された形で Experience Manager に送られ、アセットを新規作成する際に承認済みのコンテンツを簡単に再利用できます。
- カスタムワークフローと承認プロセスを作成: Experience Manager Sites と Assets には多くの便利なワークフローが含まれていますが、プロセスや機能を追加するために拡張する必要がある場合は、多くの場合、これらのワークフローを拡張する必要があります。
- 機密コンテンツをアーカイブおよび保存するプロセスを実装: 多くの業界では、コンテンツの保存、格納、アーカイブの方法に関する厳しい要件があります。多くの場合、コンテンツガバナンスには、チームがこれらの要件を満たすために実装する必要のあるカスタムプロセスが存在します。
- カスタムフィールドまたは機能がアセットライフサイクルに追加されていることを確認: 画像にメタデータを追加したり、新しいプロセスを自動化したりする必要が生じる場合があります。このような場合、開発者は、新しいカスタム機能がビジネス要件を満たしていることを確認します。
- ページテンプレートを定義: 開発者と管理者は、Experience Manager Sites がページの全体的な構造とレイアウトを設定できるようにすることが可能です。コンポーネントと機能のセットを特定のブランドに即したスタイルと共に事前定義して、顧客体験をまたいで一貫したルックアンドフィールをページに提供できます。
開発者からコンテンツ作成者や実務担当者への引き継ぎについて理解したい
開発チームとオーサリングチームは、引き継ぎ中に互いに話し合い、既に構築およびカスタマイズされた内容を明確にし、質問に答える必要があります。また、開発チームは、オーサリングチームが対応する設定に関するドキュメントを提供する必要があります。オーサリングチームが追加コンテンツを作成する際に使用できるサンプルページやサンプル構造を開発チームが共有することも役立つでしょう。
Sites と Assets を実装する際に、作成者または DAM 管理者が取るべき上位 5 つの重要な要因について理解したい
- コンテンツを整理します。後で簡単に使用できるように、直感的な方法でコンテンツとアセットを構造化します。コンテンツの構造、特に複数言語での配布の方法に関する便利な例については、Adobe Experience League を参照してください。
- 分類戦略を作成します。分類戦略がないと、Experience Manager で作成されたタグをチームで見つけて管理するのが困難になりかねません。分類は階層的に整理でき、上部には幅広いカテゴリが表示され、下部にはサブカテゴリが表示されます。タグと分類に関するクイックスタートのベストプラクティスについては、Adobe Experience Manager チュートリアルドキュメントを参照してください。
- メタデータのコンプライアンスを確保します。メタデータの社内標準に準拠することは、アセット管理の重要な部分です。準拠することで、チームメンバーと外部検索エンジンの両方が、アセットを簡単に見つけることができます。
- グループに権限を割り当てます。権限をグループごとにテストして、コンテンツに適切に関与できるようにする必要があります。すべての権限を徹底的にテストし、ユーザーとグループが実行できる操作と実行できない操作を把握します。セキュリティマトリックスの例を以下に示します。
5.規制およびガイドラインに準拠します。コンテンツを正確に管理および維持し、規制や会社のガイドラインに準拠します。コンテンツガードレールの確立は、ブランドの一貫性を保つためだけでなく、508 条の準拠や同意または Cookie 管理の要件を満たすために重要です。
メタデータをより詳しく理解したい
Assets には常にメタデータを含める必要があります。メタデータを追加することには、複数の利点があります。これにより、チームとエンドユーザーの両方でアセットを簡単に見つけることができます。また、検索エンジンで画像とエクスペリエンスをより適切に見つけることもできます。
メタデータ、サブヘッドおよびタグ付けに関する考慮事項
組織は、どのメタデータフィールドがオプションで、どのフィールドが必須かについて合意する必要があります。そうすることで、作成者がアセットを簡単に見つけることができます。例えば、ほとんどの企業では各アセットにタイトルと説明が必要ですが、画像の作成者と使用条件は任意です。
スマートタグは、Adobe Sensei 生成 AI を活用したキーワードで、アップロード時にアセットに適用されます。関連する用語が識別され、対応するテキストベースのタグが顧客のアセットに適用されます。スマートタグは、検索や検索を容易にする説明的なキーワードの追加に役立ちます。顧客は、拡張スマートタグを通じて独自の用語を使用するようにアルゴリズムをトレーニングすることもできます。
タグと分類について詳しくは、これらのベストプラクティスを参照してください。
正しいスマートタグが適用されていない場合は、スマートタグトレーニングを使用して、ブランドガイドラインに従ってアセットを適切にタグ付けするように Adobe Sensei をトレーニングできます。
企業は、コンテンツをアップロードしてタグ付けする前に、明確なタグ付けと分類戦略を定義する必要があります。アセットのタグ付け方法の戦略とアプローチが明確に定義されていない場合、タグは無秩序または一時的な方法で作成および使用される可能性があります。その結果、管理が困難な未整理のタグ、未使用のタグ、誤用タグが生じかねません。
コアコンポーネントのベストプラクティスを理解したい
コアコンポーネントは、実装を成功させるための構築ブロックです。コアコンポーネントを Experience Manager で使用する際のベストプラクティスを以下に示します。
懸念要素の分離
コンポーネントのプレゼンテーションレイヤーからバックエンドロジックを分離します。バックエンドロジックには Sling モデルを使用し、ビューには HTML テンプレート言語(HTL)を使用します。これにより、ビジネスロジックとコンポーネントのフロントエンドを明確に区別できます。また、コンポーネントの柔軟性が向上し、再利用しやすくなります。
適応性
再利用を念頭に置いてコンポーネントを設計することが重要です。1 つの場所でしか使用できない大きな単体コンポーネントを構築しないようにします。代わりに、複数のページで再利用でき、将来的にその上に構築できるモジュール型コンポーネントを構築します。
カスタムコンポーネントとコアコンポーネントの比較
可能な限り多くのコアコンポーネントを使用して、開発時間を短縮することをお勧めしますが、それができない場合もあります。多くのクライアントは、ある程度の処理能力でカスタムコンポーネントを使用します。また、カスタムコンポーネントが必要になる場合もあります。それは、以下のような場合です。
- 自社ビジネスに固有の要素と機能を設計する
- カスタム API または内部 API の統合
- 高度なユーザーインタラクション
カスタムコンポーネントは、多くの場合、まったく新しいコンポーネントとは異なり、コアコンポーネントの拡張機能です。
スーパー作成者とコンテンツ作成者
ほとんどの大規模なチームには、1 人以上のスーパー作成者が含まれています。通常、スーパー作成者は、テンプレートの作成、テンプレート内の権限の割り当て、コンテンツの削除、レポートの生成などのその他のアクションを実行できます。
コンテンツ作成者は通常、特定のコンテンツにのみアクセスできます。例えば、ヘッダーやフッターなどのグローバル要素の編集や、アセットやコンテンツを削除または移動することはできません。コンテンツ作成者が公開中のサイトにページを公開することはほとんどできません。コンテンツを承認および公開するには、適切な承認ワークフローを経る必要があります。
フォルダー権限とユーザーグループの例
- 北米(NA)の事業部(BU)スペシャリストは、「NA-BU スペシャリスト」ユーザーグループの一部で、コンテンツを NA フォルダーにアップロードする権限を付与されていますが、EMEA、LATAM、APAC にはアップロードできません。
- LATAM の BU スペシャリストは、「LATAM-BU スペシャリスト」ユーザーグループに属し、LATAM フォルダーにコンテンツをアップロードする権限を付与されますが、EMEA、NA、APAC にはアップロードできません。
実装の前後の役割やチームについて理解したい
組織やチームの構造はそれぞれ異なりますが、最も一般的なのは後続の役割です。これらのチームメンバーは、実装フェーズでサポートを行い、実装後のツールの主な関係者です。
Sites と Assets の大規模なチーム
- プロダクトオーナー(1): プロダクトオーナーは、プロジェクトを最初から最後まで監督する主要な関係者です。プロダクトオーナーはマーケティング部門と協力して、ビジネスロジックと、それを技術チームに翻訳する方法を理解します。
- テクニカルリードおよびアーキテクト(1): テクニカルリードおよびアーキテクトは、主要な技術関係者です。実装チームと協力して、アーキテクチャの原則と技術的な連携を図ります。テクニカルリードは権限管理の所有者でもありますが、権限の更新方法について管理者をトレーニングできます。技術ドキュメントのシームレスな受け渡しと、ビジネスユーザーや作成者との連携を導きます。
- 開発チーム(2~4): 開発チームは、ローンチ後に発生するバグや問題を担当し、技術チーム、ビジネスユーザー、コンテンツ作成者の間での引き継ぎプロセスを支援する技術ドキュメントの作成を担当します。また、初期実装時にも役立ちます。
- QA チーム(3~5): QA チームの主な責任は、機能の観点と非機能の観点の両方でエクスペリエンスをテストすることです。問題を特定して報告し、開発者と協力して問題の修正と軽減を支援します。通常は QA リードがチームを管理し、3~4 人の QA エンジニアがテストを支援します。QA は、通常、最初のいくつかの開発スプリント後にコア開発の一部が構築されてテストできるようになると導入されます。
- コンテンツ作成者(3~4): コンテンツ作成者の主な責任は、web サイトや他のエクスペリエンスのコンテンツ作成です。コンテンツ作成者は、Experience Manager Sites と Assets をまたいで作業し、メタデータを適用してアセットをアップロードし、マーケティング目標に合ったコンポーネントをオーサリングします。コンテンツ作成者は実装プロセス全体を通じて関与でき、テンプレートとコンポーネントが利用可能になり次第、コンテンツのオーサリングを開始します。
- デジタルアセット管理(DAM)管理者(1~2): DAM 管理者は、Experience Manager Assets の構造、ガバナンスおよび編成に重点を置いています。多くの場合、レポートを生成したり、DAM のストレージのアーカイブと最適化に関する戦略を開発したりするなど、作成者よりも高度な制御が可能になります。
ストレージを最適化し、DAM を適切に整理することで、会社の時間とコストを節約できます。また、DAM 管理者は、組織内の新しいユーザーのトレーニングとサポートも行うことができます。これは通常、外部のコンサルタントを雇うよりも効率的で安価です。
Sites と Assets の小規模なチーム
- プロダクトオーナー(1): プロダクトオーナーは、多くの場合、管理やコンテンツ作成など、複数のタスクを実行します。小規模なチームのプロダクトオーナーは、多くの場合、サイトの QA を支援します。
- コンテンツ作成者と DAM 管理者(1~2): 小規模なチームでは、必要なコンテンツ作成者または DAM 管理者は 1 人のみで、通常、マーケティング部門の一員がこの役割を担います。
- テクニカルリードまたはアーキテクト(1): 小規模なチームのテクニカルリードまたはアーキテクトは、主要な技術関係者です。また、開発も手伝います。
- 開発者(1): 開発チームのサイズは様々ですが、新機能の追加や技術的な問題への対処には、常に開発者が必要です。
リスク
専用のコンテンツガバナンスがない場合、DAM システムはいくつかの重大なリスクに直面します。
- 無制限のアセット蓄積: DAM がただのアセットの集積所となり、その有用性と組織を損なうリスクがあります。
- プロトコルの侵食: たとえ少数のユーザーであってもプロトコルを回避するユーザーがいると、プロトコル順守の意識が低下し、他のユーザーが都合の良い場所にアセットを配置することを推奨する前例を作ることになります。
- アセットのタグ付けが不完全: プロジェクトに時間の制約があると、必要なメタデータやタグのないアセットがアップロードされ、検索性やアクセシビリティが低下する場合があります。
- アセットの命名があいまいな場合: ファイル名が不明なアセット(例:「test1.jpg」、「newtest.pdf」)が存在すると、アセットの取得が複雑になり、増加する可能性があります。
- 今後の再実装: タグ付けや命名が不適切なことで DAM が混乱すると、ユーザーの不満が高まり、管理性を復元するために 5~10 年以内に高価な再実装が行われる可能性があります。
- 変更管理の困難さ: 適応性の低下:ビジネスニーズの発展に合わせて DAM の更新と変更を管理することが、より困難になり、効率と適応性の両方が損なわれるでしょう。
技術エキスパートと実務担当者のコラボレーション
DAM 管理者は、Experience Manager Assets の実装と使用を監督します。しかし、それらの役割はかなり異なる可能性があります。デジタルアセット管理者はガバナンスとコミュニケーションにより多く取り組み、DAM 管理者は技術面を扱います。
デジタルアセット管理者(機能)
- Experience Manager Assets を管理して全事業部門とすべてのチャネルをサポートします。DAM コンテンツおよびプロセスの各分野のエキスパートです。
- Assets レポートと定期的な監査を使用して、ガバナンスをチェックし、コンプライアンス違反の項目を特定します。ビジネスまたはパートナーがコンテンツをコンプライアンスに対応するのに役立ちます。
- メタデータ標準、DAM フォルダー構造および分類のガバナンスを開発し、維持します。
- DAM が処理および標準化するドキュメントをパートナーに伝達します。
- 最新のビジネスニーズとトレンドを常に把握し、日常的なユーザーエクスペリエンス調査を実施して、メタデータ構造と分類があらゆるユーザーのニーズを満たしていることを確認します。
- 定期的な DAM のクリーンアップとアーカイブの手法を実装します。
- アセットの問い合わせの窓口としての役割を担います。
- 必要に応じてサポートを提供し、新規および既存のユーザーのトレーニングを支援します。
DAM 管理者(技術)
- システムレポート、モニタリングツール、定期的な監査を使用して、Experience Manager Assets の技術的な健全性を測定し、リスクを特定します。
- 社内のアドビチームまたは DAM 管理者が定義した構造と権限を実装します。
- Experience Manager Assets の使用方法に関するシステムアーキテクチャについてのガイダンスを開発チームと事業部門に提供します。
- Experience Manager Assets の機能、コンポーネントおよびツールを作成、管理する手順について説明します。
- Experience Manager Assets の新機能が技術要件を満たし、必要に応じてテストと実装が行われるように、事業部門メンバーと開発パートナーのトレーニングを行います。
- 新しいソフトウェアリリースおよびアプリケーションのシステムアップグレードのインストールをスケジュールします。また、パッチと新しいアプリケーションの評価とインストールも行います。
- Experience Manager のテクニカルガバナンスとパフォーマンスに関する各分野のエキスパートとしての役割を担います。
ユーザー、グループ、ワークフローの例を確認したい
ユーザープロファイルとグループプロファイルの実践的な図と、それらの権限の詳細を説明するセキュリティマトリックスを次に示します。
- 作成者はページを作成または既存のページを編集します。特定の承認ワークフローをトリガーするメタデータやタグなどのアセットをアップロードおよび変更します。
- クリエイティブチームは、アセットやコンテンツの表示、アップロード、編集を行います。
- 開発 QA チームは、表示アクセス権のみを持っています。機能の健全性テストを実行し、視覚的なエラーがないことを確認します。また、アクセシビリティや分析についてもチェックします。
- プロダクトオーナーは、最終的にサインオフし、コンテンツを承認します。
- リーダーシップは、ページと関連アセットが公開、承認されると、通知を受け取ります。
大規模なチームのワークフロー
- クリエイティブ がエクスペリエンスのコンテンツを作成します。
- 作成者 がワークフローをトリガーにするメタデータを含むコンテンツをアップロード、設定します。
- QA チーム がページ全体を確認し、ワークフローを次の手順に進めます。
- プロダクトオーナー には、変更とワークフローの承認に対する最終的なサインオフがあります。
- リーダーシップ は、ワークフローが承認され、リーダーシップグループにメールが送信されると、結果を確認します。
小規模なチームのワークフロー
- クリエイティブ がコンテンツを作成およびオーサリングし、ワークフローをトリガーします。
- QA チーム がページ全体を確認し、ワークフローを次の手順に進めます。
- プロダクトオーナー には、変更とワークフローの承認に対する最終的なサインオフがあります。
DAM 管理者の役割を評価する方法をさらに詳しく理解したい
DAM システムが成熟するにつれて、DAM 管理者の役割はますます重要になります。
社内知識:時間が経つと、DAM 管理者は大量の社内知識を蓄積するようになり、デジタルアセットを効果的に管理するための貴重なリソースになります。
チームの拡大:コンテンツと ROI が拡大すると、チームを拡大することが可能になります。チームメンバーは DAM 管理者の下で作業し、増加したコンテンツ取り込みを効率的に管理します。
システム開発:システムに関する深い知識があれば、DAM 管理者は、ビジネスの成長やニーズの発展に合わせて、開発や将来の機能強化を支援できます。
推奨事項の強化:豊富な実践経験があれば、DAM 管理者は、システム改善に関する十分な情報に基づいた提案を行い、DAM のパフォーマンスとユーザーエクスペリエンスをさらに最適化できます。
導入後の Experience Manager 管理について理解したい
最初の実装の後、技術チームと事業部門の間で定期的なチェックインが必要です。これらのチェックインでは、ユーザーエクスペリエンスについて話し合い、問題を特定し、新機能や機能に関するフィードバックを収集する必要があります。さらに、作成者やビジネスユーザーが発生したバグや技術的な問題をレポートするための追加のプロセスを定義し、確立する必要があります。技術チームは、これらの問題に迅速に対処し、更新を作成者やビジネスユーザーに伝える必要があります。これらのプロセスを実装することで、システム効率が向上し、エンドユーザーのエクスペリエンスが向上します。
3 か月経過時の考慮事項
ガバナンス委員会:発見と実施の一環としてガバナンス委員会を設置することがベストプラクティスです。機能に関する方向性を示した関係者は、システムの長期的な健全性に必要な分類と権限を引き続き支持するビジネス担当者および技術担当者の選択を支援できます。
ワークフローの最適化:最初の実装の後、チームは、コンテンツワークフロー内の手順が複雑すぎるか不十分であると感じる場合があります。コンテンツワークフローを確認して最適化し、生産性を最大限に高めることをお勧めします。
追加のトレーニング:最初の実装が完了すると、チームで追加のサポートやトレーニングが必要な場所が明確になります。メタデータの強化、カスタム属性の追加、新しい製品や統合のワークフローへの追加など、プラットフォーム固有の詳細には通常、追加のサポートが必要です。
6 か月経過時の考慮事項
役割と責務:最初の実装が完了し、チームがコンテンツワークフローの一部を確立して最適化したら、役割と責務を確認することをお勧めします。多くの場合、QA やコンテンツ作成者などといった役割は、フル稼働する必要がなくなります。これらのチームメンバーは、多くの場合、別のプロジェクトに移動したり、現在のプロジェクト内で異なる役割を見つけたりします。
12 か月経過時の考慮事項
定期的なプロセスと標準のレビュー:実装から 1 年後、チームは現在のすべてのプロセスとワークフローをレビューして、現在のビジネスニーズと要件に合致していることを確認する必要があります。一部のプロセスが現在のニーズに合わなくなったり、生産性を向上させるために最適化できたりする可能性があります。現在のプロセスをレビューして、生産性を毎年最大化しましょう。
コンテンツのトラッキングと最適化:実装の初年度の後、コンテンツ戦略とパフォーマンスをレビューします。例えば、アクションを呼び出す一部のアクションが他のアクションを上回っていないか、または一部の画像が他の画像よりも影響が大きいかどうかを評価します。コンテンツのパフォーマンスを分析チームと共に確認して追跡中であることを確認し、適切なアクションを実行してコンテンツを強化します。