フローの特定と評価に関する推奨事項

この Power Platform Well-Architected Reliabilityチェックリストの推奨事項に適用されます:

このガイドでは、ワークロード フローを特定して優先順位を付けるための推奨事項について説明します。 ワークロード フローを識別して優先順位を付けるには、ユーザー フローとシステム フローをマッピングして、組織にとっての重要性を判断する必要があります。 この実践により、最も重要なワークロード機能を特定し、優先順位を付けることで、有害な不具合やエラーのリスクを低減することができます。 ワークロード フローを識別して優先順位を付けない場合、システムが停止し、ワークロードの信頼性が低下する可能性があります。

定義

主要な設計戦略

ワークロードを設計する際には、ユーザーフローとシステムフローを定義することが不可欠です。

• ユーザー フローは、アプリケーション内でのユーザーの動きを図表化します。 ユーザー インターフェイス、インタラクション、決定、タスクを完了するために必要な手順に重点を置いています。 ユーザー フローは、ユーザー エクスペリエンスとインターフェイスのデザインに関してユーザー中心の視点を提供します。

• システム フローは、ワークロードの内部動作を図表します。 データの移動、入力処理、出力処理、ワークロード コンポーネント、バックエンド サービス、外部 API 間の相互作用に焦点を当てています。 システム フローは、ワークロードが内部でどのように動作するかの複雑な詳細を示します。

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

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

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

• 主要な貢献者を特定します。 このプロセスに貢献するすべての人をよく考えてみましょう。 これには、この問題に取り組んでいる自分の部門やその他の部門の人々が含まれます。 解決しているビジネスの問題のコンテキストで、この人達が何をするのかを理解してください。

• 関係者にインタビューする。 関係者はフローを特定するための貴重な情報を提供し、フローのマッピングと優先順位付けをサポートすることもできます。 また、ユーザー、ビジネス アナリスト、技術チームにインタビューして、ワークロード内のユーザー インタラクションや依存関係についての分析情報を収集することもできます。

• プロセス マイニング を使用して改善するプロセスを見つけます。 タスクが完全にデスクトップで実行される場合、プロセス マイニングを使用して、組織内の人々がタスクを完了するために取るすべてのステップを発見することができます。 Process Mining は、プロセス マップ でプロセスを視覚化し、分析レポートでプロセスのボトルネックと指標を明らかにします。

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

• どのような活動が実行されているかを観察します。 タスクが別の方法で実行される場合は、実行中のタスクを監視します。 ビジネス プロセスのこのステップでタスクを完了するためにユーザーが行うアクティビティを書き留めます。 そのアクティビティの詳細に入ります。 アクティビティを決定するときは、各アクティビティの原因と結果、それらが相互にどのように関係しているか、およびそれらがどのようにして目的に近づくかを検討する必要があります。 プロセスの開始点を特定し、目的につながるアクティビティを記入します。 アクティビティには、1 つ前のアクティビティが完了するまで発生しない「シーケンシャル」と、2 つ以上のアクティビティが同時に発生する「パラレル」があります。

• 必要なデータとそのデータの取得元を特定します。 すべてのデータ ソースのリストを作成し、データがどこから来たのかを観察します。 それは内部システムからですか、それとも外部データソースからですか？ ユーザーがデータを取得するための認証方法は何でしょうか？ さまざまなアクセス許可レベルがありますか？ 誰がシステムを使うかによってデータは変わるのですか？

• 作成または編集されたデータを特定します。 現在データの取得に使用しているのは、紙のフォームですか、それとも電子フォームですか？ こうしたフォームは、画面のレイアウトやデータがどのように取り込まれているかを考える上で、有用な出発点として役立ちます。 取り込まれているデータは何ですか？ それは何と呼ばれていますか？ これはデータ ソースに由来する本名ですか？または業務のみで使われている通称ですか？ データ ソースの名称を、ユーザーが知っている「わかりやすい」名前にマッピングした方がよい場合もあります。

• ユーザーまたはシステムフローの一部として行われた決定を決定します。 このプロセスにおける活動の最後に、何らかの決定がなされていますか？ データに基づいてソリューションが自動的に決定する方法はありますか？ データに階層がありますか？ たとえば、各経費レポートには複数の経費が含まれる場合があり、経費の種類によっては追加情報を必要とするものもあります。 この決定は誰かに伝えられますか？ それはどのように伝えられますか？ プロセスの次のステップが始まる前に承認は必要ですか？ これらの承認はどのように得られますか？ プロセスの次のステップを承認できる特定のユーザー、またはロールはありますか？

• 識別されたフローを一覧表示します。 インタビュー、文書化、観察により、ワークロード内のすべてのフローを特定できるようになります。 特定したすべてのフローのリストを作成し、それらをユーザー フロー (ユーザー インタラクションに重点を置く) とシステム フロー (バックエンド プロセスとデータ移動に重点を置く) に分類します。

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

• 各フローを分解します。 各フローを個別のステップに分解し、各ポイントで発生するアクション、決定、またはプロセスを説明します。 各ステップが、他のフローや外部システムへの依存関係など、システムの他の部分とどのようにやり取りするかに注目してください。 フローがどのようにワークロードとユーザー エクスペリエンスに統合され、それらに影響を与えるかを正確に特定できる必要があります。 この 2 つのアプローチにより、ワークロード全体の総合的なビューが提供されます。

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

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

• フロー マッピング を反復的に更新します。 フローマッピングは反復プロセスです。 特に設計段階では、フローが変更、分割、または結合されることがあります。 ワークロード フローがより明確に定義されると、それに合わせてフローのカタログを更新する必要があります。 関係者からのフィードバックに基づいてフロー図を検証、改良し、正確性と完全性を確保します。

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

ビジネス プロセスとは、経費報告、年次休暇管理、注文処理、在庫管理などの出力を達成するための一連のタスクです。 各フローのビジネス プロセスを識別するには、フローをひとつ以上のビジネス プロセスにマッピングする必要があります。 このマッピングは、ビジネスに対する各フローの重要性を理解する際に役立ちます。

ビジネス プロセスへのフローのマッピングを提供する既存の文書、またはビジネス プランがある場合があります。 ユーザー マニュアル、トレーニング資料、またはシステム仕様から、ワークロードとそのフローの使用目的と目的についての分析情報が得られる場合があります。 そうでない場合は、フローをサポートするビジネス プロセスにマッピングする必要があります。 各フローのビジネス プロセスを識別するための推奨事項は次のとおりです:

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

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

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

• 接続 出力をビジネス プロセスに渡します。 フロー出力の点と、それがサポートするビジネス プロセス全体を結び付けます。 たとえば、フロー ステップに顧客の注文の処理が含まれる場合、注文処理のビジネス プロセスが直接サポートされます。 注文処理は、顧客満足の維持と収益の創出というビジネス目標に貢献します。 最後に、フローの内訳を使用して、どのフローが営業レポートを作成したかを判断します。

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

フローのプロセス所有者は、特定のプロセスの正常な実行に責任を負う個人となります。 彼らはそのプロセスとそれをサポートするフローに責任を負います。 各ワークロード フローのプロセス所有者を特定する必要があります。 また、各フローのステークホルダーを特定する必要があります。 関係者は、ワークロードに関与したり、フローに依存関係を持ったり、フローの依存関係を管理したりできます。

すでにプロセスオーナーと利害関係者を特定した Responsibility Assignment Matrix (RAM) または Responsible, Accountable, Consulted, Informed (RACI) マトリックスがあるかもしれません。 通常、プロセス所有者はプロセスに対して責任または説明責任を負い、関係者に相談したり通知したりします。

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

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

計画するエスカレーション パスは、特定の問題を解決する可能性が最も高い個人またはグループから始める必要があります。 この個人またはグループが問題を解決できない場合は、エスカレーション パスで次の連絡先を特定する必要があります。 次の連絡先はより広範な責任を負い、組織のより多くの部門と緩和する戦略を調整できます。 エスカレーション パスに参加する人の数は、フローや組織によって異なります。 エスカレーション パス上の人数が多すぎると、解決の取り組みが遅くなる可能性があります。

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

各フローが主要なビジネス目標にどのように貢献しているかを理解するには、各フローのビジネスへの影響を特定することが不可欠です。 ビジネス インパクトには、パフォーマンスの向上、直接的または間接的なコスト削減、リスクの軽減、ビジネスの変革などが含まれます。 各フローのポジティブな影響とネガティブな影響の両方を理解することで、ビジネスにとって最も重要なフローの信頼性を確保するための努力に優先順位をつけることができます。 フローの失敗およぼす直接的な影響と、相互に関連する他のプロセスへの間接的な影響を考慮することが重要です。 ここでは、各フローのビジネスインパクトを特定するための手順を説明します:

• プラスの影響を特定する。 フローが意図したとおりに実行された場合に期待されるメリットを判断します。 期待されるメリットには、業務の効率性と有効性の向上、顧客や従業員の満足度の向上、データ セキュリティの向上、規制要件への準拠の確保、その他ビジネスへのプラスの影響などが挙げられます。

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

• 容量と可用性の仮定を定義します。 各プロセスの予想されるキャパシティと可用性についての仮定を設定します。 予想される営業時間や目標稼働率などの要素を考慮してください。 復旧時間目標 (RTO) または復旧ポイント目標 (RPO) に対する期待がある場合は、これらの期待も含める必要があります。 これらの仮定は、各フローの信頼性要件を理解するのに役立ちます。

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

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

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

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

• 重要 (重要度中): 重要なフローはビジネス機能の一部を果たしますが、重要なビジネス オペレーションに直接インターフェイスしたり、影響を与えたりすることはありません。 たとえば、問題により内部データ処理フローが中断された場合、直ちに外部に影響を与えることなくデータ処理を再試行できます。 これらのフローは円滑な運用に不可欠ですが、即時の顧客または財務への影響という点でのバッファーを提供し、問題に対する管理された対応を可能にします。

• 生産性 (重要度が低い): 生産性フローは、コアビジネス機能や顧客エクスペリエンスに直接的または重大な影響を与えません。 この例には、ストレージをバックアップするためのファイルの定期的な転送やフィードバック調査の処理など、補助的なプロセスや小規模チームのユースケースが含まれます。 これらのフローはシステム全体に貢献しますが、その中断によって直ちに重大なビジネス上または運用上の問題が発生する可能性は低く、多くの場合、手動による回避策が存在します。

この構造化されたアプローチに従って重要度を割り当てることで、リソースに効果的に優先順位を付け、最も重要なフローの信頼性と有効性を維持および強化することに集中できます。

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

フローカタログの例

次の例は完全なシナリオを示し、フローを識別、マッピング、優先順位付けするのに役立つ重要なポイントを示しています。 たとえば、経費報告用の業務アプリで、従業員は経費申請フォームに記入し、管理者は経費の確認と承認を行い、監査人は週次報告書を確認します。

ユーザー フロー 1: 経費フォームに入力します

フローの説明: 従業員はアプリケーションを使用して経費フォームに記入します。

• ビジネス プロセス: このフローは 経費フォームへの入力と送信をサポートしていますが、非同期であるため、それほど重要ではありません。

• プロセス所有者: ビジネス管理者

• 利害関係者: 従業員、ラインマネージャー、ビジネス管理者

• エスカレーションパス: アプリケーションチーム、プラットフォームチーム

• ビジネスへの影響: このフローは従業員が経費を請求するために重要ですが、ビジネスの主な収益源に直接影響を与えたり、顧客に直接影響を与えたりすることはありません。 このフローが利用できないために従業員が経費請求を作成できなくても、会社の収益や評判に悪影響を及ぼすことはありません。 従業員は後で経費を提出できます。 ダウンタイムが長引くと、費用の支払いが滞った場合にクレジットカードの追加料金が発生する可能性があります。 ただし、このプロセスでは高可用性は必須ではありません。 ビジネス管理者は、このプロセスに対して 90％ の可用性を要求しており、メンテナンスのために営業時間外にダウンタイムが発生することに同意しています。

• 重要度評価: 生産性 (低)

ユーザー フロー 2: 経費の確認と承認

フローの説明: 従業員のラインマネージャーが経費請求を確認し、承認します。

• ビジネス プロセス: このフローは 経費請求の確認と承認をサポートしますが、これは非同期プロセスです。

• プロセス所有者: ビジネス管理者

• 利害関係者: 従業員、ラインマネージャー、ビジネス管理者

• エスカレーションパス: アプリケーションチーム、プラットフォームチーム

• ビジネスへの影響: このフローにより、ライン マネージャーは経費請求を確認して承認し、詳細を要求できます。 ラインマネージャーは経費請求を承認するまでに 7 日間の猶予があるため、このフローの可用性が高いことは重要ではありません。 このフローが利用できないために従業員が経費請求を作成できなくても、会社の収益や評判に悪影響を及ぼすことはありません。 従業員は後で経費を提出できます。 ダウンタイムが長引くと、費用の支払いが滞った場合にクレジットカードの追加料金が発生する可能性があります。 ただし、このプロセスでは高可用性は必須ではありません。 ビジネス管理者は、このプロセスに対して 90％ の可用性を要求しており、メンテナンスのために営業時間外にダウンタイムが発生することに同意しています。

• 重要度評価: 生産性 (低)

ユーザー フロー3: トランザクションの入力と送信

フローの説明: ビジネス管理者は経費を確認し、クレジット カード が支払われるようにトランザクションを投稿する必要があります。

• ビジネス プロセス: このフローは、クレジット カード 料金の支払いをサポートします。

• プロセス所有者: ビジネス管理者

• 利害関係者: ビジネス管理者、プラットフォーム チーム、データ チーム

• エスカレーション パス: プラットフォーム チーム、データ チーム、プラットフォーム チームのオンコール エンジニア

• ビジネスへの影響: このフローは経費の支払いに不可欠であり、支払いが遅れるとクレジット カード 料金が発生する可能性があります。 ただし、通常、経費の申告から支払い期日までには十分な時間があります。 ビジネス管理者は、このプロセスに対して 90％ の可用性を要求しており、メンテナンスのために営業時間外にダウンタイムが発生することに同意しています。

• 重要度評価: 中

システム フロー 4: 週次経費報告書を作成する

フローの説明: CFOが確認できるように、経費の週次レポートが作成されます。 レポートが生成されて Power BI に公開され、通知が CFO に送信されます。

• ビジネス プロセス: このフローは経費のレビューをサポートします。

• プロセスオーナー: CFO

• 利害関係者: ビジネス管理者、すべての技術チーム

• エスカレーション パス: アプリケーション チームのオンコール エンジニア、プラットフォーム チームのオンコール エンジニア、データ チームのオンコール エンジニア

• ビジネスへの影響: このフローが利用できなくなっても、会社の収益や評判には影響しません。 ビジネス管理者は、このプロセスに対して 90％ の可用性を要求しており、メンテナンスのために営業時間外にダウンタイムが発生することに同意しています。

• 重要度評価: 中

ユーザーフロー5: 監査費用

フローの説明: 外部監査人は、経費のジャストインタイム監査を実行し、レポートがコンプライアンス要件を満たしているかどうかを確認します。

• ビジネス プロセス: このフローは、 コンプライアンスおよび監査プロセスを直接サポートします。 この機能がなければ、会社は外部監査人から罰金を科される可能性があります。

• プロセスオーナー: プラットフォームチーム

• 利害関係者: プラットフォーム チーム、運用チーム、ビジネス管理者

• エスカレーションパス: プラットフォームチームのオンコールエンジニア

• ビジネスへの影響: 外部監査人が警告や通知なしに経費報告を要求する可能性があるため、このフローでは高可用性が必要です。 このフローが利用できない場合、罰金が科せられる可能性があります。 営業時間の延長を含め、99.9% のアップタイムを期待される重要なプロセスです。

• 重要度評価: 高

Power Platform の促進

Power Automate のプロセス マイニングとタスク マイニングは、ビジネス プロセスを可視化し分析する強力なツールであるプロセス マップを含めた使用を検討してください。

Power Apps プロジェクトを計画 することによって、あなたのアイデアを完全に機能的なソリューションに変換する方法を解説します。

信頼性チェックリスト

完全なレコメンデーションのセットを参照してください。