このページでは、プロジェクトの管理 - ベストプラクティスチェックリストで扱ったドキュメントの内容や原則を拡張および補足する詳細情報を提供します。
ここに示すリストは完全ではなく、概要として示しています。
AEM を実装するとき(特に初回)は、AEM の機能とワークフローを見直して、必要な領域を確認する必要があります。
次のような使用する AEM の機能と、デザインへの影響を検討します。
また、リリースノートで AEM の様々なバージョンをチェックして、新機能が追加された時期を確認してください。
AEM は、他のアドビ製品やサードパーティのサービスと統合できます。統合により、さらなるパワーと機能を自由に利用できます。
詳しくは、ソリューションの統合を参照してください。
主に考慮する点は、以下のいずれを実行するかです。
旧バージョンから最新バージョンに移行する場合、次の 2 つのオプションがあります。
あらゆるプロジェクトと同様に、できるだけ早い時期に基本原則を確立することが重要です。次の機能が含まれます。
これらは一般的な項目です。AEM に関連した具体例については、ベストプラクティスチェックリストで扱っています。
役割
役割は明確に定義し、プロジェクトに関わる全員に知らせる必要があります。また、以下の役割を特に強調して知らせることをお勧めします。
責務
関与
できるだけ早く関係者を関与させることで、プロジェクトのステークホルダーになるように働きかけ、成功に向けての意欲を向上させることができます。
伝達経路
プロセス
定義するプロセスは、個々のプロジェクトに応じて異なります。再度、以下を考慮して、これらのシンプルな設定を維持するようにしてください。
追跡ツール
バグやタスクなど、プロジェクトに関する情報を追跡できる多くのツールがあります。詳しくは、使用する可能性があるツールの概要を参照してください。
範囲
様々なレベルで、プロジェクトでカバーする内容を明確に定義します。
レポート
レポートする情報、形式、頻度およびレポート先を明確に定義します。
用語
前提
この情報は、プロジェクトハンドブック内で定義できます。また、Wiki の使用も、継続的な変化に効率よく対応するために役立ちます。定義するポイントに関わらず、重要な要因は以下のとおりです。
組織は主要業績評価指標(KPI)を使用して、ターゲット達成の成功を評価します。これらの指標は測定可能な値です。これにより、特定の目的がいかに効果的に達成されているかを示すことができます。
以下の指標があります。
ビジネス:
パフォーマンス:
指標の一部は、特定および定義されたターゲット指標をベースとすることができますが、すべてそうする必要はありません。
指標は、Web サイトの品質の量的な測定を定義するために使用されます。基本的には、パフォーマンスの達成目標の定義であり、KPI(主要業績評価指標)を定義する際に使用できます。
多数のメトリックを定義できますが、その多くは、パフォーマンスと同時性に関する目標を定義するものです。特に、量的に示すことが難しく、感情によって評価される傾向にある次のような要素について定義します。
「Web サイトの現在の速度が遅すぎる」 - 低速になるのはいつか。
「同僚がログインすると、すべてが停止する」 - システムでサポートされる同時ユーザー数は何人か。
「検索時にシステムが停止する」 - どのような種類の検索要求がシステムに影響を及ぼすか。
「ファイルのダウンロードに長く時間がかかる」 - (標準ネットワーク条件下で)許容されるダウンロード時間はどれくらいか。
Target 指標は、プロジェクトの開始時に次の目的で定義されます。
ターゲット指標を定義する際は、常に注意する必要があります。
これらのメトリックは、プロジェクトの開発時に必要に応じて更新したり、調整したりできます。プロジェクトが正常に実装されたら、これらのメトリックを使用してインストール環境を制御したり、継続中の操作に必要なサービスレベルの監視や維持を行ったりすることができます。
適切に使用すると、これらの指標は役立つツールとなりますが、無責任に使用すると時間を無駄にすることになります。いつものように、何をどのように測定するのか、およびその理由を理解する必要があります。
この節では、考慮すべき基本原則と問題を取り扱います。インストールはそれぞれ異なるので、測定する実際の値も異なります。
測定されるすべての指標は、ある意味で、プロジェクトのデザインの影響を受けます。逆に、問題が多数ある場合は、デザインの変更によって解決されるのが最善です。
したがって、デザインを決定する前にターゲットメトリックを定義する必要があります。これにより、これらの要因に基づいてデザインを最適化できます。プロジェクトが開発されると、基本的なデザイン原則を変更するのは難しくなります。
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
を使用して、同時実行をテストできます。詳しくは、パフォーマンスの最適化を参照してください。
同時ユーザー数のターゲットは、環境のタイプによって異なります。
オーサー環境
パブリッシュ環境
関連するメトリックについて説明する前に、いくつかの用語の大まかな定義を示します。
ボリューム
処理能力
処理能力とボリューム
対象/場所 | 処理能力 | ボリューム |
---|---|---|
クライアント | ユーザーのコンピューターの処理能力。 | ページレイアウトの複雑さ。 |
ネットワーク | ネットワークの帯域幅。 | ページ(コード、画像など)のサイズ。 |
Dispatcher キャッシュ | Web サーバーのサーバーメモリ(メインメモリとハードドライブ)。 | Web サーバー(メインメモリとハードドライブ)。キャッシュされたページの数とサイズ。 |
出力キャッシュ | AEM サーバーのサーバーメモリ(メインメモリとハードドライブ)。 | 出力キャッシュ内のページの数とサイズ、ページあたりの依存関係の数。Dispatcher キャッシュを使用すると、このボリュームが少なくなります。 |
Web サーバー | 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 は、プロジェクトの構築プロセス(ソフトウェアおよびドキュメント)を管理するための包括的なソフトウェアプロジェクト管理ツールです。 |
また、次の各節では、特に注目すべき内容を取り上げています。
アドビでは、以下のようなすべてのフェーズおよびオーディエンスに対してさらにベストプラクティスを提供しています。