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

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

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

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

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

  • フェーズの品質

  • フェーズのヘルス

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

  • フェーズの完了状況

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

役割別のスタータス

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

フェーズおよびマイルストーン

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

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

メモ

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

準備

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

  • ビジネスの論理的根拠

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

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

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

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

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

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

projectphases_fourphases

マイルストーン

  • 検証

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

    • 何を達成または提供するか。
    • 誰が恩恵を受けるか。
    • 適用範囲はどうするか。
      • 状況を明らかにするために役立つ場合は、適用範囲外にある事項も必要に応じて定義します。
    • 成功をどう定義するか。
    • 成功をどのように測定するか。
      • ビジネス要件と技術要件。
      • 交換が必要なレガシーシステムの有無。これが該当する場合は移行が必要なデータの有無。
      • 誰が関与するか。
      • 進行状況をどのように測定するか。
      • プロジェクトの期間中に進行状況を確認する頻度。

  • 予算

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

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

計画

プロジェクトを計画すると、準備が一本化されます。ここではまず、目標と期待を転換することにより、具体的なタスクから成り、明確なコミュニケーションを伴い、厳格なレビューによって進行状況を測定する、十分に定義されたロードマップを作成する必要があります。

マイルストーン

  • 引き継ぎ

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

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

  • リスク評価

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

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

  • コミュニケーション

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

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

  • キックオフ

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

    • 関心のあるすべての関係者（または少なくともグループの代表者）の招待
    • プロジェクトに関する重要な情報の提示
    • 質問への回答
    • メンバー全員の知識ベースの合致
    • 関係するすべての人から必要なコミットメントを得る
      • 最重要プレーヤー（作成者になる見込みの人を含む）をプロジェクトの開始時点から参画させると、その人たちのプロジェクトに対する取り組みが真剣なものになる可能性が高まります。

開発の準備

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

マイルストーン

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

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

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

    コンテンツのアーキテクチャでは、以下を含むコンテンツの将来のアーキテクチャを定義し、説明します。

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

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

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

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

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

    以下に焦点が当てられています。

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

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

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

  • システムの統合

    システムの統合には、以下の計画（および実装）が必要です。

    • すべてのサブシステムおよびソリューションの統合をどのようにして 1 つのまとまったシステムとして動作させるか
    • サードパーティ製システムの統合方法と共に、オフライン/オンライン、クライアント側/ブラウザー側、サードパーティシステムがダウンした場合のフォールオーバー処理など、特別な考慮事項も含まれます。

  • テスト概念

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

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

    • 実施するすべてのテストの詳細
    • テストに必要なコンテンツの準備
    • 使用するテストツールの情報
    • テスト要員、特に QA チーム外のグループの概要
    • テストの自動化の詳細（Selenium や AEM 開発モードの使用など）

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

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

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

  • サポートのセットアップ

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

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

運用計画と運用

同様に、運用を適切に計画し、プロジェクトのライフサイクルの全段階に関して、必要な環境が整っていることを確認する必要があります。また、メンテナンスのための適切なプロセスも必要です。

マイルストーン

  • 権限

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

    次に例を示します。

    • read/ write個々のアクセス定義を持つ役割（グループ）のリスト
    • パブリッシュ環境に影響を与える権限の使用の定義例： replicate
    • 最小限の権限を持つユーザーの場合は、ワークフローを定義する必要があります
    • editorグループのユーザーは、adminの権限を持つことも、administratorsグループに属することもできません

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

  • 監視とメンテナンス

    監視とメンテナンスは、実稼動後のソリューションのスムーズな運用を実現するために重要な局面です。そのためには、以下を定義する必要があります。

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

    詳しくは、監視とメンテナンスも参照してください。

  • 移行

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

  • 障害回復計画

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

開発

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

マイルストーン

  • 開発環境

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

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

  • テストシステム

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

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

  • 実稼動システム

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

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

  • 統合

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

  • 移行

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

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

  • コミュニケーション

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

  • ドキュメント

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

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

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

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

メモ

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

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

マイルストーン

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

    ユーザー受け入れテスト（UAT）は、以下のことを確実にする上で重要です。

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

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

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

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

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

    メモ

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

ロールアウト

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

マイルストーン

  • 準備

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

  • トレーニング

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

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

  • 管理者のトレーニング

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

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

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

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

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

  • 侵入テスト

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

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

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

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

運用開始

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

マイルストーン

  • 準備

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

  • セキュリティ

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

  • フォールバック

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

  • サポート

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

  • トランジション

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

  • ロールアウト

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

ペルソナ

チェックリストはペルソナによってデザインされます。この役割は、プロジェクトのライフサイクルに重要な関わりを持っています。

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

プロジェクトスポンサー

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

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

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

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

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

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

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

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

アーキテクト

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

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

ビジネスアナリスト

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

  • 全体的な要件を収集して分析し、次のような仕様に転換する作業を主に担当します。

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

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

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

開発リーダー

開発リーダーの役割：

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

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

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

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

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

品質リーダー

品質リーダーの役割：

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

システムエンジニア

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

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

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

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

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

セキュリティリーダー

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

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

その他のペルソナ

  • 関係者

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

  • 法律担当者

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

  • トレーナー

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

  • テクニカルライター

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

  • システム管理者

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

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

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

必須ドキュメントと成果物

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

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

必須ドキュメント

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

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

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

成果物

マイルストーンごとに、適切なペルソナが特定のドキュメントを提供します。そのため、各自が特定のマイルストーンに対する自身の責任を認識しています。

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

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

成果物は、現在のマイルストーンまたはそれ以降のマイルストーンの​必須ドキュメント​として使用されます。

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

ドキュメントの重要個所

このページ