グローバル企業を中心に導入が進むAdobe Experience Manager（AEM）。前編（なぜAEMを推薦するのか？――ツール選定の背景）では、AEMがなぜ多くの企業に選ばれているのか、その多機能性や導入メリットについて紹介しました。

一方で、AEMの導入を成功に導くには、ツールの機能理解だけでなく「要件定義」の設計が欠かせません。承認フローや権限管理、多言語対応、移行計画など、最初の整理を丁寧に定義しておくことで、公開直前のトラブルや予算超過といったリスクを防ぎ、スムーズな運用につなげられます。

後編では、AEM導入プロジェクトを数多く手がけるBusiness Architects（ビジネス・アーキテクツ、以下BA）の事業部長の小山とプロジェクトマネージャーの野島が、現場で培った知見をもとに「要件定義の勘どころ」を解説します。

CMS選定の背景と企業が抱える課題

前編の記事では、AEMの魅力や導入のメリットが良くわかりました。では実際にAEMへの移行プロジェクトを立ち上げる際、お二人はどういった点に気をつけていますか？

小山：プロジェクトの起点となる「要件定義」がとくに重要になります。AEMに移行されるお客さまというのは、前編でお話ししたとおり、グローバルに事業を展開するエンタープライズ企業が多く、数千ページ規模のWebサイトを複数言語・複数リージョンで運用し、国や拠点ごとに多くのメンバーが関わっているケースも珍しくありません。

そのような状況で、仕様の途中変更が起きてしまうとプロジェクトの致命傷になります。

ですから、承認フローや権限設定、多言語対応（ライブコピー機能、言語コピー機能）の設計は、最初に固めておくべき重要事項です。さらにクラウド前提なので、運用自体を“プロダクト”として設計する感覚が必要だと思います。

野島：小山さんの言うように、開発途中で頻繁に仕様変更や機能追加が発生してしまうと、AEMのような複雑なシステムでは、膨大な手戻りが発生してしまいますよね。

結果として、当初の予算を大幅に超過、公開スケジュールが大幅に遅延、なんて事態にもなりかねません。逆に要件定義をしっかりと行っておけば、手戻りを最小限に抑え、スケジュールの遅延や予算オーバーを防ぐことができます。

要件定義が不十分だったために、生じやすい問題は何ですか？

小山：「ワークフローや承認フローが現場の実態にあっていない」という実際の運用面の問題が多いですね。それにより、「承認が滞って公開が遅れる」「結局、メールや口頭で回してしまい、承認フローのシステムが形骸化する」といった残念な状態になってしまいます。

また、移行要件を曖昧にしたまま開発を進めると、公開直前に「旧サイトのデータが一部移行されていないことが発覚した」という事態にもなりかねません。

スケジュールの遅延やコストの超過に直結するこうした問題は、要件定義の段階で丁寧に洗い出しておけば防げるものです。

野島：「承認」と並んで、「権限」も問題が起こりやすいですよね。要件定義の段階で厳密な権限設定は決められないとしても、どのようなグループがあって、どのような権限を付与するのかなど、ある程度のレベルまでは権限内容を決めておく必要があると思います。

とりわけAEMでは、緻密な権限設定が可能なゆえに、設定ミスや運用ルールの不備を招きやすいという面もあります。

必要な人が作業できずスムーズな運用が妨げられてしまう、という事態を防ぐためにも、担当者への権限付与ミスをなくし、部署間のアクセス制限を適切に行うことが大切です。

要件定義において抑えるべき5つのポイント

要件定義は、一般に①業務要件、②機能要件、③システム要件、④環境要件、⑤移行要件の5つの要素から構成されます。

それぞれのポイントを教えてください。まず①業務要件を整理する際、クライアントに必ず聞く質問は何でしょうか？

小山：前述の承認や権限の問題と関わることですが、「誰が」「どのコンテンツを」「どの頻度で更新するのか」は、必ず確認します。

現場の担当者からは「ページの更新ができればいい」とサラッと言われることも多いのですが、実際に企業として本当に求めているのは「ガバナンスの効いた情報発信」ということが多いわけです。

とりわけAEMの場合、承認フローや権限管理をどう設計するかが肝にもなるので、「本当の目的は何か」を掘り下げながら、将来の運用体制を見据えた質問を投げかけていますね。

野島：私は「現状のWebサイトや業務プロセスで、最も大きな課題は何か」を必ず質問します。やはり現場の方々が日々の運用で感じている具体的な問題を明らかにして、どのように改善するかを整理することがスタートになると思います。

では、②機能要件を考える際、どのような要素を意識するのでしょうか。

野島：AEMでは「コンポーネント（ページを作る部品）」の設計がポイントです。これを適当に作ってしまうと、似たような部品が乱立して管理が大変になり、時間もコストも膨らみます。

そこで、基本的にはAEMが標準で用意している「コアコンポーネント」を使うのがベストです。独自に作る「カスタムコンポーネント」は最小限に抑えた方が良いと考えています。なぜなら、カスタムは将来的にAdobe社のサポートが効かなくなる可能性があるからです。

次の質問です。③システム要件を設計する際に意識している点は？

小山：3つあります。

1つ目は「いかに止めないか」。そのために、たとえば「稼働率99.9％＝月43分までの停止」などと稼働に関するSLO（サービスレベル目標）をしっかり決めます。

稼働が止まってしまった場合も想定して、RTO（リカバリータイム目標）と連絡フロー、切り戻し手順まで合意を取っておきます。

2つ目は「増えることを前提にする」。国・ブランド・コンテンツ量が増えることを見越して、増やし方のルールなどをあらかじめ決めておき、“増やす運用”を設計します。それができれば、後から慌てることもありません。

そして3つ目は、「いかに守るか」。誰が見られるか、誰が更新できるか、ログをどれだけ残すか、個人情報を扱うかどうかなどを明確にしておきます。繰り返しになりますが、やはり「承認」と「権限」は、とくにAEMの運用において重要なポイントになります。

④環境要件でとくに難しいのは、どういった場面ですか？

野島：責任範囲の線引き・定義が重要だと思います。AEMの運用では、Adobe社・開発ベンダー・クライアント企業さまの3社で役割分担を明確にしないと、トラブル時に責任の所在がわからなくなってしまいます。具体的には「パフォーマンスが落ちた際に誰が調査するのか？」などを事前に決めておきます。

小山：また、社内の情報システム部門やセキュリティ部門との調整も大事です。シングルサインオン（SSO）やコンテンツデリバリーネットワーク（CDN）、ログの管理などを後回しにすると、プロジェクト終盤でトラブルになり、スケジュールに大きく影響します。要件定義の段階で関係部門を巻き込むのを意識するのが大事です。

⑤移行要件において、よくある落とし穴とその回避方法について教えてください。

小山：よくある失敗は「移行対象を最後まで決めきれていない」ことです。数千ページある中で「残すページ・捨てるページ」「移すデータ・移さないデータ」を曖昧にすると、公開直前に大きなトラブルになります。棚卸しを徹底することが重要です。

野島：移行は半年〜1年かけて進めるのが一般的ですが、その間も現行サイトは更新され続けます。この「差分」をどう扱うかを決めておかないと、公開時にデータがあわなくなります。

「いつの時点のデータを使い、どの期間の差分を反映するか」を日付レベルで定義し、差分の管理方法を決めておく必要があります。それにはクライアント企業さまの協力も欠かせません。

プロジェクト現場での学び

プロジェクトを成功に導くために、お二人がとくに重視していることは何ですか？

小山：クライアントの担当者と丁寧なコミュニケーションを取り、「期待値と成果物のギャップをなくす」ということです。Webサイトのリニューアルプロジェクトというのは、多くの場合、クライアントの皆さまにとってはコア業務ではありません。

そのため、「アジャイル」や「スクラム」といったように、密な連携が必要な開発手法は難しいケースも多々あります。そういった点からも「ウォーターフォール型」の進め方は、予算や進め方を考慮すると大企業のAEM移行プロジェクトにあっていると思いますが、“最終成果物”と“クライアントの皆さまが想像する期待値”とのギャップは、アジャイル型のプロジェクトよりも起こりがちです。

そうならないよう、BAではプロトタイピングで実際に動くものを、要所要所でクライアントの皆さまに見ていただくことで、後戻りをなくすようにしています。

野島：情報やデータの管理も重要ですね。プロジェクトでは、さまざまな情報・データが飛び交いますから、それらを整理してわかりやすくまとめることを意識しています。

プロジェクトマネージャー自身で整理するもの、デザイナー・エンジニアが整理するもの、クライアントの皆さまに整理いただくもの……と役割を明確にして作業を割り振ることも大切です。

クライアントの担当者のご負担を減らすためにも、その情報整理のタタキ台をこちらで用意して、穴埋めしていただくなどのサポートも行うようにしています。

では、チーム内で異なる職種のメンバーと連携する際に心がけていることは？

野島：「タスクの背景を共有し、プロジェクト全体への共通認識をもつこと」です。

プロジェクトマネージャーとして、単に「このタスクをやってください」とメンバーに依頼するのではなく、「なぜこのタスクが必要なのか」「このタスクがプロジェクト全体にどう影響するのか」といった背景や目的を明確に伝えるようにしています。

これにより、各メンバーは自分の担当範囲だけでなく、プロジェクト全体における自身の役割を理解してくれます。結果として、“受け身の作業”ではなく、プロジェクトの一員として、自律的により良いアウトプットを目指すようになる。モチベーションも上がり、作業効率も上がると思いますね。

小山：「誰がやるか」ではなく、「誰がどの成果物に責任をもつか」を先に決めることも大事です。

AEMは設計とコンポーネント・テンプレートさえ固まれば、GUI（グラフィカルユーザーインターフェース）で見たまま編集できます。つまり、誰でも触れるわけです。だからこそ、「触れる自由」と「出す責任」を分けることが重要なのです。

具体的には、成果物ごとに責任者と完了条件（DoD）を明文化します。責任の単位を“人”から“成果物”に移す。これだけで連携の摩擦はかなり減りますし、成果物の質も高まります。

最後に今後の展望をお聞かせください。

野島：ありがたいことにAEM案件が増え、BA全体でノウハウがたまってきました。今後はそれを標準化して社内で共有し、安定した進行体制を整えたいと考えています。

そのうえで、必要なカスタマイズにしっかりリソースを割けるようにし、成果物の質をさらに高めていきます。

小山：AEMのソリューションパートナーとしてのBAの強みは「企画から開発、そして運用まで一貫して支援できること」です。これまでAEMをフルCMSとして提供してきましたが、最近ではヘッドレスCMSとしても柔軟に活用できます。

マーケティングとの連携を強化しながら、お客さまの課題解決にさらに貢献できる提案をしていきたいですね。ぜひ今後にもご期待ください。

要件定義は、成果を最大化する“運用戦略”

AEMの導入を成功させるには、単にツールを導入するだけではなく、承認フローや権限設計、多言語対応、移行範囲の明確化などを初期段階で丁寧に定義することが欠かせません。
こうした要件定義の質が、公開後の運用効率や成果に直結します。

BAはAEMを数多く支援してきた中で、「要件定義＝運用戦略」であると考えています。導入時にどの機能をどう活用し、どの業務をどこまでAEMに任せるかを設計することこそが、プロジェクトの成功を左右する鍵です。

要件定義は単なる仕様づくりではなく、導入後の運用をどう設計し、どのように成果を最大化するかを描く“戦略”そのものです。 BAはAEMのソリューションパートナーとして、企画から設計・構築・運用までを一貫して支援し、クライアントとともに最適な運用モデルを形づくります。
AEMの導入や運用に課題を感じている方は、ぜひお気軽にご相談ください。