用語集

この用語集リストは、プロジェクトチェックリストのすべての成果物ドキュメントの詳細を（別途）説明しています。

ビジネス関係者からの受け入れ

ビジネス関係者からの受け入れでは、ビジネス関係者が、主要な関係者として、ソリューションに準拠し、ビジネス要件によってビジネス事例を満たす方法について承認していることを確認します。

受け入れテスト

受け入れテストは、アプリケーションを実稼動する準備が整ったときに実行されます。テストは、様々なタイプのエンドユーザーを代表するグループによって、現実的なシナリオを使用して実行されます。

受け入れテストは、以下を確認するためにおこないます。

• プロジェクトが顧客の要求を満たしている。
• ソリューションが目的に適合している。
• ユーザーがソリューションを受け入れ、対応を思い描くことができる。
• 顧客がプロジェクトを承認する。

受け入れテストの計画および設計が早いほど、最終的なデプロイが容易になります。受け入れテストは、顧客および品質保証チームと共に定義する必要があります。

プロジェクトの開始に詳細をすべて定義できない場合もありますが、初期の定義については、話し合い、同意を得る必要があります。 受け入れテストは、多くの場合、基本的な要件（機能およびパフォーマンス）に基づいておこなわれます。

テストシステムへのアクセスの調整

すべての役割に対して、必要なシステムアクセスレベルが付与されていることを確認します。

アドビのセキュリティチェックリスト

アドビのセキュリティチェックリストは、インストール時に AEM のセキュリティが保護されていることを確認するために提供されている公式のチェックリストです。インスタンスの整合性を確保するためにおこなう必要のあるセキュリティ対策や検証手順が含まれています。

アドビのサポートポータルのプロジェクト設定

アドビのサポートポータルを使用すると、実装のパートナーや顧客は、サポートポータル内で AEM 実装をプロジェクトとして設定できます。

例えば、実装されるテクノロジーやバージョンに関してなど、詳細を登録できます。これにより、顧客とアドビの間に透過性が提供されます。

AEM 管理者トレーニング

ソリューションの管理スタッフのためのトレーニングです。詳しくは、アドビのトレーニングサービスを参照してください。

AEM 作成者トレーニング

ソリューションのコンテンツを生成（オーサリング）するスタッフのためのトレーニングです。詳しくは、アドビのトレーニングサービスを参照してください。

AEM の認定試験

適切なペルソナが関連する認定試験の受験者として登録されていることを確認します。

AEM 認定

適切なペルソナが関連する認定試験に合格していることを確認します。

AEM テクニカルトレーニング

適切な担当者向けの技術トレーニングを提供する例えば、開発者、建築家、エンジニア、ビジネス従事者などです。

プロジェクトの目標として定義された KPI に対する合意

主要業績評価指標（KPI）は、組織の目標や目的に向けた進行状況を定義および測定するのに役立ちます。組織は、ミッションを分析し、目標を定義したら、目標に向けた進行状況を測定する必要があります。KPI は測定のためのメカニズムを提供します。

ビジネス KPI とパフォーマンス KPI の一致

ビジネスとパフォーマンスの主要業績評価指標（KPI）を一致させると、組織内の関係者や関係プロセスをまとめるのに役立ちます。これにより、ビジネス目標への到達や提案された目的の達成に必要な時間と労力を削減できます。

コンテンツアーキテクチャと KPI の一致

提案されたコンテンツアーキテクチャが関連する主要業績評価指標（KPI）と一致することを確認します。

顧客ロードマップとプロジェクトタイムラインの一致

顧客ロードマップは、大まかなマイルストーンとビジネス目標で構成されています。プロジェクトタイムラインでは、この戦略を順守することにより、潜在的なリスクや逸脱を明確化し、追跡する必要があります。

アプリケーションアーキテクチャの定義

アプリケーションアーキテクチャは、提案されたアプリケーションの動作を明確に定義する必要があります。

以下に焦点が当てられています。

• アプリケーション間、およびアプリケーションとユーザーとの相互動作。
• 内部構造ではなく、アプリケーションによって消費および生成されるデータ。

アプリケーション固有のメンテナンスタスクの定義

Adobe Experience Manager（AEM）の標準的なメンテナンスタスクとは別に、ソリューションの継続的なメンテナンスのために必要なその他の運用タスクを定義する必要があります。

適切なトレーニングを受けたスタッフ

適切なトレーニングを受けたスタッフでチームが構成されていることを確認します。プロジェクトチームには、次のメンバーをすべて配置することをお勧めします。

• aem認定リード開発者が少なくとも1人

• aem認定アーキテクトを少なくとも1人

• 少なくとも75%の開発者がAEM認定を受けています。

  これにより、認定された開発者はジュニア開発者を指導し、知識の共有と透明性を確保できます。

アーキテクチャ図

アーキテクチャ図は、アーキテクチャを図で表現したものです。以下の表現が含まれています。

• 概念
• 概念の原則
• アーキテクチャの一部である要素およびコンポーネント

アーキテクチャのドラフト

システムおよびソリューションのアーキテクチャの概要を提供します。この段階ではドラフトであり、後続の段階でレビューされ、改善されます。

アーキテクチャレビューボードの承認

アーキテクチャレビューボードは、組織をまたがった体制であり、以下の役割を担っています。

• 一貫した戦略の実施を監督する
• システム内の整合性を確保

レビューボードは、アーキテクチャに関与するすべての主要な関係者の代表である必要があります。通常は、アーキテクチャ全体のレビューやメンテナンスを担当する幹部のグループで構成されます。

自動化テストスイートの実際のコンテンツへの適合および結果と KPI の比較

自動化スクリプトおよび自動化された基本事例は次のとおりです。

• 実稼動コンテンツに適合させる
• KPI に照らしてチェックする

自動テスト戦略

この戦略では、再利用可能な自動スクリプトのフレームワークを、品質保証（QA）チームによって計画されたアプローチとともに定義します。自動テストの全体的な計画の概要を説明し、以下を実現できるようにします。

• 投資利益率（ROI）の向上
• テスト範囲の拡大
• 質の高いテストを繰り返すことによるテストの信頼性の向上

自動テスト戦略を実際に想定される負荷に対して検証

自動テスト戦略は、ソリューションのコンテンツおよび想定される負荷に従って検証し、調整する必要があります。

自動化戦略

デプロイメントを自動化すると、短時間で一貫したデプロイメントが可能になります。自動化戦略では、以下を含むこのような自動化メカニズムの設定の概要を説明します。

• 頻度
• 使用するツール
• デプロイ先の環境

コミュニケーション計画の認識

プロジェクトチーム全体およびすべての関係者が、以下のことを認識しておく必要があります。

• レポート構造
• レポートのサイクル
• コミュニケーションのチャネル

成功の定義および条件の認識

プロジェクトチーム全体およびすべての関係者が、以下のことを認識しておく必要があります。

• 成功の定義
• 成功の条件

バックアップと復元の概念

バックアップと復元の概念では、ソリューションで実装される技術的機能の概要を説明します。会社のバックアップおよび復元ポリシーで必要となります。

バックアップと復元のテスト

バックアップと復元の概念に基づいた完全なエンドツーエンドのテストです。

ビジネス事例

ビジネス事例ドキュメントでは、アクションの実行、代替アクションの実行（可能な場合）、またはアクションを実行しないことに関連する議論を示します。この議論は、具体的事実（可能な場合や関連性がある場合）に基づいてバランスを取り、すべての事例のメリットとリスクの両方を示す必要があります。

ビジネス事例ドキュメントは、すべてのオプションを明確に定義するものとし、提案されたソリューションの実装に関する説得力のある議論で締めくくる必要があります。

ビジネスアナリストによるプロジェクトの範囲および期待の理解

ビジネスアナリストは、以下を完全に理解していることを確認する必要があります。

• プロジェクトの範囲
• 顧客のすべての期待
• これが、ペルソナごと、プロジェクトのフェーズごとに下されるすべての決定の基礎となること

ビジネス KPI

組織は主要業績評価指標（KPI）を使用して、ターゲット達成の成功を評価します。

ビジネス KPI は、会社が主要なビジネス目的をいかに効果的に達成しているかを示す測定可能値を定義します。実際のビジネスやシナリオに適した KPI を選択することが重要です。その KPI が何であるか、どのように測定するか、誰がどのように使用するかを明確に定義する必要があります。

ビジネス要件ドキュメント

ビジネス要件ドキュメント（BRD）では、プロジェクトのビジネスソリューションの詳細を説明し、顧客のビジネスニーズおよび期待を明確に指定しています。また、BRD では、ビジネスソリューションとテクニカルソリューションが区別されます。

BRDは、ビジネス・ソリューションを検討する際に、次の質問に答える必要があります。「この商売は何をしたいの？」

ソリューションへの必要な調整および ROI や KPI 期待値に対して特定され、準拠したアーキテクチャに関するビジネスの承認

リスク評価と侵入テストのプロセスにより、ソリューションのアーキテクチャまたは開発で対応が必要な問題や結果が発生する場合があります。

これらのプロセスの結果による調整はすべて、ビジネスがレビューおよび承認し、全体的な目標に適合させる必要があります。

キャッシュ戦略

キャッシュ戦略では、エンドユーザー用に何をキャッシュするかの概要を説明します。パフォーマンス KPI に準拠する必要があります。

例えば、画像、JavaScript およびその他のサーバーファイルなどの要素は、ソリューションのパフォーマンスを向上させるためにキャッシュできます。

コーディングのガイドライン

コーディングのガイドラインは、開発者がソリューション開発時に順守する必要のある基本原則を定義します。この原則には、特に以下のようなものがあります。

• 命名規則
• サービスの使用状況
• ライブラリの使用状況

運用マニュアルの伝達

該当するすべてのペルソナ／役割が運用マニュアルを受け取っていることを確認します。

パフォーマンステストレポートの伝達

該当するすべてのペルソナ／役割がパフォーマンステストレポートを受け取っていることを確認します。

リリースノートの伝達

該当するすべてのペルソナ／役割がリリースノートを受け取っていることを確認します。

チームへの範囲および期待の伝達

遂行するプロジェクトの範囲および期待についてプロジェクトチームが完全に認識し、準拠していることを確認します。

トレーニング資料およびユーザーガイドの伝達

該当するすべてのペルソナ／役割がトレーニング資料とユーザーガイドを受け取っていることを確認します。

顧客のセキュリティ要件への準拠

顧客のセキュリティ要件がすべて揃っていることを確認します。

セキュリティ概念への準拠

セキュリティ概念が揃っていることを確認します。

コンポーネントとテンプレートの関係の概念

新しいアプリケーションで使用されるテンプレートおよびコンポーネントの概要です。特に継承ルール、権限、関係などの詳細が含まれます。

コンポーネントとテンプレートの関係の仕様

コンポーネントとテンプレートの関係の概念の詳細です。

コンポーネントの仕様

実装される各コンポーネントの仕様の詳細です。

外部インターフェイスのモックアップの概念

開発環境やテスト環境に公開されていない、または使用できない可能性のある外部インターフェイスに対処するための開発方法およびテスト方法に関する概念です。

テストが可能な限り実稼動に近い動作になるように、これらのインターフェイスのモックアップを計画および実装します。

コンテンツアーキテクチャドキュメント

提案されたコンテンツのアーキテクチャのドキュメントです。詳細には、特に以下を含める必要があります。

• コンテンツツリー
• タグ付けの概念
• コンテンツを再利用するための戦略

コンテンツを移行するための検証

新しいソリューションに移行するために、レガシーシステムのコンテンツがレビューされ、選択したコンテンツが検証されます。

契約のドラフト

法的契約の最初のドラフトです。

現在のコンテンツの構造と形式

現在のコンテンツのアーキテクチャおよび形式に関するドキュメントです。これを使用して、今後のコンテンツアーキテクチャが生成されます。移行の概念にも使用されます。

顧客のバックアップと復元のポリシー

以下に関する顧客のポリシーです。

• データとソリューションの両方のバックアッププロセス
• バックアップのストレージ
• バックアップが期待どおりにおこなわれていることの確認
• 障害が発生した場合の復元

顧客のコーディングガイドライン

開発方法に関する顧客からのガイドライン／要件です。

顧客のデプロイメント／リリースポリシー

デプロイメント／リリースをおこなう方法および時期を定義する顧客のポリシーです。

多くの場合、タイムライン、スケジュール、承認の要件が含まれます。

顧客の監視のポリシーまたは要件

監視対象に関する顧客のポリシーおよび要件です。監視の概念で指定されている推奨事項に追加して指定されます。

顧客の実稼動リリーススケジュール

実稼動環境へのリリースに関して顧客が定義しているスケジュールです。

顧客のレポートのポリシーまたは要件

レポートに関して顧客が定めているポリシーや要件です。これには以下のような内容が含まれます。

• 特定のレポートの提供頻度
• 特定のレポートの形式
• 特殊な要件

顧客ロードマップ

技術とビジネスの両面で、実装する主要なマイルストーンのロードマップを策定します。このロードマップは、その後顧客に伝達されます。

顧客のセキュリティポリシー

顧客（ビジネスおよび IT）は、ソリューションに必要なセキュリティレベルを定義するポリシーを定めます。これには以下のような内容が含まれます。

• リスク評価にパスするための要件。
• 侵入テストにパスするための要件。
• すべての入力フィールドのエスケープ、暗号化の使用（SSL）、証明書、認証とセッションなど、具体的なセキュリティ要件。

顧客の仕様ガイドライン

仕様の形式、提供および承認に関連する顧客のガイドラインです。

顧客のテストレポート

ユーザー受け入れテスト（UAT）期間中の、顧客から品質リーダーへのレポートです。

アップグレードに影響するカスタマイズやホットフィックスの文書化

今後のアップグレードに影響する可能性があるので、カスタマイズや適用されているホットフィックスはすべて文書化する必要があります。

• AEM は、ビジネスニーズに合わせて大幅にカスタマイズできます。アップグレードに影響する可能性のあるカスタマイズはすべて完全に文書化する必要があります。例えば、AEMのユーザーインターフェイス(UI)に対する大きな変更があった場合、

• 以下のような現在のソリューションに必要な更新はすべて完全に文書化する必要があります。

  • 累積修正パック（CFP）
  • サービスパック（SP）
  • ホットフィックス
  • アップグレード

ユーザー受け入れテストの日別レポート

ユーザー受け入れテスト（UAT）の結果のレポートまたは会議です。以下の詳細を説明する必要があります。

• 報告対象の問題
• これらの問題の優先順位

デフォルトのセキュリティの有効化

AEM のデフォルトのセキュリティ設定が有効化／実装されるようにします。

デプロイメント／リリースのポリシーおよびプロセス

プロジェクトのデプロイメントとリリースの両方に対応する、形式化されたポリシーです。これには以下のような内容が含まれます。

• リリースの時期
• 休日計画
• 頻度
• 対象となる環境に依存する内容

デプロイメントのサイクルの確立

複数の環境にまたがったデプロイメントに必要な頻度を定義します。

開発方法

ソフトウェアの開発では、ソフトウェア開発作業のプロセス全体を個別のフェーズ（段階）に分割し、それぞれで異なるアクティビティをおこなう方法が採用されています。目的は、計画や管理をしやすくすることです。

方法を定義するときは、プロジェクトチームによって作成され、完成される特定の成果物およびアーティファクトを事前に定義して、アプリケーションを開発またはメンテナンスする必要があります。

開発の役割の定義

ソリューションの中で、IT（パフォーマンスその他）テストや単体テストを実施する開発者や役割を定義します。

開発環境の準備

デプロイメントの自動化に必要な統合されたツールを含めて開発環境が設定されていることを確認します。

開発チームによるプロジェクトの範囲および期待の理解

開発チームは、以下を完全に理解していることを確認する必要があります。

• プロジェクトの範囲
• 顧客のすべての期待
• これが、ペルソナごと、プロジェクトのフェーズごとに下されるすべての決定の基礎となること

ダイアログの仕様

ソリューションに必要なダイアログに関する詳細です。

開発環境の設定の文書化

開発環境のドキュメントです。

実稼動環境の設定の文書化

実稼動環境のドキュメントです。

テスト環境の設定の文書化

テスト環境のドキュメントです。

耐久性テスト

耐久性テストは、特定の負荷の下でのソリューションのパフォーマンスを示します。このテストでは、しきい値の負荷を受けたときに、ソリューションがどのくらいの時間、どのようなパフォーマンスレベルで存続するかを測定します。

耐久性テストの実施

耐久性テストを実施します。

エラー処理の概念

エラー処理とは、プログラミング、アプリケーションおよび通信のエラーを予測し、検出し、解決することです。

エラー処理のドキュメント

エラー処理の概念に基づいた、提案されたエラー処理の詳細なドキュメントです。

エスカレーションプロセス

すべてのエスカレーションプロセスを定義します。プロジェクトレベルごとに別々のプロセスがあります。

• プロジェクトチーム
• 顧客
• アドビ

定期的な品質レビューセッションの実施

適切なチームメンバーで定期的な品質レビュー会議を実施します。

既存の権限の構造

レガシーソリューション用に、または組織内で定義されている、一連の既存の権限やグループのドキュメントです。

既存のシステムマップ

既存のシステムおよび依存関係の図（または一連の図）です。

期待される成功の定義および条件

プロジェクトスポンサーは、プロジェクトの成功に関連するビジネスの期待事項を収集します。プロジェクトの開始時に期待されるすべての内容が、導入全体で行われるすべての決定に影響を与えるので、期待される内容を十分に活用することが重要です。

以下のようなことが期待されます。

• ページの増加割合など、特定の KPI
• コンテンツ公開までの時間の短縮
• 使いやすいインターフェイスなどの高レベルの目標

エクスペリエンスデザインの要件

ソリューションの全体的なエクスペリエンスの要件です。特に、パーソナライゼージョン、クロスデバイスの永続性、ユーザーエクスペリエンスなどの要素をカバーします。

エクスペリエンスの仕様

エクスペリエンスデザインの要件の詳細です。

外部システムとユーザーの依存関係／システムコンテキスト

ソリューションのエコシステム全体の概要を説明する図（または一連の図）です。これには、外部の統合、インターフェイス、依存関係、ネットワークなどの要素が含まれます。

フォールバックシステムと手順

フォールバックシステムは次のように定義されます。

• 重大な障害が発生した場合でも動作の継続が求められるビジネスクリティカルな機能
• フォールバックの際に必要なプロセス

フォールバックシステムと手順のテスト

フォールバックシステムのエンドツーエンドのテストです。

ビジネス関係者からのフォールバックシステムの承認

フォールバックシステムおよび関連する手順によって重大なビジネス機能を確保するという、ビジネス関係者からの承認です。

KPI の実行可能性の確認

AEM と高レベルのソリューションデザインの実行可能性調査の結果です。これらを KPI に対して測定し、達成可能であることを確認する必要があります。

最終決定された契約

プロジェクトを進行させるには、最終決定され、署名された契約が必要です。これは契約のドラフトに基づきます。

関係者に受け入れられるソリューションの機能

関係者が以下を完全に受け入れることを確認します。

• ソリューションの機能
• ソリューションの既知問題

運用開始スケジュール

以下のために必要なアクティビティのタイムラインおよびスケジュールです。

• 運用開始の準備
• 実際の運用開始

ハッピーパスの定義

ハッピーパスとは、例外やエラーの状態のないデフォルトのシナリオのことです。すべてが期待どおりに進んだ場合に実行される一連のアクティビティから成っています。

ハードウェアの見積もり

以下の項目の初期の見積もりです。

• AEM の基本インストールに必要なハードウェア
• 高レベルのソリューションデザインに基づいた追加の要件

要件を満たすハードウェアが利用可能

すべての環境に必要最小限のハードウェアがインストールされることを確認します。

全体的な要件

全体的な要件を定義することにより、システムの要件が全般的に分類され、以下のような点をカバーします。

• ビジネスプロセス
• 主要なシステム機能

これらの機能に関する基本的な詳細は一般的に知られているので、このドキュメントは見積もりとしては使用できません。

高レベルのソリューションデザイン

高レベルのソリューションデザインでは、ソリューションの開発に使用するアーキテクチャについて説明します。アーキテクチャ図によってシステム全体の概要を示し、製品用に開発される主要なコンポーネントおよびそのインターフェイスを特定します。

全体的なシステムマップ

このシステムマップは、システムの非常に大まかな図を提供します。ソリューションコンテキストと異なる点は、関与するすべてのシステムの全般的なマップであり、この図にはインターフェイスが表示されないことです。

過去のコンテンツ構造

レガシーシステムのコンテンツ構造を定義します。参照用、および移行戦略を準備する際に使用します。

過去のパフォーマンスと過去のパフォーマンス KPI

パフォーマンス統計およびパフォーマンス KPI をレガシーシステムから収集して文書化する必要があります。これらは後に、基準点として使用されるか、または新しいソリューションのベンチマーク用に使用されます。

キーとなる最も重要なソリューションや機能の特定

ビジネスクリティカルな機能のリストです。

実装 - 侵入テストの結果に基づく変更

必要なすべての変更（承認済みのもの）を、侵入テストの結果に基づいてソリューションに実装します。

実装 - 自動テスト戦略

自動テストのサポートに必要なツールとプロセスを設定します。

実装 - 自動化戦略

自動化のサポートに必要なツールセットとプロセスを設定します。

実装 - コンテンツアーキテクチャ

コンテンツアーキテクチャ、タグ付けの概念およびコンテンツの再利用を実装します。

実装 - エクスペリエンスデザイン

エクスペリエンスデザインをサポートするための要件を実装します。

実装 - フォールバックシステムと手順

フォールバックシステムおよび関連する手順を実装します。

実装 - 統合

必要なすべての外部システムとともに統合を実装します。

実装 - 移行戦略

コンテンツの検証および新しいソリューションのその他のアーティファクトとともに移行します。

実装 - 役割と権利

役割と権利、ユーザーとグループを実装します。

実装 - セキュリティ概念

AEM のデフォルトを含めて、すべてのセキュリティ対策を実装します。

実装 - セキュリティソフトウェア

ソフトウェアアプリケーションのセキュリティを実装します。

実装 - システムアーキテクチャのセキュリティ概念

システムセキュリティを実装します。

実装 - URL 処理

URL 処理の概念を実装します。

実装 - ワークフロー

デザインされたワークフローを実装します。

実装概念

実装概念は、実装全体の指針を示します。以下の点を考慮する必要があります。

• 運用
• メンテナンス
• 互換性
• 再利用性
• セキュリティ
• スケーラビリティ

この概念では、ソリューションで使用するフレームワーク、ライブラリおよびその他のアーティファクトの概要も示すことができます。

運用開始のスケジュールをアドビサポートに通知

アドビサポートに連絡して、運用開始時に必要なサポートが有効になるようにします。

初期エクスペリエンスデザイン

エクスペリエンスのデザインに関する予備概念です。

統合テスト

内部と外部両方のすべての統合をテストし、結果を確認します。

自動化し、頻繁に実行して、システムの安定性を確保する必要があります。

問題追跡プロセス

明確なプロセスにより、発生するすべての問題を記録し、継続中のアクティビティを追跡します。目的は、確実にすべての問題に対処することです。

問題追跡システムとプロセス

追跡システムと必要なプロセスを同時に使用することにより、発生するすべての問題を記録し、継続中のアクティビティを追跡します。目的は、確実にすべての問題に対処することです。

プロジェクトのステータスの透過性を促進するために、プロジェクトの全関係者にアクセス権が必要です。

例として、Atlassian JIRA や HP Quality Center があります。

問題追跡プロセスの設定と統合

選択したツールは完全に統合され、必要なすべての役割に対してアクセス権が付与されます。

レガシーシステム

プロジェクトに関して、既存のテクノロジー、コンピューターシステムまたはアプリケーションプログラムであるレガシーシステムは、新しいソリューションに置き換えられます。

レガシーシステムの詳細を収集して、いつ何を使用停止にするかや、他のシステムへの影響を知っておく必要があります。

使用する開発ツールのリスト

実装で使用する、以下のようなツールの概要を示します。

• ドキュメントツール
• 問題追跡ツール
• デプロイメントツール
• ビルドツール

アドビのサポートポータルへのアクセスが必要なユーザーのリスト

アドビのサポートポータルへのアクセスが必要なすべてのユーザーおよび役割のリストです。

このリストは通常、ソリューションアーキテクトや顧客の IT スタッフで構成されます。

ログファイルの分析

分析およびその結果の推奨事項です。ソリューションを監視するには何をログに記録する必要があるかを定義します。

• ログに記録するアクティビティ
• 精度のレベル
• 各アクティビティに関してログに記録される情報

メンテナンスタスク（AEM 固有）のテストと有効化

次のような AEM メンテナンスタスクをテストして有効にします。

• コンパクション
• システムクリーン
• ワークフローのパージ

移行計画

以下を含めて、移行を文書化します。

• 移行のタイムライン
• 移行戦略に従ったコンテンツメンテナンス計画

移行戦略

既存のコンテンツ、コンテンツアーキテクチャおよび新しいソリューションにマップする形式を完全に説明します。以下をカバーする必要があります。

• 可能であれば、自動移行の技術的詳細
• 移行されたコンテンツを検証するために移行後に実行するスモークテスト

移行と新しいシステムの運用開始の間の期間に、コンテンツを最新の状態（または可能な限り最新の状態）に保つことも推奨します。つまり、コンテンツのフリーズ、二重公開、アルファシステムのメンテナンスなどが必要な場合があります。

監視 - CPU

ソリューションのシステム CPU 使用率を監視します。

• 平均
• ピーク

監視 - ディスク I/O

ソリューションのディスク入出力率を監視します。

• 平均
• ピーク

監視 - ディスク容量

ソリューションのディスク容量の使用状況を監視します。

• 平均
• 時間の経過に伴う増加

以下を使用して使用状況を監視する必要があります。

• リポジトリ
• ログファイル

監視 - 外部システム

ソリューションと外部システムの間の接続を監視します。

• トラフィック率
• ピーク
• 安定性

監視 - ネットワーク帯域幅

ソリューションによるネットワーク帯域幅の使用状況を監視します。

• 平均トラフィック率
• ピーク
• 安定性

監視 - リクエスト

ソリューションに対するリクエストを監視します。

監視 - セキュリティポイント

定義したセキュリティポイントで監視します。

監視 - システム

システム全体で以下を監視します。

• 可用性
• 平均パフォーマンス
• パフォーマンスのピーク
• アラート

監視 - しきい値と介入

ソリューションで定義されているしきい値と、負荷を削減するための介入手順の実装を監視します。

監視の概念

ソリューションに適用される監視の概念です。以下が組み込まれます。

• AEM 標準監視
• システム監視
• 顧客に固有の監視要件

潜在的な弱点の監視

障害が発生しやすい点を特定し、定義する必要があります。これらに関連する監視タスクも定義する必要があります。

次に例を示します。

• 主要なワークフロー
• トランザクション処理
• 統合ポイント

監視ポリシーをシステムエンジニアに伝達

システムエンジニアおよびオペレーションスタッフが監視ポリシーについて理解していることを確認します。

監視レポート - 構造の準備

以下を定義します。

• 監視レポートを生成する場合
• 監視レポートを誰に提供するか

運用タスクの文書化

すべての運用タスクを、頻度を定義して文書化します。

運用マニュアル

ソリューションを正常に運用し、メンテナンスするために必要なすべての情報を提供するマニュアルです。

• すべての運用タスク
• 主要な連絡先
• デプロイメント計画
• デプロイメント前後のチェックリスト
• その他の重要なタスク

以下のための実装の概念も詳細に説明します。

• パフォーマンス KPI を満たすこと
• KPI を継続して満たすようにソリューションをスケーリングすること

パッケージの準備

ソフトウェアパッケージをビルドして提供し、デプロイメントの準備を整えます。

侵入テスト

侵入テストでは、コンピューターシステムを攻撃してセキュリティの弱点を探し、場合によってはコンピューターの機能やデータにアクセスします。

侵入テスト - パス

必要なすべての条件にパスしています。

侵入テスト - 結果

侵入テストの結果を説明するレポートがビジネス用に作成されます。

パフォーマンスとスケーラビリティの概念

実装がパフォーマンス KPI を満たすようにする方法、および KPI を継続して満たすようにソリューションをスケーリングする方法に関する概念ドキュメントです。

パフォーマンスベンチマーク

パフォーマンスベンチマークは、パフォーマンステスト、耐久性テストおよび監視を定義する際に使用します。これは、ソリューションとシステムハードウェアのパフォーマンス特性を評価することで行います。

パフォーマンス KPI

システムのパフォーマンスの測定に必要な主要業績評価指標（KPI）を定義します。例として、ページの読み込み時間、サーバーの応答時間、データベースのクエリパフォーマンスなどがあります。

パフォーマンステスト - レポート

ビジネス用に作成されるレポートです。パフォーマンステストの結果を詳細に説明します。

パフォーマンステスト - 結果がパフォーマンス KPI に一致

結果は、パフォーマンスに定義されている KPI および期待値に一致する必要があります。

ペルソナベースのテストの概念

ペルソナベースのテストは、エクスペリエンスデザインで概要を説明した様々なペルソナに基づいたメソッドです。アカウントおよび関連する権限レベルもテストします。

多くの場合、これはユーザー受け入れテスト（UAT）で使用されます。

要件ドキュメントに対する POC のテストおよび検証

要件に対して概念実証（POC）を測定して、双方が一致するようにします。

デプロイメント後のチェックリスト

各デプロイメント後に実行する一連のチェックやタスクを定義するチェックリストです。

デプロイメント前のチェックリスト

各デプロイメント前に実行する一連のチェックやタスクを定義するチェックリストです。

実稼動環境のベースラインパフォーマンステスト

通常、ベースラインテストは AEM の標準インストールで実行します。これはその後、実装およびハードウェアをテストするためのベンチマークとして使用されます。

実稼動環境の準備完了

自動デプロイメントが配置され、実稼動環境の準備が整っていることを確認します。

ビジネス関係者からの実稼動の承認

実稼動環境で運用を開始する前に、実稼動の承認（PSO）を受ける必要があります。これは、実稼動に移行するリリースおよび既知問題のレビューの結果を判断しておこなわれます。承認は、運用開始スケジュールの一環として与えられます。

実稼動の承認のプロセスとポリシー

パッケージを実稼動環境に移行する前に、実稼動の承認を得るために必要なポリシーとプロセスです。

プロジェクトのコミュニケーション計画

ビジネス関係者とプロジェクトチーム双方のコミュニケーション計画を定義します。

プロジェクトの労力 - 最終見積もり

初期見積もりは、大まかな見積もりであり、実装の大まかな要件に従っておこなわれています。

初期見積もりをレビュー、改善し、発展させて、最終見積もりを提供します。見積もりは、プロジェクト管理、コンサルティング、アーキテクチャ、テスト、開発などを担当する各プロジェクトリードが提供する必要があります。

これらの見積もりは、リソース配置や予算策定に使用されます。

プロジェクトの労力 - 初期見積もり

初期見積もりは、大まかな見積もりであり、実装の大まかな要件に従っておこなわれます。これが後の段階でレビューされ、改善されます。

プロジェクトの組織

プロジェクトとチームの組織およびレポート構造の概要を説明する必須ドキュメントです。

多くの場合、タイムラインや責務を視覚的に示すチャート形式か、チャートを含んでいます。これに役立つツールが多数あります。

プロジェクトの適用範囲のドキュメント

プロジェクトの適用範囲のドキュメントでは、以下のリストを特定し、文書化する必要があります。

• プロジェクトの具体的目標
• 成果物
• 機能
• 関数
• タスク
• 期限
• 計画されている労力

プロジェクトを遂行するための達成目標と、必要な作業をカバーしています。

定義されたサイクル内でのプロジェクトステータスレポート

同意されたスケジュールに従い、必要な形式で提供されるプロジェクトステータスレポートです。

概念実証（POC）

概念実証（POC）は、限られた範囲の機能をソリューションに実装します。

目的は、ソリューションの実行可能性を示し、必要な目的を達成できることを検証し、使用できることを証明することです。

パージルール

AEM は複数のバージョンのアセットおよびコンテンツを維持します。リポジトリのヘルスとサイズを維持するため、古いバージョンを定期的に削除する目的で、パージルールがデザインされ、設定されています。

品質レポートの形式とサイクル

品質レポートの必要なコンテンツと形式を、必要な提供頻度とともに定義します。

リリースの調整

プロジェクトマネージャーが、実稼動へのリリースに必要なすべての役割を調整します。

リリースノート

リリースノートは、リリースのためのドキュメントの一部です。リリースノートでは、以下の項目をカバーする必要があります。

• 前提条件
• 含まれている要件
• 解決された問題
• リリースの既知問題

ランブックとともに使用して、インストール前後の手順およびチェックを実行します。

実稼動環境で実行されるリリース

実稼動環境で実行され、アクティブ化される最終リリースです。

関連する契約条件

契約のマイルストーン、請求期間、スタッフの要件など、プロジェクトの実装に関連する契約条件を強調する必要があります。

レポートのサイクル

顧客とともに、提供するレポートの頻度を定義します。

リポジトリの最適化

tar ファイルではデータは上書きされないので、既存のデータを更新するだけの場合でもディスク使用量は増加します。

リポジトリのサイズが拡大し続けるのを避けるために、古くなったデータを削除する最適化戦略が用意されています。

アドビのサポートポータルにおけるプロジェクトセクションの設定リクエスト

アドビのサポートポータルでの、プロジェクト設定の正式なリクエストです。

要件のドキュメント

この一連のドキュメントは、機能および機能以外の要件と、推定される労力をカバーします。

サポートの運用開始で使用できるリソース

運用開始に必要なすべての役割にスタッフが配置され、稼動できることを確認します。

リスク評価

リスク評価は、顧客の IT 部門やセキュリティ部門によって実行されます。

プロジェクトの技術的、ビジネス的リスクを評価します。この評価は、ソリューションがセキュリティポリシーに準拠していることを確認するために必要です。

リスク緩和計画

リスク緩和計画にはリスク評価が含まれます。2 つ合わせて以下がカバーされています。

• 特定リスク
• 実装内でリスクが発生した場合に考えられるソリューション

ROI の期待値

ソリューションに結び付けられる投資利益率（ROI）の期待値を定義します。

目的は、予測される投資に関連して期待されるメリット／利益を定義することにより、経済的な意味でのソリューションの効率性を示すことです。

役割と権利の概念

新しいアプリケーションに必要な役割およびアクセス権に関連する概念の詳細な仕様です。以下の概要を含みます。

• 役割
• グループ
• ユーザー
• 権限
• ユーザー管理およびプロビジョニング

セキュリティガイドラインを満たす役割と権利の概念

役割と権利の概念をレビューして、セキュリティポリシーを満たしていることを確認します。

役割と権利の仕様

役割と権利の概念に基づいた詳細な仕様です。

セキュリティアーキテクチャの推奨事項

ソフトウェアおよびハードウェアのアーキテクチャのセキュリティに関連する推奨事項です。

セキュリティベースのコーディングガイドライン

これらのガイドラインでは、以下のようなセキュリティ要件に基づいて開発コーディングをおこなう方法を定義します。

• 命名規則
• ライブラリ
• フレームワークのガイドライン
• API の使用

セキュリティチェックリスト

セキュリティの概念およびソリューションの整合性を確保するために必要な追加のポリシーに基づいた、プロジェクト固有の項目のチェックリストです。

多くの場合、デプロイメント後の手順の一部としてランブックにも含まれます。

セキュリティの概念

アプリケーション、アーキテクチャおよびインフラストラクチャに必要なセキュリティ設定の詳細を定義して文書化します。

セキュリティ概念のドラフト

以下のセキュリティ設定をカバーする大まかな概要です。

• アプリケーション
• アーキテクチャ
• インフラストラクチャ

セキュリティ問題のリストと評価

ソリューションのセキュリティ問題をすべてリストし、評価します。労力の見積もりも含みます。

ビジネス関係者からのセキュリティの承認

セキュリティ実装がポリシーおよび期待に沿っていることを確認する、関係者からの承認です。

サポートプロセスの設定

必要なサポートプロセスを設定します。

サードパーティシステムの SLA

実装およびサポート時に使用できるように、サービス契約（SLA）が開発チームと運営チームの双方に伝達されていることを確認します。

スモークテストの概念

スモークテストは、ソリューションの主要な機能をテストして基本的な操作および機能を確保する、一連の定義済みの手順で構成されます。

インストールまたはデプロイメント後に、どの環境でも実行されます。

システム検証のためのスモークテストの実行

スモークテストは、すべてのシステム上で実行し、任意の環境へのインストール時またはデプロメント時にソリューションの基本機能が正常に動作することを確認する必要があります。

ソフトウェアのアーキテクチャの戦略

ソフトウェアのアーキテクチャの大まかな戦略です。サービス、サーブレット、フレームワークおよび実装に関するその他の決定が含まれます。

ソリューションレビューボードの設置と会議のサイクルの設定

ソリューションレビューボードは、通常は顧客の関係者で構成されます。

ボードは定期的に会議を開き、現在調査中の要件および関連する仕様を継続的にレビューします。目的は、成功の定義および条件を満たすことと、要件の開発に関する情報を提供することです。

ソリューションランブック

ソリューションのインストール手順と、インストールで実行する基本的な操作タスクです。

ソリューションの承認と受け入れのプロセス

承認と受け入れのプロセスでは、ソリューションを実稼動環境にリリースする前に満たす必要のある条件の概要を説明します。

契約のマイルストーンの役割も果たします。

特殊機能の概念

AEM プラットフォームでの通常の開発の範囲外とみなされる特殊機能の初期概念です。

特殊機能の仕様

AEM プラットフォームでの通常の開発の範囲外とみなされる特殊機能の詳細です。

仕様のガイドライン

仕様の指定方法に関する顧客からのガイドラインです。

仕様のレビューおよび承認プロセスの定義と伝達

顧客が仕様を承認する際の明確なプロセスを用意しておく必要があります。このプロセスにより、要件の範囲が明確かつ確固たるものとなります。

AEM 管理者トレーニングに選ばれたスタッフ

ソリューションを管理するためのトレーニングが必要な内部スタッフです。

作成者およびエンドユーザーのトレーニングに選ばれたスタッフ

ソリューションでオーサリングをおこなうためのトレーニングが必要な内部スタッフです。

関係者

関係者とは、プロジェクトに大きな利害関係を持つ主要な人物や役割のことです。プロジェクトの予算に貢献する場合もあります。

関係者は、内部の場合も外部の場合もあります。

関係者による成功の定義および条件の認識

実際の実装チーム外のすべての関係者が、以下を認識していることを確認します。

• 成功の定義
• 成功の条件

関係者によるプロジェクトおよび期待の理解

実際の実装チーム外のすべての関係者（プロジェクトチームと顧客の双方）が、全体的なプロジェクトと期待を理解していることを確認します。

ステータスレポートの形式の定義

ステータスレポートは、重要なコミュニケーションツールです。顧客からのレポート要件に沿った形式にする必要があります。

成功の条件および定義

顧客、プロジェクトスポンサーとプロジェクトマネージャーまたはコンサルタントは以下を指定する必要があります。

• 何がプロジェクトの成功を定義付けるか
• 成功の定義を満たすために必要とされる具体的な条件

これらを使用して、次のような場合に成功の基準が満たされるようにします。

• KPI の基礎として使用する場合
• 実装中に意思決定する場合

報告された問題の検証のサポート

品質リーダーの責務の一部は、テスト時にユーザーをサポートするリソースの存在を確認することです。例えば、テスト時や問題の報告時にユーザーを支援したり、テスト環境に対する問題の検証を支援したりします。

サポートプロセスおよびアドビのサポートポータルへのアクセス

アドビのサポートポータルへのアクセスは、実装時に発生する可能性のある製品ベースの問題に関して、チケットを送信する上で不可欠です。

チームの主要メンバーにアクセス権を割り当てる必要があります。

システムアーキテクチャの定義

ソリューションのすべての環境のアーキテクチャに関する初期の提案と定義です。

システムアーキテクチャのドキュメント

システムアーキテクチャを詳細に説明するドキュメントです。すべての環境のインターフェイス、ネットワークの場所および統合などの情報が含まれます。

システムアーキテクチャのセキュリティ概念

システムアーキテクチャをセキュリティポリシーに準拠させる方法の概要です。以下をカバーできます。

• ファイアウォールおよびファイアウォールのルール
• セキュリティゾーン
• ローカルおよび一般のトラフィックマネージャー
• Web サーバー
• プロキシおよびリバースプロキシ

システムリスク要因の特定および検証

リスク評価（またはその他のレビュー）で見つかったリスク要因を特定し、評価します。

• それぞれに含まれるリスクのレベル
• リスクに対処するために必要な実装を変更する上で予測される労力

チームによる成功の定義および条件の認識

成功の定義および条件をチーム全体が認識していることを確認します。

チームによるコミュニケーション計画の認識

顧客とのコミュニケーションの担当者、およびコミュニケーションの方法やタイミングの詳細について、チームの全メンバーが認識していることを確認します。

チームによるプロジェクトおよび期待の理解

プロジェクトチームと顧客の双方が、全体的なプロジェクトと期待を理解していることを確認します。

技術要件

これらの要件は、ソリューションをサポートするサービスの技術的な実装に固有です。

技術的リスク要因の検証

潜在的な技術的リスクを特定して検証します。技術的リスクには以下が含まれます。

• クロスサイトスクリプティング
• エンドユーザーが利用する入力フィールド
• インフラストラクチャ
• テクノロジーの老朽化
• 統合の数
• と依存関係

技術仕様

技術仕様は、特に以下の情報をカバーします。

• インターフェイス
• 設定
• API
• ソリューションの要件をサポートするサービス

テンプレートの仕様

必要なテンプレートの仕様です。parsys、ブループリント、継承マッピングなどの詳細をカバーします。

仕様は、ビジネス要件とエクスペリエンス要件に基づきます。

テストケース

ソリューションの機能テストを実行するために必要な詳細手順に固有のテストケースです。

テストコンテンツ

テストコンテンツは、可能な限り実稼動コンテンツに近付ける必要があります。すべてのシナリオをテストできる幅の広い値を選択する必要があります。

テスト環境の準備完了

テスト環境の準備が整っていることを確認します。自動デプロイメントを配置し、すべてのリリース候補コードがテスト用に最新の状態であることを確認します。

テストレポート

以下を含む、テストの結果を詳細に説明するレポートです。

• 発生した不具合
• 実行されたテストケースのステータス
• その他の品質関連トピック

次のことに注意してください。

• テストチームは中立を保ち、テスト結果を提供する必要があります。
• 結果に伴う影響を評価し、適切な対応を決定するのは、プロジェクトマネージャの責任です。

テストスイート

選択された自動化スイートおよびツールです。ユースケース用も含めて、テストを自動化するために使用されます。

テストツールスイートの選択

ユースケースの自動化およびその他のテスト実行タスク用に選択された自動化スイートおよびツールです。

テストの概念

テストの概念は、プロジェクトのテストの非常に大まかな概要を説明します。QA、UAT、パフォーマンス、セキュリティおよび統合テストが含まれます。

テスト計画

これらの計画は、テスト戦略に基づくものであり、開発の各フェーズでのテストの実行について詳細に説明します。

テスト範囲

これらの要件は、ソリューションをサポートするサービスの技術的な実装に固有です。

テスト戦略

テスト戦略では、品質保証およびユーザー受け入れテストのための戦略の概要を説明します。タイムライン、レポートのサイクルおよび実行が含まれます。

サードパーティ統合の概念

サードパーティシステムとの統合に関するアーキテクチャおよびシステムレベルの概念です。

サードパーティ統合の仕様

サードパーティシステムでサポートされている機能および統合に関する要件（機能と機能以外の両面）の詳細です。

サードパーティのセキュリティの概念

サードパーティ統合のセキュリティを確保するための概念です。適切なセキュリティポリシーに準拠する必要があります。

統合対象のサードパーティシステム

統合の実装対象となるすべてのサードパーティシステムと適切なドキュメントが揃っていることを確認します。

サードパーティシステムのアクセスの有効化

それぞれの役割に必要なアクセス権が付与され、サードパーティシステムとともに使用されます。

サードパーティのテストの概念

以下を定義します。

• 統合のテストの使用例
• サードパーティアプリケーションに関連する機能

しきい値の定義

システム内の監視ポイントの基準値を定義します。

次に例を示します。

• 未送信のログが何キロバイト（KB）に達したときにプリンシパルサーバーインスタンスで警告が生成されるか
• トランザクションあたりの平均遅延が何ミリ秒を超えたときにプリンシパルサーバーで警告が生成されるか

タイムラインとマイルストーン

以下に使用するプロジェクトのタイムラインと契約のマイルストーンを定義します。

• 請求
• 成功の定義、成功条件および KPI への準拠

プロジェクトの合計労力

プロジェクトの各リーダーからの労力の見積もりをすべて統合する必要があります。これにはオーバーヘッド、開発、システムエンジニアリング、アーキテクチャおよびテストの労力が含まれます。

サポートレベルが合意に含まれている場合は、サポートと運用の労力も含める必要があります。

トレーニング資料

トレーニングセッションで使用する資料です。資料は該当するソリューション専用に作成し、ユーザーガイドとともに使用するようにデザインする必要があります。

プロジェクトの範囲および期待の理解

該当するペルソナが、以下を完全に理解していることを確認する必要があります。

• プロジェクトの範囲
• 顧客のすべての期待
• これが、ペルソナごと、プロジェクトのフェーズごとに下されるすべての決定の基礎となること

URL 処理の概念

URL 処理の概念では、以下を含む AEM に固有の URL 機能をカバーする必要があります。

• バニティー URL
• リンクの外部向け変換
• エラーページ
• マッピング

この概念は以下もカバーする必要があります。

• 書き換えルール
• Web サーバー上の仮想ホスト
• SEO の考慮（robots.txt など）
• サイトマップ

ユースケース

ユースケースとは、目標を達成するために必要なアクションまたはイベント手順のリストです。通常は、役割とソリューションの間のインタラクションを定義します。この場合の役割とは、ユーザーまたは外部システムです。

ユースケースをテストシナリオに変換

テストシナリオは技術およびビジネスのユースケースに基づいています。ソリューションの動作が期待どおりであることをテストするために使用されます。

ユーザーガイド

ユーザーガイドは、以下のようなソリューションのユーザーに情報と支援を提供します。

• 作成者
• 上級ユーザー
• 管理者

検証済みの予算計画

予算計画は、すべての関係者によってレビューされ、検証される必要があります。請求、金額、予算レポートの方法とタイミングなどの詳細をチェックする必要があります。

ホワイトボックステストの結果

ホワイトボックステストとは、機能ではなく、アプリケーションの内部構造や動作をテストする方法です。ホワイトボックステストは、ソフトウェアテストプロセスの単体レベル、統合レベルおよびシステムレベルで適用できます。

ワークフローの仕様

ワークフローの概念に基づいて、この仕様では、完全なワークフローを作成する手順を詳細に定義する必要があります。

各ワークフローの仕様には、（最低でも）以下を含める必要があります。

• ユースケース
• 役割
• 手順
• 結果
• エラー処理

ワークフローの概念

ワークフローを使用すると、AEM のアクティビティを自動化できます。ワークフローの概念では以下の概要を説明します。

• 自動化が必要となるプロセス
• 影響を受ける AEM 内のサービスおよび役割