チェックリスト - 詳細情報 the-checklist-further-reference

役割

役割は、明確に定義し、プロジェクトに関わるすべてのユーザーに知らせる必要があります。また、以下を強調することをお勧めします。

• 意思決定者
• 連絡先

責務

• 各役割に対して、プロジェクトに関連した責務を明確に定義すると、混乱を防ぐことができます。

関与

できるだけ早期に関係者を巻き込み、プロジェクトの​ ステークホルダー ​になるよう促すことができます。そうすることで、成功へのコミットメントが高まります。

• お客様側では、この役割には、日常的にシステムを操作する作成者が含まれます。
• 自身のプロジェクトチーム内では、この関与には、品質保証を担当する人も含まれます。お客様の要件を理解すればするほど、より適切にテストを計画できるようになります。

コミュニケーション経路

• コミュニケーション経路は過度に形式化すべきではありませんが、具体的に定義することで、主要な人々に常に情報を提供し、最新の状態に保つことができるようになります。外部の関係者とのコミュニケーションには、特に注意が必要です。

プロセス

定義するプロセスは、個々のプロジェクトに応じて異なります。ここでも、次の点を考慮して、これらのプロセスをシンプルに保つようにしてください。

• サードパーティ（特に設計会社やサードパーティ製ソフトウェアのサプライヤーなど）とやり取りするプロセス（およびコミュニケーション経路）の定義。
• 多くの場合、お客様にはプロジェクト管理とレポーティングを行う独自の手順とツールがあります。

トラッキングツール

プロジェクトに関するバグやタスクなどの情報をトラッキングできるツールは多数あります。詳しくは、使用できるツールの概要を参照してください。

• ここで注意すべき重要な点は、情報のコピーを 1 つだけ保持し、情報を共有することです（したがって、使用中のツールにアクセスする）。このワークフローは、メンテナンスを容易にし、不一致を防ぐのに役立ちます。

範囲

様々なレベルで、プロジェクトでカバーする内容を明確に定義します。

• 個々のリリース（反復リリースプロセスを使用する場合、顧客に提供されるか社内テストチームに提供されるかに関係なく）。
• AEM プロジェクト。
• プロジェクト全体（サードパーティ製ソフトウェア、テストへの影響、組織の問題、その他多くを含みます）。
• プロジェクトの範囲内に​ ない ​ものを示すことが役に立つ場合もあります。このアイデアは、必須の問題に限定されるべきですが、混乱や誤認を防ぐのに役立ちます。

レポート

レポートする情報、形式、頻度およびレポート先を明確に定義します。

用語

• 使用する略語やお客様固有の用語を定義します。

前提

• あらゆる想定事項を定義します。

ビジネス：

• 主要なビジネス目標を測定します。
• 実際のビジネスやシナリオに適した KPI を選択することが重要です。何が KPI であるか、どのように測定するか、誰がどのように使用するかを明確に定義する必要があります。

パフォーマンス：

• システムのパフォーマンスの測定方法を定義します。
• 例として、ページの読み込み時間、サーバーの応答時間、データベースのクエリパフォーマンスなどがあります。

「今日は web サイトが​ あまりにも遅い」- 遅い ​というのはいつからですか？

「同僚がログインするとすべてが​ 止まってしまう」- システムでサポートできる同時ユーザー数は何人ですか？

「検索するとシステムが​ 停止してしまう」- システムに影響を与えている検索リクエストはどれですか？

「ファイルのダウンロードに​ 長い時間 ​がかかる」-（標準ネットワーク条件下で）許容されるダウンロード時間はどのくらいですか？

個々のページの応答時間は、次を考慮します。

• オーサー環境での応答時間
• パブリッシュ環境での応答時間

検索リクエストの応答時間

オーサー環境

この環境は、コンテンツの入力および更新を行う作成者が使用する環境なので、以下のように設定することが必要です。

• コンテンツページやページ内の各要素を更新する際に、多数のリクエストを発生させる少数のユーザーに対応する
• コンテンツを Web サイトにできる限り速く展開し、生産性を最大限に高める

パブリッシュ環境

この環境には、ユーザー向けに提供するコンテンツが置かれます。

• 速さは重要ですが、多くの場合、オーサー環境より遅くなる

• パフォーマンス強化メカニズムの追加は、多くの場合、次のように適用されます。

  • コンテンツがキャッシュされる
  • 負荷分散が適用される

AEM の request.log を使用した応答時間の監視

パフォーマンス分析は、リクエストログから始めることをお勧めします。この情報を使用すると、個々のリクエストの応答時間を確認できます。詳しくは、パフォーマンスの最適化を参照してください。

HTML コメントを使用した応答時間の監視

HTML コメント を使用すると、各ページのソース内に次のように応答時間の情報を含めることができます。

</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests

検索自体のの応答時間

• 高速な検索機能は、Web サイトの品質の目標です。

全般的なパフォーマンスへの影響

• 検索機能は、コンテンツのセクション（大きい可能性が高い）や、特別に抽出されたインデックスをスキャンする必要があるので、この機能は最適化されていないと、システム全体のパフォーマンスに影響を与える可能性があります。

AEM request.log を使用した検索応答時間の監視

この場合も、request.log を使用すると、検索リクエストの応答時間を監視できます。詳しくは、パフォーマンスの最適化を参照してください。

検索応答時間を測定するためのプログラムされたメカニズム

検索リクエストに関して収集する情報、および検索リクエストのパフォーマンスをカスタマイズするには、プロジェクトのソースコードに情報の収集を含めることをお勧めします。詳しくは、パフォーマンスの最適化を参照してください。

オーサー環境

• 通常、同時ユーザー数は正確に見積もることができます。同時にアクティブとなる作成者の数は把握できなくても、作成者の総数はわかります。

パブリッシュ環境

• パブリッシュ環境の予測はより困難なので、ターゲット値を選択する必要があります。この値も、現在の web サイトでの経験と、新しい web サイトに対する現実的な期待に基づく必要があります。
• 特別なイベント（例えば人気のあるコンテンツを新規公開する場合）では、予測を超えたり、（イベントのチケットの発売時に報道されたりすると）処理能力を超えたりすることもあります。

ボリューム

• システムが処理し、提供する出力の量です。

処理能力

• ボリュームを提供するシステムの能力です。
• 次の表に示すように、処理能力とボリュームの測定方法は各手順で異なります。最高のパフォーマンスを得るには、処理能力が各手順のボリュームに釣り合い、処理能力とボリュームの両方がすべての手順で共有されていることを確認します。例えば、リクエストごとにサーバーでナビゲーションを計算する代わりに、クライアントコンピューターで計算したり、キャッシュに格納したりできます。

処理能力とボリューム

開発

• 基本アーキテクチャを最初に定義します。

• 開発にはいくつかの繰り返し（スプリント）を使用します。

  • 最初のスプリントは最初の全開発サイクルに相当します。
  • 最初のスプリントの結果として、テスト環境への最初のデプロイを行います。
  • すべてのスプリントが実行可能な結果を持ちます。
  • スプリントごとにお客様の承認（最低限の構造テストとフィードバック）を得ます。

• プロジェクトの進行中に利用可能な AEM バージョンが最終的に更新されるように計画します。

• スプリント中にテストと最適化が行われるように計画します。

• 安定化フェーズと最適化フェーズを計画します。

• 今後のリリース対象として計画する項目のログを作成します。

• パートナーの関与と引き継ぎを計画します。

インフラストラクチャ

• 基本アーキテクチャを最初に定義します。

  • パフォーマンス要件を定義します。
  • パフォーマンス目標を定義します（つまり、期待事項を明確に定義します）。
  • サイジングを含め、ハードウェアとインフラのアーキテクチャを定義します。
  • デプロイメントを定義します。

• 最初のスプリントと初期設定の準備にいくつかの繰り返しを使用します。

  • 開発環境。
  • 開発プロセス。
  • テスト環境。
  • デプロイメントプロセス（設定管理を含む）。

• 複数の負荷テストを計画します。

• スプリント中にテストと最適化が行われるように計画します。

• 安定化と最適化のフェーズを計画します。

• できるだけ早く実稼働環境にデプロイします（運用チームがシステムをセットアップして経験を積めるようにします）。

• 指定されたユーザーと定義済みのロールをできるだけ早く使用します。

• トレーニング（管理者向けトレーニングなど）を計画します。

• 運営への引き継ぎを計画します。

コンテンツ

• 基本アーキテクチャの概要は次のとおりです。

  • コンテンツ階層を稼働させます。
  • コンテンツの概念の定義に役立ちます。
  • MSM の使用方法とレイアウトを定義します。
  • 役割、グループ、ワークフロー、権限を定義します。

• オフラインページの作成が有益かどうかを検討します。

• 初期ページとコンテンツの早期作成を計画します（テストとフィードバックで使用するため）。

• 既存のコンテンツの移行を計画します。

• リファクタリングの後で「スプリント中の移行」を計画します。

• 「コンテンツのバーンダウン」（実稼動コンテンツ用のサイトマップ）を計画します。