フローの識別と評価に関する推奨事項

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

RE:02	ユーザー フローとシステム フローを特定して評価します。 ビジネス要件に基づいて重要度スケールを使用して、フローに優先順位を付けます。

このガイドでは、ワークロード フローを特定して優先順位を付けるための推奨事項について説明します。 ワークロード フローの識別と優先順位付けには、ユーザー フローとシステム フローをマッピングして、その重要度をorganizationに判断する必要があります。 この方法により、障害が発生するリスクを軽減するために、最も重要なワークロード機能を特定して優先順位を付けられます。 ワークロード フローを特定して優先順位を付けできないと、システムの内訳やワークロードの信頼性が損なわれる可能性があります。

定義

期間	定義
ユーザー フロー	ユーザーがアプリケーションまたはシステム内で実行するアクションのパスまたはシーケンス。
システム フロー	システム内の情報とプロセスのフロー。 システムはこのフローに自動的に従って、ユーザー フローまたはワークロード機能を有効にします。

主要な設計戦略

ワークロードを設計するときは、ユーザー フローとシステム フローを定義することが不可欠です。 ユーザー フローは、アプリケーションを介したユーザーの動きをグラフ化します。 ユーザー インターフェイス、対話、決定、およびタスクを完了するために必要な手順に焦点を当てます。 ユーザー フローは、ユーザー エクスペリエンスとインターフェイス設計に関するユーザー中心の視点を提供します。 システム フローは、ワークロードの内部作業をグラフ化します。 ワークロード コンポーネント、バックエンド サービス、外部 API 間のデータ移動、入力処理、出力処理、相互作用に重点を置いています。 システム フローは、ワークロードがどのように内部的に動作するかの複雑な詳細を示します。

ワークロードの設計フェーズの早い段階でフローを特定して定義する必要があります。 ワークロードの信頼性に影響する内容をより明確に理解できます。 アーキテクチャ上の決定は、ワークロードの信頼性の目標と密接に一致します。

すべてのユーザー フローとシステム フローを特定する

すべてのユーザー フローとシステム フローを識別する出力は、ワークロード内のすべてのフローのカタログです。 この識別プロセスでは、システム内のすべてのユーザー操作とプロセスを最初から最後までマップする必要があります。 このマッピングは、重要なフローを識別するための前提条件です。 ワークロード内のすべてのユーザー フローとシステム フローを識別するための推奨事項を次に示します。

• 利害関係者にインタビューします。 利害関係者は、フローを識別するための貴重な情報を提供でき、フローのマップと優先順位付けにも役立ちます。 また、ユーザー、ビジネス アナリスト、技術チームにインタビューして、ワークロード内のユーザー操作と依存関係に関する分析情報を収集することもできます。

• ドキュメントを確認します。 設計フェーズでは、確認するドキュメントがない可能性があります。 ただし、ドキュメントが存在する場合は、それを使用する必要があります。 システム アーキテクチャの図、ユーザー マニュアル、およびプロセスの説明を求めます。 これらのドキュメントは、ワークロードとその個々のフローの意図された機能を理解するのに役立ちます。

• ワークロードを観察します。 操作中のワークロードを監視し、ユーザーが操作する方法と、さまざまなコンポーネントが互いに対話する方法に関する説明を示します。 システム ログ、パフォーマンス メトリック、およびユーザー アクティビティ ログを分析して、パターン、頻繁なタスク、システム応答を特定する必要があります。

• 特定されたフローを一覧表示します。 インタビュー、ドキュメント、観察を使用すると、ワークロード内のすべてのフローを特定できます。 特定するすべてのフローの一覧をコンパイルし、それらをユーザー フロー (ユーザー操作に重点を置く) とシステム フロー (バックエンド プロセスとデータ移動に重点を置く) に分類します。

• フローの始点と終点を定義します。 特定された各フローについて、フローの開始場所と終了場所を明確に定義します。 ユーザー フローの場合は、各ユーザー操作とその期待される結果を文書化します。 ユーザー エクスペリエンスとインターフェイスの設計に重点を置きます。 システム フローの場合は、その基になるトリガーと予想される結果を特定する必要があります。

• 各フローを分割します。 各フローを個々のステップに分割し、各時点で発生するアクション、決定、またはプロセスを記述します。 他のフローや外部システムへの依存関係など、各ステップがシステムの他の部分とどのように対話するかに注意してください。 フローと統合し、ワークロードとユーザー エクスペリエンスに与える影響を特定できる必要があります。 このデュアル アプローチでは、ワークロード全体を包括的に把握できます。

• 一意の出力を文書化します。 エラー処理や条件付き分岐など、各フロー内の代替パスまたは例外を特定します。 フローに複数の可能な結果がある場合は、個別のエントリとしてカタログに追加する必要があります。 ユーザー フローの場合は、対話の意図した動作を特定する必要があります。 システム フローの場合は、プロセスの意図した動作を特定する必要があります。

• 図を使用して視覚化する。 フローとその手順を視覚的に表すフローチャートまたは図を作成します。 Microsoft Visio、UML シーケンス図、ユース ケース図、単純な描画ツール、テキスト形式の説明リストなどのツールを使用できます (フロー カタログの例を参照)。

• フロー マッピングを反復的に更新します。 フロー マッピングは反復的なプロセスです。 フローは、特に設計フェーズで変更、分割、または結合できます。 ワークロード フローがより明確に定義されるにつれて、フローのカタログを一致するように更新する必要があります。 正確さと完全性を確保するために、利害関係者からのフィードバックを使用してフロー図を検証して調整します。

各フローのビジネス プロセスを特定する

ビジネス プロセスは、注文フルフィルメント、顧客サービス管理、在庫管理など、出力を達成するための一連のタスクです。 各フローのビジネス プロセスの識別には、フローを 1 つ以上のビジネス プロセスにマッピングすることが含まれます。 このマッピングは、ビジネスへの各フローの重要性を理解するのに役立ちます。

ビジネス プロセスへのフローのマッピングを提供する既存のドキュメントまたはビジネス プランがある場合があります。 場合によっては、ユーザー マニュアル、トレーニング資料、またはシステム仕様によって、ワークロードとそのフローの意図された用途と目的に関する分析情報が得られる場合があります。 そうでない場合は、フローをサポートするビジネス プロセスにマップする必要があります。 各フローのビジネス プロセスを特定するための推奨事項を次に示します。

• ワークロード出力を使用します。 ワークロードの出力とフローの内訳を使用して、フローをサポートするビジネス プロセスと関連付けることができます。 まず、ワークロードによって生成される出力を確認します。 出力には、売上レポート、データ ファイル、または完了したタスクがあります。

• 面接を実施する。 ワークロードと対話するチーム メンバーや利害関係者と話す。 毎日のタスク、ワークロードの使用方法、およびワークロードで達成する目的について、具体的な質問をする必要があります。 多くの場合、技術チームはワークロード構造をより深く理解し、サポートするビジネス プロセスに関する分析情報を提供できます。

• ワークロードの使用状況を監視します。 既存のワークロードの場合は、ワークロードを監視し、データ入力、注文処理、顧客との対話など、基になるビジネス プロセスを示す使用状況のパターンを探します。

• 出力をビジネス プロセスに接続します。 フロー出力のドットを、サポートするビジネス プロセス全体に接続します。 たとえば、フロー ステップに顧客注文の処理が含まれる場合、注文フルフィルメントのビジネス プロセスが直接サポートされます。 注文フルフィルメントは、顧客満足度を維持し、収益を生み出すビジネス目標に貢献します。 最後に、フローの内訳を使用して、売上レポートを作成したフローを特定します。

各フローのプロセス所有者と利害関係者を特定する

フローのプロセス所有者は、特定のプロセスの正常な実行を担当する個人です。 そのプロセスと、それをサポートするフローに責任があります。 各ワークロード フローのプロセス所有者を特定する必要があります。 また、各フローの利害関係者を特定する必要もあります。 利害関係者は、ワークロードに関与したり、フローに依存関係を持ったり、フローが持つ依存関係を管理したりできます。

プロセスの所有者と利害関係者を既に識別する責任の割り当てマトリックス (RAM) または RACI マトリックスがある場合があります。 通常、プロセス所有者はプロセスに対する責任または責任を負い、利害関係者に相談または通知します。

各フローのエスカレーション パスを特定する

エスカレーション パスの識別は、フローに関連する問題をエスカレートするためのチャネルを決定することです。 エスカレーションが必要な問題は、緊急の更新、セキュリティ上の懸念事項、劣化、または技術的なインシデントである可能性があります。 エスカレーション パスを特定する目的は、問題をタイムリーかつ効果的に解決することです。

マップアウトするエスカレーション パスは、特定の問題を解決する可能性が最も高い人物またはグループから開始する必要があります。 このユーザーまたはグループが問題を解決できない場合は、エスカレーション パスで次の連絡先を特定する必要があります。 次の窓口は、より広範な責任を持ち、organizationのより多くの部分で軽減戦略を調整できます。 エスカレーション パス上のユーザー数は、フローとorganizationによって異なります。 エスカレーション パス上のユーザーが多すぎると、解決作業が遅くなる可能性があります。

各フローのビジネスへの影響を特定する

各フローが主要なビジネス目標にどのように寄与するかを理解するには、各フローのビジネスへの影響を特定することが不可欠です。 ビジネスへの影響には、収益の生成、顧客満足度、または運用効率が含まれます。 各フローの肯定的な影響と否定的な影響の両方を理解することで、ビジネスにとって最も重要なフローの信頼性を確保するための取り組みに優先順位を付けることができます。 フロー障害の直接的な影響と、他の相互接続されたプロセスに対する間接的な影響を考慮することが重要です。 各フローのビジネスへの影響を特定する手順を次に示します。

• 肯定的な影響を特定します。 フローが意図したとおりに実行されるときに予想される利点を決定します。 期待される利点には、効率の向上、収益の増加、顧客満足度の向上、またはその他のビジネスへのプラスの効果が含まれます。

• 負の影響を特定します。 プロセスが失敗した場合、または期待どおりに動作しない場合に、潜在的な悪影響を評価します。 収益の減少など、特定の損失を定量化することを検討してください。 評判の損壊、顧客信頼の損壊、その他の関連するビジネス プロセスへの悪影響などの主観的な影響を含めます。

• 容量と可用性の前提条件を定義します。 各プロセスの予想される容量と可用性に関する前提条件を確立します。 時間単位あたりのスループット、予想される営業時間、目標のアップタイム率などの要因を考慮してください。 目標復旧時間 (RTO) または目標復旧ポイント (RPO) に対する期待がある場合は、これらの期待値を含める必要があります。 これらの前提条件は、各フローの信頼性要件を理解するのに役立ちます。

これらの側面を体系的に評価することで、各フローがビジネスにどのように影響するかを包括的に把握し、信頼性の最適化に関する戦略的な決定を行うことができます。

各フローに重要度評価を割り当てる

全体的なビジネスへの影響に対するフローの重要度の詳細な評価を使用すると、各フローに重要度の評価を割り当てることができます。 定量的または定性的重要度評価を使用できます。 目的は、フローを優先順位で並べ替え、重要なフローを識別できるラベルを割り当てることです。 このプロセスは、ビジネス プロセスと影響を特定、マッピング、調整する論理的な継続です。 次の重要度の説明を使用して、重要な評価を割り当てます。

• 重要度が高い: 重要度の高いフローは、コア ビジネス機能に不可欠です。 カスタマー エクスペリエンス、金融取引、セキュリティ プロトコル、人間の健康、安全性など、ビジネスの重要な側面に直接影響します。 これらのフローの障害または中断により、即時または長期的な悪影響が生じる可能性があります。 負の影響の例としては、収益の損失、信頼の侵害、法的な問題などがあります。 これらのフローの優先順位を付けると、ワークロードの最も重要な側面が堅牢で回復性が確保されます。

• 中程度の重要度: 中程度の重要度フローは、システムの完全な機能にとって重要ですが、顧客や重要なビジネス操作と直接インターフェイスすることはありません。 たとえば、問題によって内部データ処理フローが中断された場合は、外部からの影響なしでデータ処理を再試行できます。 これらのフローは円滑な運用に不可欠ですが、顧客や財務上の即時効果の観点からバッファーを提供し、問題に対する管理された対応を可能にします。

• 重要度が低い: 重要度の低いフローは、コアビジネス機能やカスタマー エクスペリエンスに直接的または重大な影響を与えません。 たとえば、夜間のログ転送などの補助的なプロセスや、フィードバック調査などのオプションのユーザー機能が含まれます。 これらのフローはシステム全体に寄与しますが、中断によってビジネスや運用上の重大な問題が発生する可能性は低くなります。

重要度を割り当てるためにこの構造化されたアプローチに従うことで、リソースに効果的に優先順位を付け、最も重要なフローの信頼性と有効性の維持と向上に重点を置くことができます。

トレードオフ: 信頼性に対する高い期待が、セットアップ コスト、運用コスト、オペレーターの管理負担の増加と一致する場合があります。 重要なフローの信頼性を向上させる潜在的なコスト増加を利害関係者が理解していることを確認します。

組織の配置

クラウド導入フレームワークでは、ビジネス重要度の分類を必要とするワークロードに関するガイダンスが提供されます。

詳細については、「 クラウド管理におけるビジネスの重要度」を参照してください。