このページでは、プロジェクトの管理 - ベストプラクティスチェックリストで扱ったドキュメントの内容や原則を拡張および補足する詳細情報を提供します。
ここに示すリストは完全ではなく、概要として示しています。
AEMを(特に初めて)実装する場合は、AEM](https://www.adobe.com/marketing/experience-manager.html)の[機能とワークフローを確認し、どの領域が必要かを確認する必要があります。
次のような使用する AEM の機能と、デザインへの影響を検討します。
また、リリースノートで AEM の様々なバージョンをチェックして、新機能が追加された時期を確認してください。
AEM は、他のアドビ製品やサードパーティのサービスと統合できます。統合により、さらなるパワーと機能を自由に利用できます。
詳しくは、ソリューションの統合を参照してください。
主に考慮する点は、以下のいずれを実行するかです。
旧バージョンから最新バージョンに移行する場合、次の 2 つのオプションがあります。
あらゆるプロジェクトと同様に、できるだけ早い時期に基本原則を確立することが重要です。有効なタイプには以下が含まれます。
これらのポイントは一般的なもので、ベストプラクティスチェックリストはAEMに関する詳細を扱います。
役割
役割は明確に定義し、プロジェクトに関わる全員に知らせる必要があります。また、以下の役割を特に強調して知らせることをお勧めします。
責務
関与
できるだけ早く関係者を関与させることで、プロジェクトのステークホルダーになるように働きかけ、成功に向けての意欲を向上させることができます。
伝達経路
プロセス
定義するプロセスは、個々のプロジェクトに依存します。 次の点を考慮して、これらのシンプルさを保つよう再度試みます。
追跡ツール
バグやタスクなど、プロジェクトに関する情報を追跡できる多くのツールがあります。詳しくは、使用する可能性があるツールの概要を参照してください。
対象範囲
様々なレベルでプロジェクトの対象となる内容を明確に定義します。
レポート
レポートする情報、形式、頻度およびレポート先を明確に定義します。
用語
仮定
この情報は、プロジェクトハンドブック内で定義できます。また、Wiki の使用も、継続的な変化に効率よく対応するために役立ちます。これらが定義される場合、主な要因は次のとおりです。
組織は主要業績評価指標(KPI)を使用して、ターゲット達成の成功を評価します。これらの指標は測定可能な値です。これにより、特定の目的がいかに効果的に達成されているかを示すことができます。
以下の指標があります。
ビジネス:
パフォーマンス:
指標の一部は、特定および定義されたターゲット指標をベースとすることができますが、すべてそうする必要はありません。
指標は、Web サイトの品質の量的な測定を定義するために使用されます。基本的には、パフォーマンスの達成目標の定義であり、KPI(主要業績評価指標)を定義する際に使用できます。
多数のメトリックを定義できますが、その多くは、パフォーマンスと同時性に関する目標を定義するものです。特に、量的に示すことが難しく、感情によって評価される傾向にある次のような要素について定義します。
「Web サイトの現在の速度が遅すぎる」 - 低速になるのはいつか。
「同僚がログインすると、すべてが停止する」 - システムでサポートされる同時ユーザー数は何人か。
「検索時にシステムが停止する」 - どのような種類の検索要求がシステムに影響を及ぼすか。
「ファイルのダウンロードに長く時間がかかる」 - (標準ネットワーク条件下で)許容されるダウンロード時間はどれくらいか。
ターゲット指標は、プロジェクトの開始時に次の目的で定義されます。
ターゲット指標を定義する際は、常に注意が必要です。
これらのメトリックは、プロジェクトの開発時に必要に応じて更新したり、調整したりできます。プロジェクトが正常に実装されたら、これらのメトリックを使用してインストール環境を制御したり、継続中の操作に必要なサービスレベルの監視や維持を行ったりすることができます。
適切に使用すると、これらの指標が役立つツールを提供します。無責任に使うと、時間を無駄にする気晴らしになる。 いつものように、測定するもの、測定する方法、理由を理解する必要があります。
本節では、検討すべき基本原則及び課題について取り組む。 各インストールは異なるので、実際の測定値は異なります。
測定されるすべての指標は、ある意味で、プロジェクトのデザインの影響を受けます。 逆に、多くの問題は設計の変更によって解決するのが最善策です。
したがって、デザインを決定する前にターゲットメトリックを定義する必要があります。これにより、これらの要因に基づいてデザインを最適化できます。 プロジェクトが開発されると、基本的な設計原則を変更するのは難しくなります。
Web サイトの構造を作成する際には、AEM Web サイトで推奨される構造に従います。次の問題や原則を理解していることを確認してください。
デザインがガイドラインに従っていない場合、または意味が不明な場合は、プログラミング段階を開始するかコンテンツを入力する前に、これらの問題を明確にしてください。
インフラストラクチャを定義または評価する際に、次のようなターゲット値を定義するのに役立ちます。
使用時の状況、および Web サイトの戦略的意義に応じて、以下の項目がインフラストラクチャの評価や選択に役立ちます。
評価できるパフォーマンス要因はいくつかあります。
個々のページの応答時間を考慮してください。
検索リクエストの応答時間
このセクションは、パフォーマンスを実際に測定する技術的な詳細を拡張するパフォーマンスの最適化と組み合わせて読むことができます。
Web サイトが訪問者の要求に応答するまでにどの程度の時間がかかるかは、非常に重要な問題です。
当然、応答時間は個々の要求によって異なりますが、平均的なターゲット時間の値を定義することはできます。この値が達成可能かつ維持可能な数値と証明されれば、Web サイトのパフォーマンスを監視したり、潜在的な問題の進行を示したりするために使用できます。
オーサー環境とパブリッシュ環境でのターゲットの違い
オーサー環境とパブリッシュ環境では、対象ユーザーが異なるので、目標とする応答時間が異なります。
オーサー環境
この環境は、コンテンツの入力および更新をおこなう作成者が使用する環境なので、以下のように設定することが必要です。
パブリッシュ環境
この環境には、ユーザーが利用できるようにするコンテンツが含まれます。
速度は重要であるが、多くの場合、オーサー環境より遅くなる
その他のパフォーマンス向上メカニズムが多く適用されます。
以上に基づき、どうすれば達成可能な(平均)応答時間を決定できるでしょうか。これは多くの場合、経験の問題です。
ただし、(制御下にある状況では)以下のガイドラインを適用できます。
以上の数値は、次の条件を前提としています。
いくつかのメカニズムを使用して応答時間を監視できます。
AEM request.log を使用した応答時間の監視
パフォーマンス分析を開始するのに適したのは、要求ログです。 その他の情報として、この情報を使用して個々のリクエストの応答時間を確認できます。 詳しくは、パフォーマンスの最適化を参照してください。
HTML コメントを使用した応答時間の監視
*HTML comments* can be used to include response time information within the source of each page:
</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 サイトをデザインする必要があります。この場合も request.log
を使用して、同時実行をテストできます。詳しくは、パフォーマンスの最適化を参照してください。
同時ユーザー数のターゲットは、環境のタイプによって異なります。
オーサー環境
パブリッシュ環境
関連するメトリックについて説明する前に、いくつかの用語の大まかな定義を示します。
ボリューム
処理能力
処理能力とボリューム
対象/場所 | 処理能力 | ボリューム |
---|---|---|
クライアント | ユーザーのコンピューターの計算能力。 | ページレイアウトの複雑さ。 |
ネットワーク | ネットワーク帯域幅。 | ページのサイズ(コード、画像など)。 |
ディスパッチャーキャッシュ | Webサーバーのサーバーメモリ(メインメモリとハードドライブ)。 | Webサーバー(メインメモリとハードドライブ)。 キャッシュされたページの数とサイズ。 |
出力キャッシュ | AEMサーバーのサーバーメモリ(メインメモリとハードドライブ)。 | 出力キャッシュ内のページの数とサイズ、ページごとの依存関係の数。 Dispatcher キャッシュを使用すると、このボリュームが少なくなります。 |
Web サーバー | Webサーバーの計算能力。 | リクエストの量。 キャッシュを使用すると、このボリュームが少なくなります。 |
テンプレート | Webサーバーの計算能力。 | テンプレートの複雑さ。 |
リポジトリ | リポジトリのパフォーマンス。 | リポジトリから読み込まれたページ数。 |
以上の節では、定義される主なメトリックについて説明しました。
具体的な要件に応じて、追加の指標を個別に定義したり、上記の分類を考慮したりすると便利です。
ただし、Webサイトのあらゆる側面を測定および定義するのではなく、簡単かつ確実に機能する正確なコア指標の小さなセットを用意することをお勧めします。 その本質上、貴社のウェブサイトはユーザに届くとすぐに変化し進化する開始を持ちます。
セキュリティはきわめて重要であり、対処すべき課題として深刻性を増しています。プロジェクトの早期の段階からセキュリティについて検討し、計画する必要があります。**
セキュリティチェックリストでは、デプロイ時に AEM インストールを確実に保護するための手順が詳細に説明されています。その他のセキュリティの側面は、セキュリティ(開発時)とユーザ管理とセキュリティに含まれています。
このセクションでは、以下の点について留意してください。
標準的な AEM プロジェクトを新規に実装するには、以下のようなタスクを検討する必要があります。
すべての面で、反復アプローチを使用することをお勧めします。
実稼動環境の実際の条件で調整、最適化およびユーザートレーニングができるように、プロジェクト開始をソフトローンチ(不完全な可用性、複数の反復)とハードローンチ(完全な可用性 - ライブ)に分割します。
プロジェクトのライフサイクルで実行(または評価)する必要のあるタスクの例については、プロジェクトチェックリストを参照してください。
各カテゴリについての留意事項を次に示します。
開発
基本アーキテクチャを最初に定義します。
開発にはいくつかの繰り返し(スプリント)を使用します。
プロジェクトの進行中に利用可能な AEM バージョンが最終的に更新されるように計画します。
スプリント中にテストおよび最適化が行われるように計画します。
安定化および最適化フェーズを計画します。
今後のリリース対象として計画している項目のログを作成します。
パートナーの関与と引き継ぎを計画します。
インフラストラクチャ
基本アーキテクチャを最初に定義します。
最初のスプリントと次の初期設定の準備にいくつかの繰り返しを使用します。
いくつかの負荷テストを計画します。
スプリント中にテストおよび最適化が行われるように計画します。
安定化および最適化フェーズを計画します。
実稼働環境にできるだけ早期にデプロイします(運営チームにシステムのセットアップ経験を積ませます)。
指定されたユーザーと定義済み役割をできるだけ早期に使用します。
トレーニング(管理者向けトレーニングなど)を計画します。
運営への引き継ぎを計画します。
コンテンツ
結果のタスクリストに応じて、(高レベルの)タスク定義に関する時間と労力の初期予測を作成できます。 これには、誰(顧客またはパートナー)が何をいつ実行するかを示す指示が含まれます。
次のリストは、標準近似と、関連する作業の相互関係を示しています。したがって、コストが発生します。
これらの数字は初期見積もりにのみ使用できます。経験豊富な AEM 開発者は詳細な分析をおこなう必要があります。
フェーズ | 労力 |
---|---|
開発 | コンポーネントノードごとに 2 ~ 4 時間の概算見積もりを使用すると、すべての開発要件を満たします。 |
開発者によるテスト | 開発 15 % |
フォローアップ | 開発 10 % |
ドキュメント | 開発 15 % |
JavaDoc 文書化 | 開発 10 % |
バグ修正 | 開発 15 % |
プロジェクト管理 | 進行中のプロジェクトの管理および統制にかかるプロジェクトコストの 20 % |
その後の詳細な計画で、使用可能なリソースや必要なリソースを、納期やコストに関連付けることができます。
参照アーキテクチャは、AEM アーキテクチャにテンプレートソリューションを提供するために用意されました。参照アーキテクチャは、拡張性、信頼性、セキュリティなどの、企業システムで一般的に発生する問題に対処します。
次のサイトメトリックを定義する必要があります。
分類 | 定義 |
---|---|
インターネットサイトの数 | |
イントラネットサイトの数 | |
コードベースの数(インターネットとイントラネットが異なる場合など) | |
個々のページの数 | |
1 日あたりのサイト訪問の数 | |
1 日あたりのページビューの数 | |
1 日あたりのデータ転送量(GB) | |
同時ユーザーの数(閉じられたユーザーグループ) | |
同時訪問者の数(公開) | |
同時作成者の数 | |
登録済み作成者の数 | |
営業日あたりのページアクティベーションの数 | |
デプロイ時のページアクティベーションの数 |
次のリストは、使用可能な各種ツールを示しています。このリストはあくまでもツールの紹介で、詳細な推奨リストではありません。その他の任意のツールは使用できないということを意味するものではありません。
製品 | 説明 |
AEM | AEM自体は、アプリケーションの監視、テスト、調査、デバッグを行うのに役立つ様々なメカニズムを備えています。含める: |
Selenium | Selenium は、オープンソースのテストツールです。テストはブラウザーで直接実行され、ユーザーの作業がエミュレートされます。 |
Microsoft Project | 一般的に使用されるプロジェクト管理ツール。 |
Jira | Jira は、ソフトウェアバグを詳細に追跡および管理するためオープンソースツールです。必要に応じて、バグの詳細情報にワークフローを組み込むこともできます。 |
Git | Git は、リビジョン管理ソフトウェアです。 |
Eclipse | Eclipse は、様々なプロジェクトからなるオープンソース IDE です。ソフトウェアをライフサイクルに沿って構築、デプロイ、管理するために必要な広範なフレームワーク、ツールおよびランタイムで構成されるオープン開発プラットフォームを構築することに焦点を当てています。 詳しくは、Eclipseを使用したAEMプロジェクトの開発方法を参照してください。 |
IntelliJ | 各種機能を包括的に備えたプロフェッショナル向け IDE です(そのため、ライセンス費が発生します)。 詳細については、IntelliJ IDEAを使用したAEMプロジェクトの開発方法を参照してください。 |
Maven | Maven は、プロジェクトの構築プロセス(ソフトウェアおよびドキュメント)を管理するための包括的なソフトウェアプロジェクト管理ツールです。 |
また、次の各節では、特に注目すべき内容を取り上げています。
アドビでは、以下のようなすべてのフェーズおよびオーディエンスに対してさらにベストプラクティスを提供しています。