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

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

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

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

定義

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

主要な設計戦略

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

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

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

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

• 関係者と面接します。 関係者は、フローを識別するための貴重な情報を提供できる可能性があり、フローのマッピングと優先順位付けを支援してくれる可能性があります。 また、ユーザー、ビジネス アナリスト、技術チームと面接して、ワークロード内のユーザー操作と依存関係に関する分析情報を収集することもできます。

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

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

• 特定されたフローのリストを作成します。 面接、ドキュメント化、観察によって、ワークロード内のすべてのフローを特定できる必要があります。 特定したすべてのフローのリストをまとめ、それらをユーザー フロー (ユーザー操作に重点を置く) とシステム フロー (バックエンド プロセスとデータ移動に重点を置く) に分類します。

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

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

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

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

• フローのマッピングは繰り返し更新します。 フローのマッピングは、反復的なプロセスです。 フローは、特に設計フェーズでは変更、分割、結合される可能性があります。 ワークロード フローがより明確に定義されるようになったら、フローのカタログをこれと整合するように更新する必要があります。 関係者からのフィードバックを使用してフロー ダイアグラムを検証および調整し、精度と完成度を高めます。

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

ビジネス プロセスとは、注文処理、顧客サービス管理、在庫管理などの成果を達成するための一連のタスクです。 各フローのビジネス プロセスを特定するには、フローを 1 つ以上のビジネス プロセスにマップする必要があります。 このマッピングは、ビジネスにとっての各フローの重要性を理解するのに役立ちます。

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

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

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

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

• 出力をビジネス プロセスと関連付けます。 フロー出力のドットを、サポートする全体的なビジネス プロセスに関連付けます。 たとえば、フローの特定のステップに顧客注文の処理が含まれる場合、そのステップは、注文調達の業務プロセスを直接サポートします。 注文調達は、顧客満足度を維持し、収益を生み出すビジネス目標に貢献します。 最後に、フローの内訳を使用して、営業レポートを作成したフローを特定します。

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

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

プロセス所有者と関係者が既に特定された責任割り当てマトリックス (RAM) または RACI マトリックスが作成されている場合があります。 通常、プロセス所有者はプロセスに対して責任または説明責任を負い、あなたは利害関係者に相談や報告を行います。

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

エスカレーション パスの特定とは、フローに関連する問題をエスカレーションするためのチャネルを決定することです。 エスカレーションが必要な問題として、緊急の更新、セキュリティ上の懸念、機能低下、技術的なインシデントなどがあります。 エスカレーション パスを特定する目的は、問題がタイムリーかつ効果的に解決されるようにすることです。

立案するエスカレーション パスは、特定の問題を解決する可能性が最も高い人物またはグループから始める必要があります。 この人物またはグループが問題を解決できない場合は、エスカレーション パスの次の連絡先を特定する必要があります。 次の連絡先は、より広範な責任を持ち、組織のより多くの部門と調整して軽減戦略が図れる人物です。 エスカレーション パスに設ける連絡先の数は、フローと組織によって異なります。 エスカレーション パスに多くの人物が関与しすぎると、解決処理が遅くなる可能性があります。

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

各フローが主要なビジネス目標にどのように貢献しているかを理解するには、各フローのビジネスへの影響を特定することが不可欠です。 ビジネスへの影響には、収益創出、顧客満足度、業務効率などが含まれます。 各フローのプラスとマイナスの両方の影響を把握することで、ビジネスにとって最も重要なフローの信頼性を確保するための取り組みに優先順位を付けることができます。 フローの障害の直接的な影響と、他の相互に関連付けられたプロセスへの間接的な影響を考慮することが重要です。 各フローのビジネスへの影響を特定する手順を次に示します。

• プラスの影響を特定します。 フローが意図したとおりに実行された場合に予想される利点を判断します。 予想される利点には、効率性の向上、収益の増加、顧客満足度の向上、またはその他のビジネスへのプラスの効果が含まれると考えられます。

• マイナスの影響を特定します。 あるプロセスが失敗した場合、または予想どおりに進行しない場合に発生する潜在的なマイナスの影響を評価します。 収益の低下など、特定の損失を定量化することを検討してください。 評判の低下、顧客からの信頼の損失、他の関連するビジネス プロセスへの悪影響などの主観的な影響を含めます。

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

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

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

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

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

• 中重要度: 中程度の重要度のフローは、システムが完全に機能するうえで重要ですが、顧客や重要なビジネス運営に直接影響することはありません。 たとえば、問題が発生したために内部データ処理フローが中断された場合は、外部からの直接の影響を受けずに、データ処理を再試行できます。 これらのフローは円滑な運営に不可欠ですが、顧客や財務上の即時効果の観点からは緩衝域となり、問題に対する管理された対応を可能にします。

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

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

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

組織の配置

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

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