用語集

AEM 作成者トレーニング

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

AEM の認定試験

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

AEM 認定

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

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

開発者、アーキテクト、エンジニアおよびビジネス従事者など、適切なペルソナにテクニカルトレーニングを提供します。

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

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

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

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

コンテンツアーキテクチャと KPI の整合性

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

顧客ロードマップとプロジェクトタイムラインの整合性

顧客ロードマップは、高レベルのマイルストーンとビジネス目標で構成されています。プロジェクトタイムラインは、この戦略に従い、整合させる必要があり、潜在的なリスクや偏差があれば、それを強調表示して追跡する必要があります。

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

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

次に焦点を当てます。

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

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

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

チームが適切なトレーニングを受けたスタッフで構成されていることを確認します。プロジェクトチームの場合、次のすべての条件を満たしていることが推奨されます。

アーキテクチャ図

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

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

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

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

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

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

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

自動化スクリプトおよび基本的な自動化のユースケースは次のとおりです。

自動テスト戦略

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

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

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

自動化戦略

デプロイメントを自動化して、迅速で一貫性のあるデプロイメントを実現します。自動化戦略では、このような自動化メカニズムの設定の概要を説明します。これには、以下の内容が含まれます。

コミュニケーションプランの認識

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

成功の定義と基準の認識

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

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

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

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

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

ビジネスケース

ビジネスケースドキュメントでは、アクションの実行、代替アクションの実行（可能な場合）、または何のアクションも実行しないことに関する論拠を示します。論拠はバランスの取れたものであるとともに、具体的な事実に（可能な限り、関連性がある場合は）基づいており、あらゆるケースについてメリットとリスクの両方を強調する必要があります。

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

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

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

ビジネス KPI

組織は、目標達成の成功度合いを評価するために、主要業績評価指標（KPI）を使用します。

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

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

ビジネス要件ドキュメント（BRD）では、プロジェクトのビジネスソリューションの詳細を記述し、お客様のビジネスニーズと期待事項を明確に定義します。また、BRD では、ビジネスソリューションと技術ソリューションを区別します。

ビジネスソリューションを調査する場合、BRD は次の質問に答える必要があります。
「ビジネスで実現したいことは何ですか？」

ソリューションまたはアーキテクチャに対して必要な調整を特定し、ROI と KPI の期待値を調整した上で、ビジネスが承認

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

これらのプロセスによって生じる調整は、ビジネスが確認および承認し、全体的な目標に照らして実施される必要があります。

キャッシュ戦略

キャッシュ戦略では、エンドユーザー向けにキャッシュされる内容について概要を説明します。パフォーマンス KPI に準拠する必要があります。

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

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

コーディングのガイドラインでは、ソリューションを開発する際に開発者が準拠する必要がある基本原則を定義します。これには、次のものが含まれます。

運用マニュアルの伝達

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

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

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

リリースノートの伝達

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

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

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

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

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

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

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

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

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

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

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

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

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

コンポーネントの仕様

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

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

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

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

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

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

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

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

契約のドラフト

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

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

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

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

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

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

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

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

デプロイメント／リリースを実行する方法とタイミングが定義された顧客のポリシーです。

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

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

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

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

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

顧客のレポートのポリシーと要件

レポートに関して顧客が定めているポリシーや要件またはその両方。これには次の内容が含まれます。

顧客ロードマップ

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

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

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

顧客の仕様ガイドライン

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

顧客のテストレポート

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

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

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

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

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

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

AEM のデフォルトのセキュリティ設定が有効化／実装されていることを確認します。

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

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

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

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

開発方法

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

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

開発の役割の定義

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

開発環境の準備

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

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

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

ダイアログの仕様

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

開発環境の設定の文書化

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

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

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

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

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

耐久性テスト

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

耐久性テストの実施

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

エラー処理の概念

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

エラー処理に関するドキュメント

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

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

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

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

適切なチームメンバーとの定期的な品質レビュー会議を確立します。

既存の権限の構造

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

既存のシステムマップ

既存のシステムと依存関係の図（または図のセット）です。

期待される成功の定義と基準

プロジェクトスポンサーは、プロジェクトの成功に関連するビジネスの期待事項を収集します。プロジェクトの開始時に、すべての期待事項を揃えておくことが重要です。実装時に下されるすべての決断に影響することだからです。

期待事項は次のとおりです。

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

ソリューションの全体的なエクスペリエンスに対する要件です。これには、パーソナライズ機能、クロスデバイスの永続性、ユーザーエクスペリエンスなどの要素が含まれます。

エクスペリエンスの仕様

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

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

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

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

フォールバックシステムでは以下が定義されます。

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

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

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

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

KPI の実行可能性の確認

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

最終決定された契約

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

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

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

運用開始のスケジュール

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

ハッピーパスの定義

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

ハードウェアの見積もり

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

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

すべての環境に最低限必要なハードウェアが配備されることを確認します。

全体的な要件

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

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

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

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

全体的なシステムマップ

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

過去のコンテンツ構造

レガシーシステムのコンテンツ構造を定義したものです。これは参照用に、また移行戦略を準備する際にも使用されます。

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

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

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

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

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

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

実装 - 自動テスト戦略

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

実装 - 自動化戦略

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

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

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

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

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

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

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

実装 - 統合

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

実装 - 移行戦略

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

実装 - 役割と権限

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

実装 - セキュリティ概念

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

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

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

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

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

実装 - URL 処理

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

実装 - ワークフロー

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

実装の概念

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

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

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

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

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

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

統合テスト

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

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

問題追跡プロセス

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

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

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

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

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

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

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

レガシーシステム

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

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

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

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

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

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

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

ログファイルの分析

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

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

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

移行プラン

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

移行戦略

既存のコンテンツ、コンテンツアーキテクチャおよび新しいソリューションにマップする形式を詳細に説明します。次のような内容も記載します。

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

監視 - CPU

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

監視 - ディスク I/O

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

監視 - ディスク容量

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

次の方法で使用状況を監視する必要があります。

監視 - 外部システム

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

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

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

監視 - リクエスト

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

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

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

監視 - システム

システム全体を監視します。以下に例を示します。

監視 - しきい値と介入

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

監視の概念

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

潜在的な弱点の監視

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

以下に例を示します。

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

システムエンジニアおよび運用スタッフが監視ポリシーを熟知し、理解していることを確認します。

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

以下の事項を定義します。

運用タスクのドキュメント

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

運用マニュアル

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

また、次の点に関する実装の概念も詳細に説明します。

パッケージの準備

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

侵入テスト

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

侵入テスト - パス

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

侵入テスト - 結果

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

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

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

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

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

パフォーマンス KPI

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

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

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

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

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

関連する契約条件

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

レポートのサイクル

顧客と共に、顧客に配信するレポートの頻度を定義します。

リポジトリの最適化

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

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

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

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

要件のドキュメント

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

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

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

リスク評価

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

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

リスク緩和計画

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

ROI の期待値

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

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

役割と権限の概念

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

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

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

役割と権限の仕様

役割と権限の概念に基づく詳細な仕様です。

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

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

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

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

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

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

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

セキュリティの概念

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

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

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

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

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

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

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

サポートプロセスの設定

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

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

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

スモークテストの概念

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

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

システム検証で実行されるスモークテスト

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

関係者による成功の定義および基準の認識

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

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

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

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

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

成功の基準および定義

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

これらを使用して、成功の基準が満たされていることを確認します。

報告された問題の検証におけるサポート

品質リードの責任の 1 つは、テスト時にユーザーをサポートするために利用できるリソースを確保することです。例えば、テスト時や問題の報告時にユーザーを支援し、テスト環境に対して問題を検証するのに役立ちます。

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

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

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

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

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

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

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

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

システムアーキテクチャをセキュリティポリシーに準拠させる方法の概要。対象は次のとおりです。

特定および検証されたシステムリスク要因

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

チームは成功の定義と条件を認識

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

チームがコミュニケーションプランを認識

チームのすべてのメンバーが、顧客とのコミュニケーションが必要なユーザー、その方法とタイミングの詳細を認識していることを確認します。

チームがプロジェクトと期待事項を理解

プロジェクトチーム内部および顧客に対する、全体的なプロジェクトと期待事項との整合性。

技術要件

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

技術的リスク要因の検証

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

技術仕様

技術仕様では、特に以下の情報を扱います。

テンプレートの仕様

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

これらの仕様は、ビジネス要件とエクスペリエンス要件に基づいています。

テストケース

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

テストコンテンツ

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

テスト環境の準備完了

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

テストレポート

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

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

テストスイート

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

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

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

テストの概念

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

テスト計画

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

テスト範囲

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

テスト戦略

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

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

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

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

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

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

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

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

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

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

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

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

以下を定義します。

しきい値の定義

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

次は例です。

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

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

プロジェクトの合計労力

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

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

トレーニング資料

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

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

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

URL 処理の概念

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

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

ユースケース

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