説明
リスク管理は、アーキテクチャ開発手法 (ADM) のすべてのフェーズ、および準備フェーズと要件管理フェーズ2 に適用できる一般的な手法です。リスク管理には、次の手順が含まれます1。
*リスクの特定: このステップでは、技術、ビジネス、組織、環境、法務などのリスクなど、アーキテクチャ プロジェクトに影響を及ぼす可能性のある潜在的なリスクを特定します。リスクは、関係者へのインタビュー、ワークショップ、調査、チェックリスト、履歴データ、専門家の判断など、さまざまなソースを通じて特定できます。
*リスク分類: このステップでは、リスクの性質、発生源、影響、優先度に基づいてリスクを分類します。リスクは、時間、コスト、範囲、品質、セキュリティ、コンプライアンスなど、さまざまな基準に従って分類できます。分類は、リスクの優先順位付けと、リスクに効果的に対処するリソースと労力の割り当てに役立ちます。
*初期リスク評価: このステップでは、各リスクの可能性と影響を評価し、リスクの初期レベルを決定します。可能性はリスクが発生する確率であり、影響はリスクが発生した場合の結果の重大性です。リスクの初期レベルは、可能性と影響の積であり、リスクの緊急性と重要性を示します。初期リスク評価は、すぐに対応して軽減する必要がある最も重要なリスクを特定するのに役立ちます。
参考資料: 1: TOGAF 標準、バージョン 9.2 - リスク管理 2: TOGAF ADM: トップ 10 テクニック - パート 9: リスク管理

最適な答えは C です。ビジネス シナリオ手法を使用して、各製造工場で一連のインタビューを実施します。これにより、システムと現地パートナーとの統合について理解できます。ステークホルダー分析を使用して、エンゲージメントの主要プレーヤーを特定し、彼らの懸念を理解します。次に、アーキテクチャに対する主要なステークホルダーの高レベルの要件を特定して文書化します。次に、ベースライン アーキテクチャとターゲット アーキテクチャの高レベルの定義を生成します。
この回答は、アーキテクチャ プロジェクトを開始するために次の手順を推奨する TOGAF 標準に基づいています1。
建築プロジェクトの確立
利害関係者、懸念事項、ビジネス要件を特定する
ビジネス目標、ビジネス推進要因、制約を確認して詳しく説明する ビジネス機能を評価 事業変革の準備状況を評価する スコープを定義する 事業原則を含むアーキテクチャ原則を確認して詳しく説明する アーキテクチャ ビジョンを開発する ターゲット アーキテクチャの価値提案と KPI を定義する ビジネス変革のリスクと緩和活動を特定する 利害関係者とスポンサーの承認を確保する 回答 C は、ビジネス シナリオ手法を使用して、ビジネス要件、目標、推進要因、制約、およびアーキテクチャの現在の状態と将来の状態を引き出し、検証することで、これらのステップのほとんどをカバーしています2。 また、回答 C では、利害関係者分析を使用して主要な利害関係者を特定して関与させ、彼らの懸念と期待に対処します3。 また、回答 C では、ベースライン アーキテクチャとターゲット アーキテクチャの高レベルの定義も生成され、これを使用してアーキテクチャ ビジョンと価値提案を開発できます4。
他の回答は、次の理由により、アーキテクチャ開発に最適なアプローチではありません。
回答 A は、ベンダーの資料の調査とベンダーとのブリーフィングに重点を置いていますが、これは企業のビジネス ニーズと現状を理解するための最善の方法ではありません。また、回答 A では、関係者を関与させたり要件を検証したりせずに、予備的なアーキテクチャ ビジョンを定義しているため、不一致や合意の欠如につながる可能性があります。
回答 B は、ベンダーが潜在的なソリューションを実証できるようにするパイロット プロジェクトを実施しますが、アーキテクチャ プロジェクトのこの段階では時期尚早でコストがかかります。回答 B では、利害関係者の懸念や現在のシステムと統合にも対処していないため、ギャップやリスクが生じる可能性があります。また、回答 B では、パイロット プロジェクト後に要件が作成されますが、実際のビジネス ニーズと目標が反映されない可能性があります。
回答 D では、各製造工場のベースライン アーキテクチャとターゲット アーキテクチャが開発されていますが、企業全体の視点や共通 ERP システムの潜在的な利点が考慮されていない可能性があります。また、回答 D では、利害関係者を関与させたり、利害関係者の懸念に対処したりしていないため、抵抗や対立が生じる可能性があります。また、回答 D では、アーキテクチャの価値と実現可能性を示すために不可欠なビジネス ケースやパフォーマンス メトリックも定義されていません。

表示されているチャートはガントチャートです。これはプロジェクト管理でプロジェクトスケジュールを示すためによく使用されます。エンタープライズアーキテクチャのフレームワークである TOGAF (The Open Group ArchitectureFramework) のコンテキストでは、このガントチャートはアーキテクチャ開発手法 (ADM) への順序付けられたアプローチを示しています。ADM は、アーキテクチャを開発するためのテスト済みの繰り返し可能なプロセスを提供する TOGAF のコアプロセスです。ADM は、プロセス全体、フェーズ間、フェーズ内で反復的であると説明されています。ADM の各反復では、各パラメータ (範囲、粒度、期間、およびアーキテクチャ資産) について新たな決定を行う必要があります。
ADM は、順番に実行する必要があるいくつかのフェーズで構成されています。
予備段階: 枠組みと原則
フェーズA: アーキテクチャビジョン
フェーズ B: ビジネスアーキテクチャ
フェーズ C: データおよびアプリケーション アーキテクチャを含む情報システム アーキテクチャ、フェーズ D: テクノロジ アーキテクチャ、フェーズ E: 機会とソリューション、フェーズ F: 移行計画、フェーズ G: 実装ガバナンス、フェーズ H: アーキテクチャ変更管理、要件管理。各フェーズは前のフェーズの出力に依存しており、要件管理フェーズはフェーズ全体にわたって実行されます。ガント チャートには、これらのフェーズが発生する依存関係と順序が明確に示されており、構造化されたアプローチに従ってエンタープライズ アーキテクチャが作成されていることが示されています。
参考文献:
TOGAF 標準バージョン 9.2、The Open Group の標準
TOGAF ドキュメントは https://publications.opengroup.org/standards/architecture および https://publications.opengroup.org/guides/architecture で入手できます。

ビジネス価値評価手法は、アーキテクチャ作業パッケージを実装するプロジェクトおよびプロジェクト増分のビジネス価値を推定および比較するために使用できる手法です。アーキテクチャ作業パッケージは、アーキテクチャの特定の部分を実装するために必要な一連のアクションまたはタスクです。ビジネス価値とは、収益の増加、コストの削減、品質の向上、顧客満足度の向上など、プロジェクトまたはプロジェクト増分によってビジネスにもたらされるメリットまたは利点の尺度です。ビジネス価値評価手法を適用する手順は次のとおりです。
* コスト、メリット、リスク、機会など、ビジネス価値評価に関連する基準と要因を特定します。基準と要因は、アーキテクチャ作業の動機となるビジネス目標と推進要因、およびアーキテクチャ作業に影響を与える利害関係者の要件と懸念事項と一致している必要があります。
* 専門家の判断、履歴データ、分析モデルなどのさまざまな方法を使用して、基準と要因に重みとスコアを割り当てます。重みとスコアは、基準と要因の重要性とパフォーマンス、および利害関係者のトレードオフと好みを反映する必要があります。
* 正味現在価値、投資収益率、バランスト スコアカードなどのさまざまな手法を使用して、各プロジェクトまたはプロジェクト増分のビジネス価値を計算します。ビジネス価値は、プロジェクトまたはプロジェクト増分がビジネスに与える期待されるまたは実際の成果と影響を示す必要があります。
* ビジネス価値と、依存関係、リソース、リスクなどのその他の考慮事項に基づいて、実装プロジェクトとプロジェクト増分の優先順位を決定します。優先順位付けによって、プロジェクトとプロジェクト増分の順序やシーケンス、およびリソースの割り当てと使用率が決定されます。
したがって、最適な答えは C です。これは、ベースライン アーキテクチャからターゲット アーキテクチャへの移行をサポートするアクティビティである、移行計画の次のステップを説明しているからです。この答えは、シナリオに関連するビジネス価値評価手法をカバーしています。
参考文献: 1: TOGAF 標準、バージョン 9.2、パート III: ADM ガイドラインとテクニック、第 28 章:
ビジネス価値評価手法 : TOGAF 標準、バージョン 9.2、パート II: アーキテクチャ開発手法 (ADM)、第 18 章: フェーズ A: アーキテクチャビジョン : TOGAF 標準、バージョン
9.2、パート II: アーキテクチャ開発手法 (ADM)、第 21 章: フェーズ F: 移行計画 : TOGAF 標準、バージョン 9.2、パート IV: アーキテクチャ コンテンツ フレームワーク、第 36 章: ビルディング ブロック

説明
ビジネス シナリオは、システムの機能要件と非機能要件を捕捉、明確化、伝達するための手法です。ビジネス シナリオでは、ビジネス環境、関係するアクター、望ましい結果、システムの動作を管理するプロセスまたはルールについて説明します。ビジネス シナリオは、アーキテクチャが利害関係者の真のニーズと懸念に対応していることを確認したり、予想される状況に対してアーキテクチャを検証およびテストしたりするのに役立ちます。ビジネス シナリオは、ADM サイクルのフェーズ A: アーキテクチャ ビジョンで開発され、他のフェーズを通じて改良および更新されます3 参考文献: 3: TOGAF 標準、バージョン 9.2、パート III: ADM ガイドラインとテクニック、第 26 章: ビジネス シナリオ : TOGAF 標準、バージョン 9.2、パート II: アーキテクチャ開発方法 (ADM)、第 18 章: フェーズ A: アーキテクチャ ビジョン