ドキュメントAEM 6.5ユーザーガイド

プロジェクトの管理 - ベストプラクティスチェックリスト managing-projects-best-practices-checklist

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

作成対象：

  • 管理者
  • 開発者
  • リーダー

Adobe Experience Manager（AEM）実装プロジェクトの管理では、プロジェクトの実装前および実装中の問題点と（関連する）決定を下す必要があることを認識するための計画と理解を必要とします。

ベストプラクティスは次のような役に立つ内容で構成されています。

プロジェクトのハートビートダッシュボード project-heartbeat-dashboard

プロジェクトのハートビート ​ワークシートでは、以下のプロジェクトの重要な指標の概要が図解されています。

  • フェーズの品質

  • フェーズのヘルス

    • プロジェクトの全体的なステータスインジケーター。リスクの可能性のある領域を強調するのに便利です。

  • フェーズの完了状況

    • プロジェクト中、任意の時点で、プロジェクトの各フェーズがどれだけ完了済みかを示します。

役割別のステータス status-by-role

役割別のステータス ​ワークシートには、ヘルス、**品質および​ 完了状況​の詳細な分類が、フェーズ ​および​ ペルソナ ​別に表示されます。

フェーズおよびマイルストーン phases-and-milestones

プロジェクト計画は個別の（上位レベルの）フェーズに分類されます。

フェーズごとに独自のマイルストーンが含まれます。ペルソナ（役割）ごとに、関連するマイルストーンと、定義された成果物の作成に必要なドキュメントが一覧表示されます。

NOTE
個々の必須ドキュメントと成果物の間には、直接の 1:1 の関係はありません。

準備 preparation

プロジェクトの準備は、プロジェクト全体の基礎を形成します。以下の項目に関して、主要な要件、および明確な目標と期待事項を定義します。

  • ビジネスの論理的根拠

    • プロジェクトを開始するための根本的理由と正当性。

  • 適用範囲とスケジュール

    • 要件と実施期間を定義するために、基本的な適用範囲と大まかなスケジュールを設定する必要があります。状況を明らかにするために役立つ場合は、適用範囲外にある事項も必要に応じて定義します。

プロジェクトの準備、計画および実行方法と、ソリューションの実装方法は、制約による影響を受けます。例えば、決められた予算や日程、コンテンツの量、求められる品質などです。

すべての場合に当てはまりますが、ある要因を調整すると別の要因が影響を受けます。例えば、期間を短縮し、かつ同じ品質水準を要求すると、価格は上昇し、満足できるコンテンツの量は減少します。予算が重要な要因となることが多いので、このような関係を忘れてはなりません。

4 つの要因は次のとおりです。

projectphases_fourphases

マイルストーン milestones

  • 検証

    このフェーズでは、次のようなプロジェクトの目標を検証し、確認する必要があります。

    • 何を達成または提供するか。

    • 誰にメリットがあるか。

    • 適用範囲はどうするか。

      • 状況を明らかにするために役立つ場合は、適用範囲外にある事項も定義します。

    • 成功をどう定義するか。

    • 成功をどのように測定するか。

    • ビジネス要件と技術要件。

    • 置き換えが必要なレガシーシステムの有無。これが該当する場合は移行が必要なデータの有無。

    • 誰が関与するか。

    • 進行状況をどのように測定するか。

    • プロジェクトの期間中に進行状況を確認する頻度。

  • 予算

    プロジェクトを開始する前に、実装にかかるコストに関して信頼性が高く現実的な見積もりを行う必要があります。

    • 検証マイルストーンの情報を見積もりの基礎として使用します。
    • 現実的に見積もりを行います。
    • クライアントが従うガイドライン、プロセスまたは制限を考慮し、尊重します。
    • 後の段階で予算の再検討や見直しが必要になった場合の、不測の事態やレビューのプロセスを考慮します。
    • 物品の購入やリソースの使用、手数料など、多くの形でコストが発生することに留意します。

計画 planning

プロジェクトを計画すると、準備が一本化されます。ここでは、目標と期待事項を明確なロードマップに変換していく必要があります。具体的なタスクで構成し、明確なコミュニケーションを伴い、厳格なレビューによって進捗状況を測定するようにします。

マイルストーン milestones-1

  • 引き継ぎ

    引き継ぎを明確化することで、適切なペルソナまたはグループが、プロジェクト内の自らの責任を確実に理解できるようになります。

    それには、ロードマップ、適用範囲、目標、要件および KPI を含む関連するすべての局面を十分に理解できるように、完全な詳細を提供または生成する必要があります。

  • リスク評価

    不測の事態を避けるために、リスク評価を使用して、潜在的なリスクおよびその影響と発生確率を識別し、定量化します。

    これは、プロジェクトのライフサイクルの早期に実施し、脆弱性を確実に識別して評価する必要があります。結果に基づいて、要件がすべて実装可能かどうか、また必要に応じて、適切な措置を実施して追跡することが可能かどうかを関係者に報告できます。

  • コミュニケーション

    どんなプロジェクトにおいても、コミュニケーションは常に成功への鍵となります。明確かつ効率的なコミュニケーションにより、全員が次のことを確実に行えるようにします。

    • 同じ基本目標に向かう
    • 同じ情報ベースから出発する
    • 同じチャネルを使用する

  • キックオフ

    キックオフミーティングは、プロジェクト開始の認識を高めるために使用されます。次のことを行う良い機会です。

    • 関係するすべての人（少なくともグループの代表者）の招待

    • プロジェクトに関する重要な情報の提示

    • 質問への回答

    • メンバー全員のナレッジベースの合致

    • 今後関係するすべての人からのコミットメント（コミットメントを得る必要が出てきます）

      • 最重要プレーヤー（作成者になる見込みの人を含む）にプロジェクトの開始時点から参画してもらうと、その人たちのプロジェクトへのコミットメントを得られる可能性が高まります。

開発の準備 development-preparation

開発計画は、強固なデザインに基づき、必要な知識を持つチームがプロジェクトを構築するための確かな鍵となります。

マイルストーン milestones-2

  • 開発チームの人員確保とトレーニング

    プロジェクトに取り掛かる前に、開発チームに適切な人材が確保されていて、チームのメンバー全員が必要なトレーニングを受けていることを確認する必要があります。

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

    コンテンツのアーキテクチャでは、次のようなコンテンツの将来のアーキテクチャを定義し記述します。

    • コンテンツツリー（アセットを含む）
    • 基本構造（キャンペーンなどを含む）
    • マルチサイトと多言語の構造（MSM、翻訳など）
    • サポートコンテンツ（タグとタグ付けの概念を含む）
    • キャッシュとコンテンツ再利用の戦略

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

    システムのアーキテクチャでは、特に次の情報を含むシステムの概念表示を定義します。

    • 必要なすべての環境のシステム構造

    • サブシステム

    • サードパーティシステム

    • インターフェイス（ハードウェア、ソフトウェアおよび人間の操作）

    • 各環境のサーバー（技術要件およびハードウェアのサイジングのガイドラインを参照）

    • 各環境用のプロセス（デプロイメント要件やメンテナンス要件など）

    • メンテナンスアクティビティ（データストア GC、TarPM の最適化など）

    • Dispatcher のキャッシング

    • 公開/作成者共有のクラスター化

    • クライアント側のパフォーマンス（JavaScript の圧縮、結合、CSS スプライト、HTTP リクエストの合計数など）

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

    アプリケーションのアーキテクチャでは、提案されたアプリケーションの動作を定義し、説明します。

    次に焦点を当てます。

    • アプリケーション間およびアプリケーションとユーザーのやり取りの方法。
    • 内部構造ではなく、アプリケーションによって消費および生成されるデータ。

    定義では、以下についてカバーする必要があります。

    • プロジェクトの基本コード構造
    • コードアーティファクト（バンドル、パッケージなど）
    • テンプレートまたはコンポーネントの分類とその関係
    • 必要なカスタマイズの全体的な概要（具体的なオーバーレイは後で検討します）
    • ソリューションで必要なワークフローのデザイン（コンテンツの作成、承認、公開、変換、読み込み、書き出しなど）
    • MSM、コマース、サードパーティ統合など、複雑なモジュールに関する特別な検討事項

  • システム統合

    システム統合では、以下を計画（その後実装）する必要があります。

    • すべてのサブシステムとソリューションの統合をどのようにまとめ、1 つの一貫性のあるシステムとして稼動させるか
    • サードパーティのシステムをどのように統合するか（オフラインかオンラインか、クライアント側かブラウザー側か、サードパーティのシステムがダウンした時のフェイルオーバー処理などの特別な考慮も必要）

  • テストの概念

    開発を始める前に、プロジェクトのすべてのテスト要件の詳細で包括的な概念を作成する必要があります。

    これには、特に以下のことを含める必要があります。

    • 実行するすべてのテストの詳細
    • これらのテストに必要なコンテンツの準備
    • 使用するテストツールの情報
    • テストに参加するユーザー（特に QA チーム以外のグループ）の概要
    • テストの自動化の詳細（Selenium や AEM 開発者モードの使用など）

  • エクスペリエンスデザイン

    エクスペリエンスデザイン（XD）には、ソリューションのユーザーエクスペリエンスのデザインが含まれます。

    Web サイトの作成者と最終ユーザーの双方に関してユーザーエクスペリエンスを分析し、開発する必要があります。

  • サポートの設定

    開発の前に、デプロイ、リリース、テスト、問題の報告に必要なすべてのサポートプロセスを設定する必要があります。

    詳しくは、アドビサポートポータルも参照してください。

運用計画と運用 operations-planning-and-operations

同様に、運用を適切に計画して、プロジェクトのライフサイクルのすべての段階で、必要な環境が確保されるようにする必要があります。また、その運用を維持するための適切なプロセスも必要です。

マイルストーン milestones-3

  • 権限

    ソリューションを使用するすべてのユーザーやグループに対して、役割と権利の概念を計画し、実装する必要があります。

    例：

    • 役割の一覧（グループ）とそれぞれの read／write アクセス権限の定義

    • パブリッシュ環境に影響を及ぼす権限の使用の定義（replicate など）

    • 最小限の権限を持つユーザーの場合、ワークフローを定義する必要があります。

    • editor グループのユーザーは、admin の権利を持つことも、administrators グループに属することもできません。

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

  • モニタリングとメンテナンス

    モニタリングとメンテナンスは、運用を開始した後にソリューションをスムーズに運用するための重要な要素です。 そのためには、以下を定義する必要があります。

    • 何をモニタリングする必要があるか
    • メンテナンスタスク（定期的および特殊ケース用）

    詳しくは、モニタリングとメンテナンスも参照してください。

  • 移行

    レガシーシステムに由来するコンテンツは、移行用にレビューし、検証する必要があります。

  • 障害回復計画

    障害回復計画が整っていることを確認します。緊急時には、この計画により、AEM の実稼動環境を保護できるようにする必要があります。バックアップ、復元、フェイルオーバーおよびその他の状況をカバーします。

開発 development

開発は重要なフェーズであり、必要なのはコーディングだけではありません。

マイルストーン milestones-4

  • 開発環境

    以下を含めて、開発環境を計画し、文書化します。

    • アーキテクチャ

    • 開発ツール

      • 典型的な環境の構成内容は次のとおりです。

        • 問題追跡システム（Jira など）
        • IDE（Eclipse など）
        • ビルド管理ツール（Maven など）
        • 継続的統合のためのツール（Jenkins など）
        • バージョン管理ツール（GIT や SVN など）
        • ビルドアーティファクトのリポジトリマネージャー（Archiva や Nexus など）

    • サードパーティソフトウェアの統合と依存関係

    • ソリューションの統合と依存関係

    • デプロイメントのサイクル

  • テストシステム

    以下を含めて、テスト環境を計画し、文書化します。

    • アーキテクチャ
    • 夜間ビルドを含む開発ビルドへの依存性
    • サードパーティソフトウェアの統合と依存関係のテストの可能性または制限
    • テストツール
    • 自動テスト戦略

  • 実稼動システム

    以下を含めて、実稼動環境を計画し、文書化します。

    • アーキテクチャ
    • デプロイメントのサイクル
    • サードパーティソフトウェアの統合と依存関係
    • セキュリティ設定
    • 実稼動セットアップで Tough Day テストを実行して検証されたベースラインパフォーマンス
    • パフォーマンステストの要件（品質保証のベストプラクティスを参照）

  • 統合

    以下を含めて、システムおよびソリューションの統合のすべての局面を計画、文書化およびテストします。

  • 移行

    以下を含めて、コンテンツ移行のすべての局面を計画、文書化およびテストします。

    • コンテンツのアーキテクチャ
    • 移行戦略

  • コミュニケーション

    チームの全メンバーおよびプロジェクトのペルソナに必要な最新情報を伝達します。

  • ドキュメント

    以下を含めて、ソリューションを完全に文書化します。

    • 運用マニュアル
    • アップグレードに影響する可能性のあるカスタマイズ
    • リリースノート

パフォーマンスおよびテスト performance-and-testing

新しいアプリケーションが使用可能になったら、機能とパフォーマンスの両面で厳格なテストを行う必要があります。

NOTE
テストチームは、中立を保ち、テスト結果を提供する必要があります。
結果の影響を評価し、適切な行動を決定するのは、プロジェクトマネージャーの責任です。

マイルストーン milestones-5

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

    ユーザー受け入れテスト（UAT）は、次のことを確実にするために非常に重要です。

    • ソリューションがユーザーや顧客の要件を満たしていること
    • 顧客やユーザーがソリューション（機能、デザインおよびパフォーマンス）を受け入れること

    顧客への引き渡し用の形式化されたチェックリストが必要です。自動化され、スナップショットに対して夜間に実行されるのが理想的です。その結果をプロジェクトマネージャーおよび開発チームに送信する必要があります。

  • パフォーマンステストと負荷テスト

    パフォーマンステストと負荷テストは、平均負荷とピーク負荷で必要なパフォーマンスレベルをソリューションが満たしていることを確認するために使用されます。

    パフォーマンステストについて詳しくは、以下を参照してください。

    note note
    NOTE
    このプロセスは、通常の AEM 使用時も引き続き実行する必要がありますが、この初期段階では最も重要です。

ロールアウト rollout

スムーズに運用を開始するためには、新しいアプリケーションのロールアウトを慎重に計画する必要があります。これには、全体的なセキュリティの確認、見込みユーザー全員のトレーニング、すべての問題が対応済みであることを確認するためのドライランの複数回に渡る実行が含まれます。

マイルストーン milestones-6

  • 準備

    準備と計画は、スムーズなロールアウトの実現に役立ちます。

  • トレーニング

    関与する全スタッフがトレーニングを受けていることを確認します。

    コースカタログで Adobe Experience Manager を参照してください。

  • 管理者のトレーニング

    ソリューション管理者に関して、以下のことを確認します。

    • トレーニングを受けていること
    • 適切なトレーニング資料を受け取っていること
    • 適切なドキュメントを受け取っていること

  • ユーザーのトレーニング

    作成者に関して、以下のことを確認します。

    • トレーニングを受けていること
    • 適切なトレーニング資料を受け取っていること
    • 適切なドキュメント（ユーザーガイドなど）を受け取っていること

  • 侵入テスト

    侵入テストでは、コンピューターシステムへの攻撃をシミュレートして、潜在的なセキュリティの弱点を特定します。

  • 侵入／セキュリティテスト

    ソリューションのセキュリティを確実にするために、特定の侵入テストを、多岐に渡るセキュリティテストとともに実行します。

    詳しくは、セキュリティチェックリストを参照してください。

運用開始 go-live

運用開始は可能な限りスムーズにする必要があります。ここでも、クリーンな実行のために、最終手順を計画する必要があります。

マイルストーン milestones-7

  • 準備

    準備と計画は、スムーズな運用開始の実現に役立ちます。

  • セキュリティ

    内部、外部両方のユーザーとユーザーのコンテンツに対して、ソリューションのセキュリティを確認します。

  • フォールバック

    運用開始前に、フォールバックに必要なシステム、手順およびメカニズムがすべて揃っていることを確認します。

  • サポート

    サポートサービスが整っていて、準備ができていることを確認します。

  • トランジション

    実稼動環境およびユーザーへの切り替えを計画し、実行します。

  • ロールアウト

    スモークテストを準備して実行します。

ペルソナ persona

チェックリストはペルソナごとに設計します。この役割は、プロジェクトのライフサイクルに重要な関わりを持っています。

また、特定のタスクに関与するその他のペルソナも存在します。

プロジェクトスポンサー project-sponsor

プロジェクトスポンサーは：

  • プロジェクトにビジネスケースを提供または提示します。

  • プロジェクトの適用範囲を形成し、定義する上での鍵となります。以下を含みます。

    • 成功の定義と条件
    • 主要な KPI

  • クライアントのロードマップに基づいて主要なマイルストーンを提供します。

プロジェクトマネージャー project-manager

プロジェクトマネージャーの役割：

  • プロジェクトスポンサーによって提供された要件（適用範囲、KPI、成功の条件および定義など）に基づいて、プロジェクトを全体的に遂行します。
  • 予算を定義し、その予算に基づいてプロジェクトを準備します。
  • プロジェクトに関与する全ペルソナのコミュニケーションの要となります。

アーキテクト architect

ソリューションアーキテクトの役割：

  • ソリューションおよびシステムの高レベルのデザインを担当します。
  • AEM の実装戦略の定義を支援します。例えば、クラスターインストールとコールドスタンバイのどちらを実装するか、どのような場合にコンテンツ配信ネットワーク（CDN）が必要かなどです。
  • クライアントの要件に基づいて、AEM ソリューションアーキテクチャも定義します。これには、ユーザーの役割（および関連する権利）の概念、テンプレートとコンポーネントの関係、どんな場合にマルチサイト管理を使用するかなどが含まれます。

ビジネスアナリスト business-analyst

ビジネスアナリストの役割：

  • ハイレベルの要件を収集して分析し、次のような仕様に転換する作業を主に担当します。

    • プロジェクトマネージャーが開発を計画する際に利用する仕様
    • 開発チームがデザインおよび開発の際に基準とする仕様

  • クライアントと密接に協力して要件を分析します。以下に照らして要件を一致させます。

    • 成功の定義
    • 成功の条件
    • KPI（ビジネスベースとパフォーマンスベース）

開発リーダー development-lead

開発リーダーの役割：

  • プロジェクトを技術的に遂行します。

  • クライアントの要件に準拠する開発方法を選択します。

  • 次のようにして開発戦略を作成します。

    • ビジネス KPI とパフォーマンス KPI に合致していることを確認する
    • 成功の条件および定義を考慮

  • アーキテクトと密接に協力し（特に AEM の開発戦略を作成する際）、テンプレートとコンポーネントの関係、サードパーティアプリケーションの統合戦略、特殊な機能などの局面を定義します。

品質リーダー quality-lead

品質リーダーの役割：

  • 成果物の品質に関する責任を負い、成功のための条件やクライアントが定義している KPI が満たされていることを確認します。
  • 品質の指標を定義し、全関係者と協調し、テスト計画を作成して確実に実行します。
  • レポートを作成し、プロジェクトの関係者に配信します。

システムエンジニア system-engineer

システムエンジニアの役割：

  • プロジェクトのインフラストラクチャを監督します。

  • 次の作業を担当します。

    • 内部の開発環境とテスト環境の設定
    • 設定したシステムとクライアントのシステムとのマッチング

  • 推奨されるハードウェアを提案し、様々な実装を監視し、運用開始前後の運用サポートを提供します。

セキュリティリーダー security-lead

セキュリティリーダーの役割：

  • ソリューションの全体的なセキュリティ概念に関する責任を負い、セキュリティ概念がクライアントの要件やポリシーに沿っていることを確認します。
  • セキュリティ概念、セキュリティ操作を提供し、ゾーンやファイアウォールといったハードウェアベースのセキュリティ概念を推奨します。

その他のペルソナ other-persona

  • 利害関係者

    • プロジェクトの成功に利害関係を持つ人物（多くの場合はビジネス関係者）。多くの場合、予算に貢献します。

  • リーガル

    • 契約交渉時には、法的助言が必要です。

  • トレーナー

    • プロジェクトの規模と性質によっては、専門的なトレーナーを活用して、関連グループのトレーニングセッションを開発し、提示できます。

  • テクニカルライター

    • プロジェクトの規模と性質によっては、専門のテクニカルライターを使用して、特定のグループ向けのガイドラインやマニュアルを作成できます。例えば、システム管理者向けのメンテナンスマニュアルや、作成者向けのユーザーガイドなどです。

  • システム管理者

    • システムの継続運用に関する責任を負います。

  • 作成者とエンドユーザー

    • システムを使用して web サイトのコンテンツを作成し、メンテナンスする人物です。

必須ドキュメントと成果物 required-documents-and-deliverables

チェックリストは、各マイルストーンの​ 必須ドキュメント ​および​ 成果物 ​をカバーしています。

  • これらの間には、一対一の関係はありません。例えば、複数の必須ドキュメントのグループが 1 つの成果物になる場合もあります。
  • 同じマイルストーンの中で、あるペルソナからの成果物が、別のペルソナの必須ドキュメントになる場合もあります。

必須ドキュメント required-documents

必須ドキュメント ​は、適切なペルソナが成果物を作成する際に必要になるものです。

必須ドキュメント ​ごとに、ペルソナは以下を示す必要があります。

  • Y／N：必須ドキュメントを受け取ったかどうか。
  • 1 ～ 3：受け取ったドキュメントの品質の表示。

成果物 deliverables

マイルストーンごとに、適切なペルソナは特定のドキュメントを提供する責任を負い、その結果、特定のマイルストーンに対する責任を負うことになります。

成果物 ​ごとに、ペルソナは以下を示す必要があります。

  • Y/N：成果物が完成したかどうか。

成果物は、多くの場合、現在のマイルストーンまたは後続のマイルストーンの​ 必須ドキュメント ​として使用されます。

デプロイ、管理、開発またはオーサリングのベストプラクティスについては、次を参照してください。

ドキュメントの重要個所 key-documentation-areas

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2