要件をマッピングする
要件収集の作業では、要件と Dynamics 365 アプリの機能とのマッピングが重要な手順となります。 このタスクは、カスタム ソフトウェアまたは Microsoft Power Platform のみのプロジェクトで行う場合とは異なります。これらには、あらかじめ組み込まれたビジネス プロセス ロジックが存在しませんが、Dynamics 365 アプリには存在するためです。 たとえば、Microsoft Dynamics 365 Sales では営業案件の追跡が既に実装されているので、このロジックを作成する必要はありません。 マッピング作業は、各要件を確認し、その実装方法を検討するために行います。 一般的に、マッピングによって次のカテゴリのいずれかが要件に適用されます。
標準 - Dynamics 365 アプリにはこの要件が組み込まれており、有効化または最小限の構成が必要です。 このカテゴリの例としては、営業案件の追跡があります。
構成 - Dynamics 365 アプリでは、既定では構成がサポートされていませんが、テーブルにいくつかの列を追加するか、いくつかのカスタム テーブルや、場合によっては自動化を追加することで、この要件を実装できます。 たとえば、各営業案件のコミッション金額を追跡することが要件となる場合があります。 この要件は、ローコード/コード不要の構成と、場合によっては計算を自動化するための自動化を使用して実装できます。
カスタム - Dynamics 365 アプリではカスタマイズがサポートされていませんが、カスタム コンポーネントまたはロジックを構築するためのコード開発者のリソースを含めることで、カスタマイズを実現できます。 たとえば、チームのコード開発者は Microsoft Power Apps Component Framework コントロールを作成して、営業案件フォームにカスタム製品コンフィギュレーターを実装できます。
パートナー ソリューション - 多くのパートナー ソリューションは Dynamics 365 アプリと連携します。 たとえば、製品コンフィギュレーターは、カスタム構築ではなくパートナー ソリューションから提供される場合があります。
これらの例は、使用できるカテゴリですが、チームはこれらのカテゴリに限定されません。
これらのカテゴリを負荷レベルや優先順位と組み合わせて使用すると、フィット ギャップ分析を完了できます。 フィット ギャップ分析は、解決しようとする問題に対して、ソリューションがどれだけ適合するかを評価するプロセスです。 前のカテゴリでは、標準の機能は「適合」と見なされます。Dynamics 365 のようなビジネス アプリケーションでは、アプリで行う内容に適合しているという意味であるため、この側面は重要です。 "適合" の割合が低ければ、そのアプリはソリューションの構築の出発点としては適切でないと考えられます。
通常、構成またはカスタムに分類される要件は、固有の要件に適合するように何らかの構成を行って、標準の機能に近づけるためのオプションが利用できるかどうかを判断する必要があります。 顧客は Dynamics 365 の標準のサポートが若干異なることに気づかず、旧システムと同じように行わなければならないと考えているため、最初に要件がカスタムにマッピングされることは珍しくありません。 顧客と連携して、このような要件を標準の機能に近づけていくこと有益な場合があります。
マッピングの演習を行うもう 1 つの利点は、要件の実現可能性を評価することにあります。 要件が実現不可能である一般的な理由を次に示します。
最小限の数のユーザーが機能を使用する。
機能が技術的に不可能である。
規制または法律によって機能またはプロセスが禁止されている。
要件がどのように実装されるかを検討すると、その実装方法を特定するために概念実証ソリューションが必要となりそうな場所を特定するという利点も得られます。 概念実証には、通常、問題の解決方法の例を構築または作成することが含まれます。 製品化できるほどの機能性はありませんが、概念が適切かどうかを評価するには十分なものです。 この概念は、パートナー ソリューションを評価して、それによって問題を解決できるかどうかを判断する場合にも適用できます。 Microsoft AppSource は、これらのパートナー ソリューションを探すのに便利です。
マッピングを非公式に行うか、またはプロジェクト手法の一環として公式に行うかに関係なく、要件を絞り込み、それらの実装に必要な負荷レベルについて理解を深めることは、貴重な演習になります。