現在表示中:

プロジェクト遂行のベストプラクティス

次のチェックリストを使用すると、プロジェクトのライフサイクルのすべてのフェーズを通じてプロジェクト遂行を成功に導きます。これらはプロジェクト配信の一連のベストプラクティスを想定しています。高品質のサービスを配信するには、チェックリストのすべての項目を、可能な限り順番に実行する必要があります。

チェックリストには、必要情報要素と成果要素があります。必要情報と成果は 1 対 1 で対応していません。例えば、複数の必要情報の結果が 1 つの成果となる場合があります。

ダウンロード

準備

プロジェクトの準備には要件やロードマップの収集のほか、次のような事前作業が必要です。

検証

必要情報 成果
顧客ロードマップ
  ソリューションの概要設計  
適用範囲に関する文書   アーキテクチャのドラフト  
見込み投資利益率(ROI)   ハードウェアの見積り  
初期エクスペリエンスの設計要件   パフォーマンス KPI  
ビジネス要件文書   プロジェクトの目標策定  
技術要件文書    

注意:

主要業績評価指標(KPI)とは:

  • 同時並行で作業できる作成者とユーザーの数(同時並行性)
  • 応答時間
  • 日ごとのアセット数(平均時とピーク時)
  • 日ごとのページ変更数(平均時とピーク時)

予算

必要情報 成果
適用範囲に関する文書   検証済みの予算計画  
ソリューションの概要設計    
ハードウェアの見積り    
プロジェクトの目標策定    
要件文書    

プランニング

プロジェクトのプランニングには、まずプロジェクトに関わる全員がプロジェクトについて十分に理解している必要があります。また、プロジェクトがさらされるリスクについての適切な知識があること、および全体を通じてのコミュニケーション方法を計画する必要があります。これにより、プロジェクトを開始するうえで確かな基盤を築くことができます。次の 4 つのチェックリストに従って進めることで、主なポイントを把握できます。

引き継ぎ

必要情報 成果
顧客のプロジェクト全体のロードマップ   パフォーマンス KPI に関する文書  
プロジェクト適用範囲の定義   プロジェクト管理チームがプロジェクトの範囲と期待する結果を理解できる  
ROI の期待値    
初期エクスペリエンスの設計    
ビジネス要件文書と技術要件文書    
ソリューションの概要設計    
アーキテクチャのドラフト    
ハードウェアの見積り    
これまでのパフォーマンス KPI の履歴と今後の期待値    
関連する契約条件    

注意:

プロジェクト管理チームは、次の内容について明確に理解している必要があります。

  • サイトのスループット
  • ピーク時間(例:独立記念日、スーパーボウルなどのイベント時)を含む訪問者の数
  • ページ表示時間(ミリ秒単位)(サードパーティの統合を含む)
  • アセットの配信 
  • キャッシュ方法

リスク評価

必要情報 成果
キーとなる最も重要なソリューションや機能の特定   技術的なリスク要素を把握できる  
顧客ロードマップのプロジェクトタイムライン   必要な機能や範囲を調整できる  
技術およびビジネス上のリスク評価   結果やビジネス上の判断を提案できる  
概念実証(POC)、設計と実装   技術的なリスク要素を検証できる  
要件文書に対する POC のテストと検証    

注意:

潜在的なリスクを抱えているソリューション(例:MSM、コマースの統合など)を特定することは重要です。特定した結果は、要件の完全実装が可能か、あるいはその他の概念を適用すべきかをビジネス側に報告する基準となります。ソリューションの概念がリスクを含んでいる場合に備えて、ビジネス側にはキーとなる要件にどのように対処したらよいかを判断できるテンプレートが必要となります。

コミュニケーション

入力 成果
内外の関係者の定義   問題追跡プロセスが確立および統合される  
関係者からの問題追跡システムおよびプロセス   プロジェクトのステータスが定義されたケイデンス(遅延)内で報告される  
ステータスレポートの形式の定義    
レポートの頻度    

キックオフ

必要情報 成果
顧客ロードマップ   プロジェクトチームがプロジェクトと期待する結果を把握できる  
プロジェクト適用範囲文書   ハードウェアが要件を満たすことができる  
ROI の期待値   KPI について合意し、プロジェクトの目標として定義される  
初期エクスペリエンスの設計   プロジェクトチームがコミュニケーション計画を把握できる  
要件文書    
ソリューションの概要設計    
アーキテクチャのドラフト    
ハードウェアの見積り    
パフォーマンス KPI    
タイムラインとマイルストーン    
プロジェクトの組織とコミュニケーション    

注意:

キックオフの要件について詳しくは、次のリンクもご覧ください。

開発の準備

チームが実際の開発に着手する準備ができているかどうか、事前にいくつかの前提条件を確認する必要があります。

開発チームの資格検定

必要情報 成果
AEM 技術トレーニング   スタッフの習熟  
AEM の認定プログラム   認定を受けた AEM コンポーネントの開発者(75%)  
  認定を受けた AEM リード開発者(最低 1 人)  
  認定を受けた AEM アーキテクト(最低 1 人)  

注意:

AEM のトレーニングと認定プログラムについて詳しくは、次のリンクをご覧ください。

コンテンツのアーキテクチャ

必要情報 成果
初期エクスペリエンスの設計   コンテンツのアーキテクチャの定義  
要件文書   KPI の実行可能性の確認  
ソリューションの概要設計    
アーキテクチャのドラフト    
KPI の定義    

注意:

このチェックリストでは、次の内容が定義されます。

  • 基本構造(コンテンツ、アセット、キャンペーンなど)
  • 複数サイトおよび複数言語構造(MSM、翻訳など)
  • 支援コンテンツ(タグなど)
  • キャッシュされたコンテンツとキャッシュされないコンテンツの比較

システムのアーキテクチャ

必要情報 成果
要件文書   システムのアーキテクチャの定義  
ソリューションの概要設計   設定やカスタマイズ不要な AEM のインストールを行い、推奨されている自動化テストスイートを使用してベースラインテストを実行し、計画とのかい離を把握して調整。  
アーキテクチャのドラフト   パフォーマンスやスケーラビリティについて KPI を満たすための施策確認  
ハードウェアの見積り    
KPI の定義    
リード開発者のチェックリストによるサインオフ    
パフォーマンスとスケーラビリティの概念    

注意:

このチェックリストでは、次の内容を取り上げます。

  • ハードウェアのサイズ設定に関するガイドライン
  • 必要な環境(開発、ステージング、実稼働以外に必要?)
  • 各環境のサーバーとプロセス
  • 保守アクティビティ(データストア GC、TarPM の最適化など)
  • 営業との整合性が取れた KPI
  • ディスパッチャーのキャッシング 
  • 公開/作成者共有のクラスター化 
  • 最も重要:クライアント側のパフォーマンス(JavaScript の圧縮、結合、CSS スプライト、HTTP リクエストの合計数など)

アプリケーションのアーキテクチャ

必要情報 成果
要件文書   設定やカスタマイズ不要な AEM のインストールを行い、推奨されている自動化テストスイートを使用してベースラインテストを実行し、計画とのかい離を把握して調整  
ソリューションの概要設計   開発されるコンポーネントとテンプレートの一覧、ダイアログの定義、およびこれらのすべての重要なプロパティ(名前と種類)  
アーキテクチャのドラフト   AEM の特定の(大規模な)モジュールが使用されたときの実装概念  
ハードウェアの見積り    
KPI に関する文書    
コンポーネントとテンプレートの概念    
特殊機能の概念    

注意:

このチェックリストでは、次の内容を取り上げます。

  • プロジェクトの基本コード構造
  • コードのアーティファクト(バンドル、パッケージなど)
  • テンプレート/コンポーネントの分類と関連性
  • 必要なカスタマイズ(概要、具体的なオーバーレイは後ほど)
  • ソリューションサポートの必要な一般的なワークフローの設計(コンテンツの作成、承認、公開、変換、インポート、エクスポートなど)
  • 複雑なモジュール(MSM、コマース、サードパーティの統合など)に対する特別な注意

システムの統合

必要情報 成果
サードパーティの統合の要件   サードパーティの統合の技術概念  
定義されたサービス契約とプラットフォームとの同期   サポートプロセスと緊急時の対策  

注意:

このチェックリストでは、次の内容を取り上げます。

  • サードパーティシステムの統合方法に関する技術概念(オフライン/オンライン、クライアント側/ブラウザー側)
  • サードパーティシステムが停止したときのフェイルオーバー処理 

テスト概念

必要情報 成果
初期エクスペリエンスの設計   テスト概念に関する文書  
要件文書   テスト計画  
ソリューションの概要設計   顧客のユースケースに対応するようにカスタマイズされた Tough Day  
Tough Day 用変換されたパフォーマンス KPI   形式化された受け入れテスト  
ユースケース/顧客のストーリー   実行可能なテストケースを生成する、クリックパスに分類されたユーザーのストーリー  

注意:

テストは Selenium や AEM の開発者モードなどで自動化されています。

設定のサポート

必要情報 成果
サポートプロセスの設定(パートナー/顧客/アドビ)   スタッフがアドビのサポートプロセスを把握する  
アドビのサポートポータルへのアクセスが必要なユーザーの一覧   スタッフがサポートポータルに必要な権限を得る  
エスカレーションプロセスの定義   スタッフがエスカレーションプロセスを把握する  
アドビのサポートポータルにおけるプロジェクトセクションの設定リクエスト   アドビのサポートポータルでプロジェクトが設定される  

注意:

アドビのサポートポータルをご覧ください。

トレーニングを受けた開発者にのみ読み取り/書き込みアクセス権限が付与されます。

開発

プロジェクトには開発の成功が不可欠です。これには、まず次のチェックリストを実行します。

開発環境

必要情報 成果
プロジェクトで使用される標準の開発ツールの一覧   開発環境が設定される  
ソリューションの概要設計
  開発システムの準備が整う  
アーキテクチャのドラフト    

注意:

一般的な開発は、問題追跡システム、IDE(Eclipse など)、Maven、Jenkins(継続的な統合のため)、GIT/SVN、Archiva/Nexusで構成されます。

テストシステム

必要情報 成果
ソリューションの概要設計   テストシステムの準備が整う  
アーキテクチャのドラフト    

注意:

テストシステムは、次を満たしている必要があります。
  • 開発リリースや夜間構築の準備が整っている
  • パフォーマンスのテストのため、サイズ設定が可能な限り実稼働システムと同じである

実稼働システム

必要情報 成果
システムのアーキテクチャの定義   実稼働システムの準備が整う  
最終的な実稼働時の設定で Tough Day テストを実行   Tough Day テストによりベースラインのパフォーマンスが検証される  
ディスクパフォーマンステスト   ディスクのパフォーマンス(ディスクのベンチマーク)が有効なパターンになる  

注意:

このチェックリストをアーカイブするには、次のリンクをご覧ください。

結合テスト

必要情報 成果
結合テストの設定   自動化された開発プロセス  
IT/単体テストの役割の定義    

注意:

このチェックリストでは、次の内容を取り上げます。

  • アプリケーションを開発環境、テスト環境、実稼働環境へと移行する自動化されたプロセス(コンテンツについては順番は逆)
  • 開発者が実行するテストのレベルの定義(IT、単体など)

ドキュメント

必要情報 成果
アップグレードやホットフィックスに影響を及ぼすカスタマイズについての文書化   運用マニュアル(ユーザーガイド)  
運用タスクの文書化    
リリースノート    

注意:

運用マニュアルには、次の内容が含まれている必要があります。

  • インストール済みのシステムやコンテンツに影響を及ぼす可能性のある変更点に関する情報
  • アップグレードやホットフィックスなどに影響を及ぼす可能性のあるカスタマイズやオーバーレイに関する情報
  • 運用に伴うタスクに関する情報(設定など)

パフォーマンスとテスト

優れたパフォーマンスはプロジェクトを成功に導くキーの 1 つです。

(エンド)ユーザー受け入れテスト

必要情報 成果
実稼働環境で実行されるリリース   アプリケーションの機能が関係者に受け入れられる  
受け入れテスト   顧客に渡すための正式なチェックリスト(スナップショット上で夜間ベースで実行され、出力された結果はプロジェクトマネージャーや開発チームに自動的に送信されるように適切に設定されている)  

注意:

機能やワークフローに関する問題の最終チェック段階です。すべての開発スプリントで検証される必要があります。

パフォーマンスおよび負荷テスト

必要情報 成果
パフォーマンス KPI   Tough Day または同等のテストスイートにパスする必要がある  
ユースケースの定義   実際の負荷と期待される負荷に対して検証されたテストスクリプト  
テストを実行する実際のコンテンツ   実際のコンテンツと OOTB テスト実行結果との比較に適用するようにカスタマイズされた Tough Day または同等のテストスイート  
完全に読み込まれたテストスイート   自動、または定期的に手動で実行  
  ページ要求件数の 70 %に対して 100 ms 未満で応答する  
  ページ要求への応答時間が 1 秒を超えることはない  
  ビジネス関係者からの受け入れ  

注意:

パフォーマンステストについて詳しくは、次のリンクをご覧ください。

ロールアウト

安全に運用を開始するには、トレーニングを受けたユーザーと高いレベルのセキュリティの両方が必須です。

トレーニング

必要情報 成果
AEM 管理者向けトレーニング   システム管理者の習熟  
作成者向けの標準のトレーニング   作成者/ユーザーの習熟  
必要に応じて:アプリケーション/サイト専用のトレーニング資料   エンドユーザーの習熟  

注意:

アドビの AEM トレーニングのコースカタログから目的のトレーニングを探してください。

侵入テスト

必要情報 成果
セキュリティチェックリスト   セキュリティテストレポート  
    システム所有者からの署名  

運用開始

必要情報 成果
セキュリティに関する問題の一覧   セキュリティに関する問題が修正される  
セキュリティチェックリスト   セキュリティが有効になる  
侵入テスト   侵入テストにパスする  
フォールバックシステム   システムとプロセスをスイッチバックできるようになる  
フォールバックプロシージャのテスト実施   フォールバックプロシージャのテストにパスする  
運用開始スケジュール   アドビのサポートに運用開始スケジュールが通知される  

運営

ユーザーに合わせて具体的な権限を持つ役割(作成者、寄稿者、管理者など)を定義する必要があります。また、プロジェクトの進捗に合わせてシステムを保守および監視して、緊急時に復元できるようにバックアップしておく必要があります。

権限

必要情報 成果
権限の概念(役割の一覧、グループ)   権限がセキュリティのガイドラインを満たす  

注意:

  • 役割の一覧(グループ)とそれぞれの読み取り/書き込みアクセス権限が定義されます。  
  • レプリケーションなどの権限が定義されます。 
  • 最小の権限を持つユーザーについては、ワークフローを定義する必要があります。 
  • エディターグループのユーザーは、管理権限を割り当てられることや、管理者グループの一員となることはできません。

詳しくは、ユーザー管理とセキュリティをご覧ください。

保守と監視

必要情報 成果
ディスク領域の監視   システムの監視が有効になる  
CPU の監視   しきい値と介入が有効になる  
ディスク I/O の監視   外部システムの監視が有効になる  
ネットワーク帯域幅の監視    
データストアのガベージコレクションの有効化とテスト実施    
レポジトリの最適化    
外部システムの監視    
監視の要求    

注意:

詳しくは、メンテナンスもご覧ください。

バックアップと復元

必要情報 成果
オーサーインスタンスおよびパブリッシュインスタンスのバックアップ   復元計画と手順が文書化される  
復元テストの実行と文書化    
クラスター:クローン作成の手順のテストと文書化    

注意:

AEM の実稼働環境での使用の安全性を確保するには、緊急時に備え、完全ロールバック/復元が有効になっている必要があります。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー