• 20 分

次のセクションでは、ソリューション パフォーマンス ワークショップの実施方法、および詳細な情報を提供するフォローアップ セッションの実施方法について説明します。

ソリューション パフォーマンス ワークショップの参加者

ソリューション パフォーマンス ワークショップでは、プロジェクト チームのさまざまな役割、ソリューションのユーザー、またはソリューションをサポートする人員に関連する領域について検討します。 また、このソリューションに依存する他のシステムを管理するためのリソースも必要です。 一般的に、参加者は次のカテゴリに分類されます。

• 対象分野の専門家は、主要なビジネス プロセスや、システムの応答性やパフォーマンスに関する基準を明確にすることができます。
• 非機能要件を明確化できるビジネスや技術チームの担当者。
• 構成、カスタマイズ、統合、およびソリューション パフォーマンス レビューでフォーカスするソリューションの他の側面で使用される、設計および実装の方法に関する知識を持つ実装チーム メンバー (顧客および実装パートナー)。
• パフォーマンス テストを実施するテスト チーム。
• 環境/テナント戦略に関する情報を提供し、パフォーマンス テストのための環境の設定を支援できる IT 管理者。

技術的な議論においても、ビジネスの代表者がパフォーマンスの要件に与える影響を認識できるようにすることには意味があります。 業務範囲を変更しない限り、非機能要件を満たすことが困難なシナリオが存在する場合があります。 これらのシナリオでは、要件の必要性と優先順位を分析しより良い意思決定を行うために、ビジネスの代表者が技術的な側面を理解することが重要です。

ソリューション パフォーマンス ワークショップの実施

ソリューション パフォーマンス ワークショップはソリューション アーキテクトによって進められますが、実装チームがソリューション パフォーマンスに関する情報のプレゼンテーションをすることが求められます。 議題の各セクションには、実装チーム内の所有者を割り当てる必要があります。 各セッションの開始時に、その所有者が、ソリューションのその側面に適用される設計を含め、スコープおよび計画の概要や要約を示す必要があります。 チームは、割り当てられた時間の 25 ～ 50% の範囲内で、概要のプレゼンテーションを行うことを計画します。 残りの時間は、ソリューション アーキテクトとの質疑応答に割り当てます。

実装チームのリーダーは、ワークショップの前にソリューション アーキテクトと打ち合わせて、各セッションの議題とタイミングを決定する必要があります。 ソリューションの状態と複雑さによっては、各セクションの時間を長くまたは短くする必要があります。 基本的にワークショップを実施する予定時間は 2 ～ 4 時間ですが、この時間は実装に合わせてある程度変えることができます。

ソリューション パフォーマンス ワークショップの時間管理は重要です。 このワークショップで最も優先すべきは、すべての関連するコンテンツを理解することであり、1 つのセッションで必要以上に話し合うことではありません。 話し合いがあまりに細部に入り、議題全体をカバーする時間がなくなる場合は、ソリューション アーキテクトが話を切り上げて、詳細についてはその後のフォローアップのワークショップで話し合うようにすることが求められます。

各セッションでは、参加者はスコープやアプローチに関する議論を行います。 その期待の一部として、ソリューション アーキテクトが会議内で直接ガイダンスを提供する場合があります。 ただし、これらのセッションは、設計セッションではなく、レビュー セッションとなるよう意図されています。 提供されたフィードバックによって現在の計画や設計が変更される場合がありますが、それらの領域の詳細な作業は、ワークショップの後で実装チームが実施します。

ソリューション パフォーマンス ワークショップのアウトプット

ソリューション パフォーマンス ワークショップのアウトプットは、調査結果ドキュメントになります。 この調査結果ドキュメントは、ワークショップの準備段階、またはワークショップの間に提供された情報に対する回答です。 これらの調査結果には、通常、次の 3 つのタイプがあります。

• アサーション – これらの調査結果は、ソリューション アーキテクチャが設計上重要な要素としてコール アウトした、ソリューションの特定の側面に関連するものです。 アサーションは特定のリスクや問題を表す要素ではありませんが、ソリューションの基礎となる可能性があります。変更された場合は大きな影響を及ぼすため、注意する必要があります。 これらのアサーションは、特定のスコープ項目、ソリューション アーキテクチャの設計側面、実装のアプローチや手法に関連する場合があります。
• リスク – これらの調査結果は、プロジェクトにおいて追跡すべきリスクを構成するソリューションや実装のアプローチの側面を表します。 これらのリスクは、マイナス結果の可能性が確認されている既存の計画、アプローチ、または設計に関連付けできます。 また、まだ十分に調査されていないソリューションの領域に関連し、予期しない問題が発生するリスクを示している場合もあります。 これらの調査結果には、リスクと見なされるものに関する記述と、推奨される軽減策の手順が伴います。
• 問題 – これらの調査結果は、ソリューションまたは実装アプローチの側面を表します。実装に悪影響を与える問題や、修正されない場合後でマイナスの影響を及ぼす問題の構成要素を示します。 これらの調査結果には、現在または今後の影響に関する記述と、推奨される解決策の手順が伴います。

調査結果ドキュメントは、顧客および取引先組織に配布され、調査結果を詳細にレビューするための会議が開催されます。 このドキュメントは、両方の組織における実装リーダーとエグゼクティブ スポンサーに送られます。 調査結果ドキュメントは長くなることがあります。その場合は、経営幹部にとってわかりやすいように重要な結果のみを抜粋した概要が提供されます。

すべてのリスクと問題に対処しても、ソリューションにパフォーマンス上の問題が生じないことを保証することはできません。 このワークショップは、レビューの時点で確認されたすべての要因のリスクを軽減し、問題に対処するために行います。 ただし、パフォーマンスは、プロジェクトにおける例外や新しい開発によって影響を受けることがあります。 そのため、新しいニーズに対処するために、新しい要素がソリューションに導入される時点で、ワークショップを反復的に実施する必要があります。

追加のソリューション パフォーマンス ワークショップ

ソリューション パフォーマンスは、実装チームがプロジェクトのライフ サイクル全体を通じて認識すべき側面です。 チームは、プロジェクトの開始時や、開発とテストの段階で、ソリューション パフォーマンスを計画する必要があります。 このため、次のような理由から、追加のレビューが必要になる場合があります。

• 初期のソリューション パフォーマンス ワークショップでの課題 - プロジェクト チームは、初期のワークショップのリスクと問題を適切に評価するために必要なすべての関連情報を持っていない場合があります。 したがって、過去のワークショップで議論した領域を追加のワークショップで議論する場合があります。
• スコープの大幅な変更 – いくつかのケースでは、さまざまな状況によって、スコープやアプローチが大幅に変更され、実装が影響を受ける場合があります。 これらの要素には、外部要因による変更も含まれますが、詳細な要件分析に基づく大幅な変更に関連することもあります。 そのため、ソリューション パフォーマンス ワークショップでそれらを再度レビューする必要があります。
• チームからのフィードバック - ソリューションが開発されテストされるにつれて、最初のワークショップで特定されなかったソリューションの問題領域を、特定できるようになる場合があります。 統合テストでのユーザー受入テストまたは管理者からのフィードバックによって、実際のエンド ユーザー エクスペリエンスに関する詳細が提供されることがあります。これによって、追加のワークショップが必要になることがあります。

ソリューション パフォーマンス ワークショップのフォローアップ

ソリューション パフォーマンス ワークショップが実施され、調査結果のレビューが行われた後、リスクおよび問題として特定された項目、およびそれらに関連付けられている軽減策と解決策の実施項目は、全体的なエンゲージメントの一部として完了するまで管理されます。

特定された問題は、多くの場合、本番運用の成功に影響を与えます。 このような問題は、Go-live 準備評価や運用環境の展開前に解決する必要があります。

リスクおよびそれらに関連する推奨される軽減策は、プロジェクトの全体的な戦略に沿って管理できますが、プロジェクト全体を通して監視されます。 軽減されていないリスクが、本番運用に影響を与える可能性もある問題として、後で認識される場合があります。

フォローアップと詳細なフォローアップは、レコメンデーションに従ってプロジェクト チームがサポートする必要があります。 この要素は、ソリューション パフォーマンス ワークショップで特定されたリスクと問題の領域に影響を与える可能性がありますが、複雑さのため、さらなる詳細レベルが必要な関連領域に影響を与えることもあります。