用語集 glossary

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

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

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

受け入れテスト acceptance-tests

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

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

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

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

テストシステムへのアクセスの調整 access-to-test-system-coordinated

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

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

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

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

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

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

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

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

AEM 作成者トレーニング aem-author-training

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

AEM の認定試験 aem-certification-exam

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

AEM 認定 aem-certified

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

AEM テクニカルトレーニング 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 を選択することが重要です。何が 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 に対して測定し、達成可能であることを確認する必要があります。

最終決定された契約 finalized-contract

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

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

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

運用開始のスケジュール 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 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

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

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

運用開始のスケジュールをアドビサポートに通知 inform-adobe-support-about-the-go-live-schedule

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

初期エクスペリエンスデザイン 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

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

アドビのサポートポータルへのアクセスが必要なユーザーのリスト list-of-users-that-require-access-to-adobe-support-portal

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

このリストは通常、ソリューションアーキテクトや顧客の 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）を受ける必要があります。これは、実稼動に移行するリリースおよび既知の問題のレビューの結果を判断して行われます。承認は、運用開始スケジュールの一環として与えられます。

実稼動の承認のプロセスとポリシー 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

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

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

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

最終リリースが実行中であり、実稼働環境でアクティブです。

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

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

レポートのサイクル reporting-cadence

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

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

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

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

アドビのサポートポータルにおけるプロジェクトセクションの設定リクエスト request-for-setting-up-project-section-in-adobe-support-portal

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

要件のドキュメント requirements-documentation

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

運用開始のサポートで使用できるリソース 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

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

セキュリティアーキテクチャの推奨事項 security-architecture-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）が開発チームと運用チームの双方に伝達されていることを確認します。

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

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

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

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

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

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

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

ソリューションレビューボードの設置と会議のサイクルの設定 solution-review-board-established-and-meeting-cadence-set

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

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

ソリューションランブック 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 管理者トレーニングに選ばれたスタッフ 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

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

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

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

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

システムアーキテクチャの定義 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 のアクティビティを自動化できます。ワークフローの概念では以下の概要を説明します。