ITパスポート 2015年 秋期 問25

業務要件の定義で必ず合意を得ておくべき関係者【ITパスポート 解説】

正解の理由

解法ステップ

1. 「業務要件」の定義を確認する
   • 業務要件 = 業務上必要な機能・ルール・条件（例：この業務をどう短縮するか、誰がどの情報を扱うか）
2. 誰が業務を最終的に決めるかを考える
   • 実務を使う部署（利用部門）が最終的な業務オーナーであることが多い
3. 選択肢を当てはめて検討する
   • 現行システム関係者や保守ベンダは参考情報を提供する立場
   • 開発ベンダは実現の「受注・実装」側で、要件決定の最終責任者ではない
4. 最終的に合意を得るべきは利用部門の責任者と結論づける

選択肢別の誤答解説

• ア: 現行システム開発時のプロジェクトの責任者
  • 現行システムの責任者は過去の経緯や技術的情報を教えてくれますが、新しい業務要件を最終決定する権限は必ずしも持ちません。参考意見として重要ですが「必ず合意を得るべき相手」ではありません。
• イ: 現行システムの保守ベンダの責任者
  • 保守ベンダ（運用や障害対応を行う業者）は現行運用の知見がありますが、業務方針や機能要件を決める立場ではありません。技術的制約の確認などで協議は必要ですが、最終承認者ではありません。
• ウ: 新システムの開発ベンダの責任者
  • 開発ベンダは設計・実装の責任者で、要件の実現可能性やコストを提示します。合意は「実現方法」や「見積り」については重要ですが、業務上の必要性そのものを承認するのは利用部門です。
• エ: 新システムの利用部門の責任者
  • 利用部門は業務の目的と成果に責任を持ちます。業務要件が業務プロセスや組織ルールに直接影響するため、ここに必ず合意を取る必要があります（これが正解）。

よくある誤解

1. 「開発ベンダが合意すれば良い」と考える誤解
   • 開発ベンダは実装責任を持ちますが、業務の何を実現するかを決めるのは利用部門です。ベンダ合意は技術的合意であり、業務上の承認ではありません。
2. 「現行システムの責任者＝新システムの決定権者」と考える誤解
   • 現行システムの担当が新システムでも同じ権限を持つとは限りません。組織変更や業務見直しで利用部門の責任者が決定権を持つケースが多いです。

補足コラム

• 合意（サインオフ）を得る文書：要件定義書（業務要件書）。署名またはメール承認で記録を残すことが重要です。
• ステークホルダー整理：RACI（役割分担表）を作ると便利です。RACIは Responsible（実行）、Accountable（最終責任）、Consulted（相談される）、Informed（報告を受ける）の頭文字です。利用部門の責任者は通常「Accountable（最終責任）」に置きます。
• 実務例：要件合意前に利用部門で承認者を一人に指定しておくと、意見の集約と責任の明確化が早くなります。

• 利用部門責任者：Accountable（最終承認）
• 業務担当者（現場）：Consulted（意見提供）
• 開発ベンダ：Consulted（実現可否・見積り）
• 保守ベンダ：Informed（運用影響確認）

FAQ