【解説】
このシナリオでは、「新しい複雑な統合の構築」と「レガシーシステム自体のアップグレード」という、互いに影響し合う2つの大きなプロジェクトが並行して進んでいます。アーキテクトとして最も警戒すべきは、これらのプロジェクト間の相互依存性です。

D. 依存関係のある複数の作業ストリーム (正解)

理由: 一方のシステム（レガシー側）で仕様変更や開発の遅延が発生すると、それに依存しているもう一方（Salesforce側との統合開発）も連鎖的に影響を受けます。特に「複雑な統合」かつ「どちらも開発中」という状況では、インターフェースの仕様が固まらないまま進むことになり、最終的な結合テストで致命的な問題が発覚するリスクが極めて高いです。取締役会への「予定通りの完了」という約束は、こうした不確実性によって守れなくなる可能性が高い（クリティカルパスの崩壊）と判断します。

【不正解の理由】
A. 期限は Salesforce リリース中にスケジュールされています。

理由: Salesforce の季節リリース（年3回）との重複は確かに管理すべきリスクですが、リリース日を把握していれば調整可能です。システム間の相互依存によるリスクに比べれば、特定・管理が容易な部類に入ります。

B. プロジェクト チームはウォーターフォール手法を使用することを決定しました。

理由: ウォーターフォール自体がリスクというわけではありません。要件が明確な大規模統合では、むしろウォーターフォールの方が制御しやすい場合もあります。

C. レガシー システム チームはアジャイル手法を使用しています。

理由: 開発手法の不一致（一方がアジャイル、他方がウォーターフォールなど）もリスクになりますが、選択肢Dのような「作業ストリーム間の依存関係が稼働そのものを脅かす」という包括的なリスクに比べると、範囲が限定的です。

【対象セクション】
Planning (計画) - 13% Application Lifecycle Management (ALM) - 8%

プロジェクトのリスク特定、ガバナンス、および複雑なシステム連携（マルチストリーム）における計画策定能力が問われます。

【合格のための応用ポイント】
試験で「複数のプロジェクトが同時進行」「他システムとの連携」「厳しい期限」といったキーワードが出た場合、アーキテクトとしての思考回路は以下のように働かせてください。

影響分析 (Impact Analysis):

「片方が遅れたら、もう片方にどう影響する...