Success by Design の実装
このユニットでは、テンプレートの使用から、調査結果やレコメンデーションの提示に至るまで、Success by Design プロセスの実装方法について説明します。 Success by Design は柔軟性を持たせるように設計されており、デリバリー スタイルに応じて調整できます。 ただし、デリバリーの構造は、誰もが従うことができるように明確にする必要があります。
期待の調整
Success By Design は、プロジェクト チームとのやり取りにおける積極的な関与、顧客の目標の検出、アーキテクチャの観点での設計内容の理解、プロジェクト チームがプロジェクト中に問題に直面する可能性が高い領域の回避をソリューション アーキテクトが達成することを目的としています。
ソリューション アーキテクトは信頼できるアドバイザーと見なされる立場に立つべきであり、他のプロジェクトの作業を通じて得た知識や経験を活かし、問題を回避するための経験やベスト プラクティスを共有する必要があります。 したがって、ソリューション アーキテクトは、顧客が自信を持って正常に Go-Llive を実現できるように支援できます。
エンゲージメントでは、ソリューション アーキテクトは、ワークショップの成果の目標およびそれが重要である理由を関係者が理解できるようにする必要があります。
ソリューション ブループリント ワークショップでは、プロジェクト (計画、マイルストーン、目標、スコープなど) で使用されるインサイトを得ることを期待できます。 このワークショップは、構築する内容 (統合、インターフェイス、ソリューションなど) に関する計画を策定し、プロジェクトを提供するステージを決定して、これらのプロジェクト計画がすべての関係者およびプロジェクト スコープに適していることを確認できるため、実装時のプロジェクト チームにとって有益です。
実装ワークショップの目標は、最も一般的な問題がプロジェクト計画やマイルストーンに影響を与える可能性のある領域を徹底的に調査することで、プロアクティブに対応し、リスクや機能のギャップを特定して、認識を高めることです。 これらのリスクやギャップを特定することにより、リスクを軽減するための計画を策定し、展開に関する一般的な問題を回避できます。
Go-live 準備ワークショップでは、顧客の Go-live 戦略を理解してその形成を支援し、この戦略をベスト プラクティスと比較することを目標としています。 このアプローチにより、プロジェクトの最も重要なフェーズである Go-live 中に、予期しない問題を回避することができます。
ワークショップの成果
各ワークショップの後、ソリューション アーキテクトは、ワークショップ中に学習した内容に基づいて、調査結果とレコメンデーションの一覧を準備します。 必要に応じてフォローアップ ミーティングをスケジュールして、レコメンデーションについての話し合いの場を設けるようにします。
このワークショップでは、ソリューション アーキテクトは念入りな作業を行っていきますが、プロジェクトに関して考えられるあらゆる懸念が提起され、プロジェクトの問題がすべて回避されることは期待できません。 ソリューション アーキテクトは、顧客およびパートナー チームが共有する情報を確認するだけで、共有されていない情報 (または十分な詳細レベルで共有されていない情報) がある場合、その情報はレビューに含まれません。
レビューは、他のやり取りから得たベスト プラクティスや経験と、現在手がけているプロジェクトおよびビジネス プロセスを比較することによって実施されます。 プロジェクトの期間中に問題が発生しないことを出席者に保証することはできませんが、レビュー時に評価される情報と評価されない情報を理解することの重要性を強く訴えることはできます。
ワークショップの成果に関して注意が必要な点を次に示します。
開発者が記述したコードの品質は、Success by Design では検証されません。 コードをチェックする方法はありますが、コードのロジックは検証されません。
ソリューションのアーキテクチャは上位レベルで確認されますが、それがどのように構築されたかについての詳細は確認されません。 たとえば、特定の目的のために構築された Power Automate フローがある場合、そのフローの設計は確認されません。 フローで、わずか 2 つのステップで済むところを 10 のステップが使用されている場合、これはレビューのスコープ外になります。
アーキテクチャ、統合、インターフェイス、および設計は上位レベルのビューでチェックされ、使用可能なオプション、ベスト プラクティス、および Microsoft ロードマップにソリューションが適しているかどうかが判断されます。 このような状況の例として、顧客の Dynamics 365 環境と同じデータ センターの Microsoft Azure 内にある可能性があるという理由から、オンプレミスの仮想マシンを使用しないよう決定する場合が挙げられます。
準備
顧客およびパートナー チームがなぜワークショップが必要であるかを理解できたら、これらの顧客およびパートナー チームに短く簡単なワークショップ テンプレートを送信し、各スライドでの質問内容の目的について説明する注記を提供することができます。 短いテンプレートを使用することで、顧客およびパートナー チームが、要求される情報を提供することに抵抗感を抱く可能性を最小限に抑えることができます。
ソリューション アーキテクトは、ワークショップの予定日の少なくとも 1 週間前に顧客およびパートナー チームに PowerPoint テンプレートを送信して、顧客が余裕を持ってテンプレートを受け取り、要求された情報を追加できるようにする必要があります。 展開の複雑さに応じて、または最初に調査する新機能が追加されている場合は、このタイミングのレコメンデーションを調整します。
改訂された PowerPoint ファイルを顧客から受け取ったときは、ファイル内の情報を確認してから、ワークショップの実行準備を開始するための時間を予定に組み込んでください。
ワークショップの準備は、対象者について知ることから始まります。 ソリューション アーキテクトは、プロジェクト チームと協力して参加者を特定する必要があります。これは、ワークショップのトピックによって異なります。
対象者が多く、数多くの異なるロールや部署が関与する場合は、ワークショップを複数のセッションに分割することを検討してください。 対象者が多すぎるか、多様すぎる場合、オーバーランのリスクが高くなります。
ワークショップに先駆けて議題を準備し、出席者に送信してください。 議題には、セッション時間と名前を指定したリソースを含めます。 この準備により、参加者は、さらに時間が必要になると思われる場合にフィードバックを提供でき、ワークショップ中にトピックごとに合意された時間を遵守できるようになります。
納品
ワークショップでは、必要に応じて顧客やパートナーがコンテンツを提示する必要があります。 顧客やパートナーがコンテンツを提供している間は、メモを取る必要があります。 プレゼンテーションを中断せずに、各スライドの最後まで待ってから質問するか、発表者が間を入れるまで待つことをお勧めします。
ワークショップは、一方的な照会ではなく、会話のように流れる必要があります。 質問は、簡潔かつ関連性のあるものにします。 ワークショップは、必ず議題と要点を述べることから開始し、次のステップを示すことで終了する必要があります。 次に起こることについて全員に理解してもらう必要があります。
ワークショップの終了後は、記憶が冷めないうちにメモを見直して、内容を更新してください。 メモは調査結果とレコメンデーションの基になるため、メモがすべてを網羅していることを確認します。
ワークショップを成功させるための一般的なガイダンス
以下のガイドラインは、ワークショップで成功を収めるのに役立ちます。
各ミーティングには、前のセッションに参加しなかった人が参加している可能性があるため、ワークショップのセッションでは必ず最初に自己紹介を行い、経歴や Dynamics 365 または Microsoft Power Platform の作業経験を含めて準備する必要があります。
すべてのセッション中はメモを取るようにしてください。 常にメモを取ることはできないかもしれませんが (特に対面の会議中など)、必ず誰かが詳細なメモを取るようにして、セッションの後でそのメモの写しを取得してください。
自分の経験と知識について自信を持ってチームと共有してください。
対象者を読み上げて、これらの対象者の技術レベルを理解してもらうようにします。 ワークショップに関して同意を得ている技術レベルを維持するようにします。 たとえば、ソリューション ブループリント レビューは概要に留める必要があるため、話が細かくなりすぎた場合には中断する必要があります。 現在のセッションは、延長したり、時間が足りなくなって急ぐよりも、フォローアップ セッションをスケジュールすることをお勧めします。
ビジネス セッションでは、方法に焦点を当てるのではなく、理由を理解する必要があります。
技術的なセッションでは、方法に焦点を当てている場合であっても、理由も忘れてはなりません。
セッションに参加する前に、すべてのアクションとオープンなトピックをキャプチャします。 ただし、ワークショップの最後に、実施項目についてまとめるために 5 分から 10 分必要です。
フォローアップ
ワークショップの実施後、ソリューション アーキテクトは調査結果とレコメンデーションを準備する必要があります。 この準備には時間がかかる場合があるため、フォローアップの話し合いをスケジュールする場合は、その前に十分な準備時間を確保する必要があります。 ミーティングの議事録および合意したフォローアップ アクションは、セッション後 24 時間以内に参加者および必要な関係者に送信します。 フォローアップ アクションには、担当者と期日を含めるようにします。 期日に合意しなかった場合は、TBD を使用します。 ミーティングの議事録では、問題やリスクを共有します。
ワークショップのステップ
ワークショップには、3 つの重要なステップが含まれます。
- 情報のキャプチャ
- ワークショップの実施
- レコメンデーションと調査結果の作成
プロジェクトのソリューション アーキテクト、またはプロジェクトの日々の業務を担当していない人が、ワークショップを実施できます。 プロジェクトに割り当てられていないソリューション アーキテクトを配置することの利点は、FastTrack プロジェクトを実行する場合と同様になります。 このアプローチにより、多くの場合、プロジェクト チームはプロジェクトの外部からの追加のインサイトを得ることができます。
情報のキャプチャ
すべてのプロジェクトにはいくつかのドキュメント レベルがありますが、ドキュメントのレベルと形式は、関係者、プロジェクトのスコープ、およびプロジェクトの方法によって異なります。 ソリューション テンプレートは、プロジェクトの成功基準に関連する情報を収集し、構造化された方法で文書化するように設計されています。 多くの場合、プロジェクト チームは既にこの情報を持っており、既存のプロジェクト ドキュメントからコピーすることができます。 ただし、これらの情報が複数の場所に存在していて、チームと共用したり共有したりできない状態にあるのは珍しいことではありません。 このステップの一部として、ソリューション アーキテクトはワークショップ テンプレートを顧客と共有し、ワークショップ予定日の少なくとも 5 日前に情報を記入して返送してもらうよう依頼することができます。 このステップにより、内容の確認に十分な時間を確保できます。
ヒント
情報のキャプチャは、関係者と密接に協力して行ってください。 テンプレートに情報を記入するにあたって必要な支援を行い、既にわかっている情報はあらかじめ記入しておくことができます。 場合によっては、完成されたドキュメントが関係者から共有されることもあります。この場合、内容を確認して関連情報のみを抽出するために、追加の時間が必要になることがあります。 交換される情報の質は、レコメンデーションの品質に影響し、他のワークショップの優先順位の設定につながります。
ワークショップの実施
ワークショップは、オンサイトで、またはオンライン会議を利用して実施できます。 通常、ワークショップをオンサイトとオンラインのどちらで行うかの決定は、プロジェクト、リスク、および顧客の規模の複雑さに基づきます。 この準備の一環として、ソリューション アーキテクトは完成したテンプレートを確認し、さらに詳しく説明するための追加の質問やコメントを準備しておく必要があります。
主要な関係者が参加を承認できるように、ワークショップをスケジュールしてください。 完成したテンプレートは、ワークショップの主要な成果物になります。
顧客またはプロジェクト固有のトピックや質問に合わせて、デッキを調整またはカスタマイズします。
ワークショップでは、各トピックを顧客と確認し、理解が共有されるようにします。
必要に応じて、質問を通じてさらに詳しく説明していきます。 各トピックのワークショップ テンプレートを確認したときにそれぞれのトピックについてキャプチャした質問を確認します。 この目的は、これらの質問を顧客と直接共有することではなく、ワークショップ中にこれらの質問を使用して会話を促し、関連トピックや成功評価基準に対するクライアントの準備状況を評価することです。
レコメンデーションと調査結果の作成
ソリューション アーキテクトがクライアント、プロジェクトのスコープ、ソリューションについて理解したら、従うべき適切な手順と展開パターンを特定できるようになります。 それによって、潜在的なリスク (スケーラビリティやパフォーマンスの問題など) が明らかになります。 調査結果は文書化し、リスクまたはレコメンデーションとして分類する必要があります。
リスク - 主要な統合について、適切なエラー テストを行う計画を立てないなどのフォローアップ アクションが必要です。 リスクは、ワークショップ中にレビューや話し合いを通じて検出されることもよくあります。
レコメンデーション - ソリューションの一貫性と信頼性を高め、プロジェクトを無事完了するために確認する必要がある領域が含まれます。 たとえば、複数の環境で統合をテストするための十分な構成が存在しないことがよくあります。 レコメンデーションが実践可能かつ明確であることを確認してください。