ソリューション ブループリントのレビューの準備

  • 10 分

通常、ソリューション ブループリントのレビューの実施には約 2 ～ 8 時間かかります。 この時間は、レビューに使用できる詳細レベルと、ソリューション全体の種類によって異なる場合があります。 ソリューション アーキテクトは、実装チームのリーダーと協力して、レビューするソリューションの詳細に基づいて計画します。

ソリューション ブループリントのレビュー ワークショップの前に、ワークショップの参加者は、ワークショップの構成や説明されるトピックの種類と前提条件に関して、できる限り精通しておく必要があります。 ソリューション アーキテクトは、ワークショップを実施する前に、トピックや前提条件についてのアジェンダを提供します。

注

ソリューション ブループリントのレビューは、基本的にはディスカッションです。オフライン モードで記入およびレビューできるアンケートは意図されていません。 前提条件を事前に定義して提供することはできますが、レビューで交わされるであろう会話の方向性を事前に示すことはできません。

ソリューション アーキテクトは、既存のプロジェクト成果物を確認して、ワークショップの準備を事前に行う必要があります。 次のプロジェクト成果物が役に立ちます。

  • プロセス カタログ – 実装のスコープに含まれるプロセス、サブプロセス、ユーザー ストーリーの一覧または階層。
  • プロセス フロー ダイアグラム – プロセス カタログにコンテキストを追加し、業務の工程を記載したダイアグラム。 ソリューション ブループリントのレビュー ステージでは、上位レベルのエンド ツール エンド プロセスが最も役立ちます。
  • アプリケーション ダイアグラム – ソリューションを構成する各種コンポーネントを示すブロック ダイアグラム。 これらのダイアグラムは、機能がアプリケーション コンポーネントにマップされる方法や、アプリケーション コンポーネントが互いにやり取りする方法に関連するコンテキストを示すこともできます。
  • ギャップ要件 – 標準システムによりサポートされていると見なされない既知の機能領域。
  • データ フロー ダイアグラム – 複数の Dynamics 365 アプリ、レガシまたは外部のサービスとコンポーネントを含むソリューションでは、データの生成元と、そのデータがどのようにソリューションに移動して消費されるかを識別できると役立ちます。
  • データ移行戦略 – 移行するエンティティ、エンティティのソース、量、タイミング、移行方法を示すドキュメントまたはレジスター。 ソリューション ブループリントのステージでは、スコープ (テーブルとソース) を確実に設定することが重要です。
  • インターフェイス レジスター – 非機能要件を持つインターフェイスの一覧と、それらのインターフェイスを実装するためのスコープおよびアプローチを文書化するデザイン パターン。
  • 分析データ集計デザイン – 分析の集計のために移行するデータ ソースのダイアグラムまたはレジスター。
  • 環境戦略 – プロビジョニングする環境のタイプ、それらの環境をいつどのように使用するか、コードと構成が環境をどのように流れるかについて説明するブロック ダイアログラムまたはフロー ダイアログラム。
  • システム使用状況プロファイル – 運用プロセス スケジュールとワークロード タイプ別ピーク トランザクション量。
  • 法人構造 – ソリューションでモデリングされる法人とそのリレーションシップを示すダイアグラムまたはレジスター。
  • 展開場所 – 言語やローカライズ要件と共にソリューションを展開する物理的な場所を示すダイアグラムまたはレジスター。
  • プロジェクト チャーター – プロジェクトのバックグラウンドと、目的、期待される重要な結果、関係者、予算、タイムライン、マイルストーンを提供するドキュメント。
  • プロジェクトの計画/スケジュール – 主要なプロジェクト フェーズと関連する活動の全体的なスケジュールおよび依存関係を表すドキュメントまたはガント チャート。
  • 責任割り当てマトリックス – タスクとそれらのタスクに対するプロジェクト ロールのリレーションシップのテーブル。 通常、これらのリレーションシップは、RACI、つまり Responsible (実行責任者)、Accountable (説明責任者)、Consulted (協業先)、Informed (報告先) の分類を通じて割り当てられます。
  • テスト計画/戦略 – 実装全体で行われるテストのタイプと、テストの定義、実装、測定方法について説明するドキュメント。

このリストは、プロジェクトの成果物を完全に網羅したものではありませんが、ソリューション ブループリントのレビューを開始する際の参考になります。 各成果物の形式、合成、および名前は、プロジェクトによって異なる場合があります。 形式などはそれほど重要ではありません。重要なのはチーム全体でアクセスでき同意している情報です。

プロジェクトの初期にソリューション ブループリントのレビューを実施する場合、これらのドキュメントの多くは完成されませんが、ほとんどの場合それでも問題ありません。 スコープを決定することと、そのスコープをソリューションでサポートする方法を決める概念計画を用意することの方が重要です。 計画がうまくいかなかった場合、導入を支援するコンサルティング パートナーが提供する作業明細書で、ある程度これらの項目を説明する必要があります。 スコープと概念的なソリューション アプローチが用意されている場合、ソリューション ブループリントのレビューでは概念的なアプローチに焦点を当て、その後の詳細なワークショップにおける詳細が判明した時点でその詳細に焦点を当てることができます。

プロジェクトで過去にリストしたものとは異なる方法を使用して、プロジェクト情報を管理または追跡しても問題ありません。 通常、プロジェクト メンバーが情報をいつでも入手できるのであれば、形式はそれほど重要ではありません。 過去にリストした情報がプロジェクトでドキュメント化されていない場合、または簡単にアクセスできない方法でドキュメント化されている場合は、関連する成果物を生成することを優先して行う必要があります。

レビューを実施する際は、可能な限り図や視覚情報を使用して、高レベルの概要を示すことをお勧めします。 これらの図、チャート、およびグラフは、チーム全体や役員と計画やデザインについてコミュニケーションを図る際のツールとして使用することができます。

注

ソリューション ブループリントのレビューは、詳細な要件や設計ドキュメントを完全に網羅するレビューとなることは意図されていません。 実装チームが下位レベルの詳細を扱い、全体的なアーキテクチャを生成およびプレゼンテーションします。 前提条件は、実装チームが主要な懸念事項を提示し、アーキテクトが問題の可能性がある領域を調べることです。 ソリューション アーキテクトが、追加の評価が必要な領域を調査するための詳細なワークショップを提案します。