回答.

問題の歴史:

従来のプロジェクトでは、アナリストとアーキテクト、またシステムアナリストとビジネスアナリストの間でしばしば対立が生じていました。各自が「責任を奪おう」や「責任を他に任せよう」としていました。明確な責任範囲の定義は、成熟したチームの特徴の一つです。

問題:

作業の重複と交差の危険性があり、これが誤解、責任の喪失、遅延を引き起こし、場合によっては同じシステムの一部に関する矛盾した作業を行うことにつながります。

解決策:

• 各役割のためにアーティファクトと最終製品を定義します（例：ビジネスアナリストはビジネス目標に責任を持ち、システムアナリストは機能仕様に責任を持ち、アーキテクトはアーキテクチャ的決定に責任を持ちます）
• プロジェクトの開始時に、ワークショップ/会議を開催し、責任範囲を明確にし、規制文書（例えばRACIマトリックス）を合意します
• プロジェクトの進行と文脈の変化に応じて、定期的に責任範囲を議論し、修正することが重要です

重要な特徴:

• 役割と責任の透明な分配
• アーティファクトとそれらの間の入出力ポイントの明確な定義
• タスク間の継続的なコミュニケーションとコンタクトの管理

陷し穴のある質問。

システムアナリストはシステム全体のアーキテクチャ設計に関与するべきでしょうか？

いいえ、アーキテクトがアーキテクチャ的決定に責任を持っています。アナリストはアーキテクトが使用できる要件を明確にしますが、アーキテクチャ全体を設計することはありません。

ビジネスアナリストが直接技術的制約を記述することはできますか？

通常はできません — ビジネスアナリストはビジネス要件を形成します。技術的制約はシステムアナリストまたはアーキテクトの領域です。

ビジネスアナリストからタスクの説明を受け取った場合、システムアナリストはビジネスとの会議を重複させる必要がありますか？

いいえ、しかしシステムアナリストはすべてを正しく理解していることを確認し、誤解があれば質問を始める必要があります。

一般的なエラーとアンチパターン

• 責任範囲の「デフォルト」での転送
• 最終製品（アーティファクト）の不明確な説明
• 役割間の定期的なコミュニケーションの欠如による対立

実生活からの例

ネガティブなケース:

二つのチームが同じシステムの一部を平行して開発していました。アナリストは擬似的なアーキテクチャを書き、アーキテクトはビジネスプロセスを記述しました。その結果、仕様が食い違い、実装が遅れました。

プラス:

• 作業を迅速化しようとした試み

マイナス:

• 重複、文書の不一致、期限の喪失

ポジティブなケース:

開始時に行った共同ワークショップで、誰が何に責任を持つかを合意し、境界と接続を文書化しました。その後の各ステージでもこれらの合意の見直しを行いました。

プラス:

• 明確な作業、対立の不在、迅速な作業の完了

マイナス:

• スタート時にコミュニケーションが多く必要ですが、リスクを最小限に抑えることができました。