ITパスポート 2026年 問52
問題文
業務システムの開発において、開発者がシステム要件定義を実施する場合、利用者の関わり方として、最も適切なものはどれか。
選択肢
ア:開発者が行うシステム要件のレビューに参加し、妥当性を確認する。(正解)
イ:開発者に全て任せ、その決定に従う。
ウ:システムの保守が可能かどうかを見極める。
エ:システム要件の技術的な実現性を検証する。
🔒 解説は解答すると表示されます
業務システムの開発での利用者の関わり方【ITパスポート 解説】
正解の理由
システム要件定義(システムが満たすべき業務上の条件や機能を整理する作業)を開発者が行う場合、利用者は作成された要件の「妥当性」を確認する役割を担うのが最も適切です。つまり、利用者は業務の専門家として「これで業務が正しく行えるか」「抜けや誤りはないか」をチェックします。選択肢の中では、利用者が要件レビューに参加して妥当性を確認する ア がこれに当たります。
ポイント:
- 利用者は業務の内容・ルールの専門家。業務視点で要件の正しさを判断する必要があります。
- 技術的な判断(実現可能性や保守性の評価)は主に開発者側の業務です。利用者がすべて任せるのも、逆に技術評価を行うのも適切ではありません。
解法ステップ
- 問題文の主語と役割を確認する。ここでは「開発者が要件定義を実施する」状況。
- 「利用者」が担うべき責務を考える。業務知識を持つ立場であり、業務要件の正しさを保証する役目。
- 選択肢を業務寄り(妥当性確認)か技術寄り(実現性・保守性判断)かに分類する。
- 業務寄りの選択肢が正答候補となる。該当するのが ア。
この流れで、「誰が何を判断するべきか」を基準に選べば迷いません。
選択肢別の誤答解説
-
ア: 開発者が行うシステム要件のレビューに参加し、妥当性を確認する。
- 正答です。利用者は業務の正確性や抜け漏れをチェックする役割が適切です。
-
イ: 開発者に全て任せ、その決定に従う。
- 誤りです。利用者が全く関与しないと業務要件の誤りや運用上の問題が見落とされます。要件が業務に合っていないと現場で使えないシステムになります。
-
ウ: システムの保守が可能かどうかを見極める。
- 誤りです。保守性(後で修正や運用しやすいかどうか)の評価は技術的な判断で、主に開発者や運用側の担当分野です。利用者が直接判断する役割ではありません。
-
エ: システム要件の技術的な実現性を検証する。
- 誤りです。技術的実現性の検証は開発者の専門領域です。利用者は業務要件の妥当性確認を行い、技術的な詳細は開発者に相談します。
よくある誤解
-
利用者は「口を出すだけ」でよい
- 実際は、要件定義では利用者の積極的な参加(具体的な業務手順や例の提示)が重要です。単に最終承認だけする、では不十分です。
-
技術的な評価も利用者の仕事だと思う
- 利用者は業務の正しさを判断します。技術的な実現性や保守性の検証は開発者の専門分野で、両者で協力して進めるのが正しいやり方です。
補足コラム
要件定義時の役割分担を明確にするために、RACI(レーシー)という考え方がよく使われます。RACIは次の4つの頭文字です。
- Responsible(実行する人)
- Accountable(最終責任者)
- Consulted(相談を受ける人)
- Informed(報告を受ける人)
要件定義では、開発者が「Responsible」となり、利用者は「Consulted」でかつ「Accountable(業務側の承認責任者)」になることが多いです。これにより、誰がどの判断をするかが明確になり、ミスや手戻りを減らせます。
また、要件レビューに臨む利用者向けの簡単チェックリスト例:
- この要件で業務が正しく遂行できるか?(想定事例で確認)
- 抜けている業務や例外はないか?
- 業務ルールや法令に矛盾していないか?
- 実際の画面や帳票の操作イメージはあるか?
FAQ
Q1: 利用者にITの知識がなくてもレビューできますか?
A1: はい。利用者は業務の専門家なので、業務の流れや要件の正しさをチェックできます。技術的な不明点は開発者が説明すれば良いです。
A1: はい。利用者は業務の専門家なので、業務の流れや要件の正しさをチェックできます。技術的な不明点は開発者が説明すれば良いです。
Q2: もし利用者と開発者で意見が対立したら?
A2: 対立が起きたら、業務の目的と現場の運用を基準に議論します。必要ならPoC(概念実証)や試作で確認する方法も有効です。
A2: 対立が起きたら、業務の目的と現場の運用を基準に議論します。必要ならPoC(概念実証)や試作で確認する方法も有効です。
Q3: 要件レビューは誰が主導するべきですか?
A3: 開発者がレビューの進行・技術的説明を行い、利用者が業務観点の判断を行う共同作業が望ましいです。進行は開発側が担当することが多いです。
A3: 開発者がレビューの進行・技術的説明を行い、利用者が業務観点の判断を行う共同作業が望ましいです。進行は開発側が担当することが多いです。
関連キーワード: 要件定義、レビュー、利用者参加、業務要件、保守性、技術的実現性、RACI、要件レビュー、関係者調整

\ せっかくなら /
ITパスポートを
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

