プロジェクトの管理 ― ベストプラクティスチェックリスト

注意

AEM 6.4 の拡張サポートは終了し、このドキュメントは更新されなくなりました。 詳細は、 技術サポート期間. サポートされているバージョンを見つける ここ.

Adobe Experience Manager(AEM) を実装するプロジェクトを管理する場合、（プロジェクトの実装前と実装中の）問題と、実行する必要のある（関連する）決定を認識するために、計画と理解が必要です。

ベストプラクティスは次の要素で構成されています。

プロジェクトハートビートダッシュボード

この プロジェクトハートビート ワークシートでは、プロジェクトの重要な指標の概要をグラフィカルに示します。

  • フェーズの品質

  • フェーズのヘルス

    • プロジェクトの高レベルステータスインジケーター。危険な領域を強調するのに役立ちます。

  • フェーズの完全性

    • プロジェクトの任意の時点で、これは、プロジェクトの各フェーズで既に完了している量を示します。

ロール別ステータス

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

フェーズとマイルストーン

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

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

メモ

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

準備

プロジェクトの準備は、プロジェクト全体の基礎となります。 次の項目に関する明確な目標と期待と共に、主要な要件を定義する必要があります。

  • ビジネスの根拠

    • プロジェクトを実行するための基本的な理由と理由。

  • 範囲とスケジュール

    • 何が必要で、どの期間内に必要かを定義するには、基本的な範囲と大まかなスケジュールを使用できるようにする必要があります。状況を明確にするのに役立つ場合は、範囲の外にあるものを定義することもできます。

プロジェクトの準備、計画、実行、およびソリューションの実装方法は、固定予算、固定タイムライン、コンテンツの数量、必要な品質など、運用中の制限の影響を受けます。

いつものように、任意の要因を調整すると、他の要因に影響します。 例えば、時間を短縮しますが、同じ品質を必要とすると、価格が上昇し、対応可能なコンテンツの量が減少する可能性があります。 多くの場合、予算は重要な要素なので、このような関係を忘れることはできません。

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

projectphases_fourphases

マイルストーン

  • 検証

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

    • 何を実現/提供したいか。
    • 誰が利益を得るのか？
    • 範囲とは
      • 状況を明確にするのに役立つ場合は、範囲の外にあるものを定義することもできます。
    • 成功をどのように定義しますか？
    • 成功をどのように測定しますか？
      • ビジネス要件と技術要件。
      • 置き換えるレガシーシステムはありますか。置き換える場合は、移行するデータがありますか。
      • 誰が関わるの？
      • 進捗をどのように測定しますか？
      • プロジェクトの期間中、進捗状況をどのくらいの頻度で確認しますか？

  • 予算

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

    • 見積もりの基礎として、検証マイルストーンの情報を使用します。
    • 見積もりを現実的にする。
    • クライアントが従う可能性のあるクライアントガイドライン、プロセスまたは制限を考慮し、尊重します。
    • 予算の検討または改善が後の段階で必要になる場合は、事故とレビュー・プロセスを検討します。
    • コストは多くの形で生じるので、購入、リソースの使用、手数料など。

計画

プロジェクトを計画すると、準備が統合されます。 ここでは、目標と期待を、明確なコミュニケーションに縛られ、進捗を測定する厳しいレビューを伴う具体的なタスクから成る明確に定義されたロードマップに変換し始める必要があります。

マイルストーン

  • 引き渡し

    クリーンな引き継ぎにより、適切なペルソナ/グループがプロジェクト内での自分の責任を認識するようになります。

    ロードマップ、範囲、目標、要件、KPI など、すべての関連事項を完全に理解できるよう、詳細な情報を提供/生成する必要があります。

  • リスク評価

    不快な事態を避けるには、リスクアセスメントを使用して、潜在的なリスクを特定し、その影響と確率と共に定量化します。

    これは、プロジェクトのライフサイクルの早い段階でおこない、すべての不具合を確実に識別し評価する必要があります。 結果に基づいて、すべての要件を実装できるかどうか、および必要に応じて適切な行動を計画し、追跡できるかどうかについて、関係者に報告できます。

  • 通信

    コミュニケーションは常に、あらゆるプロジェクトを成功させる鍵となります。 誰もが次のことを確実に行うために、明確かつ効率的にコミュニケーションを取る必要があります。

    • 同じ基本目標に向けた取り組み
    • 同じ情報ベースから
    • 同じチャネルで

  • キックオフ

    キックオフ会議は、プロジェクトが始まっているという認識を高めるために使用されます。 これは、次のことをおこなう良い機会です。

    • すべての関心のある関係者（または少なくともグループの担当者）を招待します。
    • プロジェクトに関する主な事実を示します。
    • 質問に答えます。
    • 誰もが同じナレッジベースを持っていることを確認します。
    • 関与するすべての人からコミットメントを得る — これは獲得する必要があります。
      • プロジェクトの最初にプライムプレーヤー（作成を見込む人を含む）を参加させることで、プロジェクトへの取り組みを獲得する機会を増やすことができます。

開発準備

開発の計画は、必要な知識を持つチームが、プロジェクトを確実な設計に基づいて構築するための鍵となります。

マイルストーン

  • 開発チームのスタッフとトレーニング

    プロジェクトを開始する前に、開発チームが適切にスタッフを配置し、すべてのチームメンバーが目の前のタスクに関するトレーニングを受けていることを確認する必要があります。

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

    コンテンツアーキテクチャは、コンテンツの将来のアーキテクチャを定義し記述します。次を含む：

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

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

    システムアーキテクチャは、システムの概念的なビューを定義します。次の情報を含みます。

    • システム構造 すべての必要な環境
    • サブシステム
    • サードパーティ製システム
    • インターフェイス；ハードウェア、ソフトウェア、人間の相互作用
    • 各環境のサーバー（技術要件およびハードウェアのサイジングのガイドラインを参照）
    • 各環境のプロセス例えば、デプロイメントとメンテナンスの要件などです。
    • メンテナンスアクティビティ（データストア GC、TarPM の最適化など）
    • Dispatcher のキャッシング
    • 公開/作成者共有のクラスター化
    • クライアント側のパフォーマンス（JS の縮小、連結、CSS スプライト、HTTP リクエストの合計数など）

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

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

    重点的な役割は次のとおりです。

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

    以下の定義をカバーする必要があります。

    • プロジェクトの基本コード構造
    • コードアーティファクト（バンドル、パッケージなど）
    • テンプレート/コンポーネントの分類とその関係
    • 必要なカスタマイズの大まかな詳細（特定のオーバーレイは後で表示されます）
    • ソリューションで必要なワークフローのデザイン（コンテンツの作成、承認、公開、変換、インポート、エクスポートなど）
    • MSM、コマース、サードパーティ統合など、複雑なモジュールに関する特別な考慮事項

  • システム統合

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

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

  • テストの概念

    開発を始める前に、すべての テスト プロジェクトの要件を示します。

    これには、次を含める必要があります（特に）。

    • 実行するすべてのテストの詳細
    • テストに必要なコンテンツの準備
    • 使用するテストツールの情報
    • テストに関与する人物の概要特に QA チーム外のグループ
    • テストの自動化の詳細例えば、Selenium またはAEM Developer モードを使用する場合

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

    エクスペリエンスデザイン (XD) では、ソリューションのユーザーエクスペリエンスをデザインします。

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

  • サポートの設定

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

    関連トピック Adobeサポートポータル.

運用計画と運用

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

マイルストーン

  • 権限

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

    次に例を示します。

    • 役割の一覧（グループ）とそれぞれの read／write アクセス権限の定義
    • パブリッシュ環境に影響を及ぼす権限の使用の定義（replicate など）
    • 最小限の権限を持つユーザーの場合、ワークフローを定義する必要があります。
    • editor グループのユーザーは、admin の権利を持つことも、administrators グループに属することもできません。

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

  • 監視とメンテナンス

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

    • 監視が必要なもの
    • メンテナンスタスク通常の場合と特殊な場合の両方

    関連トピック 監視とメンテナンス を参照してください。

  • 移行

    レガシーシステムのコンテンツを確認し、移行の検証を行う必要があります。

  • 復旧計画

    回復計画が設定されていることを確認します。 緊急事態が発生した場合は、AEMの実稼動環境での使用を保護するために、この機能を使用できる必要があります。 これは、バックアップ、復元、フォールオーバーなどの状況をカバーする必要があります。

開発

開発は、単なるコーディング以外にも必要とされる重要なフェーズです。

マイルストーン

  • 開発環境

    次のような開発環境の計画と文書化

    • アーキテクチャ
    • 開発ツール
      • 典型的な環境の構成内容は次のとおりです。
        • 問題追跡システム例えば、ジラ
        • IDE;例： Eclipse
        • ビルド管理ツール例えば Maven
        • 継続的統合のためのツール（Jenkins など）
        • バージョン管理用のツール例：GIT/SVN
        • アーティファクトリポジトリマネージャーを作成する例えば、Archiva/Nexus
    • サードパーティのソフトウェアの統合/依存関係
    • ソリューションの統合と依存関係
    • デプロイメントケイデンス

  • テストシステム

    次のようなテスト環境を計画し、文書化します。

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

  • 実稼動システム

    次のような実稼動環境の計画と文書化

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

  • 統合

    システムおよび ソリューション統合、次を含む：

  • 移行

    コンテンツ移行のあらゆる側面を計画、文書化、テストする。次を含む：

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

  • 通信

    すべてのチームメンバーとプロジェクトのペルソナが必要に応じて最新の状態に保たれていることを確認します。

  • ドキュメント

    ソリューションを完全に文書化する。次を含む：

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

パフォーマンスとテスト

新しいアプリケーションが利用可能になったら、機能と 性能.

メモ

テストチームは、中立を保ち、テスト結果を提供する必要があります。

結果の影響を評価し、適切な行動を決定するのは、プロジェクトマネージャーの責任です。

マイルストーン

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

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

    • ソリューションは、ユーザー/お客様の要件を満たします
    • お客様/ユーザーがソリューション（機能、設計、パフォーマンス）を受け入れる

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

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

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

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

    メモ

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

ロールアウト

新しいアプリケーションのロールアウトでは、スムーズな運用を実現するために、慎重な計画が必要です。 これには、高いレベルのセキュリティの確認、すべての見込みユーザーのトレーニング、すべての問題に対処したことを確認するための複数のドライランの作成が含まれます。

マイルストーン

  • 準備

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

  • トレーニング

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

    詳しくは、 Adobe Experience Manager コースカタログ内

  • 管理者のトレーニング

    ソリューション管理者が以下の権限を持っていることを確認します。

    • トレーニング済み
    • 適切なトレーニング資料を受け取りました
    • 適切なドキュメントを受け取りました

  • トレーニング済みユーザー

    作成者が以下の条件を満たしていることを確認します。

    • トレーニング済み
    • 適切なトレーニング資料を受け取りました
    • 適切なドキュメントを受け取りました。例えば、ユーザーガイド

  • 侵入テスト

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

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

    ソリューションのセキュリティを確保するには、特定の侵入テストを実行すると共に、幅広いセキュリティテストを実行します。

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

運用開始

Go Live をできるだけスムーズにしたい。 最後の手順は、クリーンな実行の計画が必要です。

マイルストーン

  • 準備

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

  • セキュリティ

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

  • フォールバック

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

  • サポート

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

  • トランジション

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

  • ロールアウト

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

ペルソナ

チェックリストはペルソナでデザインします。 これらは、プロジェクトのライフサイクルに大きく関わる役割です。

また、 他のペルソナ 特定のタスクに関与する

プロジェクトスポンサー

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

  • プロジェクトのビジネスケースを提供/提示する責任を負います。

  • プロジェクトの範囲を形成し定義するための鍵；次を含む：

    • 成功の定義、成功の基準
    • 主要 KPI

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

プロジェクトマネージャー

プロジェクトマネージャーは次のようになります。

  • プロジェクトスポンサーが提供する要件（範囲、KPI、達成基準、定義など）に基づいて、プロジェクトの全体的な配信を担当します。
  • 予算の定義と、その予算に基づくプロジェクトのリソースを設定します。
  • プロジェクトに関わるすべてのペルソナのコミュニケーションの主なポイント。

設計者

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

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

ビジネスアナリスト

ビジネス・アナリスト：

  • 主に、高レベル要件の収集と分析を担当し、次の仕様に変換します。

    • プロジェクトマネージャが開発を計画する際に使用する
    • 開発チームが設計と開発の間に働くために

  • クライアントと緊密に連携して要件を分析します。 これらを次と照合します。

    • 成功の定義。
    • 成功の基準。
    • KPI（ビジネスベースとパフォーマンスベースの両方）

開発リード

開発リード：

  • プロジェクトの技術的な配信を担当します。

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

  • 開発戦略を作成します。

    • ビジネス KPI とパフォーマンス KPI に合致していることを確認する
    • 達成基準と定義を考慮する

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

品質リード

品質リード：

  • 配信の品質を担当します。成功の基準と、クライアントが定義した KPI を満たしていることを確認する。
  • 品質指標を定義し、すべての関係者と整合し、テスト計画を作成し、確実に実行するようにします。
  • レポートを作成し、プロジェクトの関係者に配信します。

システムエンジニア

システムエンジニア：

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

  • 以下を担当します。

    • 内部開発環境とテスト環境の設定
    • これらのシステムをクライアントシステムに一致させる

  • ハードウェアの推奨事項を提供し、様々な実装を監視し、運用を開始する前とその後の両方で運用サポートを提供します。

セキュリティリード

セキュリティリード：

  • ソリューションの全体的なセキュリティ概念を担当し、クライアントからの要件やポリシーに合わせていることを確認します。
  • あらゆるハードウェアベースのセキュリティ概念に対するセキュリティ概念、セキュリティ操作、推奨事項を提供ゾーンやファイアウォールなど。

その他のペルソナ

  • 関係者

    • プロジェクトの成功に関心（関心）を持つ人（多くの場合、ビジネスの人）。 彼らは予算に貢献することが多い。

  • リーガル

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

  • トレーナー

    • プロジェクトの規模や性質に応じて、専門のトレーナーを使用して、関連するグループのトレーニングセッションを開発し、提示することができます。

  • テクニカルライター

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

  • システム管理者

    • システムの継続的な運用を担当します。

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

    • Web サイトのコンテンツの作成と管理にシステムを使用するユーザー。

必要なドキュメントと成果物

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

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

必須ドキュメント

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

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

  • Y/N:受け取ったかどうか。
  • 1-3:受け取ったドキュメントの品質を示します。

成果物

マイルストーンごとに、適切なペルソナが特定のドキュメントの配信を担当し、特定のマイルストーンに対する責任を実現します。

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

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

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

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

ドキュメントの重要個所

このページ