用語集 glossary

この用語集には、プロジェクトチェックリストのすべての成果物ドキュメントの詳細が（アルファベット順に）記載されています。

ビジネス関係者からの受け入れ acceptance-from-business-stakeholders

ビジネス関係者からの受け入れは、主要な関係者として、ソリューションに合致し、ビジネス要件がビジネスケースをどのように満たすかについて、承認を与えていることを確認します。

受け入れテスト acceptance-tests

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

受け入れテストは、次の点を確認するために使用されます。

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

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

テストシステムへのアクセスが調整されました access-to-test-system-coordinated

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

Adobeセキュリティチェックリスト adobe-security-checklist

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

Adobeサポートポータルプロジェクトの設定 adobe-support-portal-project-set-up

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

詳細は登録することができます。例えば、実装されたテクノロジーとバージョンについてです。 これらは、顧客とAdobeの間の透明性を提供します。

AEM管理者トレーニング aem-administrator-training

ソリューションの管理スタッフ向けトレーニング。 詳しくは、 Adobeトレーニングサービス を参照してください。

AEM オーサートレーニング aem-author-training

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

AEM認定試験 aem-certification-exam

適切なペルソナが適切な 認定試験.

AEM Certified aem-certified

適切なペルソナが、 認定試験.

AEM Technical Training aem-technical-training

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

プロジェクトの目標として定義された KPI に関する合意 agreement-on-kpis-defined-as-goals-for-the-project

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

ビジネス KPI とパフォーマンス KPI の連携 align-business-and-performance-kpis

ビジネスとパフォーマンスの主要業績評価指標 (KPI) の調整により、組織内から関連するすべての人とプロセスを統合できます。 これにより、ビジネス目標の達成と提案された目的の達成に必要な時間と労力を削減できます。

コンテンツアーキテクチャと KPI の連携 alignment-of-content-architecture-with-kpis

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

顧客ロードマップとプロジェクトのタイムラインの整合 alignment-of-the-customer-roadmap-with-project-timeline

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

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

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

重点的な役割は次のとおりです。

定義済みのアプリケーション固有のメンテナンスタスク application-specific-maintenance-tasks-defined

標準のAdobe Experience Manager(AEM) メンテナンスタスクに加え、ソリューションの継続的なメンテナンスに必要な、その他の運用タスクを定義する必要があります。

適切に訓練されたスタッフ appropriately-trained-staff

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

アーキテクチャ図 architecture-diagram

アーキテクチャ図は、アーキテクチャをグラフィカルに表したものです。 以下の表現が含まれます。

アーキテクチャ下書き architecture-draft

これにより、システムとソリューションのアーキテクチャの概要が得られます。 この段階では、後の段階でレビューおよび絞り込まれる下書きです。

アーキテクチャレビューボードのサインオフ architecture-review-board-sign-off

アーキテクチャレビューボードは、組織をまたいだ次の機関です。

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

KPI と比較した、実際のコンテンツと結果に適合した自動テストスイート automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

自動化スクリプトと基本的な自動化ユースケース：

自動テスト戦略 automated-testing-strategy

この戦略では、品質保証 (QA) チームが計画したアプローチと共に、再利用可能な自動スクリプトのフレームワークを定義します。 自動化テストの全体的な計画の概要を説明し、以下を確認できます。

実際の負荷と予想される負荷に対して検証された自動テスト戦略 automated-testing-strategy-validated-against-realistic-and-expected-load

自動テスト戦略は、ソリューションで実行される内容と予想される負荷に応じて検証し、調整する必要があります。

自動化戦略 automation-strategy

デプロイメントを自動化することで、迅速で一貫性のあるデプロイメントを実現します。 自動化戦略では、このような自動化メカニズムの構成の概要を説明します。次を含む：

通信計画の把握 aware-of-communication-plan

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

成功の定義と条件の認識 aware-of-success-definitions-and-criteria

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

バックアップと復元の概念 backup-and-restore-concept

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

バックアップと復元のテスト backup-and-restore-tested

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

ビジネス事例 business-case-s

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

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

ビジネスアナリストがプロジェクトの範囲と期待事項を理解 business-analyst-understands-scope-of-project-and-expectations

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

ビジネス KPI business-kpis

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

ビジネス KPI は、企業が主要なビジネス目標を効果的に達成していることを示す測定可能な値を定義します。 ビジネスやシナリオに適した KPI を、その概要、測定方法、使用方法、使用者に関する明確な定義を含めて選択することが重要です。

ビジネス要件ドキュメント business-requirements-documentation

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

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

ROI と KPI の期待値に対して特定され、調整されたソリューションやアーキテクチャに対する必要な調整に関するビジネスの承認 business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations

リスク評価と侵入テストのプロセスによって、ソリューションのアーキテクチャや開発で対処する必要のある問題と結果が生じる可能性があります。

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

キャッシュ方法 caching-strategy

キャッシュ方法では、エンドユーザーに対してキャッシュする内容の概要を説明します。 パフォーマンス KPI に準拠している必要があります。

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

コーディングのガイドライン coding-guidelines

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

運用マニュアルの伝達 communicate-operations-manual

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

パフォーマンステストレポートの伝達 communicate-performance-test-report

適切なすべてのペルソナ/役割がパフォーマンステストレポートを受け取ったことを確認します。

リリースノートの伝達 communicate-release-notes

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

範囲と期待事項をチームに伝える communicate-scope-and-expectations-to-team

プロジェクトチームが、配信の範囲と期待事項を完全に認識し、それに沿っていることを確認します。

トレーニング資料およびユーザーガイドについて communicate-training-materials-and-user-guides

適切なすべてのペルソナ/役割がトレーニング資料とユーザーガイドを受け取るようにします。

顧客セキュリティ要件への準拠 compliance-with-customer-security-requirements

お客様のセキュリティ要件がすべて満たされていることを確認します。

セキュリティ概念への準拠 compliance-with-security-concept

セキュリティの概念が正しく設定されていることを確認します。

コンポーネントとテンプレートの関係の概念 components-and-templates-relationship-concept

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

構成部品とテンプレートの関係仕様 components-and-templates-relationship-specification

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

コンポーネント仕様 components-specification

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

外部インターフェイスのモックアップの概念 concept-for-mock-ups-of-external-interfaces

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

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

コンテンツアーキテクチャドキュメント content-architecture-document

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

移行用に検証されたコンテンツ content-validated-for-migration

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

契約下書き contract-draft

法的契約の最初の草案。

現在のコンテンツの構造と形式 current-content-structure-and-format

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

お客様のバックアップ/復元ポリシー customer-backup-and-restore-policy

次に関するお客様のポリシー：

カスタマーコーディングガイドライン customer-coding-guidelines

開発の方法に関するお客様からのガイドライン/要件。

お客様の導入/リリースポリシー customer-deployment-release-policies

デプロイメント/リリースを実行する方法とタイミングを定義する、お客様のポリシー。

これには、多くの場合、タイムライン、スケジュール設定およびサインオフ要件が含まれます。

顧客監視ポリシーまたは要件 customer-monitoring-policies-or-requirements

監視する対象に関する顧客のポリシーおよび要件。 これらは、監視概念で指定された推奨事項に加えておこなわれます。

顧客の実稼動リリーススケジュール customer-production-release-schedule

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

顧客レポートのポリシーと要件 customer-reporting-policies-and-requirements

レポートに関して顧客が持つポリシーまたは要件。 次のものが含まれます。

顧客ロードマップ customer-roadmap

実装すべき主要なマイルストーンのロードマップを作成し、技術とビジネスの両方を行う。 このロードマップは、お客様に伝えられます。

顧客セキュリティポリシー customer-security-policies

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

顧客仕様ガイドライン customer-specification-guidelines

仕様の形式、配信、および承認に関する顧客のガイドライン。

顧客テストレポート customer-test-reports

ユーザー受け入れテスト (UAT) 期間中に顧客から品質リードにレポートします。

アップグレードに影響するカスタマイズとホットフィックスについて説明 customizations-and-hotfixes-that-affect-upgrades-documented

今後のアップグレードに影響が及ぶ可能性があるので、カスタマイズや適用済みのホットフィックスは、ドキュメントに記載する必要があります。

日別ユーザー受け入れテストレポート daily-user-acceptance-test-report

ユーザー受け入れテスト (UAT) によって生じたレポートまたは会議。 詳細は次のとおりです。

デフォルトのセキュリティが有効 default-security-enabled

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

デプロイメント/リリースのポリシーとプロセス deployment-release-policies-and-processes

プロジェクトのデプロイメントとリリースの両方をカバーする形式化されたポリシー。 次のものが含まれます。

デプロイメントケイデンスが確立されました deployment-cadence-established

環境をまたいだデプロイメントに必要な頻度を定義する。

開発手法 development-methodology

ソフトウェア開発手法では、ソフトウェア開発作業のプロセス全体を個別のフェーズ（またはステージ）に分割し、それぞれが個別のアクティビティを持つようにします。 その目的は、計画と管理の改善です。

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

開発ロールの定義 development-role-definition

IT（パフォーマンスなど）テストや単体テストをソリューション内で実行している開発者や役割を定義します。

開発環境の準備完了 development-environment-ready

デプロイメントの自動化に必要な統合ツールを使用して開発環境を設定する。

開発チームがプロジェクトの範囲と期待事項を理解 development-team-understands-scope-of-project-and-expectations

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

ダイアログの仕様 dialogs-specification

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

ドキュメント開発環境の設定 document-development-environment-setup

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

ドキュメント実稼動環境の設定 document-production-environment-setup

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

テスト環境の設定のドキュメント化 document-test-environment-setup

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

耐久性テスト durability-test

耐久性テストでは、特定の負荷下でのソリューションのパフォーマンスを示します。 テストでは、しきい値の負荷に送信されたときにソリューションが存続する時間、およびパフォーマンスレベルを測定します。

耐久性テストが実行されました durability-test-executed

耐久性テストの実行。

エラー処理の概念 error-handling-concept

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

エラー処理に関するドキュメント error-handling-documentation

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

エスカレーションプロセス escalation-processes

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

定期的な品質レビューセッションの確立 establish-regular-quality-review-sessions

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

既存の権限構造 existing-permissions-structure

レガシーソリューションまたは組織内で定義された既存の権限およびグループのセットに関するドキュメント。

既存のシステムマップ existing-systems-map

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

期待される成功の定義と条件 expected-success-definitions-and-criteria

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

式には次のものが含まれます。

エクスペリエンスデザインの要件 experience-designs-requirements

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

エクスペリエンスの仕様 experience-specifications

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

外部システムとユーザーの依存関係/システムコンテキスト external-system-and-user-dependencies-system-context

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

代替システムと手順 fallback-system-and-procedure

フォールバックシステムの定義：

フォールバックシステムと手順のテスト fallback-system-and-procedure-tested

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

ビジネス関係者からの代替システムの承認 fallback-system-sign-off-from-business-stakeholders

フォールバックシステムと関連する手順によって、ビジネス関係者から重要なビジネス機能が確実に使用されるようにサインオフします。

KPI の実行可能性の確認 feasibility-confirmation-on-kpis

AEMと高レベルのソリューション設計の両方に関する実行可能性スタディの結果。 これらを KPI に照らして測定し、KPI を満たすようにする必要があります。

確定した契約 finalized-contract

プロジェクトを続行する前に、確定し署名済みの契約が必要です。 これは、 契約下書き.

関係者が受け入れたソリューションの機能 functionality-of-the-solution-accepted-by-stakeholders

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

Go Live スケジュール go-live-schedule

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

定義済みハッピーパス happy-paths-defined

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

ハードウェア見積もり hardware-estimates

以下の初期見積もり。

要件を満たすハードウェアが利用可能 hardware-will-be-available-to-fulfill-requirements

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

要件の概要 high-level-requirements

高レベル要件の定義により、次のような側面をカバーし、システムの要件が一般的に分類されます。

これらの関数の基本的な詳細は通常知られているので、このドキュメントは見積もりではありません。

ソリューション設計の概要 high-level-solution-design

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

概要システムマップ high-level-system-map

このシステムマップは、システムの非常に高いレベルの図を提供する必要があります。 ソリューションコンテキストとは異なり、関連するすべてのシステムの一般化されたマップであり、この図にはインターフェイスがありません。

履歴コンテンツ構造 historical-content-structure

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

実績 KPI と実績 KPI historical-performance-and-historical-performance-kpis

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

重要な主要なソリューション/機能の特定 identify-critical-key-solutions-functionalities

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

実装 — 侵入テスト結果に基づく変更 implementation-changes-based-on-penetration-test-results

侵入テストの結果に基づいて、ソリューションに対する必要なすべての変更（サインオフ済み）の実装。

実装 — 自動テスト戦略 implementation-automated-testing-strategy

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

実装 — 自動化戦略 implementation-automation-strategy

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

実装 — コンテンツアーキテクチャ implementation-content-architecture

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

実装 — エクスペリエンスデザイン implementation-experience-design

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

実装 — フォールバックシステムと手順 implementation-fallback-system-and-procedures

フォールバックシステムと関連する手順の実装。

実装 — 統合 implementation-integration

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

実装 — 移行戦略 implementation-migration-strategy

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

実装 — 役割と権限 implementation-roles-and-rights

役割および権限、ユーザーおよびグループの実装。

実装 — セキュリティ概念 implementation-security-concept

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

実装 — セキュリティソフトウェア implementation-security-software

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

実装 — システムアーキテクチャのセキュリティ概念 implementation-system-architecture-security-concept

システムセキュリティの実装。

実装 — URL の処理 implementation-url-handling

URL 処理の概念の実装。

実装 — ワークフロー implementation-workflows

設計されたワークフローの実装。

実装の概念 implementation-concept

実装の概念は、実装全体のガイド原則を提供します。 次の点を考慮に入れる必要があります。

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

Go Live スケジュールに関するAdobeサポートへの通知 inform-adobe-support-about-the-go-live-schedule

Adobeサポートに問い合わせて、運用中に必要なサポートを有効にできることを確認します。

初期エクスペリエンスデザイン initial-experience-designs

エクスペリエンスのデザインに関する事前の概念。

統合テスト integration-testing

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

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

問題追跡プロセス issue-tracking-process

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

問題追跡のシステムとプロセス issue-tracking-system-and-processes

トラッキングシステムは、必要なプロセスと共に、発生したすべての問題を記録し、すべての問題に対処するために進行中のアクティビティを追跡します。

プロジェクトのステータスの透明性を高めるために、すべてのプロジェクト関係者がアクセスできる必要があります。

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

問題追跡システムプロセスの設定と統合 issue-tracking-system-process-is-set-up-and-integrated

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

レガシーシステム legacy-system

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

旧システムの詳細を収集し、廃止できる内容、いつ、他のシステムに与える影響を把握する必要があります。

使用する開発ツールのリスト list-of-development-tools-to-be-used

実装で使用されるツールの概要。ツールには以下が含まれます。

Adobe・サポート・ポータルへのアクセスを必要とするユーザのリスト list-of-users-that-require-access-to-adobe-support-portal

Adobeサポートポータルへのアクセスが必要なすべてのユーザーと役割のリストです。

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

ログファイルの分析 log-file-analysis

分析と、結果のレコメンデーションを組み合わせて、ソリューションを監視するためにログに記録する必要があるものを定義します。

メンテナンスタスク (AEM固有 ) テスト済みおよび有効 maintenance-tasks-aem-specific-tested-and-enabled

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

移行プラン migration-plan

移行を文書化する。含む

移行戦略 migration-strategy

新しいソリューションにマッピングされた既存のコンテンツ、コンテンツのアーキテクチャおよび形式についての完全な説明です。 対象は次のとおりです。

また、移行から新しいシステムの実際の運用開始までの間、コンテンツを最新の状態（または可能な限り最新の状態）に保つ方法もお勧めします。 これは、コンテンツのフリーズ、ダブルパブリッシング、アルファシステムのメンテナンスを意味する場合があります。

監視 — CPU monitoring-cpu

システム CPU のソリューションの使用状況を監視する：

監視 — ディスク I/O monitoring-disk-i-o

ソリューションのディスク入力率と出力率の監視：

監視 — ディスク容量 monitoring-disk-space

ソリューションのディスク容量使用量の監視：

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

監視 — 外部システム monitoring-external-system-s

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

監視 — ネットワーク帯域幅 monitoring-network-bandwidth

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

監視 — リクエスト monitoring-requests

ソリューションに対しておこなわれたリクエストを監視します。

監視 — セキュリティポイント monitoring-security-points

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

監視 — システム monitoring-system

システム全体を監視する。例：

監視 — しきい値と介入 monitoring-threshold-and-intervention

負荷を軽減する介入手順の実装と共に、ソリューションの定義済みしきい値を監視する。

監視の概念 monitoring-concept

ソリューションに適用する監視概念。組み込み：

潜在的な弱点の監視 monitoring-potential-weak-points

障害の影響を受けやすい特定のポイントを特定し、定義する必要があります。 これらに関連する監視タスクも定義する必要があります。

以下に例を示します。

監視ポリシーがシステムエンジニアに伝達されました monitoring-policy-communicated-to-system-engineer

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

レポートの監視 — 構造を実装する monitoring-reports-structure-in-place

定義：

運用タスクのドキュメント operational-tasks-documentation

すべての運用タスクをドキュメント化し、頻度を定義しました。

運用マニュアル operations-manual

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

また、次の実装概念についても詳しく説明する必要があります。

パッケージの準備 package-prepared

ソフトウェアパッケージが構築され、展開の準備が整いました。

侵入テスト penetration-tests

侵入テスト（ペンテストとも呼ばれます）は、セキュリティの弱点を探し、潜在的にコンピュータの機能やデータにアクセスするコンピュータシステムへの攻撃です。

侵入テスト — 合格 penetration-tests-passed

必要な条件がすべて満たされます。

侵入テスト — 結果 penetration-tests-results

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

パフォーマンスと拡張性の概念 performance-and-scalability-concept

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

パフォーマンスベンチマーク performance-benchmark

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

パフォーマンス KPI performance-kpis

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

パフォーマンステスト — レポート performance-tests-report

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

パフォーマンステスト — 結果がパフォーマンス KPI に一致する performance-tests-results-match-performance-kpis

結果は、定義された KPI と、パフォーマンスに対する期待値に一致する必要があります。

ペルソナベースのテストの概念 persona-based-testing-concept

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

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

要件ドキュメントに照らしてテストおよび検証された POC poc-tested-and-verified-against-requirement-documentation

概念実証 (POC) は、両方が一致するように要件に対してゲージ化されます。

デプロイ後のチェックリスト post-deployment-checklist

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

デプロイメント前のチェックリスト pre-deployment-checklist

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

実稼動環境のベースラインパフォーマンステスト production-environment-baseline-performance-tests

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

実稼動環境の準備完了 production-environment-ready

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

ビジネス関係者からの実稼動の承認 production-sign-off-from-business-stakeholders

実稼動環境に移行する前に、実稼動のサインオフ (PSO) を許可する必要があります。 これは、実稼動環境に移行されるリリースのレビューと、既知の問題の結果です。 サインオフは、Go Live スケジュールの一部として指定されます。

実稼動のサインオフプロセスとポリシー production-sign-off-process-and-policy

パッケージを実稼動環境に移動する前に、実稼動のサインオフを取得するために必要なポリシーとプロセスです。

プロジェクト通信計画 project-communication-plan

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

プロジェクトの取り組み — 最終見積もり project-efforts-final-estimates

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

これらは、最終的な見積もりを提供するために、レビュー、絞り込み、拡張されました。 見積もりは、プロジェクト管理、コンサルティング、アーキテクチャ、テスト、開発など、適切なプロジェクトリードごとに提供する必要があります。

これらの見積もりは、リソースの割り当てと予算の割り当てに使用されます。

プロジェクトの取り組み — 初期見積もり project-efforts-initial-estimates

初期見積もりは高レベルで、実装の高レベル要件に従っておこなわれます。 これは後の段階でレビューおよび絞り込まれます。

プロジェクト組織 project-organization

プロジェクトとチームの組織とレポート構造の概要を説明するために必要なドキュメント。

多くの場合、タイムラインと責務の視覚的な概要を示すグラフをフォームに記述し、含めます。 これに役立つツールが多数あります。

プロジェクト範囲ドキュメント project-scope-document

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

プロジェクトを提供するために何を達成する必要があるかを、実行する必要がある作業と共に説明します

定義済みのケイデンス内のプロジェクトステータスレポート project-status-reports-within-a-defined-cadence

同意されたスケジュールに従って、必要な形式で配信されるプロジェクトステータスレポート。

概念実証（POC） proof-of-concept-poc

概念実証 (POC) は、ソリューションに対して限られた範囲の関数を実装します。

ソリューションの実現可能性を実証し、必要な目的を満たすことができることを確認し、使用される可能性があることを証明する必要があります。

ルールをパージ purge-rules

AEMでは、複数のバージョンのアセットやコンテンツを管理しています。 パージルールは、リポジトリの正常性とサイズを維持するために、古いバージョンを定期的に削除するように設計および設定されています。

品質レポートの形式とケイデンス quality-report-format-and-cadence

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

連携リリース release-coordinated

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

リリースノート release-notes

リリースノートは、このリリースのドキュメントの一部です。 リリースノートでは、次の内容を扱う必要があります。

Runbook と共に使用して、インストール前と後の手順と確認を実行します。

実稼動環境で実行されているリリース release-running-on-production-environment

最終リリースが実行され、実稼動環境でアクティブになっています。

関連する契約条件 relevant-contract-terms

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

レポート頻度 reporting-cadence

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

リポジトリの最適化 repository-optimization

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

リポジトリのサイズが増え続けるのに対処するために、古いデータを削除するための最適化戦略が導入されています。

Adobeサポートポータルでのプロジェクトセクションの設定のリクエスト request-for-setting-up-project-section-in-adobe-support-portal

Adobeサポートポータルでプロジェクトをセットアップするための公式リクエスト。

要件ドキュメント requirements-documentation

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

Go Live をサポートするために利用できるリソース resources-available-to-support-go-live

運用開始に必要なすべての役割がスタッフを配置し、使用可能であることを確認します。

リスク評価 risk-assessment

リスク評価は、お客様の IT 部門やセキュリティ部門が実行します。

プロジェクトの技術的リスクとビジネス上のリスクを評価します。 この評価は、セキュリティポリシーへのコンプライアンスを確保するために、ソリューションに必要です。

リスク軽減計画 risk-mitigation-plan

リスク軽減計画には、リスクアセスメントが含まれます。 2 つのカテゴリーで構成される内容は次のとおりです。

ROI の期待値 roi-expectations

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

また、予想投資に対して期待される利益と利益を定義し、経済的にソリューションの効率を示すことを目的としています。

役割と権限の概念 roles-and-rights-concept

新しいアプリケーションに必要な役割とアクセス権に関する概念の詳細な仕様（以下の概要を含む）。

セキュリティガイドラインを満たす役割と権利の概念 roles-and-rights-concept-meets-security-guidelines

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

役割と権限の指定 roles-and-rights-specification

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

セキュリティアーキテクチャRecommendations security-architecture-recommendations

Recommendationsは、ソフトウェアとハードウェアアーキテクチャのセキュリティに関連しています。

セキュリティに基づくコーディングガイドライン security-based-coding-guidelines

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

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

セキュリティ概念に基づくプロジェクト固有の項目のチェックリストと、ソリューションのコンプライアンスを確保するために必要な追加のポリシー。

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

セキュリティ概念 security-concept

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

セキュリティ概念下書き security-concept-draft

次のセキュリティ設定に関する概要です。

表示および評価されたセキュリティ上の問題 security-issues-listed-and-assessed

このソリューションのセキュリティ上の問題は、すべてリストされ、評価されました。労力の見積もりも含む

ビジネス関係者からのセキュリティの承認 security-sign-off-from-business-stakeholders

セキュリティ実装がポリシーや期待に準拠していることを確認するには、関係者からサインオフします。

サポートプロセスの設定 set-up-support-processes

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

サードパーティシステムの SLA slas-for-third-party-systems

実装とサポートの際に使用する SLA(Service Level Agreement) が使用可能で、開発チームと運用チームの両方に伝達されていることを確認します。

スモークテストの概念 smoke-test-concept

スモークテストは、ソリューションの主要な機能をテストし、ソリューションの基本的な操作と機能を確実に確認する、定義された一連のステップで構成されます。

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

システム検証で実行される煙テスト smoke-tests-executed-for-system-validation

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

ソフトウェアアーキテクチャ戦略 software-architecture-strategy

ソフトウェアアーキテクチャの高度な戦略サービス、サーブレット、フレームワークおよびその他の実装の決定を含みます。

ソリューションレビューボードの確立と会議ケイデンスセット solution-review-board-established-and-meeting-cadence-set

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

同委員会は、現在範囲を定めた要件と関連仕様を継続的にレビューするための定期的な会議を開催しています。 この目的は、成功の定義と条件との整合性を確保し、要件の開発に関する情報を提供することです。

ソリューション Runbook solution-runbook

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

ソリューションの承認および承認プロセス solution-sign-off-and-acceptance-process

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

契約上のマイルストーンとしても機能します。

特殊機能の概念 special-functionality-concept

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

特殊機能仕様 special-functionality-specification

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

仕様ガイドライン specification-guidelines

仕様の実行方法に関するお客様からのガイドライン。

定義済みおよび伝達済みの仕様レビューおよび承認プロセス specification-review-and-approval-process-defined-and-communicated

顧客が仕様を承認するための明確なプロセスを実施する必要があります。 このプロセスにより、要件の範囲が明確で確実になります。

AEM Administrator Training 用に選択されたスタッフ staff-selected-for-aem-administrator-training

ソリューションの管理にトレーニングが必要な社内スタッフ。

作成者およびエンドユーザートレーニング用に選択されたスタッフ staff-selected-for-author-and-end-user-training

ソリューションの作成に必要なトレーニングを受ける社内スタッフ。

関係者 stakeholders

関係者は、プロジェクトに大きな関心を持つキーパーソンや役割です。 プロジェクト予算に貢献する人もいます。

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

関係者が成功の定義と条件を認識する stakeholders-are-aware-of-success-definitions-and-criteria

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

関係者がプロジェクトと期待事項を理解する stakeholders-understand-project-and-expectations

実際の実装チーム以外のすべての関係者が、プロジェクトチーム内部およびお客様側の両方で、プロジェクト全体および期待に沿っていることを確認します。

ステータスレポート形式の定義 status-report-format-definition

ステータスレポートは、コミュニケーションの主要ツールです。 形式は、お客様のレポート要件に合わせる必要があります。

達成基準と定義 success-criteria-and-definition

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

これらは、成功の基準を確実に満たすために使用されます。

報告された問題の検証におけるサポート support-in-validation-of-reported-issues

品質リードの責任の一部は、テスト時にユーザーをサポートするリソースがあることを確認することです。 例えば、テスト時、問題の報告時、テスト環境に対する問題の検証に役立つように、ユーザーを支援します。

サポートプロセスとAdobeサポートポータルへのアクセス support-processes-and-access-to-adobe-support-portal

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

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

システムアーキテクチャの定義 system-architecture-definition

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

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

システムアーキテクチャを詳しく説明するドキュメントすべての環境用のインターフェイス、ネットワークの場所、統合などの情報を含みます。

システムアーキテクチャのセキュリティ概念 system-architecture-security-concept

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

特定および検証されたシステムリスク要因 system-risk-factors-identified-and-verified

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

チームは成功の定義と条件を認識しています team-is-aware-of-success-definitions-and-criteria

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

チームがコミュニケーションプランを認識 team-is-aware-of-the-communication-plan

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

チームがプロジェクトと期待を理解する team-understands-project-and-expectations

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

技術要件 technical-requirements

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

技術的リスク要因の検証 technical-risk-factors-verified

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

技術仕様 technical-specification

技術仕様では、次の情報を扱います。

テンプレートの指定 template-specification

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

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

テストケース test-cases

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

コンテンツをテスト test-content

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

テスト環境の準備完了 test-environment-ready

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

テストレポート test-reports

テストの結果を詳しく説明するレポート次を含む：

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

テストスイート test-suite

自動化スイートとツールの選択。 これらは、使用例のテストを含め、テストの自動化に使用されます。

テストツールスイートが選択されました test-tooling-suite-selected

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

テストの概念 testing-concept

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

テスト計画 testing-plans

これらのプランは、開発の各段階でのテストの実行の詳細を示し、 テスト戦略.

テスト範囲 testing-scope

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

テスト戦略 testing-strategy

テスト戦略は、品質保証とユーザー受け入れテストに関する高レベルの戦略を概説しています。 これには、タイムライン、レポートサイクル、実行が含まれます。

サードパーティ統合の概念 third-party-integration-concept

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

サードパーティ統合仕様 third-party-integration-specification

サードパーティ製システムのサポートされる機能と統合に関する要件（機能と機能以外の両方）の詳細。

サードパーティのセキュリティ概念 third-party-security-concept

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

統合のためのサードパーティシステム third-party-system-for-integration

統合の実装に関して、適切なドキュメントと共に、すべてのサードパーティ製システムが使用可能であることを確認します。

サードパーティシステムのアクセスが有効 third-party-systems-access-enabled

サードパーティ製システムと組み合わせて使用されるそれぞれの役割に対して付与される必要なアクセス権。

サードパーティのテストの概念 third-party-testing-concept

定義：

しきい値の定義 threshold-definition

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

次は例です。

タイムラインとマイルストーン timeline-and-milestones

これにより、以下に使用するプロジェクトのタイムラインと契約上のマイルストーンを定義する必要があります。

プロジェクトの取り組みの合計 total-project-efforts

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

契約にサポートレベルが含まれている場合は、サポートと運用の取り組みも含まれる必要があります。

トレーニング資料 training-materials

トレーニングセッションで使用する資料。 マテリアルは、ソリューション専用に作成され、ユーザーガイドと共に使用するように設計する必要があります。

プロジェクトの範囲と期待事項の理解 understands-scope-of-project-and-expectations

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

URL 処理の概念 url-handling-concept

URL 処理の概念では、次のようなAEM固有の URL 機能をカバーする必要があります。

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

ユースケース use-cases

ユースケースとは、目標の達成に必要なアクションまたはイベントステップのリストです。 通常は、役割とソリューションの間のやり取りを定義します。 役割は、ユーザーまたは外部システムにすることができます。

テストシナリオに変換されたユースケース use-cases-converted-into-test-scenarios

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

ユーザーガイド user-guides

ユーザーガイドは、ソリューションのユーザーに対して、次の情報と支援を提供します。

検証済みの予算計画 validated-budget-plan

予算計画は、すべての関係者が確認し、検証する必要があります。 請求、金額、予算報告の方法/時期などの詳細を確認する必要があります。

ホワイトボックステスト結果 white-box-test-results

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

ワークフローの仕様 workflow-specifications

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

各ワークフローの仕様には、少なくとも次の内容を含める必要があります。

ワークフローの概念 workflows-concept

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